Xref: news2.mv.net comp.lang.objective-c:1751 comp.os.msdos.djgpp:3458
Newsgroups: comp.lang.objective-c,comp.os.msdos.djgpp
From: jlemon AT netcom DOT com (Jonathan Lemon)
Subject: Re: Objective-C with djgpp v2.0
Message-ID: <jlemonDqw7zJ.Itu@netcom.com>
Cc: luke-adamson AT tamu DOT edu
Organization: NETCOM On-line Communication Services (408 261-4700 guest)
References: <4mf66e$7u5 AT news DOT myriad DOT net>
Date: Sat, 4 May 1996 18:14:06 GMT
Lines: 61
Sender: jlemon AT netcom22 DOT netcom DOT com
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

In article <4mf66e$7u5 AT news DOT myriad DOT net>,
Luke Adamson <luke-adamson AT tamu DOT edu> wrote:
>Hello all,
>
>I've fallen victim to the evil SIGFPE problem using Objective-C and dgjpp.  
>So far, everyone I know using ObjC and djgpp is incurring the same 
>difficulty.
>
>Essentially, djgpp compiles my grok.m without errors or warnings (the file 
>consists of one class, with one - sayHello method, very simple) but when run 
>the executable, it gives:
>
>Exiting due to signal SIGFPE
>Coprocessor not available at eip=000021c9
>[lots of fun ebx ecx, etc, fun.]
>.
>.
>.
>
>I'm not sure if others using Objective C, and djgpp are experiencing the 
>`Coprocessor not available' error, but that SIGFPE problem has been popping 
>up with regularity.
>
>I'm running this on a 386SL.. using the provided fp emulation package.  I 
>know the error also occurs on some 486's.
>
>I _thought_ I saw someone on comp.lang.objective-c post some sort of patch to 
>gcc 2.7.2, involving poor handling of some Objective-C issue, but I can't 
>find the post, and the archive is unavailable, so for all I know, I might 
>have dreamed it.

You didn't dream it - there is a bug in 2.7.2 related to compiling the 
Obj-C runtime.  I've reattached the patch below - you'll need to recompile
djgpp to update the compiler and then recompile libobjc.a to generate the
correct machine code.  I know that this fixes the problem on a 486 class
machine, I don't know if it will fix it on a 386.
--
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++)
      {