Re: target/8087: sparc-sun-solaris2.7 C testsuite failures inexecute/20020720-1.c w/-m64 or on sparcv9/sparc64

[Roger Sayle <roger at eyesopen dot com>]

On Thu, 3 Oct 2002, Kaveh R. Ghazi wrote:
> > From: "David S. Miller" <davem@redhat.com>
> >
> >    From: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
> >    Date: Wed, 2 Oct 2002 10:46:13 -0400 (EDT)
> >
> >    So what does that mean with respect to addressing the testcase?
> >    Fixable?  XFAIL it?
> >
> > It think it would be rediculious to mark such a simple piece of C code
> > as XFAIL on any platform.  Roger reverted his changes it appears, so
> > it should pass now.
>
> Er, I don't think what Roger reverted had anything to do with this
> testcase, e.g. I still get the failure with -m64 from last night's
> CVS bootstrap.  Roger?

Correct.  The loop unrolling change that I reverted was unrelated to
the sparc64 failures.  That change itself was only precautionary as
I'd developed a less fragile solution to PR/6405.

Whilst it would appear "rediculous to mark such a simple piece of C
code as XFAIL", its at the very limits of what GCC's optimizers can
actually simplify.  Indeed the many condition code representations
available to backends, have almost required a specific fix for each
target.

It should also be remembered that 20020720-1.c is distilled from an
even simpler(!) FORTRAN test case:

       complex function z2(z1, x)
       complex z1
       real x
       z2 = z1/x
       end

This example requires conditional jumps on all targets that fail
20020720-1.c, but can be optimized to straight line code whenever
20020720-1.c passes.


I think the aggrevating difference between sparc and sparc64 is
that in the former loading from the constant pool is hidden from
GCC's RTL, whilst with the latter it is explicit.  Perhaps the
problem could be fixed by improving avoid_constant_pool_reference?

Roger
--