🚀 go-pugleaf

Hi,

thanks for the very (!) quick help to kenner@vlsi1.ultra.nyu.edu (Richard 
Kenner). The problem really seems to be a bug in gcc (2.7.2 and 2.7.2.1) and 
can be fixed with the following patch:

----- cut here ------
diff -Nc config/i386/i386.md.orig config/i386/i386.md
*** config/i386/i386.md.orig    Mon Aug 21 17:27:58 1995
--- config/i386/i386.md Sun Jan 19 14:26:31 1997
***************
*** 5312,5321 ****
--- 5312,5324 ----
       coprocessor registers as containing a possible return value,
       simply pretend the untyped call returns a complex long double
       value.  */
+   /*
    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));
+   */
+   emit_call_insn (gen_call (operands[0], const0_rtx, NULL, const0_rtx));
  
    for (i = 0; i < XVECLEN (operands[2], 0); i++)
      {
------ cut here ------

This patch is for gcc-2.7.2.1 but should also work for gcc-2.7.2.
This experience shows also that the not officially supported patch
gcc-2.7.2-2.7.2p-pl9.diff introduces new bugs (at least if you want to work 
with Objective-C) and therefore cannot really be recommended.

Have fun,

  Marcus.