Boostrap Failure -- Expected Differences?

The saga continues.

I've been tracking the interface changes and merging them with
the refactoring work I'm doing. I got as far as building stage3
of llvm-gcc but the object files from stage2 and stage3 differ:

warning: ./cc1-checksum.o differs
warning: ./cc1plus-checksum.o differs

(Are the above two ok?)

The list below is clearly bad. I think it's every object file in
the compiler!

I've attached the diff of an `objdump -x -d -D -s -g -t -r' on
alias.o from stage2 (stage2/alias.o) and stage3 (alias.o).

From the objdump output, it appears the only differences are
in incidental symbol names (__FUNCTION__.<num> where <num> is
the difference).

Are these differences expected? Should I run objdump with any
other options to further debug this? When do I consider llvm-gcc
to be good enough (bug free) to submit my patches? I obviously
want to do a complete testsuite run but I didn't want to start
that until I know how an llvm-gcc bootstrap should go. If these
differences are ok, let me know and I'll start a testsuite run
and get these patches submitted.

Thanks.

                                   -Dave

diff.out (32.1 KB)

The saga continues.

I've been tracking the interface changes and merging them with
the refactoring work I'm doing. I got as far as building stage3
of llvm-gcc but the object files from stage2 and stage3 differ:

warning: ./cc1-checksum.o differs
warning: ./cc1plus-checksum.o differs

(Are the above two ok?)

The list below is clearly bad. I think it's every object file in
the compiler!

I've attached the diff of an `objdump -x -d -D -s -g -t -r' on
alias.o from stage2 (stage2/alias.o) and stage3 (alias.o).

From the objdump output, it appears the only differences are
in incidental symbol names (__FUNCTION__.<num> where <num> is
the difference).

Are these differences expected? Should I run objdump with any
other options to further debug this? When do I consider llvm-gcc
to be good enough (bug free) to submit my patches? I obviously
want to do a complete testsuite run but I didn't want to start
that until I know how an llvm-gcc bootstrap should go. If these
differences are ok, let me know and I'll start a testsuite run
and get these patches submitted.

These differences are not expected. It's possible you have run into a LLVM codegen bug.

These are nasty to track down. Can you pick a .c file that's miscomparing and verify with stage2 and stage3 cc1 do produce different .s files? If so, you need to track down which of the .o files that are being linked to create the stage3 cc1 is miscompiled (by replacing them with known good .o files one by one). Once you have narrowed it down to a single file, compile it with stage1 and stage2 cc1 to get the different .s files. Hopefully it's possible to spot the bug then.

Sorry if it sounds like as much fun as a root canal. But these usually require some brute force efforts to track down.

Evan

Evan Cheng wrote:

These are nasty to track down. Can you pick a .c file that's miscomparing and verify with stage2 and stage3 cc1 do produce different .s files? If so, you need to track down which of the .o files that are being linked to create the stage3 cc1 is miscompiled (by replacing them with known good .o files one by one). Once you have narrowed it down to a single file, compile it with stage1 and stage2 cc1 to get the different .s files. Hopefully it's possible to spot the bug then.

Sorry if it sounds like as much fun as a root canal. But these usually require some brute force efforts to track down.

Yep, been there, done that, wrote a script in graduate school. Am
now resurrecting said script and will hopefully be contributing it
back to the community ASAP.

Fun times. :slight_smile:

                            -Dave