Fw: rotten egcs causing gas pains

[Cheryl Fillekes]

Richard,

Do you think it would be possible to fix this problem?  Or possibly,
if it is already fixed somewhere, could you please direct me to the 
appropriate patch?

It seems that it is really just a few lines of code in tc-mips.c in the
gas source, but I just don't know any assembly language, and I really
need to comiple these numerical analysis routines so I can get on 
with my own application.  I set out to continue my research on composite
overlapping grid calculations, not debug gnu compilers and assemblers. 

Admittedly, these guys shouldn't  have such large loops in their code.  
They've converted their code from FORTRAN which was hard enough for 
them. You might be aware of the fact that it's hard enough getting 
some programmers  to fix blatant well-known  bugs in their code much 
less make their code elegant, efficient, portable, readable and robust.  

It is true that egcs shouldn't be generating code that gas can't handle 
and gas should be able to correctly parse legal code generated by egcs.  

Do you think that, because it's an easy fix for you, Richard, that you 
could please just fix this bug?  I would be ever so grateful.

Thanks

C. A. Fillekes, Ph.D.
http://www.santafe.edu/~cheryl
----------
In message < 199805172030.IAA22590@fep1-orange.clear.net.nz > I wrote:
> 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:   
(description of Relocation Overflow aka Branch Out of Range error, and 
suggestion of how this bug in the gas mips assembler could be fixed)

>    Date: Sun, 17 May 1998 18:35:13 -0600
>    From: Jeffrey A Law <law@cygnus.com>:
>    Yup.  There's definitely still problems in this area on the MIPS
>    ports.  They're rarely triggered and haven't been a priority to
>    fix.

> 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.
> 
> Later,
> David S. Miller
> davem@dm.cobaltmicro.com

ralf@uni-koblenz.de wrote:
On Mon, May 18, 1998 at 08:23:53AM +1200, Cheryl Fillekes wrote:

> However, it seems to me that it would be reasonable to request
> that egcs  produce as code with no relocation overflow/branch 
> out-of-range errors. 
> 
> Is there a particular egcs/gcc compile option that tends to 
> generate gas code that does not have this problem?  Is there someone
> working on the MIPS version of egcs, and maybe knows about this
> problem, and is maybe working on it?  
> 

> 2380: warning: name lookup for `joe' changed for new ANSI `for' scoping
> 2363: warning: using obsolete binding at `joe'
> 
> shows up for about 20 little indices on for-loops.  It's annoying, 
> and it might be responsible for the "Branch out of range" problem.

No.  The branch problem is a pure assembler problem.  A MIPS assembler
is supposed to expand a branch as a macro in such a case.  One could
solve it in the compiler, but *shiver* ...

...
While gas should do things right the only application I've seen failing due
this
particular bug is an older version of lmbench's lat_ctx.  lat_ctx was
using the huge loop for blowing the cache away. Yes, gas should do things
right.

  Ralf

======================