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: .align 16 .globl md5_buffer .type md5_buffer,@function 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.
Created attachment 793 [details] md5.bc bytecode that produces the error...
Created attachment 794 [details] Associated assembly language output for md5.c
Ok, some silly questions: 1. This is LLVM CVS/SVN, not 1.9, right? 2. What does: llc md5.o -o - -relocation-model=pic -disable-fp-elim produce for you? I get: md5_buffer: subq $200, %rsp movq %rbp, 192(%rsp) leaq 192(%rsp), %rbp ... Which is fine. If you get the bogus output, please attach the output and the output of -print- machineinstrs. Finally, what is your system GCC version? Is it in this list? http://llvm.org/docs/GettingStarted.html#brokengcc -Chris
a) Yes, current CVS/SVN. b) "lli md5.bc -o - -relocation-model=pic -disable-fp-elim" produces: .align 16 .globl md5_buffer .type md5_buffer,@function md5_buffer: subq $552, %rsp movq %rbp, 544(%rsp) leaq 544(%rsp), %rbp c) llvm and llvm-cfrontend are compiled using gcc 4.0.4, built from gcc's gcc-4_0-branch source: GNU C version 4.0.1 LLVM (Apple Computer, Inc. build 5432) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.0.4.
Created attachment 796 [details] Assembly output from llc
Created attachment 797 [details] -print-machineinstrs output from llc
Very strange. Your llc output looks good, like I would expect. Okay, try this: 1. Run the llvm-gcc command line again, it should crash. Pass -v to it in addition to the other options. This should show how it invokes "cc1". 2. Invoke cc1 with the same option. This time, pass "-mllvm -print-machineinstrs" or "-mllvm=-print- machineinstrs" (whichever works), and attach the dump again. Thanks -Chris
cc1 output uploaded. And it has the bogotic constant!
Created attachment 799 [details] cc1 -mllvm -print-machineinstrs output
Ah, interesting. There are multiple bugs here. The main issue is that the CFE is producing this type: %struct.md5_ctx = type { i32, i32, i32, i32, [2 x i32], i32, [128 x i8], [4294966912 x i8] } 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: subq $4294967112, %rsp movq %rbx, -192(%rsp) 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) %struct.md5_ctx = type { i32, i32, i32, i32, [2 x i32], i32, [128 x i8] } 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. It is possible that this was covered by one of the recent patches.
> actually, I am getting this from the code generator now: > md5_buffer: > subq $4294967112, %rsp > from the .bc file in comment #1. 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 backend emit illegal subq instructions when the frame is >4G. For me, mission accomplished :) Devang, please investigate the CFE issue. If already fixed, feel free to close this and Scott can try when he is back in town.
Codegen bug fixed. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20070423/048467.html
WFM. Now off to figure out why compiler now bails during local_init.cc...
great, thanks!