This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/20126] [3.3/3.4/4.0/4.1 Regression] Inlined memcmp makes one argument null on entry
- From: "roger at eyesopen dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 10 Apr 2005 03:18:41 -0000
- Subject: [Bug target/20126] [3.3/3.4/4.0/4.1 Regression] Inlined memcmp makes one argument null on entry
- References: <20050221214433.20126.jkohen@users.sourceforge.net>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From roger at eyesopen dot com 2005-04-10 03:18 -------
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On 9 Apr 2005, Alexandre Oliva wrote:
> On Apr 8, 2005, Roger Sayle <roger@eyesopen.com> wrote:
>
> > ++ /* If there isn't a volatile MEM, there's nothing we can do. */
> > ++ || !for_each_rtx (&object, volatile_mem_p, 0)
>
> This actually caused crashes. We don't want to scan the entire insn
> (it might contain NULLs), only the insn pattern.
Argh! Indeed, my mistake/oversight. Thanks.
> PR target/20126
> * loop.c (loop_givs_rescan): If replacement of DEST_ADDR failed,
> set the original address pseudo to the correct value before the
> original insn, if possible, and leave the insn alone, otherwise
> create a new pseudo, set it and replace it in the insn.
> * recog.c (validate_change_maybe_volatile): New.
> * recog.h (validate_change_maybe_volatile): Declare.
This is OK for mainline, thanks. Now that 4.0 is frozen for release
candidate one, Mark needs to decide whether this patch can make it
into 4.0.0 or will have to wait for 4.0.1. I also think we should
wait for that decision before considering a backport for 3.4.x (or
we'll have a strange temporal regression).
I'd recommend commiting this patch to mainline ASAP, so it can have
a few days of testing before Mark has to make his decision.
Thanks again for your patience,
Roger
--
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126