public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "roger at eyesopen dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/20126] [3.3/3.4/4.0/4.1 Regression] Inlined memcmp makes one argument null on entry
Date: Fri, 08 Apr 2005 17:03:00 -0000	[thread overview]
Message-ID: <20050408170326.31227.qmail@sourceware.org> (raw)
In-Reply-To: <20050221214433.20126.jkohen@users.sourceforge.net>


------- Additional Comments From roger at eyesopen dot com  2005-04-08 17:03 -------
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail


Hi Alex,

On 8 Apr 2005, Alexandre Oliva wrote:
> Roger suggested some changes in the patch.  I've finally completed
> bootstrap and test with and without the patch on amd64-linux-gnu, and
> posted the results to the test-results list.  No regressions.  Ok to
> install?

Hmm.  It looks like you misunderstood some of the comments in my
review (comment #16 in the bugzilla PR)...

+  gcc_assert (validate_change_maybe_volatile (v->insn, v->location,
+					       reg));

This is still unsafe.  If you look in system.h, you'll see that when
ENABLE_ASSERT_CHECKING is undefined, the gcc_assert macro gets defined
as:

#define gcc_assert(EXPR) ((void)(0 && (EXPR)))

which means that EXPR will not get executed.  Hence you can't put
side-effecting statements (especially those whose changes you depend
upon) naked inside a gcc_assert.  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.


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.  Something like:

+  if (volatile_ok
++     /* If there isn't a volatile MEM, there's nothing we can do.  */
++     || !for_each_rtx (&object, volatile_mem_p, 0)
+!     /* But 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;

This second change was just a micro-optimization, and I'd have approved
your patch without it, but the use of gcc_assert in loop_givs_rescan is
a real correctness issue.

Sorry again for the inconvenience,

Roger
--



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126


  parent reply	other threads:[~2005-04-08 17:03 UTC|newest]

Thread overview: 64+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-22  1:42 [Bug c/20126] New: " jkohen at users dot sourceforge dot net
2005-02-22  1:44 ` [Bug c/20126] " jkohen at users dot sourceforge dot net
2005-02-22  1:47 ` [Bug target/20126] " pinskia at gcc dot gnu dot org
2005-02-22  1:49 ` jkohen at users dot sourceforge dot net
2005-02-22  1:50 ` pinskia at gcc dot gnu dot org
2005-02-22  1:51 ` pinskia at gcc dot gnu dot org
2005-02-22  2:22 ` [Bug target/20126] [3.3/3.4/4.0 Regression] " pinskia at gcc dot gnu dot org
2005-02-22 15:55 ` jakub at gcc dot gnu dot org
2005-02-22 17:03 ` jakub at gcc dot gnu dot org
2005-03-03  7:04 ` [Bug target/20126] [3.3/3.4/4.0/4.1 " aoliva at gcc dot gnu dot org
2005-03-03  7:07 ` aoliva at gcc dot gnu dot org
2005-03-07 21:57 ` aoliva at redhat dot com
2005-03-07 22:15 ` aoliva at gcc dot gnu dot org
2005-03-09  1:47 ` jakub at redhat dot com
2005-03-09  4:02 ` aoliva at redhat dot com
2005-03-09  8:51 ` jakub at redhat dot com
2005-03-09  9:24 ` jakub at redhat dot com
2005-03-10 11:45 ` aoliva at redhat dot com
2005-03-11 14:30 ` aoliva at redhat dot com
2005-04-02 17:22 ` aoliva at redhat dot com
2005-04-05  4:22 ` roger at eyesopen dot com
2005-04-08 16:34 ` aoliva at redhat dot com
2005-04-08 17:03 ` roger at eyesopen dot com [this message]
2005-04-08 20:51 ` aoliva at redhat dot com
2005-04-10  2:43 ` aoliva at redhat dot com
2005-04-10  3:18 ` roger at eyesopen dot com
2005-04-10  4:01 ` cvs-commit at gcc dot gnu dot org
2005-04-10 18:44 ` mark at codesourcery dot com
2005-04-10 21:00 ` [Bug target/20126] [3.3/3.4/4.0 " pinskia at gcc dot gnu dot org
2005-04-11  3:51 ` aoliva at redhat dot com
2005-04-11 21:11 ` jconner at apple dot com
2005-04-12  3:36 ` aoliva at redhat dot com
2005-04-12  6:59 ` aoliva at redhat dot com
2005-04-12  8:19 ` aoliva at redhat dot com
2005-04-12 14:39 ` roger at eyesopen dot com
2005-04-12 17:55 ` mmitchel at gcc dot gnu dot org
2005-04-13  9:47 ` jakub at redhat dot com
2005-04-13 10:10 ` bernds_cb1 at t-online dot de
2005-04-13 11:39 ` jakub at redhat dot com
2005-04-13 21:01 ` joseph at codesourcery dot com
2005-04-14  6:03 ` mark at codesourcery dot com
2005-04-14  6:14 ` cvs-commit at gcc dot gnu dot org
2005-04-14 17:21 ` aoliva at redhat dot com
2005-04-14 17:38 ` roger at eyesopen dot com
2005-04-15  3:31 ` aoliva at redhat dot com
2005-04-15 14:52 ` roger at eyesopen dot com
2005-04-16 17:50 ` rearnsha at gcc dot gnu dot org
2005-04-16 21:42 ` cvs-commit at gcc dot gnu dot org
2005-04-16 21:49 ` aoliva at redhat dot com
2005-04-16 21:58 ` aoliva at redhat dot com
2005-04-17  0:22 ` roger at eyesopen dot com
2005-04-17  2:38 ` aoliva at redhat dot com
2005-04-17  2:46 ` mmitchel at gcc dot gnu dot org
2005-04-17  3:06 ` roger at eyesopen dot com
2005-05-19 17:28 ` [Bug target/20126] [3.3/3.4 " mmitchel at gcc dot gnu dot org
2005-07-07 19:20 ` [Bug target/20126] [3.4 " uweigand at gcc dot gnu dot org
2005-07-08 12:25 ` aoliva at gcc dot gnu dot org
2005-07-08 15:48 ` uweigand at gcc dot gnu dot org
2005-07-11  3:56 ` cvs-commit at gcc dot gnu dot org
2005-07-12  4:11 ` belyshev at depni dot sinp dot msu dot ru
2005-07-13 22:30 ` uweigand at gcc dot gnu dot org
2005-07-14 18:48 ` aoliva at gcc dot gnu dot org
2005-07-14 21:17 ` cvs-commit at gcc dot gnu dot org
2005-08-04 23:12 ` belyshev at depni dot sinp dot msu dot ru

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050408170326.31227.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).