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: [email protected]
ReportedBy: [email protected]
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).
