[LLVMbugs] [Bug 11352] New: globalopt miscompilation with i32/i64 mismatch in GEP indices

[bugzilla-daemon at llvm.org]

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: unassignedbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: llvmbugs at cs.uiuc.edu
    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.