gcc.dg/funcorder.c failure on pa64 - need advice

[Zack Weinberg]

"John David Anglin" <dave@hiauly1.hia.nrc.ca> writes:

>> to the top of the file makes the test pass.  However, this raises the
>> question of why this test case passes on any target.  I am guessing
>> that on most targets this call is eliminated before we get to calling
>> mark_constant_function, but PA64 presents unusual difficulties for the
>> RTL optimizers, such that the call can't be optimized out until later.
>> I'd like second opinions on (a) whether this is the case, and (b)
>> whether adding the above declaration is the right thing to do, or if
>> not, what should be done instead.
>
> I wrote previously to the gcc list asking for suggestions on this
> failure <http://gcc.gnu.org/ml/gcc/2004-03/msg01228.html>.  Jim Wilson
> suggested that we probably needed to wait for tree-ssa to get this
> fixed.  The test doesn't fail if `t' is long.  The problem is the
> promotion `t' prevents cse/gcse from simplifying the rtl.  Only combine
> is potentially capable of doing it (combine doesn't combine across
> function calls).  However, combine runs after the flow graph analysis.
> As a result, some rather dumb code is generated.

Yeah, I rather thought it was going to be something like that.  And
furthermore, my idea for a workaround (marking link_error pure) is
definitively wrong - a pure function with no return value is a NOP and
can be optimized out irregardless, defeating the test.

> I think the test should be xfailed on hppa64.

Ok.  I will do that.

zw