[LLVMbugs] [Bug 8060] New: JumpThreading miscompilation on whole-program SPEC CINT2000 v1.3 255.vortex

[bugzilla-daemon at llvm.org]

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

           Summary: JumpThreading miscompilation on whole-program SPEC
                    CINT2000 v1.3 255.vortex
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: luked at cs.rochester.edu
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=5443)
 --> (http://llvm.org/bugs/attachment.cgi?id=5443)
the tooptimize half of the bugpoint reduction

I'm using the LTO/gold infrastructure with cvs binutils and llvm/llvm-gcc-4.2
from svn. I use -O4 -m32 to compile all of the object files into bitcode, and
then link with -use-gold-plugin. The resulting executable fails to work.

I can avoid the problem either by compiling bitvec.c with -O3 -m32 or
suppressing jump-threading during the link phase. I've done a bugpoint
reduction of the miscompilation.

I've done a bugpoint reduction using the standard LTO passes which also
pinpoints jump-threading as the problem.

$bugpoint -llc-safe -preverify -domtree -verify -internalize -ipsccp -globalopt
-constmerge -deadargelim -instcombine -basiccg -inline -prune-eh -globalopt
-globaldce -basiccg -argpromotion -instcombine -lazy-value-info -jump-threading
-domtree -domfrontier -scalarrepl -basiccg -functionattrs -globalsmodref-aa
-domtree -loops -loopsimplify -licm -memdep -gvn -memdep -memcpyopt -dse
-instcombine -lazy-value-info -jump-threading -simplifycfg -globaldce
-preverify -domtree -verify 255.vortex.bc -args lendian1.raw
-output=vortex1.out -enable-valgrind
Read input file      : '255.vortex.bc'
*** All input ok
Running selected passes on program to test for crash: Success!
Initializing execution environment: Found gcc: /usr/bin/gcc
Running the code generator to test for a crash: <llc>
Generating reference output from raw program: <llc><llc><gcc><program>
Reference output is: bugpoint.reference.out

*** Checking the code generator...
<llc><gcc><program>
*** Output matches: Debugging miscompilation!
Checking to see if '' compiles correctly: <llc><gcc><program> yup.
Checking to see if '-preverify -domtree -verify -internalize -ipsccp -globalopt
-constmerge -deadargelim -instcombine -basiccg -inline -prune-eh -globalopt
-globaldce -basiccg -argpromotion -instcombine -lazy-value-info -jump-threading
-domtree -domfrontier -scalarrepl -basiccg -functionattrs -globalsmodref-aa
-domtree -loops -loopsimplify -licm -memdep -gvn -memdep -memcpyopt -dse
-instcombine -lazy-value-info -jump-threading -simplifycfg -globaldce
-preverify -domtree -verify' compiles correctly: <llc><gcc><program> nope.
Checking to see if '-scalarrepl -basiccg -functionattrs -globalsmodref-aa
-domtree -loops -loopsimplify -licm -memdep -gvn -memdep -memcpyopt -dse
-instcombine -lazy-value-info -jump-threading -simplifycfg -globaldce
-preverify -domtree -verify' compiles correctly: <llc><gcc><program> yup.
Checking to see if '-preverify -domtree -verify -internalize -ipsccp -globalopt
-constmerge -deadargelim -instcombine -basiccg -inline -prune-eh -globalopt
-globaldce -basiccg -argpromotion -instcombine -lazy-value-info -jump-threading
-domtree -domfrontier' compiles correctly: <llc><gcc><program> nope.
Checking to see if '-inline -prune-eh -globalopt -globaldce -basiccg
-argpromotion -instcombine -lazy-value-info -jump-threading -domtree
-domfrontier' compiles correctly: <llc><gcc><program> nope.
Checking to see if '-argpromotion -instcombine -lazy-value-info -jump-threading
-domtree -domfrontier' compiles correctly: <llc><gcc><program> yup.
Checking to see if '-inline -prune-eh -globalopt -globaldce -basiccg' compiles
correctly: <llc><gcc><program> yup.
Checking to see if '-argpromotion -instcombine -lazy-value-info -jump-threading
-domtree -domfrontier' passes compile correctly after the '-inline -prune-eh
-globalopt -globaldce -basiccg' passes: <llc><gcc><program> nope.
Checking to see if '-jump-threading -domtree -domfrontier' compiles correctly:
<llc><gcc><program> yup.
Checking to see if '-argpromotion -instcombine -lazy-value-info' compiles
correctly: <llc><gcc><program> yup.
Checking to see if '-jump-threading -domtree -domfrontier' passes compile
correctly after the '-argpromotion -instcombine -lazy-value-info' passes:
<llc><gcc><program> nope.
Checking to see if '-domtree -domfrontier' compiles correctly:
<llc><gcc><program> yup.
Checking to see if '-jump-threading' compiles correctly: <llc><gcc><program>
nope.

*** Found miscompiling pass: -jump-threading

I've attached to tooptimize half of the reduction. The SPEC input is 3.2 megs
(and presumably copyrighted by SPEC), and the tonotoptimize half of the
reduction is 1.1 megs (I'm also worried about the copyright here, given that
with tooptimize and tonotoptimize together you can generate the vortex binary
for my configuration).

Someone familiar with jump threading, and with access to the SPEC CINT2000 v1.3
source, could probably trace jump threading during LTO with bitvec.o (a small,
2 function object) to detect the bug more quickly than optimizing the 70k
tooptimize half alone.

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