From mboxrd@z Thu Jan  1 00:00:00 1970
From: ralf@uni-koblenz.de
To: cherylf@clear.net.nz
Cc: egcs@cygnus.com, egcs-bugs@cygnus.com, henshaw@lanl.gov
Subject: Re: rotten egcs causing gas pains
Date: Mon, 18 May 1998 06:02:00 -0000
Message-id: <19980518104749.49530@uni-koblenz.de>
References: <199805172030.IAA22590@fep1-orange.clear.net.nz>
X-SW-Source: 1998-05/msg00627.html

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?  
> 
> Or  would a particular type of change made to the source help.

You seem to have a huge loop or if which contains more than 128kb of
code.  Try to avoid such constructs.  Such a construct might also be
the result of agressive inlining.

> 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* ...

> I did not write the code I'm trying to compile, and have no desire to 
> re-write it.   The author blames the compiler.  It works fine--
> for him -- apparently, under egcs 1.0.1 under "Linux" (no variant
> specified)
> using gas version ??? on a ??? cpu.  It also works, for him, on the "64-bit
> 
> SGI's" again, IRIX and compiler rev unspecified.   
> 
> Upgrading my OS is an expensive proposition, and not guaranteed to work.  

It's not an OS issue.  However all Misc/SGI Riscompiler back to the stuff
included with RISC/os 4.51 did this particular thing right.

I personally consider the problem to be pretty esotheric.  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.  But for most other
code this particular error message seems more to indicate a problem
with poor code.  But yes, gas should do things right.

  Ralf