| Summary: | Too strict alias analysis? | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Robbert <gcc> |
| Component: | c | Assignee: | 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: | ||
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. |
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?