-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
x86_64 codegen bug in md5.c #1720
Comments
Ok, some silly questions:
produce for you? I get: md5_buffer: Which is fine. If you get the bogus output, please attach the output and the output of -print- Finally, what is your system GCC version? Is it in this list? -Chris |
a) Yes, current CVS/SVN.
md5_buffer: c) llvm and llvm-cfrontend are compiled using gcc 4.0.4, built from gcc's GNU C version 4.0.1 LLVM (Apple Computer, Inc. build 5432) |
Very strange. Your llc output looks good, like I would expect. Okay, try this:
Thanks -Chris |
cc1 output uploaded. And it has the bogotic constant! |
Ah, interesting. There are multiple bugs here. The main issue is that the CFE is producing this type: That last part seems bad. Devang, can you look into why this is happening? The second issue is that this type isn't turning into the proper (large) size. I'll fix this part. -Chris |
actually, I am getting this from the code generator now: md5_buffer: from the .bc file in comment #1. Devang, can you investigate the struct layout issue please? -Chris |
ok |
Now, I see (using md5.c from llvm-gcc sources on darwin platform)
which is correct. Would it be possible to send me preprocessed C source file to reproduce this ? Thank you. |
that is with -m64, right? It seems like this may have been fixed by one of your recent patches. |
Yes -m64. |
Even more strange. I get something completely different when I'm on an x86 host. Still investigating. |
After a raft of random fixes to the code generator to support >4G stack frames, I'm now seeing the X86 Devang, please investigate the CFE issue. If already fixed, feel free to close this and Scott can try when he |
WFM. Now off to figure out why compiler now bails during local_init.cc... |
great, thanks! |
mentioned in issue llvm/llvm-bugzilla-archive#22340 |
Extended Description
This occurs while compiling the C frontend, xgcc produces the following
diagnostic:
(bosbok) libiberty make
if [ x"" != x ]; then
/work/scottm/llvm-cfrontend/obj/x86_64-unknown-linux-gnu/gcc/xgcc -B/work/scottm/llvm-cfrontend/obj/x86_64-unknown-linux-gnu/gcc/ -B/work/scottm/llvm-cfrontend/i686-unknown-linux-gnu/x86_64-unknown-linux-gnu/bin/ -B/work/scottm/llvm-cfrontend/i686-unknown-linux-gnu/x86_64-unknown-linux-gnu/lib/ -isystem /work/scottm/llvm-cfrontend/i686-unknown-linux-gnu/x86_64-unknown-linux-gnu/include -isystem /work/scottm/llvm-cfrontend/i686-unknown-linux-gnu/x86_64-unknown-linux-gnu/sys-include -c -DHAVE_CONFIG_H -O2 -g -O2 -I. -I../../../../libiberty/../include -W -Wall -Wtraditional -pedantic ../../../../libiberty/md5.c -o
pic/md5.o;
else true; fi
/work/scottm/llvm-cfrontend/obj/x86_64-unknown-linux-gnu/gcc/xgcc -B/work/scottm/llvm-cfrontend/obj/x86_64-unknown-linux-gnu/gcc/ -B/work/scottm/llvm-cfrontend/i686-unknown-linux-gnu/x86_64-unknown-linux-gnu/bin/ -B/work/scottm/llvm-cfrontend/i686-unknown-linux-gnu/x86_64-unknown-linux-gnu/lib/ -isystem /work/scottm/llvm-cfrontend/i686-unknown-linux-gnu/x86_64-unknown-linux-gnu/include -isystem /work/scottm/llvm-cfrontend/i686-unknown-linux-gnu/x86_64-unknown-linux-gnu/sys-include -c -DHAVE_CONFIG_H -O2 -g -O2 -I. -I../../../../libiberty/../include -W -Wall -Wtraditional -pedantic ../../../../libiberty/md5.c -o
md5.o
/tmp/ccSlUbtP.s: Assembler messages:
/tmp/ccSlUbtP.s:924: Error: suffix or operands invalid for `sub'
The relevant portion from the assembler source is:
md5_buffer:
subq $4294966344, %rsp
movq %rbp, -960(%rsp)
leaq -960(%rsp), %rbp
movq %rbx, -8(%rbp)
movq %r12, -16(%rbp)
movq %r14, -24(%rbp)
movq %r15, -32(%rbp)
The "$42949663444" is the invalid constant about which xgcc (actually, gas)
complains.
The text was updated successfully, but these errors were encountered: