Bug 65679 - Too strict alias analysis?
Summary: Too strict alias analysis?
Status: RESOLVED DUPLICATE of bug 61502
Alias: None
Product: gcc
Classification: Unclassified
Component: c (show other bugs)
Version: 4.9.2
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Depends on:
Reported: 2015-04-06 18:22 UTC by Robbert
Modified: 2024-01-25 23:16 UTC (History)
2 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed:


Note You need to log in before you can comment on or make changes to this bug.
Description Robbert 2015-04-06 18:22:59 UTC
Consider the following example:


  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

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