egcs-1.1b alpha-dec-osf3.2 internal error in change_address()

[Fergus Henderson]

On 04-Apr-1999, Hans-Peter Nilsson <hp@bitrange.com> wrote:
> (This still happens in current CVS.)
> 
> Regarding your report in
> <URL: http://egcs.cygnus.com/ml/egcs-bugs/1999-03/msg00945.html >.

Thanks for the response.

> Your code uses:
> > register        Word    mr6 __asm__("$15");      
> 
> This is the frame-pointer-register (i.e. internally used by gcc)
> and it is incorrect to use it this way in a program.

Well, OK, I suppose that would be fair enough.  That is news to me,
however.  The GNU C manual does not document that you're not allowed to
use the frame pointer register for a global register variable, and on
the Alpha we have been successfully using it with various different
versions of gcc since 1996/04/30.  We've tested it with about 200,000
lines of Mercury code that gets compiled to millions of lines of
automatically generated C code, and this is the first time we've had a
problem with that.  Indeed, we started using the frame pointer as
a register variable long enough ago now that I had forgotten about it.
I guess we've always understood that using the frame pointer was a bit
questionable, but it did work, so if the intent is to disallow this
then I think it would be a good idea to explicitly state this in the
gcc manual.

But are you sure this is the intent?  Note that the documentation for
global register variables suggests that declaring a global register
variable is similar to using `-ffixed-REG', not `-fcall-used-REG'.
The documentation for `-fcall-saved-REG' and `-fcall-used-REG'
explicitly warns against using those options for the frame pointer,
but in contrast the documentation for `-ffixed-REG' specifically
allows it:

 | `-ffixed-REG'
 |      Treat the register named REG as a fixed register; generated code
 |      should never refer to it (except perhaps as a stack pointer, frame
 |      pointer or in some other fixed role).

I guess my understanding of using the frame pointer or stack pointer as a
global register variable was that this usage was questionable, but allowed.
That is, I thought it was up to the user to ensure that their use of it
did not conflict with gcc's use of it -- for example, by compiling with
`-fomit-frame-pointer' and by writing their C code carefully to ensure
that gcc can always omit the frame pointer, or by only ever reading
the variable, never writing it, or by some other method.  And if the
usage did conflict, then I would expect no error at compile time
(a warning would be nice, of course, but would not be expected),
instead I would just expect nasty things to happen at runtime.
Is this too much to expect?

> I would agree that this failure mode is not good.  Some sanity check
> along what would happen for '-fcall-used-$15' is better, (although
> currently the ICE still happens since gcc does not stop at that first
> error).

Is this a new error?  I don't observe any message at all with egcs-1.2.

> Would that make sense, or is there some reason not to have that check
> there too (other than "not thought about before or code not submitted")?

I would much prefer it if this was a warning, rather than an error.
Particularly for global register variables (we don't really care so much about
the `-f{fixed,call-used,call-saved}-REG' options, since we don't use them).
We've got quite a bit of existing, shipped code which uses $15 on Alphas
and it would be quite unfortunate if the next release of egcs were to
break that code.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: < http://www.cs.mu.oz.au/~fjh >  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.