From owner-freebsd-current Mon Dec 20 8:38:30 1999 Delivered-To: freebsd-current@freebsd.org Received: from smtp1.vnet.net (smtp1.vnet.net [166.82.1.31]) by hub.freebsd.org (Postfix) with ESMTP id 935CB14C32 for ; Mon, 20 Dec 1999 08:38:14 -0800 (PST) (envelope-from rivers@dignus.com) Received: from dignus.com (ponds.vnet.net [166.82.177.48]) by smtp1.vnet.net (8.9.1a/8.9.1) with ESMTP id LAA10107; Mon, 20 Dec 1999 11:38:10 -0500 (EST) Received: from lakes.dignus.com (lakes.dignus.com [10.0.0.3]) by dignus.com (8.9.2/8.8.5) with ESMTP id LAA27842; Mon, 20 Dec 1999 11:37:43 -0500 (EST) Received: (from rivers@localhost) by lakes.dignus.com (8.9.3/8.6.9) id LAA81110; Mon, 20 Dec 1999 11:37:43 -0500 (EST) Date: Mon, 20 Dec 1999 11:37:43 -0500 (EST) From: Thomas David Rivers Message-Id: <199912201637.LAA81110@lakes.dignus.com> To: freebsd-current@FreeBSD.ORG, jwd@unx.sas.com Subject: Re: cc taking a signal 11 In-Reply-To: <199912201632.LAA01647@bb01f39.unx.sas.com> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > 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