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: "aoliva at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 8 Apr 2005 20:51:29 -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 aoliva at gcc dot gnu dot org 2005-04-08 20:51 -------
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On Apr 8, 2005, Roger Sayle <roger@eyesopen.com> wrote:
> Ahh, I now see the misunderstanding; you changed/fixed the other
> "safe" gcc_assert statement, and missed the important one that I was
> worried about. Sorry for the confusion.
Yep. Doh!
> Secondly:
> + if (volatile_ok
> + /* Make sure we're not adding or removing volatile MEMs. */
> + || for_each_rtx (loc, volatile_mem_p, 0)
> + || for_each_rtx (&new, volatile_mem_p, 0)
> + || ! insn_invalid_p (object))
> + return 0;
> The suggestion wasn't just to reorder the existing for_each_rtx to
> move these tests earlier, it was to confirm that the original "whole"
> instruction had a volatile memory reference in it, i.e. that this is
> a problematic case, before doing any more work.
Aaah. Clearly, I wasn't thinking right when I made the change. I'll
test your suggested change along with the gcc_assert fix.
> Sorry again for the inconvenience,
No worries. I shouldn't have rushed to making the changes and
starting a bootstrap before going to bed on a night when I was so
tired :-/
I'll post the patch when testing is complete.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126