This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: target/8087: sparc-sun-solaris2.7 C testsuite failures inexecute/20020720-1.c w/-m64 or on sparcv9/sparc64
- From: Roger Sayle <roger at eyesopen dot com>
- To: Richard Henderson <rth at redhat dot com>
- Cc: "David S. Miller" <davem at redhat dot com>, <ghazi at caip dot rutgers dot edu>, <gcc-bugs at gcc dot gnu dot org>, <jakub at redhat dot com>
- Date: Thu, 3 Oct 2002 17:26:51 -0600 (MDT)
- Subject: Re: target/8087: sparc-sun-solaris2.7 C testsuite failures inexecute/20020720-1.c w/-m64 or on sparcv9/sparc64
On Thu, 3 Oct 2002, Richard Henderson wrote:
> I don't think this is combine's job. It's job is to smush together
> machine instructions to make cisc-y things. It does that job
> reasonably well.
>
> What you're looking for is another kind of CSE.
In that case, the reasonable thing to do is to mark 20020720-1.c as
XFAIL on sparc64-*-* and "sparc -m64". Those processors that benefit
from combine's ability to smush instructions into an unconditional
jump are just lucky, and failing to do so isn't a bug or deficiency
of the target backend.
Perhaps, in the middle term, I'll come back to modifying the CSE pass
to attempt multiple independent substitutions of an insn. That should
have the benefit of bringing "all the pieces together" and checking
the REG_EQUAL notes.
Could someone suggest a patch to gcc.c-torture/execute/20020720-1.x
that disables the test on sparc-*-* only when -m64 is specified?
Roger
--