>
> Hi,
>
> While I'm at it, a co-worker gave this one to me earlier today.
>
> cc: Internal compiler error: program cc1 got fatal signal 11
>
> 4.0-CURRENT FreeBSD 4.0-CURRENT #0: Mon Dec 20 01:45:25 EST 1999
>
>
>
> FreeBSD(root)/tmp %cc -v
> Using builtin specs.
> gcc version 2.95.2 19991024 (release)
>
> FreeBSD(root)/tmp %cc -O foo.c -o foo.o -c
> cc: Internal compiler error: program cc1 got fatal signal 11
>
>
>
> static void getsig11(parfree,dbl,lambda)
> long parfree;
> double *dbl;
> double *lambda;
> {
> long i, j;
> j = -1;
> for(i = 0; i < parfree; i++) {
> j += i+1;
> dbl[j] *= (1.0 + *lambda);
> }
> return;
> }
>
>
> Yes, the algorithm looks funny, but is correct. The program will
> compile correctly if the 'j += i+1;' is changed to 'j = i+1;' or if
> the variable 'lambda' is changed from a pointer to an actual value.
>
> Anyone want to take a stab at this? I'm not a big compiler
> person myself... (Dave, you there?).
Yes - I'm here :-)
Typically - signal 11 problems from GNU's front-end are hardware
memory issues....
I will add that a quick test on a 3.3 system compiles this just
fine (Systems/C compiles it as well.)
I would suspect hardware problems first.
As I have learned from painful experience, *always* use ECC or at least
parity memory...
- Dave R. -
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
