gas-971208 mips64orion-rtems internal error

gas-971208 mips64orion-rtems internal error

[Joel Sherrill]

The public domain floating point test paranoia when compiled by egcs 1.0
generates code which causes an internal error in gas.  I have cut the code
down to the following:

        .file   1 "p1.c"

 # -G value = 8, Cpu = 4650, ISA = 3
 # GNU C version egcs-2.90.21 971202 (egcs-1.00 release)
(mips64orion-rtems) compiled by GNU C version 2.7.2.
 # options passed:  -mcpu=4650
 # options enabled:  -fpeephole -ffunction-cse -fkeep-static-consts
 # -fpcc-struct-return -fcommon -fverbose-asm -fgnu-linker
-fargument-alias
 # -mgas -mfp64 -mgp64 -meb -mcpu=4650

gcc2_compiled.:
__gnu_compiled_c:
        .globl  One
        .align  3
One:
        .word   0x3ff00000              # 1
        .word   0x00000000
        .globl  paranoia
        .ent    paranoia
paranoia:
        .frame  $fp,72,$31              # vars= 8, regs= 3/1, args= 32,
extra= 0
        .mask   0xc0010000,-16
        .fmask  0x00100000,-8
        s.d     $f0,One

which when assembled as follows:

mips64orion-rtems-as -mcpu=4650 -v p1.s

generates this error message:

p1.s: Assembler messages:
p1.s:23: Internal error!
Assertion failure in macro_build at ../../src/gas/config/tc-mips.c line
2365.
Please report this bug.

This file assembles with a warning about the missing ".end or .bend" with
binutils 2.8.1.

Thanks.

--joel 
Joel Sherrill                    Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (205) 722-9985

Re: gas-971208 mips64orion-rtems internal error

[Ian Lance Taylor]

   Date: Sat, 20 Dec 1997 13:00:40 -0600 (CST)
   From: Joel Sherrill <joel@OARcorp.com>

	   s.d     $f0,One

   which when assembled as follows:

   mips64orion-rtems-as -mcpu=4650 -v p1.s

   generates this error message:

   p1.s: Assembler messages:
   p1.s:23: Internal error!
   Assertion failure in macro_build at ../../src/gas/config/tc-mips.c line
   2365.
   Please report this bug.

Interesting.  Reporting the error in this manner is clearly a bug in
gas.

However, as far as I can tell, the input is not valid for the 4650.
The 4650 has only single precision floating point, which means that it
can not support the s.d instruction for a floating point register.  It
doesn't make any sense.

So I think there must be a compiler bug here as well.

I'll fix the bug in the assembler to report the error in a more
coherent fashion.

Ian

Re: gas-971208 mips64orion-rtems internal error

[Joel Sherrill]

On Mon, 22 Dec 1997, Ian Lance Taylor wrote:

>    generates this error message:
> 
>    p1.s: Assembler messages:
>    p1.s:23: Internal error!
>    Assertion failure in macro_build at ../../src/gas/config/tc-mips.c line
>    2365.
>    Please report this bug.
> 
> Interesting.  Reporting the error in this manner is clearly a bug in
> gas.
> 
> However, as far as I can tell, the input is not valid for the 4650.
> The 4650 has only single precision floating point, which means that it
> can not support the s.d instruction for a floating point register.  It
> doesn't make any sense.
> 
> So I think there must be a compiler bug here as well.
> 
> I'll fix the bug in the assembler to report the error in a more
> coherent fashion.

Thanks.  This certainly turned out to be more interesting than I
expected. :)

Should I just report this to the egcs list then along with the original
offensive C program  Is there something I can do to help make this one
easier to find?  It seems pretty weird.

--joel

Re: gas-971208 mips64orion-rtems internal error

[Ian Lance Taylor]

   Date: Mon, 22 Dec 1997 11:27:44 -0600 (CST)
   From: Joel Sherrill <joel@OARcorp.com>

   Should I just report this to the egcs list then along with the original
   offensive C program

Yeah, I guess so.

   Is there something I can do to help make this one
   easier to find?  It seems pretty weird.

It's probably pretty easy to fix.  There's probably just a missing
TARGET_DOUBLE_FLOAT somewhere in mips.md or mips.c.

The 4650 is not a particularly common chip, so it's quite plausible
that changes to the MIPS code have introduced bugs in the 4650
support.

It's also possible that my analysis is wrong, although it seems right
to me.

Ian