This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Bad code generation on HPPA platform

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 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  <>
         PR middle-end/32940
         * cfgexpand.c  (expand_one_register_var): Mark pointer
         * 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?

Steve Ellcey
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 build that's causing problems?


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]