[Bug target/20126] [3.3/3.4/4.0/4.1 Regression] Inlined memcmp makes one argument null on entry

["roger at eyesopen dot com" <gcc-bugzilla@gcc.gnu.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