Re: [csmith-dev] Strict Aliasing and Csmith

[Alex Coplan <alex.coplan@arm.com>]

Hi John,

On 17/09/2020 10:52, John Regehr wrote:
> Hi Alex, I believe Csmith is intended to respect the strict aliasing
> constraints, but since we never had a checker for finding violations of
> these constraints, it seems highly possible that we messed this up. If you
> give us instructions for reproducing a problem, we can look into it more.
> 
> John
> 

Thanks for your reply, and apologies for the delay on my end.

Using csmith 2.3.0 on x86-64 Linux with the seed 3940736818, I observed
a difference in the runtime behaviour of the resulting program between
-O0 and -O2 using current (trunk) AArch64 GCC. The discrepancy went away
upon adding -fno-strict-aliasing.

Of course, this doesn't necessarily mean that the input program is to
blame. I found a similar case where -fno-strict-aliasing "fixed" the
issue which turned out to be a wrong code bug (the code did not violate
the strict aliasing constraints):
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97135

However, in this case, I believe Csmith may have generated code which
violates the strict aliasing constraints. The program generated with
seed 3940736818 can be reduced to the following:

int printf(char *, ...);
union {
  char a;
  int b;
  short c;
} d;
short *e = &d.c;
int f;
short g;
int main(void) {
  int *h = &d.b;
  g = *h = 1;
  *e |= f;
  printf("%X\n", d.a);
}

The issue here is that e and h alias and have different incompatible
types. I believe the program would be fine (w.r.t. the strict aliasing
constraints) if we accessed the union members directly, or if the union
type was visible in the pointers, but this is not the case.

Now it's possible that this is a bad reduction from the original
program, but from a brief inspection of the code generated by csmith, it
looks like the program takes the addresses of these different union
members and makes accesses through these pointers of different
incompatible types.

For a related testcase, with seed 10245076650401779801, I see similar runtime
discrepancies that disappear with -fno-strict-aliasing. The program can be
reduced to the following testcase:

int printf(char *, ...);
int a, b = -4L;
union {
  int c;
  long d;
} e;
int *f = &e.c;
long *g = &e.d;
int main(void) {
  *g = 3895278040;
  int h = b ^= *f;
  if (h >= 7)
    printf("%X\n", a);
}

Looking forward to hearing your thoughts on this issue.

Thanks,
Alex