[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: unassig...@gcc.gnu.org

        ReportedBy: g...@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).