public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: "Cheryl Fillekes" <cherylf@clear.net.nz>
To: <egcs@cygnus.com>, <egcs-bugs@cygnus.com>
Cc: <henshaw@lanl.gov>
Subject: rotten egcs causing gas pains
Date: Sun, 17 May 1998 17:58:00 -0000	[thread overview]
Message-ID: <199805172030.IAA22590@fep1-orange.clear.net.nz> (raw)

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

             reply	other threads:[~1998-05-17 17:58 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-05-17 17:58 Cheryl Fillekes [this message]
1998-05-17 21:14 ` Gerald Pfeifer
1998-05-17 22:03 ` Jeffrey A Law
1998-05-17 22:28   ` David S. Miller
1998-05-18 22:49     ` Jim Wilson
1998-05-18  6:02 ` ralf

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199805172030.IAA22590@fep1-orange.clear.net.nz \
    --to=cherylf@clear.net.nz \
    --cc=egcs-bugs@cygnus.com \
    --cc=egcs@cygnus.com \
    --cc=henshaw@lanl.gov \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).