Re: rotten egcs causing gas pains

[Jeffrey A Law <law at cygnus dot com>]

  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