Bug 65679

Summary: Too strict alias analysis?
Product: gcc Reporter: Robbert <gcc>
Component: cAssignee: Not yet assigned to anyone <unassigned>
Status: RESOLVED DUPLICATE    
Severity: normal CC: harald
Priority: P3    
Version: 4.9.2   
Target Milestone: ---   
Host: Target:
Build: Known to work:
Known to fail: Last reconfirmed:

Description Robbert 2015-04-06 18:22:59 UTC
Consider the following example:

  #include<stdio.h>
  #include<stdint.h>

  int main() {
    int x = 1, y = 2, *p = &y, *q = &x + 1;
    if ((intptr_t)p == (intptr_t)q) {
      *q = 10;
      printf("%d %d %d\n", x, y, p == q);
    }
  }

When compiled with "gcc -pedantic -std=c99 -O2" (and even with -fno-strict-aliasing added), the compiled program prints:

  1 2 0

So, despite the fact that is has been "observed" that p and q have identical representations, they are still not being treated as equal.

Is this intended?
Comment 1 Harald van Dijk 2015-04-07 06:58:13 UTC
There are two separate issues here: the assignment, and the comparison.

Assignment to *q (*(&x + 1)) is not allowed, that's still assignment past the end of an object, even if there happens to be a valid object immediately following it in memory. Two pointers comparing as equal does not make them equivalent. There's no bug there.

The comparison p == q (&y == &x + 1) gets optimised to 0, and that part is questionable: it may or may not technically be allowed here, but regardless, this optimisation also causes valid code to get miscompiled. That's bug 61502.
Comment 2 Richard Biener 2015-04-07 08:45:10 UTC
dup.

*** This bug has been marked as a duplicate of bug 61502 ***