MIPS GAS BUG

[Cheryl Fillekes]

Hi, gnu.utils bug-fixing community!  I have something fun and easy
for you to work on!  A bug whose location in the code has been found,
one that's even well-commented and recognized!  

Who could ask for  more?  

> In the file binutils-2.9.1/config/tc-mips.c, just preceding line 9451
> is a 'FIXME' comment, indicating that indeed this is still a problem:   

"It would be possible in principle to handle conditional branches
which overflow.  They could be transformed into a branch around a
jump.  This would require setting up variant frags for each different
branch type.  The native MIPS assembler attempts to handle these
cases, but it appears to do so incorrectly."  

I'm going to request again that this be fixed on the grounds that:

1) it is a well-known bug.  Several people who have been working with
egcs and gcc/g++ have run into the same problem.  No assembler 
should choke on legal assembly code produced by a compiler.  Period.

2) using IRIX native MIPS as doesn't actually fix this problem, and in fact
creates a number of new problems

3) it is a bug that will come up increasingly as people use linux on 
MIPS machines, and as more and more legacy numerical code
is ported to these machines.  i.e. if you don't fix it now, you'll have
to fix it later, anyway.  

4) it is an *easy* bug to fix for anyone who knows MIPS assembler
(I don't) since it's already been identified exactly where in the code
this bug can be fixed, and it's already been described what needs
to be done.  


Cheryl Fillekes, Ph.D.
http://www.santafe.edu/~cheryl
===============================================

> Date: Monday, May 18, 1998 4:19 PM
> From: David S. Miller <davem@dm.cobaltmicro.com>

> Actually there is one frequently compiled piece of code which hits
> this, the lat_ctx benchmark from Lmbench version 1.0
> This is where I first saw it.  Early on most people didn't see it
> since gcc was configured almost always using the IRIX assembler and
> linker.  But now that binutils is more up to snuff on IRIX systems,
> and also is used always on Linux MIPS systems, it will become more of
> an ordeal.
> 
> Last I spoke to Richard Henderson about this problem, it's really not
> terribly difficult to fix, because once you have that piece of code in
> tc-mips.c output the necessary instructions, the process will continue
> recursively fixing up any new relocs generated etc.