[llvm-bugs] [Bug 35229] New: GVN must not perform substitution based on pointer equality

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=35229

            Bug ID: 35229
           Summary: GVN must not perform substitution based on pointer
                    equality
           Product: libraries
           Version: 5.0
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: post+llvm at ralfj.de
                CC: llvm-bugs at lists.llvm.org

Clang/LLVM currently miscompiles the following program:

// gvnbug.c
#include <stdio.h>

int foo();

void test(int* gp1, int* gp2)
{
  int g = 0;
  int a = 0, b = 0;
  int x = 7777, y = 6666; // also try swapping these
  int* p = &g;
  int* q = &g;
  int* r = &g;

  if (foo()) {
    a = 1;
    p = &y+1;
    q = &x;
  }

  *gp1 = (int)p+1;
  if (q == p) {
    b = 1;
    *gp2 = (int)q+1;
    r = q;
  }
  *r = 42;

  printf("a = %d, b = %d, x = %d\n", a, b, x);
}

int main() {
  int gp1 = 0;
  int gp2 = 0;

  test(&gp1, &gp2);

  return 0;
}

// aux.c
int foo() { return 1; }

$ clang-5.0 aux.c gvnbug.c -o gvnbug -O3 && ./gvnbug 
a = 1, b = 1, x = 7777

This result is not allowed.  If a and b are both 1, the branch "q == p" must
have been taken, so r was set to &x (via q), so x cannot be 7777.

I think this issue has already come up in
<https://bugs.llvm.org/show_bug.cgi?id=34548>, but so far there was no example
showing that the bug arises independent of the incorrect
inttoptr-simplification.

What is happening here (if my analysis is correct) is that GVN sees the
equality "q == p" and uses that to replace "q" by "p" in the then-branch. 
Next, LLVM notices that because p is derived from y, writing to r (which will
either have value &g or p in the line where the assignment happens) cannot
possibly affect x, and hence the initial value of x can be propagated into the
printf.  GVN is wrong to perform this kind of replacement; just because the bit
representations of two pointers are equal, that doesn't mean that their
provenance information is equal.

Test case by Gil Hur.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20171107/d68643aa/attachment.html>