-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ldecod has undefined behavior, fails in x86 jit on linux #1335
Comments
Oops. There's a typo in the initial comment. It should say: Looking at the bugpoint.test.bc file .. instead of: Looking at the bugpoint.safe.bc file .. |
Hi Reid, thanks for filing this. In order to debug this, please do the following steps:
Please attach the output of #3 along with the output of llc on the test .bc file to this bug. Thanks, -Chris |
JIT Code: |
LLC Generated Code:
main: |
Bytecode for test function |
The difference between the gdb disassembly and llc output makes no sense. There is whole chunk of 0x00b6405a: jmp 0xb64073 That shouldn't happen. Not that it should make that kind of difference. But Reid, are you generating the llc output with - |
Here's the llc -relocation-model=static code:
main: The only difference I see is the additional block and jump to it in the lli |
I went through this carefully. The only differences are:
.BB1_2: #cond_true967 the JIT code branches to do the same thing: Those are the only differences. Furthermore, I don't see how its affecting |
Evan, please look into this and try to determine if it's bogus or not. If not, I'd like to have this fixed for Thanks, -Chris |
I can't really figure out why there is an extra block of code under JIT case. So this is a "can't fix / figured |
No, you shouldn't. This is the reason why all the ldecod tests have been failing |
An afterthought: You may be missing the point. The "extra block" doesn't matter. The LLC and JIT ******************** TEST (jit) 'ldecod' FAILED! ******************** I will attach the jit and nat output. |
Native Output |
JIT Output |
Another thought: The difference in output may not be the result of any JIT'd code at all, it |
is this still an issue? |
Yes. I tried to fix it but I can't detect where it is producing differeing |
Anton, if you get a chance, can you see if this reproduces for you? |
Ok. Will try within next 3-4 days. |
JIT fails for me too. |
Reid/Anton, can you see if this still fails with llvm/llvm-bugzilla-archive#1130 fixed? Thanks, -Chris |
It is still failing for me |
If we're enable trace feature of ldecod (define.h => TRACE define) the output |
have you tried running the native version of ldecod under valgrind? |
To be clear, the x86-jit failed because the program was reading uninitialized memory, so it was a bug in |
Well, to be clearer :) Program reads uninitialized memory, because provided |
Extended Description
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
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 ; [#uses=1]
%tmp981 = cast short %tmp981 to 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 ; [#uses=1]
br label %cond_next989.exitStub
which apparently has nothing to do with floating point calcuations.
The text was updated successfully, but these errors were encountered: