[Bug c/54945] New: Too strong non-aliasing analysis?

[gcc at robbertkrebbers dot nl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54945

             Bug #: 54945
           Summary: Too strong non-aliasing analysis?
    Classification: Unclassified
           Product: gcc
           Version: 4.7.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: gcc@robbertkrebbers.nl


Consider the following C program:

#include<inttypes.h>
#include<stdio.h>

int main(void) {
  int x=30, y=31;
  int *p = &x+1, *q=&y;
  intptr_t i=(intptr_t)p, j=(intptr_t)q;
  printf("%" PRIdPTR " %" PRIdPTR " %d\n", i, j, i==j);
}

gcc (4.7.1, with -Wall -O2 -std=c99) compiles this program, without giving any
compilation errors or warnings, and print something like

  140734157513308 140734157513308 0

when ran on a Debian amd64 machine.

Here, gcc allocates the storage of x and y adjacently (which is perfectly
fine). Therefore, the pointers &x+1 and &y point to the same storage, and thus
when converting these pointers to integers, it yields the same integers. But,
apparently, gcc's aliasing analysis optimizes the comparison i==j to 0, as it
believes that i and j are "unrelated".

I am unsure whether optimizations as the above are valid with respect to the
C11 or C99 standard. On the hand hand, it seems pretty strange that an integer
comparison of equal integers yield 0. On the other hand, the infamous Defect
report #260

  http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_260.htm

states something like

  If two objects have identical bit-pattern
  representations and their types are the
  same they may still compare as unequal

in the committee's response. But I do not see if their notion of "origin" or
"provenance" applies to integers obtained via a cast from a pointer as well.

So, is this a bug (i.e. gcc performs optimizations it should not), or is there
some dark corner in the C standard allowing this? 

I do not believe there is any undefined behavior here. The only thing that
might be considered "strange" is creating the pointer &x+1. But as long as it
is not dereferenced, that is perfectly fine by the C standard (6.5.6p8).