------- Additional Comments From mark at codesourcery dot com 2005-04-10 18:44 ------- Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
Roger Sayle wrote: > On 9 Apr 2005, Alexandre Oliva wrote: > >>On Apr 8, 2005, Roger Sayle <[EMAIL PROTECTED]> 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). Thanks for alerting me to this one; it does look relatively serious. I've added it to: http://gcc.gnu.org/wiki/Last-Minute%20Requests%20for%204.0.0 and will consider whether it merits a second release-candidate. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
