rotten egcs causing gas pains

rotten egcs causing gas pains

[Cheryl Fillekes]

I am running egcs 1.0.2 on an SGI Indigo2 EX with IRIX 5.3.

Most of the codes that have produced "Relocation Overflow"
under binutils-2.7 gas were possible to (eventually) compile by 
just fiddling with  the optimization and debug flags a bit.  

One 2393-line .C file is just being  stubborn, however.  I upgraded 
to binutils-2.9.1 gas, to find that  "Relocation Overflow" error now
calls itself "Branch out of range."  

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've asked gnu.utils.bug if they are working on applying this FIXME
possibly.

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.

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.

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.  

Any suggestions?  Thanks.

Cheryl

Re: rotten egcs causing gas pains

[Gerald Pfeifer]

On Mon, 18 May 1998, Cheryl Fillekes wrote:
> 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.

Actually the message is quite clear: The ANSI/ISO C++ committee decided to
fix a bug in the C++ language specification (Personally I didn't like the
old behaviour already more than 10 years ago! ;-).

Thus, what used to be valid code, now has different semantics. egcs
detects old code and provides a work-around for it.

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

This should not platform dependent and I'm quite sure that with exactly
the same options you're using also he will get the very same warnings.

Unless there is a real compiler bug, that is, but without seeing the
code in question this is impossible to decide.

> Any suggestions?  Thanks.

 o Have the original author use the very same options as you.
 o Possibly have the original author update to egcs 1.0.3 or a current
   snapshot.
 o If he gets the same warnings, his code quite surely is not ISO C++
   compliant and he should fix it.
 o If he doesn't get these warnings or you really believe egcs is in
   error, please provide source code (a minimal example, if possible).

Hope this helps,
Gerald
-- 
Gerald Pfeifer (Jerry)      Vienna University of Technology
pfeifer@dbai.tuwien.ac.at   http://www.dbai.tuwien.ac.at/~pfeifer/

Re: rotten egcs causing gas pains

[Jeffrey A Law]

  In message < 199805172030.IAA22590@fep1-orange.clear.net.nz >you write:
  > One 2393-line .C file is just being  stubborn, however.  I upgraded 
  > to binutils-2.9.1 gas, to find that  "Relocation Overflow" error now
  > calls itself "Branch out of range."  
  > 
  > 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:   
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.


  > "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've asked gnu.utils.bug if they are working on applying this FIXME
  > possibly.
Sounds good.

  > 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. 
It would be nice.  However, the assembler used for MIPS platforms
makes this task extremely difficult -- it's nontrivial for the
compiler to determine how much space many common instructions
take -- because the assembler treats them as macros which expand
to multiple instructions.

  > 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?  
As far as I know nobody is working on this problem.

  > Or  would a particular type of change made to the source help.
Well, I don't know exactly what's going on, but generally writing
smaller functions helps this kind of problem.  Take big hunks of
code and turn them into subroutines.

  > re-write it.   The author blames the compiler.
Sounds like the right place for the blame, but for the wrong
reasons :-)

jeff

Re: rotten egcs causing gas pains

[David S. Miller]

   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.

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

Re: rotten egcs causing gas pains

[ralf]

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

Re: rotten egcs causing gas pains

[Jim Wilson]

	Actually there is one frequently compiled piece of code which hits
	this, the lat_ctx benchmark from Lmbench version 1.0

A more obvious example is the Ada front end.  If you consider the Ada front
end to be part of gcc, then gcc can't compile itself without optimization
on most MIPS hosts because of this problem.

	 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.

This isn't correct.  GNU as has always been strongly recommended for irix5.
Otherwise, -g will not work, which makes gcc fairly uninteresting.  The
reason few people saw it is because few people have code large enough to
trigger the problem.  It is true however that irix5 users have a workaround
(use SGI as) that linux users don't, so it is more of a problem for linux
users.

Jim