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

[Hans-Peter Nilsson <hp at bitrange dot com>]

> On 08-Apr-1999, Richard Henderson <rth@cygnus.com> wrote:
> > In general, yes.  However, I would consider it a serious regression
> > if for Alpha any function that didn't use alloca ever did not have
> > its frame pointer eliminated.  Even at -O0.

Right, at -O0 *as long as you say -fomit-frame-pointer* (or set
flag_omit_frame_pointer in the target).
 And this is not alpha-specific; it's the same for most targets
where fp has no ABI-peculiarity or hardware-specific meaning.

On Fri, 9 Apr 1999, Fergus Henderson wrote:
> So, I agree that you should be allowed to use $15 as a global register
> variable; but I think that in order to make that work, you should compile
> with `-fomit-frame-pointer' (or equivalently with `-O' or `-O2' or higher).

I am opposed to this kind of option-dependency needed to make
code work.  These switches are not normally ABI-specific, and
should not be forced into that meaning; you effectively restrict
the ABI here.

The level of optimization at which flag_omit_frame_pointer is
set, is target-dependent.  If CAN_DEBUG_WITHOUT_FP (as with the
alpha), then it is generally set at 1, else the target itself
has to set it at the appropriate level.

You also have to be make sure that none of the libraries you use
need a frame-pointer (because they will overwrite your asm-reg
variable or vice versa - another effect of a changed ABI).

> The gcc bug is just that gcc should not abort with an internal
> compiler error; ideally it should instead report a better error
> message.  (In fact even generating incorrect code would in some
> respects be better than reporting a spurious ICE;

Generating incorrect code is *never* better than a compile-time
error, even if the compile-time error is as "insane" as an ICE.
(No, I don't mean that there *should* be an ICE if it can be fixed.)
 That's the reasoning behind all those abort:s in gcc for
detected inconsistencies.

> In addition, there is also a problem with fix_register()
> in regclass.c being overly conservative; it should not disallow
> the use of the frame pointer if -fomit-frame-pointer is enabled.
> 
> Does everyone agree with this diagnosis?

Well, I would think this is equivalent to what I wrote, except
for taking the opposite approach regarding allowing the frame
pointer as an explicit asm-reg variable.  To wit: I definitely
agree that the regclass stuff is inconsistent with how I
interpret RTH:s answer; that fp-as-a-reg-variable should be
allowed even with the risks involved.

> I have included a completely untested (I haven't even compiled it)
> patch to regclass.c to address the second problem.

That's the kind of patch to regclass.c I referred to, but think
is wrong.

If this is the kind of approach that is wanted, there should
also be a patch that gives an (non-ICE) error in case the frame
pointer is not eliminated but fp is an asm-reg variable, or
you'd still still face a big problem.  And there's still the
library problem.

> Below is a description of what happens for egcs-1.1.2, running on the
> test case `void foo() {}', with no options.

Yup.  That's generic frame-pointer-elimination handling, nothing
alpha-specific here.

brgds, H-P