This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: [Bug target/11156] New: new bootstrap failure on mips-sgi-irix6.5 stage2 libgcc2 fp-bit.c
- From: Richard Sandiford <rsandifo at redhat dot com>
- To: ghazi at gcc dot gnu dot org
- Cc: gcc-bugs at gcc dot gnu dot org
- Date: 12 Jun 2003 16:01:56 +0100
- Subject: Re: [Bug target/11156] New: new bootstrap failure on mips-sgi-irix6.5 stage2 libgcc2 fp-bit.c
- References: <20030611172045.11156.ghazi@gcc.gnu.org>
"ghazi@gcc.gnu.org" <gcc-bugzilla@gcc.gnu.org> writes:
> PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
> Sometime between June 7 and June 8, I started getting a new bootstrap failure
> on mainline for mips-sgi-irix6.5 in stage2 building libgcc2. It looks like
> this:
>
> fp-bit.c: In function `__pack_f':
> fp-bit.c:205: internal compiler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <URL:http://gcc.gnu.org/bugs.html> for instructions.
> make[3]: *** [libgcc/./_pack_sf.o] Error 1
Ah, so it _isn't_ just me ;)
I believe it's a bug in the native irix assembler. In fold(),
we have the code:
.set noreorder
.set nomacro
bne $2,$0,.L3414
move $6,$2
.set macro
.set reorder
which gets assembled as:
2caf4: 10400004 beqz v0,2cb08 <.LCFI407+0x184fc>
2caf8: 8f810001 lw at,1(gp)
2caf8: R_MIPS_GOT16 .text+0x14fd0
2cafc: 24214fd0 addiu at,at,20432
2cafc: R_MIPS_LO16 .text
2cb00: 00200008 jr at
2cb04: 00000000 nop
2cb08: 00403025 move a2,v0
In other words, the bne has been changed into a long branch sequence,
I'm suprised the assembler does this for branches inside a set
noreorer/set nomacro block, especially given that the original
branch _was_ within range.
Anyway, the problem is that delay slot insn is now only executed
when the branch isn't taken.
I'm not sure what's triggered it. It might be the recent growth in
fold(), or it might be related to the 'label in delay slot' problem
that was seen on sparc (the irix assembler warns about the same thing).
But whatever caused it, it's still a bug in the assembler.
Richard