Re: 971122 for arm-coff dies building newlib/libm: testcase attached

Re: 971122 for arm-coff dies building newlib/libm: testcase attached

[Robin Kirkham]

On Fri, 28 Nov 1997, Richard Earnshaw <rearnsha@arm.com> said:
 
> Robin.Kirkham@mlb.dmt.csiro.au said:
> > > Fri Oct 17 13:00:38 EDT 1997  Richard Earnshaw  (rearnsha@arm.com)
> > > 
> > >       * arm.md (movsfcc): If not TARGET_HARD_FLOAT, ensure operand[3] val
> >
> > Richard,
> >
> > Thanks for the patch but I'm afraid to say it made no difference at
> > all! Still the same error with the same testcase. And yes I did check
> > it had applied properly, and a rebuilt egcs in a fresh build
> > directory. 
> 
> You have probably been bitten by "patch" (I just have -- first time 
> ever!).  patch incorrectly applies the patch to the wrong insn (it must be 
> applied to the movsfcc pattern, NOT the movdfcc pattern.  The two insns 
> contained the same body of code, and since I extracted the patch from the 
> gcc2 sources, the line numbers weren't exact.

Yes, that's what happened. 971122 egcs now compiles all of newlib for the
ARM without a problem. Thanks kindly.

Robin Kirkham			CSIRO Manufacturing Science and Technology
Project Engineer		Locked Bag 9, Preston 3072, Australia
robin.kirkham@mlb.dmt.csiro.au	Phone: +61 3 9662-7756  Fax: +61 3 9662-7851

971122 for arm-coff dies building newlib/libm: testcase attached

[Robin Kirkham]

It's possible this is not a configuration that is supposed to work--I was 
just trying this out to prove a point but it backfired a little 8-(

I am not in a position to investigate it much, but I will report the problem
in case anyone is interested in or working on ARM support in egcs.

I built binutils 2.8.1 and egcs 971122 with target configuration arm-coff
(strictly, arm-1-coff) on a sun-sparc-solaris2.5.1 host. The tools and compiler
build without incident, including the gcclib and libstdc++ libraries. Then 
I configured newlib 1.8.0 similarly and started building it. The compiler
failed compiling newlib/libm/math/ef_exp.c. The error was

[much deleted ...]
arm-1-gcc -g -O2  -O2 -DABORT_PROVIDED -fno-builtin 
-I/opt/embedded/src/newlib-1.8.0/build-arm-1-coff/arm-1-coff/newlib/./targ-incl
ude -I/opt/embedded/src/newlib-1.8.0/newlib/./libc/include -c
../../../../../newlib/libm/math/ef_exp.c
../../../../../newlib/libm/math/ef_exp.c: In function `__ieee754_expf':
../../../../../newlib/libm/math/ef_exp.c:102: internal error--unrecognizable 
insn:
(insn 621 66 77 (set (reg:SF 49)
        (if_then_else:SF (eq (reg:CC 24 cc)
                (const_int 0))
            (reg/v:SF 31)
            (const_double:SF (cc0) 0 0))) -1 (insn_list 66 (nil))
    (expr_list:REG_DEAD (reg:CC 24 cc)
        (expr_list:REG_DEAD (reg/v:SF 31)
            (nil))))
arm-1-gcc: Internal compiler error: program cc1 got fatal signal 6
gmake[3]: *** [ef_exp.o] Error 1
gmake[3]: Leaving directory
`/opt/embedded/src/newlib-1.8.0/build-arm-1-coff/arm-1-coff/newlib/libm/math'


I've prepared a single file testcase bad.c (simply using arm-1-gcc -E) which
is attached to this mail. It causes a similar error (below). The compile 
succeeds if you don't use -O.

% arm-gcc -O -c bad.c    
ef_exp.c: In function `__ieee754_expf':
ef_exp.c:102: internal error--unrecognizable insn:

(insn 593 589 77 (set (reg:SF 46)
        (if_then_else:SF (eq (reg:CC 24 cc)
                (const_int 0))
            (reg/v:SF 31)
            (const_double:SF (cc0) 0 0))) -1 (insn_list 66 (nil))
    (expr_list:REG_DEAD (reg:CC 24 cc)
        (expr_list:REG_DEAD (reg/v:SF 31)
            (nil))))
arm-1-gcc: Internal compiler error: program cc1 got fatal signal 6
%

As I say I am not in a position to investigate this, but of course I'll
any addition information if someone wants.

Thanks,

Robin Kirkham			CSIRO Manufacturing Science and Technology
Project Engineer		Locked Bag 9, Preston 3072, Australia
robin.kirkham@mlb.dmt.csiro.au	Phone: +61 3 9662-7756  Fax: +61 3 9662-7851

Re: 971122 for arm-coff dies building newlib/libm: testcase attached

[Richard Earnshaw]

This patch was checked into the gcc2 sources back in October to fix 
precisely this bug.  There are a large number of ARM related patches that 
have been made to the gcc2 tree that have not yet propagated to egcs (ie 
most of them).  I thought there were going to be regular merges of gcc2 
changes into the egcs tree?

Fri Oct 17 13:00:38 EDT 1997  Richard Earnshaw  (rearnsha@arm.com)

        * arm.md (movsfcc): If not TARGET_HARD_FLOAT, ensure operand[3] 
valid.

Re: 971122 for arm-coff dies building newlib/libm: testcase attached

[Jeffrey A Law]

  In message < 199711271232.MAA13804@sun52.NIS.cambridge >you write:
  > most of them).  I thought there were going to be regular merges of gcc2 
  > changes into the egcs tree?
There are going to be regular merges, just not into a release branch just
before a release.

In fact, this change was brought over in a merge we did in the mainline
sources (just to get a feel for the scope of the merge issues) :-)  But
since we don't have the external cvs machine running yet, nobody can get
to the mainline sources right now.

        * arm.md (movsfcc): If not TARGET_HARD_FLOAT, ensure operand[3] 
        valid.
I've installed this patch into the release branch.  Thanks.
jeff