Date: Mon, 20 Dec 1999 11:37:43 -0500 (EST) From: Thomas David Rivers <rivers@dignus.com> To: freebsd-current@FreeBSD.ORG, jwd@unx.sas.com Subject: Re: cc taking a signal 11 Message-ID: <199912201637.LAA81110@lakes.dignus.com> In-Reply-To: <199912201632.LAA01647@bb01f39.unx.sas.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>
> 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 majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912201637.LAA81110>