[LLVMbugs] [Bug 2300] New: Wrong indices in GPE with pointer arithmetic and uintptr_t

[bugzilla-daemon at cs.uiuc.edu]

http://llvm.org/bugs/show_bug.cgi?id=2300

           Summary: Wrong indices in GPE with pointer arithmetic and
                    uintptr_t
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: matthieu at uiuc.edu
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1625)
 --> (http://llvm.org/bugs/attachment.cgi?id=1625)
the test case

llvm back-end build: RELEASE_2_2
llvm-gcc front-end: 4.2 (downloaded from the website)

Overview:

When doing some specific pointer arithmetic, the emitted code from llvm-gcc is
wrong when compiling the test case with an optimization level different than
-O0.
Looking at the IR, the indexes used in GPE instructions are wrong.

To reproduce the bug:
Download the attached test case and compile the code with llvm-gcc with
different optimizations level. Whenever it is different than -O0, the result is
wrong.

Expected result:
"Diff is 16384" (without the quotes)

Obtained result:
"Diff is 16384" when compiled with -O0
"Diff is 4294955008" when using higher levels

Additional information:

The IR I obtained at O2:

define i32 @main(i32 %argc, i8** %argv) nounwind  {
entry:
        %tmp124 = malloc [65536 x i8]           ; <[65536 x i8]*> [#uses=3]
        %ctg2 = getelementptr [65536 x i8]* %tmp124, i32 0, i32 -12288         
; <i8*> [#uses=1]
        %tmp9 = ptrtoint i8* %ctg2 to i32               ; <i32> [#uses=1]
        %tmp1314 = ptrtoint [65536 x i8]* %tmp124 to i32                ; <i32>
[#uses=1]
        %tmp15 = sub i32 %tmp9, %tmp1314                ; <i32> [#uses=1]
        %tmp18 = tail call i32 (i8*, ...)* @printf( i8* noalias  getelementptr
([12 x i8]* @.str, i32 0, i32 0), i32 %tmp15 ) nounwind          ; <i32>
[#uses=0]
        free [65536 x i8]* %tmp124
        ret i32 0
}

the second index for %ctg2 seems really bad.

Note as well that changing the cast (uintptr_t) to (char *) seems to remove the
problem.

Using opt with -std-compile-opts on the unoptimized IR generate the correct
result.

Is there a way to know which passes are actually used at -O2? I would like to
run bugpoint but using -std-compile-opts does not generate a wrong result so it
seems the bug is either from an additional pass or from the front-end.


-- 
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.