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

[Zack Weinberg <zack at codesourcery dot com>]

gcc.dg/funcorder.c has been failing on pa64, because the functions 'q'
and 't' are not recognized as pure.  The code doing the recognizing is
mark_constant_function in alias.c, which gives up on any insn in the
function for which nonlocal_set_p or global_reg_mentioned_p is true.
For 'q', the insn that trips it up is

(call_insn 28 27 29 1 (parallel [
            (set (reg:DI 28 %r28)
                (call (mem:SI (symbol_ref/v:DI ("@link_error") <function_decl 800003ffff5a28f0 link_error>) [0 S4 A32])
                    (const_int 64 [0x40])))
            (clobber (reg:DI 1 %r1))
            (clobber (reg:DI 2 %r2))
            (clobber (reg:DI 4 %r4))
            (use (reg:DI 27 %r27))
            (use (reg/f:DI 29 %r29))
            (use (const_int 0 [0x0]))
        ]) -1 (nil)
    (nil)
    (nil))

and the reason it's being tripped up is, CONST_OR_PURE_CALL_P is not
true for this insn, which causes both nonlocal_set_p and
global_reg_mentioned_p to return true.  't' falls afoul of a similar
call_insn.

Looking at the source, the compiler indeed has no reason to believe
that it should treat the call to link_error as pure, and adding

extern void link_error (void) __attribute__ ((pure));

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.

cc:ing Jeff and John as PA backend maintainers, Jan as author of the
test case.

zw