Re: Bad code generation on HPPA platform

[Steve Ellcey <sje at cup dot hp dot com>]

Jeff Law wrote:

> And just to be certain, we've used a recent GCC trunk to compile an old 
> rev of gcc (2.7 era?), which is then segfaulting when it's trying to 
> compile code, right?

Correct, I am using GCC 4.3.0 to compile the old (2.7) GCC and when I
run that old GCC it segfaults.  If I start with the ToT GCC instead of
4.3.0 GCC I have no problems.

> Assuming that's the case, I'd start by identifying the pseudos 
> corresponding to %r19 and %r8 and verify that the one associated with 
> %r8 has REG_POINTER set and %r19 is not yet.  Then work backwards to 
> find out how REG_POINTER on the pseudo associated with %r8 was set.

I have looked at the psuedo that started getting marked with REG_POINTER
after Andrew's change.  It corresponds to basic_block_live_at_end[i] and
this is a pointer (basic_block_live_at_end is an array of pointers), so
I don't believe (at least in this instance) that Andrews patch is
incorrectly marking something as a pointer when it isn't.

> Also be careful that tail merging hasn't merged two threads of control 
> which it thought were identical, but where in one thread of control 
> you've got %r8/%r19 as the base/index and in the other thread of control 
> you've got %r19/%r8 as the base/index (they are identical in 
> functionality on any sane target :-).  I fixed that eons ago, but it's 
> always possible it's reared its ugly head again.

The psuedo for %r8 does have REG_POINTER set and the psuedo for %r19
does not.  I first see REG_POINTER set for ivtmp___1536 (the psuedo for
%r8) in flow.c.138r.loop2_invariant.  This seems interesting because
Peter's patch, that fixes this problem without undoing Andrews patch,
includes a change to loop-invariant.c, though that change should be
preserving REG_POINTER's during optimization not preventing them.

I have tested a port of Peter's changes (already on the main line) to
the 4.3 branch.  It does fix the problem and it causes no regressions on
hppa.  My current inclination is to submit that patch to gcc-patches as
a backport to the branch.

Steve Ellcey
sje@cup.hp.com