[llvm-bugs] [Bug 39846] New: Interaction between C's restrict pointer and pointer casted from integer is ambiguous in LLVM's LangRef

via llvm-bugs llvm-bugs at lists.llvm.org
Thu Nov 29 22:27:12 PST 2018


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

            Bug ID: 39846
           Summary: Interaction between C's restrict pointer and pointer
                    casted from integer is ambiguous in LLVM's LangRef
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
          Assignee: unassignedbugs at nondot.org
          Reporter: juneyoung.lee at sf.snu.ac.kr
                CC: llvm-bugs at lists.llvm.org

Created attachment 21180
  --> https://bugs.llvm.org/attachment.cgi?id=21180&action=edit
The example code

Consider this example:

#include <stdint.h>

int foo(int *restrict x, int *restrict y) {
  *y = 23;
  uintptr_t xi = (uintptr_t)x;
  uintptr_t yi = (uintptr_t)y;
  if (xi != yi) { // xi == yi, so this is never taken
    yi = xi;
  }
  *(int*)yi = 42; // changes *y or UB?
  return *y;
}

int bar() {
  int x;
  return foo(&x, &x); // returns 23
}

After -O3, foo(&x, &x) is optimized into 'ret i32 23' (
https://godbolt.org/z/ty73Xk ).


Here are several ways to explain this result:

(1) foo(&x, &x) is not allowed in LLVM IR - but I believe this makes the
semantics more undefined than C (because C allows multiple restrict pointers to
point have the same address if they are only read, but never written)

(2) *(int*)yi = 42 is not allowed - but LLVM IR LangRef's pointer aliasing
rules ( https://llvm.org/docs/LangRef.html#pointer-aliasing-rules ) say that
(int *)yi is based on y, so I think this behavior is well-defined. Perhaps we
should update the definition of based-on relation, if we follow this option.

(3) Restrict pointer cannot be casted into integer - if we choose this option,
LangRef should be updated to deal with this.

If we're to choose (2) and (3), we should update LLVM LangRef.

If this is considered to be miscompilation, I think this is related to 
https://bugs.llvm.org/show_bug.cgi?id=34548 .

-- 
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/20181130/4f82fa2e/attachment-0001.html>


More information about the llvm-bugs mailing list