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 th
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 @@ regrename_
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 r
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 for
> 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 li
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:
/* Inclu
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:
> 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
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 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
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 cop
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 @@ try_rename_operands
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 t
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 m
> 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 t
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 o
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 th
> Yes, the patch is OK, modulo...
But you also need the approval of an ARM maintainer.
--
Eric Botcazou
> 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 th
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 to
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/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 searc
> 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,
Sandra Loosemore 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 reg_ptr = REG_POINT
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 machin
25 matches
Mail list logo
