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: unassignedb...@nondot.org
Reporter: pichet2...@gmail.com
CC: llvm-bugs@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._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
