Bad code generation on HPPA platform

[Jeff Law]

Steve Ellcey wrote:
>> Steve Ellcey wrote:
>>> I am investigating a bad code generation bug on the 64 bit HPPA platform
>>> with GCC 4.3.0 and would like some help and/or ideas on how to analyze
>>> and fix it.  The failing test is the SPEC 2000 GCC benchmark (version
>>> 2.7.2.2) and I have been unable to create a smaller test case so far.
>>>
>>> What I have found is that if I build GCC from version 127633 (after
>>> applying the patch for PR middle-end/33029 so that the build will work)
>>> I can build and run the SPEC GCC benchmark.  If I update GCC to version
>>> 127634 then the benchmark will abort when it is run.
>>>
>>> The difference between those versions is this patch:
>>>
>>>     2007-08-19  Andrew Pinski  <andrew_pinski@playstation.sony.com>
>>>          PR middle-end/32940
>>>          * cfgexpand.c  (expand_one_register_var): Mark pointer
>>>          DECL_ARTIFICIAL as REG_POINTER also.
>>>          * stmt.c (expand_decl): Likewise.
>>>
>>> In the PR report for 32940 there is a pointer to:
>>>
>>> 	http://gcc.gnu.org/ml/gcc-patches/2004-06/msg00020.html
>>>
>>> That patch fixed a bootstrap problem on HPPA and reverting it (which is
>>> what the patch for PR 32940 seems to do) seems to be reintroducing the
>>> problem that the earlier patch was intended to fix.  While reverting
>>> that patch didn't seem to cause bootstrap problems it does seem to cause
>>> problems when building the older GCC version that is in SPEC2000.  Any
>>> advise on how to proceed from here?
>>>
>>> Steve Ellcey
>>> sje@cup.hp.com
>> I'm well versed with the problems in this area and I'd be very leery of
>> Andrew's patch.  There are some thorny issues in this space and I'm
>> far from 100% sure that blindly propagating a pointer type into 
>> REG_POINTER is always valid, particularly for compiler generated 
>> temporaries.
>>
>> Can you describe better what you're seeing in the 2.7.2.2 build that's 
>> causing problems?
>>
>> Jeff
> 
> I am having trouble figuring out exactly what change in the generated
> code is causing the failure.  The code still compiles but it aborts when
> I run the compiled code.  In talking to David Anglin I do think it is a
> problem with a base reg and index reg getting mixed up but I can't
> put my finger on exactly where.
Hmmm, I missed the fact that this was pa64, not pa32.  It's been so 
long, I can't remember how PA64 HPUX sets up its spaces and whether or 
not that's likely to effect things in relevant ways.

If it aborts, as in calling abort, rather than segfaulting, then it's 
not a flipped base/index in a memory reference -- those almost always 
segfault.  This is the case that most worries me about Andrew's patch.

Virtual origins in Ada in particular can break with Andrew patch. 
Triggering the problem might be hard, but there's little doubt in my 
mind that setting REG_POINTER on every compiler temporary with a pointer 
type is a bad idea.  THe cases I've seen in old source code effectively 
mimicked Ada's virtual origins in C (which result in undefined behavior 
as you get pointers outside the object they're supposed to point to).

The aliasing code queries REG_POINTER to determine how to analyze an 
address.  You could be getting REG_POINTER on an index and mucking up 
the analysis that way.  Or we could simply be getting better information 
into the aliasing code, which in turn may be exposing aliasing problems 
in the older code you're compiling.

Jeff