> >
> > 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. -
Nawww... I've tried this on a bunch of different machines.. as a matter
of fact it replicates with gcc version 2.7.2.1 from December of last
year. I find it hard to believe that I have 80 machines that all
exhibit the exact same memory failure... :-)
-John
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
