This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: CSE bug (gcc.c-torture/execute/980605-1.c)
- To: "David S. Miller" <davem at dm dot cobaltmicro dot com>
- Subject: Re: CSE bug (gcc.c-torture/execute/980605-1.c)
- From: Jeffrey A Law <law at cygnus dot com>
- Date: Mon, 06 Jul 1998 13:31:32 -0600
- cc: carlo at runaway dot xs4all dot nl, egcs at cygnus dot com
- Reply-To: law at cygnus dot com
In message <199807061607.JAA30419@dm.cobaltmicro.com>you write:
>
> Don't fear, Jeff wrote a more complete fix and checked it in last
> night. But I believe you are looking at a different bug.
>
> However I want to mention that I think fundamentally the problem
> exposed with this CSE bug still exists generically, even with Jeff's
> fix. I do not believe that everyone in the compiler who rewrites
> insns within' a libcall block properly update the REG_EQUAL notes at
> the end. I could argue that every call to validate_change() should
> check for this situation, but even then all possible cases won't be
> handled.
This should only be an issue in cse/cse2 (and thus the passes that
run between cse & cse2.
We know gcse does the wrong thing (and I've got a patch for it from
Joern that I'll be looking at shortly).
> Jeff, when I showed my version of the patch to a few people I was
> cautioned that I might have broken the SH target because it does very
> strange things with libcalls. Did you check to see if your version of
> the changes have this effect? Essentially I believe they make a
> multiply or some other insn which clobbers a lot of hard registers
> look like a libcall so that CSE can still occur in their presence.
The sh's port's handling of libcalls is broken. Interestingly enough
we've got a nice little thread going inside Cygnus on the sh port's
libcall code and how to fix it.
jeff