🚀 go-pugleaf

    Ferdinand de Boevere writes:

>Compiling the next code (fatal.c):

>    main()
>    {
>        void *test(void)
>        {
>            printf("test\n");
>                return test;       
>        }
>        void *test(void);
>    }

>gives:

>    cc: Internal compiler error: program cc1 got fatal signal 11

>...

>Testing this code on another Linux computer shows that is probably
>not a hardware problem.

>A gcc-compiler (2.5.3) on the HP/UX platform did also exit with 
>fatal signal:

>    fatal.c: In function `main':
>    fatal.c:10: internal error--unrecognizable insn:
>    (insn 28 26 29 (set (reg:SI 109)
>            (nil)) -1 (nil)
>        (nil))
>    gcc: Internal compiler error: program cc1 got fatal signal 6

>This makes me conclude that it is a compiler bug.


    I have confirmed this problem on my Linux system (Pentium, v1.2.13,
gcc v2.7.0) and on a Sun SPARCStation IPX (SunOS v4.1.x, gcc v2.3.3).

    Signal 11 is SIGSEGV (on my Linux system), so it looks like gcc has
a pointer problem for at least versions 2.3.3, 2.5.3, and 2.7.0.

    Do the GCC developers test their code with any of the Q/A tools
that are available (i.e. Insure++, Purify, etc.) ?

Dean Schulze