Date: Sat, 21 Sep 1996 13:55:25 +0300 (EET DST) From: Antti-Pekka Liedes <apl@apocalypse.tky.hut.fi> To: current@freebsd.org Subject: gcc 2.7.2.1 of -current does not work with objective-C Message-ID: <Pine.BSF.3.91.960921135017.27866A-100000@apocalypse.tky.hut.fi>
next in thread | raw e-mail | index | archive | help
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: <jlemonDs4puJ.I1H@netcom.com>
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 <apl@hutcs.cs.hut.fi> 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: <jlemonDpyzwF.5Do@netcom.com>
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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.91.960921135017.27866A-100000>