[llvm-bugs] [Bug 35238] New: Unexpected result because of undefined behavior. (GNV pass)

[via llvm-bugs]

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

            Bug ID: 35238
           Summary: Unexpected result because of undefined behavior. (GNV
                    pass)
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: pichet2000 at gmail.com
                CC: llvm-bugs at lists.llvm.org

Lately I resynced an out of tree target and we found a regression in our test
suite
The same problem happen using x86 on Windows or MacOS

#include "stdio.h"

int func(short *data,int data_size)  {
  short pattern[] = {0,1,2,3};
  short d[4]={1, 2, 3, 4};
  int i, ret;
  int *ptr_int;

  for ( i = 0 ; i < data_size ; i++ )
    d[pattern[i]] = data[i];
  ptr_int = (int *)d; 
  ret = *ptr_int;  // undefined behavior

  return ret;
}
int main() {
  short data[] = {0x32,0x31};
  int result =  func(data, 4);
  printf("%x\n", result);
}

clang -O0 test.c
will print 310032

clang -Os test.c
will print: 20001  (surprising result)

Both GCC 6.5 and MSVC will print 310032 (Optimized or not).
clang 5.0 will also print out 310032 so its a recent regression.

Disabling the GVN pass on trunk will cause clang to print 310032 even in
optimized mode.

Now I understand that dereferencing a pointer after a pointer type cast is
undefined behavior.

But do we really want LLVM to be that aggressive? My personal opinion is that
LLVM shouldn't give such unexpected result even if the code contains undefined
behavior.

-- 
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/20171108/e65ea76d/attachment.html>