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.

Assembly output from llc

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

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!

mentioned in issue llvm/llvm-bugzilla-archive#22340