Arch Linux

Here's some additional info:

1) putting #define TABLES_NEXT_TO_CODE at the top of the file and omitting the -D flag also causes the segfault

2) TABLES_NEXT_TO_CODE is not really significant. Something needs to be CPP defined, and the length matters, but that's it. -DFAKE_THE_FUNK segfaults, but -DNASTY_DUNK doesn't. Or -DAAAAAAAAAAAA (12 As) works, but -DAAAAAAAAAAAAA (13 As) segfaults.

Well... a 4.5 million line testcase... Lets try and reduce it!

Compiling with "gcc -x assembler-with-cpp -c ghc3240_8.s -o ghc3240_8.o" does not segfault. So it must have an issue with TABLES_NEXT_TO_CODE. But that is not in the .s file, and nor is any .ifdef statements...

I'm clearly missing something here, but I have not needed to debug and ICE from a .s file before.

"Or -DAAAAAAAAAAAA (12 As) works, but -DAAAAAAAAAAAAA (13 As) segfaults."

Well into the realms of WTF now!

Here's another bit of information:

If I go to line 5, and duplicate it, so that there are two lines:

.byte 67
.byte 67

The segfault disappears. So perhaps it's related to the file's size (modulo some number) somehow?

Scratch the precise file size. It's number of lines that seems to be a factor.

Fiddling with bytes to make them have more or fewer characters seems to have no effect. But adding or deleting a line fixes the segfault. Even adding a blank line at the beginning of the file fixes it. But, adding blank lines to the end of the file does not.

Program received signal SIGSEGV, Segmentation fault.
0x0000000000c505ae in get_data_from_adhoc_loc(line_maps*, unsigned int) ()
(gdb) bt
#0 0x0000000000c505ae in get_data_from_adhoc_loc(line_maps*, unsigned int) ()
#1 0x0000000000c3e61c in ?? ()
#2 0x0000000000c3e84e in expand_location(unsigned int) ()
#3 0x000000000057c7ae in preprocess_file(cpp_reader*) ()
#4 0x000000000057b071 in c_common_init() ()
#5 0x0000000000531e8e in c_objc_common_init() ()
#6 0x0000000000813c87 in toplev_main(int, char**) ()
#7 0x00007ffff66efb05 in __libc_start_main () from /usr/lib/libc.so.6
#8 0x000000000050a0e7 in _start ()

I realized that editing lines was affecting things depending on where they were in the file. So I did some binary searching.

Adding a blank line before 395848 fixes the segfault.
Adding a blank line after 395848 does not.
Deleting line 395848 fixes the segfault.

But, truncating has different effects. Truncating before line 4400769 fixes the segfault, while truncating there or after does not. Truncating at line 4400769 preserves the behavior of modificaitons at line 395848, though.

I don't know if this is of any help. It doesn't slim down the test case appreciably, and those numbers don't jump out at me as meaningful.

I've compiled the 4.8.2 release from scratch, and still see the segfault using it. So I've filed an upstream bug here:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60436

Also, I think the bug is definitely narrowed down to the preprocessor, as `cpp -DABCDEFGHIJLKM` is sufficient to segfault.

Patch pushed to gcc trunk. I'll pll a snapshot once it lands on the 4.9 branch.