On Sep 26, 2014, at 12:31 PM, David Malcolm <dmalc...@redhat.com> wrote:
> 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
:-( Then, it doesn’t work.
I’d report the as bug. Also, you might try binary searching for the limit.
Hopefully 16M works just fine. If it doesn’t, then someone broke it recently.
I tested a simple program on my machine and got it up to 31M for gcc and 512M
for clang. gcc died as 32M. clang, well, I grew impatient waiting for the
compile times. 512M should bee good for the next 100 years I suspect. 31M is
likely fine for the next 2 decades, though, that bug should be fixed.
gcc died like this for me:
gcc: internal compiler error: Illegal instruction: 4 (program cc1)
:-(
$ cat t.c
#include <stdio.h>
/* gcc works to 31, fails as 32, clang goes beyond 512 */
#define M 32*1024*1024
char buf[M+1];
int main() {
int i;
for (i = 0; i < M; ++i)
buf[i] = '0';
printf ("#include <stdio.h>\n\
\n\
int i%s;\n\
\n\
int main() {\n\
++i%s;\n\
return 0;\n\
}\n\
", buf, buf);
return 0;
}
