[Bug preprocessor/60436] New: C preprocessor segfaults on assembly file

["dan.doel at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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

            Bug ID: 60436
           Summary: C preprocessor segfaults on assembly file
           Product: gcc
           Version: 4.8.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: preprocessor
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dan.doel at gmail dot com

Greetings,

While testing the latest GHC, I came across a segfault in GCC. I've tracked it
down to the preprocessor segfaulting on an intermediate assembly file produced
during compilation. I've also reproduced the segfault using the stock 4.8.2
release, although I first encountered it on the 2014-02-06 snapshot which is
currently distributed on Arch.

The assembly file is very large, but I have no smaller test case. I cannot
attach it here, because xz -9e only compresses it to ~2MiB. However, you can
find it at the Arch bug report I'll link below. Various bits about the
reproduction of the segfault are also quite odd:

  The assembly file contains no macros or includes.

  A macro must be defined to produce the segfault. The one GHC uses is
    -DTABLES_NEXT_TO_CODE. One can also get the segfault by putting
    '#define TABLES_NEXT_TO_CODE' at the top of the file

  TABLES_NEXT_TO_CODE is meaningless, though. Any macro definition of 13
  letters or more triggers the segfault. But 12 or fewer seems to work fine.

  Adding a blank line anywhere before line 395,848 stops the segfault, but
  adding blank lines after does nothing.

  Truncating the file before line 4,400,769 stops the segfault, but truncating
  after does nothing.

Here's the crash output of running `cpp -v -DABCDEFGHIJKLM` on the file:

----

Using built-in specs.
COLLECT_GCC=cpp
Target: x86_64-unknown-linux-gnu
Configured with: ./configure
Thread model: posix
gcc version 4.8.2 (GCC) 
COLLECT_GCC_OPTIONS='-E' '-v' '-D' 'ABCDEFGHIJKLM' '-o' 'ghc3240_8.pps'
'-mtune=generic' '-march=x86-64'
 /usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.8.2/cc1 -E -lang-asm -quiet
-v -D ABCDEFGHIJKLM ghc3240_8.s -o ghc3240_8.pps -mtune=generic -march=x86-64
-fno-directives-only
ignoring nonexistent directory
"/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/include
 /usr/local/include
 /usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/include-fixed
 /usr/include
End of search list.
ghc3240_8.s:1:0: internal compiler error: Segmentation fault
 .section .rodata
 ^
0x80cdcf crash_signal
    ../.././gcc/toplev.c:332
0xc4916e get_data_from_adhoc_loc(line_maps*, unsigned int)
    ../.././libcpp/line-map.c:156
0xc371db expand_location_1
    ../.././gcc/input.c:57
0xc3740d expand_location(unsigned int)
    ../.././gcc/input.c:150
0x578c1d scan_translation_unit
    ../.././gcc/c-family/c-ppoutput.c:214
0x578c1d preprocess_file(cpp_reader*)
    ../.././gcc/c-family/c-ppoutput.c:101
0x5774d0 c_common_init()
    ../.././gcc/c-family/c-opts.c:1026
0x52e59d c_objc_common_init()
    ../.././gcc/c/c-objc-common.c:63
0x80e7c6 lang_dependent_init
    ../.././gcc/toplev.c:1688
0x80e7c6 do_compile
    ../.././gcc/toplev.c:1850


----

Here is a link to the Arch bug I've filed. You can find the offending file
(compressed) there:

    https://bugs.archlinux.org/task/39180

If any further information is desired, let me know. Thanks.