[LLVMbugs] [Bug 963] NEW: MultiSource/Applications/JM/ldecod miscompilation

[bugzilla-daemon at cs.uiuc.edu]

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

           Summary: MultiSource/Applications/JM/ldecod miscompilation
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rspencer at x10sys.com


The ldecod test shows a significant difference in the output of its floating
point numbers (~0.2 to ~1.3) compared to GCC. This is most notable on the JIT.
Furthermore the JIT output does not agree with the CBE, and LLC output.

Running "make bugpoint-jit" produces:

*** The following function is being miscompiled:  dpb_split_field_cond_true967
<cbe><gcc>You can reproduce the problem with the command line:
  lli -load ./bugpoint.safe.bc.cbe.c.so bugpoint.test.bc -i
/proj/llvm/llvm-test-nc/MultiSource/Applications/JM/ldecod/data/test.264 -o
/proj/llvm/llvm-test-nc/MultiSource/Applications/JM/ldecod/data/test_dec.yuv -r
/proj/llvm/llvm-test-nc/MultiSource/Applications/JM/ldecod/data/test_rec.yuv
The shared object was created with:
  llc -march=c bugpoint.safe.bc -o temporary.c
  gcc -xc temporary.c -O2 -o ./bugpoint.safe.bc.cbe.c.so -shared \ 
    -fno-strict-aliasing

Looking at the bugpoint.safe.bc file, the interesting bit is this block:
cond_true967:           ; preds = %newFuncRoot
        %tmp974 = getelementptr %struct.StorablePicture* %tmp957.reload, int 0,
uint 30         ; <short***> [#uses=1]
        %tmp975 = load short*** %tmp974         ; <short**> [#uses=1]
        %tmp977 = getelementptr short** %tmp975, int %tmp675.reload            
; <short**> [#uses=1]
        %tmp978 = load short** %tmp977          ; <short*> [#uses=1]
        %tmp980 = getelementptr short* %tmp978, int %tmp678.reload             
; <short*> [#uses=1]
        %tmp981 = load short* %tmp980           ; <short> [#uses=1]
        %tmp981 = cast short %tmp981 to int             ; <int> [#uses=1]
        %tmp986 = getelementptr %struct.StorablePicture* %tmp957.reload, int 0,
uint 5, int %tmp981, int 1, int %tmp916.reload          ; <long*> [#uses=1]
        %tmp987 = load long* %tmp986            ; <long> [#uses=1]
        br label %cond_next989.exitStub

which apparently has nothing to do with floating point calcuations.



------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.