On 11/06/2015 08:51 PM, Jeff Law wrote:
I think the change is fine for the trunk, though I'm still curious about
how the code as-is resulted in a comparison failure.
I've been retesting and I think this was a case of something else
triggering an random failure - the patch made it go away on
On 06/17/2015 07:11 PM, Sandra Loosemore wrote:
Index: gcc/regrename.c
===
--- gcc/regrename.c (revision 224532)
+++ gcc/regrename.c (working copy)
@@ -942,19 +942,22 @@ regrename_do_replace (struct du_head *he
int
On 11/06/2015 03:48 AM, Bernd Schmidt wrote:
On 06/17/2015 07:11 PM, Sandra Loosemore wrote:
Index: gcc/regrename.c
===
--- gcc/regrename.c(revision 224532)
+++ gcc/regrename.c(working copy)
@@ -942,19 +942,22 @@
On 06/28/2015 03:08 PM, Sandra Loosemore wrote:
Re the testcase, this fixed 16 FAILs on existing tests in the gcc
testsuite with the forthcoming nios2 load/store multiple instruction
support, all assembler errors due to the bad instructions being
generated. There's nothing I can do on nios2
I notice the way gcc_assert() is defined in system.h now, the test won't
disappear even when runtime checks are disabled, though you might still
adjust it to avoid any programmer confusion.
It will disappear at run time, see the definition:
/* Include EXPR, so that unused variable warnings do
On 06/30/2015 03:06 AM, Eric Botcazou wrote:
I notice the way gcc_assert() is defined in system.h now, the test won't
disappear even when runtime checks are disabled, though you might still
adjust it to avoid any programmer confusion.
It will disappear at run time, see the definition:
/*
On 2015/6/30 05:06 PM, Eric Botcazou wrote:
I notice the way gcc_assert() is defined in system.h now, the test won't
disappear even when runtime checks are disabled, though you might still
adjust it to avoid any programmer confusion.
It will disappear at run time, see the definition:
/*
Oh, yuck -- it never even occurred to me that gcc_assert could be
disabled. I'll bet there are other bugs in GCC due to this very same
problem of depending on its argument being executed for side-effect.
Very likely so...
(E.g. take a look at add_stmt_to_eh_lp_fn in tree-eh.c.) Seems like
Hi all:
This patch seem will broken when disable assert checking for c6x
Index: gcc/config/c6x/c6x.c
===
--- gcc/config/c6x/c6x.c (revision 225104)
+++ gcc/config/c6x/c6x.c (working copy)
@@ -3516,7 +3516,7 @@
On 06/29/2015 09:07 PM, Kito Cheng wrote:
Hi all:
This patch seem will broken when disable assert checking for c6x
Index: gcc/config/c6x/c6x.c
===
--- gcc/config/c6x/c6x.c (revision 225104)
+++ gcc/config/c6x/c6x.c (working
On 2015/6/30 12:22 PM, Sandra Loosemore wrote:
On 06/29/2015 09:07 PM, Kito Cheng wrote:
Hi all:
This patch seem will broken when disable assert checking for c6x
Index: gcc/config/c6x/c6x.c
===
--- gcc/config/c6x/c6x.c
On 2015/6/30 下午 01:13, Chung-Lin Tang wrote:
On 2015/6/30 12:22 PM, Sandra Loosemore wrote:
On 06/29/2015 09:07 PM, Kito Cheng wrote:
Hi all:
This patch seem will broken when disable assert checking for c6x
Index: gcc/config/c6x/c6x.c
On 06/24/2015 09:46 PM, Jeff Law wrote:
On 06/23/2015 07:00 PM, Sandra Loosemore wrote:
On 06/18/2015 11:32 AM, Eric Botcazou wrote:
The attached patch teaches regrename to validate insns affected by each
register renaming before making the change. I can see at least two
other ways to handle
I'd be happiest if we had an assert on almost all targets. regrename has
been designed in such a way that the replacements can't fail, if the
constraints on the insns are correct. If there are ports which have
borderline insns where that doesn't hold maybe we ought to have a target
hook that
On 06/25/2015 03:53 PM, Eric Botcazou wrote:
I'd be happiest if we had an assert on almost all targets. regrename has
been designed in such a way that the replacements can't fail, if the
constraints on the insns are correct. If there are ports which have
borderline insns where that doesn't hold
On 06/25/2015 05:46 AM, Jeff Law wrote:
As Eric mentioned, please put an assert to verify that the call from the
c6x backend never fails.
I'd be happiest if we had an assert on almost all targets. regrename has
been designed in such a way that the replacements can't fail, if the
constraints
On 24/06/15 02:00, Sandra Loosemore wrote:
On 06/18/2015 11:32 AM, Eric Botcazou wrote:
The attached patch teaches regrename to validate insns affected by each
register renaming before making the change. I can see at least two
other ways to handle this -- earlier, by rejecting renamings that
On 06/24/2015 01:58 AM, Ramana Radhakrishnan wrote:
On 24/06/15 02:00, Sandra Loosemore wrote:
On 06/18/2015 11:32 AM, Eric Botcazou wrote:
The attached patch teaches regrename to validate insns affected by each
register renaming before making the change. I can see at least two
other ways
Like this? I tested this on nios2 and x86_64-linux-gnu, as before, plus
built for aarch64-linux-gnu and ran the gcc testsuite.
Yes, the patch is OK, modulo...
The c6x back end also calls regrename_do_replace. I am not set up to
build or test on that target, and Bernd told me off-list that
On 06/23/2015 07:00 PM, Sandra Loosemore wrote:
On 06/18/2015 11:32 AM, Eric Botcazou wrote:
The attached patch teaches regrename to validate insns affected by each
register renaming before making the change. I can see at least two
other ways to handle this -- earlier, by rejecting renamings
Yes, the patch is OK, modulo...
But you also need the approval of an ARM maintainer.
--
Eric Botcazou
On 06/18/2015 11:32 AM, Eric Botcazou wrote:
The attached patch teaches regrename to validate insns affected by each
register renaming before making the change. I can see at least two
other ways to handle this -- earlier, by rejecting renamings that result
in invalid instructions when it's
The attached patch teaches regrename to validate insns affected by each
register renaming before making the change. I can see at least two
other ways to handle this -- earlier, by rejecting renamings that result
in invalid instructions when it's searching for the best renaming; or
later, by
Sandra Loosemore san...@codesourcery.com writes:
Index: gcc/regrename.c
===
--- gcc/regrename.c (revision 224532)
+++ gcc/regrename.c (working copy)
@@ -942,19 +942,22 @@ regrename_do_replace (struct du_head *he
int
We ran across problems with the regrename pass introducing invalid insns
while working on support for new load/store multiple instructions on
nios2. We're using an implementation similar to what ARM already does,
with a match_parallel predicate testing for restrictions on the
underlying
25 matches
Mail list logo
