On Fri, 2014-09-26 at 11:45 -0700, Mike Stump wrote: > On Sep 26, 2014, at 8:14 AM, David Malcolm <dmalc...@redhat.com> > wrote: > > * jit.dg/test-long-names.c: New test case. > > > +/* 65KB */ > > +#define NAME_LENGTH (65 * 1024) > > 65K was a tiny name back in 1999, 16M was a large name then. Today, > 16M is tiny enough. And yeah, this was a customer bug report, just > normal C++ code with template manglings back then and yeah, we fixed > the bug and tested it out to 16M to ensure we would not hit another > bug in the next decade. As far as I know, we didn’t. If you want to > ensure it works nicely for the next decade test out to, say, 128M and > then throw that test case away. I’d be curious if you hit any > problems at 128M.
Out of curiosity I tried upping NAME_LENGTH to 129M. The compiler handled it fine, but FWIW "as" seems to be stuck here: (gdb) bt #0 0x0000000000411730 in input_scrub_next_buffer (bufp=bufp@entry=0x693340) at input-scrub.c:390 #1 0x000000000041efab in read_a_source_file (name=<optimized out>) at read.c:768 #2 0x0000000000404188 in perform_an_assembly_pass (argv=0x88bee8, argc=<optimized out>) at as.c:1095 #3 main (argc=2, argv=0x88bee0) at as.c:1242 whilst reading a 952M .s file. (binutils-2.23.88.0.1-13.fc20.x86_64, fwiw)