This is the mail archive of the
mailing list for the GCC project.
Re: Bad code generation on HPPA platform
- From: Jeff Law <law at redhat dot com>
- To: Steve Ellcey <sje at cup dot hp dot com>
- Cc: andrew_pinski at playstation dot sony dot com, dave at hiauly1 dot hia dot nrc dot ca, gcc at gcc dot gnu dot org, bergner at vnet dot ibm dot com
- Date: Thu, 08 May 2008 01:00:03 -0600
- Subject: Re: Bad code generation on HPPA platform
- References: <200805071445.HAA04364@hpsje.cup.hp.com>
Steve Ellcey wrote:
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.
Steve Ellcey wrote:
I'm well versed with the problems in this area and I'd be very leery of
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
184.108.40.206) 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 <email@example.com>
* 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:
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?
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
Can you describe better what you're seeing in the 220.127.116.11 build that's
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.
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.