public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "aoliva at redhat 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, 11 Mar 2005 14:30:00 -0000 [thread overview]
Message-ID: <20050311143002.4205.qmail@sourceware.org> (raw)
In-Reply-To: <20050221214433.20126.jkohen@users.sourceforge.net>
------- Additional Comments From aoliva at gcc dot gnu dot org 2005-03-11 14:29 -------
Subject: Re: [PR target/20126, RFC] loop DEST_ADDR biv replacement may fail
On Mar 10, 2005, Alexandre Oliva <aoliva@redhat.com> wrote:
> + ??? Should this should search new for new volatile MEMs and reject
> + them? */
Here's a stricter version that does test for this.
Index: gcc/ChangeLog
from Alexandre Oliva <aoliva@redhat.com>
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.
Index: gcc/loop.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/loop.c,v
retrieving revision 1.522
diff -u -p -r1.522 loop.c
--- gcc/loop.c 17 Jan 2005 08:46:15 -0000 1.522
+++ gcc/loop.c 11 Mar 2005 14:17:20 -0000
@@ -5470,9 +5470,31 @@ loop_givs_rescan (struct loop *loop, str
mark_reg_pointer (v->new_reg, 0);
if (v->giv_type == DEST_ADDR)
- /* Store reduced reg as the address in the memref where we found
- this giv. */
- validate_change (v->insn, v->location, v->new_reg, 0);
+ {
+ /* Store reduced reg as the address in the memref where we found
+ this giv. */
+ if (validate_change_maybe_volatile (v->insn, v->location,
+ v->new_reg))
+ /* Yay, it worked! */;
+ /* Not replaceable; emit an insn to set the original
+ giv reg from the reduced giv. */
+ else if (REG_P (*v->location))
+ loop_insn_emit_before (loop, 0, v->insn,
+ gen_move_insn (*v->location,
+ v->new_reg));
+ else
+ {
+ /* If it wasn't a reg, create a pseudo and use that. */
+ rtx reg, seq;
+ start_sequence ();
+ reg = force_reg (v->mode, *v->location);
+ seq = get_insns ();
+ end_sequence ();
+ loop_insn_emit_before (loop, 0, v->insn, seq);
+ gcc_assert (validate_change_maybe_volatile (v->insn, v->location,
+ reg));
+ }
+ }
else if (v->replaceable)
{
reg_map[REGNO (v->dest_reg)] = v->new_reg;
Index: gcc/recog.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/recog.c,v
retrieving revision 1.221
diff -u -p -r1.221 recog.c
--- gcc/recog.c 7 Mar 2005 13:52:08 -0000 1.221
+++ gcc/recog.c 11 Mar 2005 14:17:22 -0000
@@ -235,6 +235,45 @@ validate_change (rtx object, rtx *loc, r
return apply_change_group ();
}
+
+/* Function to be passed to for_each_rtx to test whether a piece of
+ RTL contains any mem/v. */
+static int
+volatile_mem_p (rtx *x, void *data ATTRIBUTE_UNUSED)
+{
+ return (MEM_P (*x) && MEM_VOLATILE_P (*x));
+}
+
+/* Same as validate_change, but doesn't support groups, and it accepts
+ volatile mems if they're already present in the original insn. */
+
+int
+validate_change_maybe_volatile (rtx object, rtx *loc, rtx new)
+{
+ int result;
+
+ if (validate_change (object, loc, new, 0))
+ return 1;
+
+ if (volatile_ok || ! insn_invalid_p (object))
+ return 0;
+
+ /* Make sure we're not adding or removing volatile MEMs. */
+ if (for_each_rtx (loc, volatile_mem_p, 0)
+ || for_each_rtx (&new, volatile_mem_p, 0))
+ return 0;
+
+ volatile_ok = 1;
+
+ gcc_assert (! insn_invalid_p (object));
+
+ result = validate_change (object, loc, new, 0);
+
+ volatile_ok = 0;
+
+ return result;
+}
+
/* This subroutine of apply_change_group verifies whether the changes to INSN
were valid; i.e. whether INSN can still be recognized. */
Index: gcc/recog.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/recog.h,v
retrieving revision 1.55
diff -u -p -r1.55 recog.h
--- gcc/recog.h 7 Mar 2005 13:52:09 -0000 1.55
+++ gcc/recog.h 11 Mar 2005 14:17:22 -0000
@@ -74,6 +74,7 @@ extern void init_recog_no_volatile (void
extern int check_asm_operands (rtx);
extern int asm_operand_ok (rtx, const char *);
extern int validate_change (rtx, rtx *, rtx, int);
+extern int validate_change_maybe_volatile (rtx, rtx *, rtx);
extern int insn_invalid_p (rtx);
extern void confirm_change_group (void);
extern int apply_change_group (void);
Index: gcc/testsuite/ChangeLog
from Alexandre Oliva <aoliva@redhat.com>
* gcc.dg/pr20126.c: New.
Index: gcc/testsuite/gcc.dg/pr20126.c
===================================================================
RCS file: gcc/testsuite/gcc.dg/pr20126.c
diff -N gcc/testsuite/gcc.dg/pr20126.c
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ gcc/testsuite/gcc.dg/pr20126.c 11 Mar 2005 14:17:36 -0000
@@ -0,0 +1,50 @@
+/* dg-do run */
+/* dg-options "-O2" */
+
+/* PR target/20126 was not really target-specific, but rather a loop's
+ failure to take into account the possibility that a DEST_ADDR giv
+ replacement might fail, such as when you attempt to replace a REG
+ with a PLUS in one of the register_operands of cmpstrqi_rex_1. */
+
+extern void abort (void);
+
+typedef struct { int a; char b[3]; } S;
+S c = { 2, "aa" }, d = { 2, "aa" };
+
+void *
+bar (const void *x, int y, int z)
+{
+ return (void *) 0;
+}
+
+int
+foo (S *x, S *y)
+{
+ const char *e, *f, *g;
+ int h;
+
+ h = y->a;
+ f = y->b;
+ e = x->b;
+
+ if (h == 1)
+ return bar (e, *f, x->a) != 0;
+
+ g = e + x->a - h;
+ while (e <= g)
+ {
+ const char *t = e + 1;
+ if (__builtin_memcmp (e, f, h) == 0)
+ return 1;
+ e = t;
+ }
+ return 0;
+}
+
+int
+main (void)
+{
+ if (foo (&c, &d) != 1)
+ abort ();
+ return 0;
+}
--
Alexandre Oliva http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist oliva@{lsd.ic.unicamp.br, gnu.org}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20126
next prev parent reply other threads:[~2005-03-11 14:30 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 [this message]
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
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=20050311143002.4205.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).