http://llvm.org/bugs/show_bug.cgi?id=11352
Bug #: 11352
Summary: globalopt miscompilation with i32/i64 mismatch in GEP
indices
Product: libraries
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Transformation Utilities
AssignedTo: [email protected]
ReportedBy: [email protected]
CC: [email protected]
Classification: Unclassified
Created attachment 7598
--> http://llvm.org/bugs/attachment.cgi?id=7598
IR which globalopt miscompiles
This code, built by clang, is incorrectly optimized when targeting
x86_64-linux:
int xs[] = { 1, xs[0] };
The relevant part of the generated IR looks like this:
@xs = global [2 x i32] zeroinitializer, align 4
define internal void @__cxx_global_var_init() nounwind section ".text.startup"
{
entry:
store i32 1, i32* getelementptr inbounds ([2 x i32]* @xs, i64 0, i64 0)
%0 = load i32* getelementptr inbounds ([2 x i32]* @xs, i32 0, i64 0), align 4
store i32 %0, i32* getelementptr inbounds ([2 x i32]* @xs, i64 0, i64 1)
ret void
}
Note that the GEPs don't have consistent types for their indices. This leads
globalopt to believe that the first store and the load do not alias, so it uses
the value 0 for %0. This results in:
@xs = global [2 x i32] [i32 1, i32 0], align 4
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
_______________________________________________
LLVMbugs mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs
