From owner-freebsd-current Sat Sep 21 04:00:12 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id EAA06858 for current-outgoing; Sat, 21 Sep 1996 04:00:12 -0700 (PDT) Received: from agora.rdrop.com (root@agora.rdrop.com [199.2.210.241]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id DAA06480 for ; Sat, 21 Sep 1996 03:58:43 -0700 (PDT) Received: from apocalypse.tky.hut.fi by agora.rdrop.com with smtp (Smail3.1.29.1 #17) id m0v4Plh-0008vjC; Sat, 21 Sep 96 03:58 PDT Received: (from apl@localhost) by apocalypse.tky.hut.fi (8.7.6/8.7.3) id NAA27875; Sat, 21 Sep 1996 13:55:25 +0300 (EET DST) Date: Sat, 21 Sep 1996 13:55:25 +0300 (EET DST) From: Antti-Pekka Liedes To: current@freebsd.org Subject: gcc 2.7.2.1 of -current does not work with objective-C Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-current@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The gcc 2.7.2.1 shipped with current (960920) doesn't compile objective-C correctly. All programs fail with floating point exception, even if there are no floating point operations. Here's a related news article: ------ snip ------ >From nntp.hut.fi!news.csc.fi!news.eunet.fi!EU.net!usenet1.news.uk.psi.net!uknet!tank.news.pipex.net!pipex!newsfeed.internetmci.com!news.mathworks.com!uunet!in2.uu.net!news.voicenet.com!news2.noc.netcom.net!noc.netcom.net!ixnews1.ix.netcom.com!netcom.com!j lemon Wed May 29 19:26:48 1996 Newsgroups: comp.lang.objective-c Path: nntp.hut.fi!news.csc.fi!news.eunet.fi!EU.net!usenet1.news.uk.psi.net!uknet!tank.news.pipex.net!pipex!newsfeed.internetmci.com!news.mathworks.com!uunet!in2.uu.net!news.voicenet.com!news2.noc.netcom.net!noc.netcom.net!ixnews1.ix.netcom.com!netcom.com! jlemon From: jlemon@netcom.com (Jonathan Lemon) Subject: Re: FPE with gcc 2.7.2 on FreeBSD Message-ID: Organization: NETCOM On-line Communication Services (408 261-4700 guest) References: <4o7t8e$rob@nntp.hut.fi> Distribution: inet Date: Tue, 28 May 1996 18:54:18 GMT Lines: 75 Sender: jlemon@netcom22.netcom.com In article <4o7t8e$rob@nntp.hut.fi>, Antti-Pekka Liedes wrote: > >Any ideas why objc runtime system causes FPE on FreeBSD? Gdb says it happens >on line 210 of sendmsg.c. It happens only with gcc 2.7.2, not with 2.6.3. >Both FreeBSD 2.1.0R and 2.2-SNAP-960501 cause the same FPE. The FAQ >mentioned similar problem on Linux, but said nothing about FreeBSD, are the >problems related? Yes - the problem is a bug in gcc 2.7.2, and probably occurrs on all x86 chips. My old posting is attached below. -- Jonathan >From jlemon@netcom.com Sat May 4 11:06:44 PDT 1996 Article: 5087 of comp.lang.objective-c Xref: netcom.com comp.lang.objective-c:5087 Newsgroups: comp.lang.objective-c Path: netcom.com!jlemon From: jlemon@netcom.com (Jonathan Lemon) Subject: ObjC runtime error - FIXED Message-ID: Cc: bug-gcc@prep.ai.mit.edu Organization: NETCOM On-line Communication Services (408 261-4700 guest) Date: Tue, 16 Apr 1996 19:38:38 GMT Lines: 44 Sender: jlemon@netcom22.netcom.com Earlier, I posted about getting SIGFPE on some working ObjC code that I had recompiled under the 2.7.2 compiler. Well, after learning more than I ever wanted to know about the internals of gcc, I managed to track down the problem - patch follows. In summary, when compiling __builtin_apply_args(), gcc turns this into a function call, and then somehow expects the call's return value to appear on the FP stack. When it then pops the stack to store the value in memory, an error condition is set. When the _next_ FP instruction comes along, a SIGFPE is generated. This was on a Sequent Symmetry v2.1.X (i486-based platform), but I imagine that this should fix the problem under linux as well. Does anyone know how to get this patch fed into the compiler distribution? I'm not a compiler expert, so I'm not sure if this is the optimal fix; but it does fix the problem that I was having. -- Jonathan =================================== cut here =================================== *** i386.md.orig Mon Aug 21 12:27:58 1995 --- i386.md Tue Apr 16 09:32:32 1996 *************** *** 5312,5321 **** --- 5312,5327 ---- coprocessor registers as containing a possible return value, simply pretend the untyped call returns a complex long double value. */ + #if 0 + /* this may be part of (set (reg: ..) (call_insn ...)), and we can't + directly set a fp register from the call. so we revert to the + old behavior */ emit_call_insn (TARGET_80387 ? gen_call_value (gen_rtx (REG, XCmode, FIRST_FLOAT_REG), operands[0], const0_rtx) : gen_call (operands[0], const0_rtx)); + #endif + emit_call_insn (gen_call (operands[0], const0_rtx, NULL, const0_rtx)); for (i = 0; i < XVECLEN (operands[2], 0); i++) { ------ snip ------ Applying this patch fixed the problem for me. Antti-Pekka Liedes * apl@IRC * In two hells, there's JMT 7 A 131 * apl@cs.hut.fi * one hell too many 02150 ESPOO * apl@apocalypse.tky.hut.fi * - Lucifer (in God's Army)