* [Bug other/97705] [11 regression] cc.c-torture/unsorted/dump-noaddr.c.*r.ira fails after r11-4637
2020-11-03 16:28 [Bug other/97705] New: [11 regression] cc.c-torture/unsorted/dump-noaddr.c.*r.ira fails after r11-4637 seurer at gcc dot gnu.org
@ 2020-11-03 17:15 ` seurer at gcc dot gnu.org
2020-11-04 2:11 ` linkw at gcc dot gnu.org
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: seurer at gcc dot gnu.org @ 2020-11-03 17:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97705
--- Comment #1 from seurer at gcc dot gnu.org ---
I tried this on multiple systems and it looks like it may only fail on a BE
system.
^ permalink raw reply [flat|nested] 8+ messages in thread* [Bug other/97705] [11 regression] cc.c-torture/unsorted/dump-noaddr.c.*r.ira fails after r11-4637
2020-11-03 16:28 [Bug other/97705] New: [11 regression] cc.c-torture/unsorted/dump-noaddr.c.*r.ira fails after r11-4637 seurer at gcc dot gnu.org
2020-11-03 17:15 ` [Bug other/97705] " seurer at gcc dot gnu.org
@ 2020-11-04 2:11 ` linkw at gcc dot gnu.org
2020-11-04 8:10 ` [Bug testsuite/97705] " rguenth at gcc dot gnu.org
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: linkw at gcc dot gnu.org @ 2020-11-04 2:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97705
Kewen Lin <linkw at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org
Last reconfirmed| |2020-11-04
--- Comment #2 from Kewen Lin <linkw at gcc dot gnu.org> ---
Thanks for reporting and sorry for the failure. I did run the regression
testing on P8 LE, but thought it's endianness irrelevant and didn't run it on
BE.
^ permalink raw reply [flat|nested] 8+ messages in thread* [Bug testsuite/97705] [11 regression] cc.c-torture/unsorted/dump-noaddr.c.*r.ira fails after r11-4637
2020-11-03 16:28 [Bug other/97705] New: [11 regression] cc.c-torture/unsorted/dump-noaddr.c.*r.ira fails after r11-4637 seurer at gcc dot gnu.org
2020-11-03 17:15 ` [Bug other/97705] " seurer at gcc dot gnu.org
2020-11-04 2:11 ` linkw at gcc dot gnu.org
@ 2020-11-04 8:10 ` rguenth at gcc dot gnu.org
2020-11-04 9:42 ` linkw at gcc dot gnu.org
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: rguenth at gcc dot gnu.org @ 2020-11-04 8:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97705
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |11.0
Component|other |testsuite
^ permalink raw reply [flat|nested] 8+ messages in thread* [Bug testsuite/97705] [11 regression] cc.c-torture/unsorted/dump-noaddr.c.*r.ira fails after r11-4637
2020-11-03 16:28 [Bug other/97705] New: [11 regression] cc.c-torture/unsorted/dump-noaddr.c.*r.ira fails after r11-4637 seurer at gcc dot gnu.org
` (2 preceding siblings ...)
2020-11-04 8:10 ` [Bug testsuite/97705] " rguenth at gcc dot gnu.org
@ 2020-11-04 9:42 ` linkw at gcc dot gnu.org
2020-11-05 5:58 ` linkw at gcc dot gnu.org
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: linkw at gcc dot gnu.org @ 2020-11-04 9:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97705
--- Comment #3 from Kewen Lin <linkw at gcc dot gnu.org> ---
The "-DMASK=2" dumping has more lines for register 282, which is introduced in
ira. Something weird causes ira to dump more contexts.
$ diff dump1/dump-noaddr.c.289r.ira dump2/dump-noaddr.c.289r.ira
107a108
> r282 costs: BASE_REGS:0 GENERAL_REGS:0 FLOAT_REGS:312 ALTIVEC_REGS:312 VSX_REGS:312 GEN_OR_FLOAT_REGS:312 GEN_OR_VSX_REGS:312 LINK_REGS:468 CTR_REGS:468 LINK_OR_CTR_REGS:468 SPEC_OR_GEN_REGS:468 ALL_REGS:1872 MEM:312
373a375
> r282 costs: GENERAL_REGS:0 FLOAT_REGS:312 ALTIVEC_REGS:312 VSX_REGS:312 GEN_OR_FLOAT_REGS:312 GEN_OR_VSX_REGS:312 LINK_REGS:468 CTR_REGS:468 LINK_OR_CTR_REGS:468 SPEC_OR_GEN_REGS:468 ALL_REGS:1872 MEM:312
^ permalink raw reply [flat|nested] 8+ messages in thread* [Bug testsuite/97705] [11 regression] cc.c-torture/unsorted/dump-noaddr.c.*r.ira fails after r11-4637
2020-11-03 16:28 [Bug other/97705] New: [11 regression] cc.c-torture/unsorted/dump-noaddr.c.*r.ira fails after r11-4637 seurer at gcc dot gnu.org
` (3 preceding siblings ...)
2020-11-04 9:42 ` linkw at gcc dot gnu.org
@ 2020-11-05 5:58 ` linkw at gcc dot gnu.org
2020-11-09 4:28 ` [Bug rtl-optimization/97705] " cvs-commit at gcc dot gnu.org
2020-11-09 5:55 ` linkw at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: linkw at gcc dot gnu.org @ 2020-11-05 5:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97705
--- Comment #4 from Kewen Lin <linkw at gcc dot gnu.org> ---
I think my commit just exposed one bug in ira. The newly introduced function
remove_scratches can bump the max_regno, then the data structures
regstat_n_sets_and_refs and reg_info_p which are allocated according to
max_regno become stale. When we call print_pseudo_costs to dump some register
information, it use the latest regno with max_reg_num (), it leads we can
access some regno which don't have relevant data structures which have been
allocated, the read values can be random (out of array bound access).
The fix can be to free/re-init/re-compute the relevant data structures when we
know the max_regno already changes like remove_scratches succeeds.
^ permalink raw reply [flat|nested] 8+ messages in thread* [Bug rtl-optimization/97705] [11 regression] cc.c-torture/unsorted/dump-noaddr.c.*r.ira fails after r11-4637
2020-11-03 16:28 [Bug other/97705] New: [11 regression] cc.c-torture/unsorted/dump-noaddr.c.*r.ira fails after r11-4637 seurer at gcc dot gnu.org
` (4 preceding siblings ...)
2020-11-05 5:58 ` linkw at gcc dot gnu.org
@ 2020-11-09 4:28 ` cvs-commit at gcc dot gnu.org
2020-11-09 5:55 ` linkw at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-11-09 4:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97705
--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Kewen Lin <linkw@gcc.gnu.org>:
https://gcc.gnu.org/g:ce4ae1f4893e322495c5d24b2f0e807a7f7cf92f
commit r11-4827-gce4ae1f4893e322495c5d24b2f0e807a7f7cf92f
Author: Kewen Lin <linkw@linux.ibm.com>
Date: Sun Nov 8 20:35:21 2020 -0600
ira: Recompute regstat as max_regno changes [PR97705]
As PR97705 shows, the commit r11-4637 caused some dumping
comparison difference error on pass ira. It exposed one
issue about the newly introduced function remove_scratches,
which can increase the largest pseudo reg number if it
succeeds, later some function will use the max_reg_num()
to get the latest max_regno, when iterating the numbers
we can access some data structures which are allocated as
the previous max_regno, some out of array bound accesses
can occur, the failure can be random since the values
beyond the array could be random.
This patch is to free/reinit/recompute the relevant data
structures that is regstat_n_sets_and_refs and reg_info_p
to ensure we won't access beyond some array bounds.
Bootstrapped/regtested on powerpc64le-linux-gnu P9 and
powerpc64-linux-gnu P8.
gcc/ChangeLog:
PR rtl-optimization/97705
* ira.c (ira): Refactor some regstat free/init/compute invocation
into lambda function regstat_recompute_for_max_regno, and call it
when max_regno increases as remove_scratches succeeds.
^ permalink raw reply [flat|nested] 8+ messages in thread* [Bug rtl-optimization/97705] [11 regression] cc.c-torture/unsorted/dump-noaddr.c.*r.ira fails after r11-4637
2020-11-03 16:28 [Bug other/97705] New: [11 regression] cc.c-torture/unsorted/dump-noaddr.c.*r.ira fails after r11-4637 seurer at gcc dot gnu.org
` (5 preceding siblings ...)
2020-11-09 4:28 ` [Bug rtl-optimization/97705] " cvs-commit at gcc dot gnu.org
@ 2020-11-09 5:55 ` linkw at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: linkw at gcc dot gnu.org @ 2020-11-09 5:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97705
Kewen Lin <linkw at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|ASSIGNED |RESOLVED
--- Comment #6 from Kewen Lin <linkw at gcc dot gnu.org> ---
Should be fixed with latest trunk r11-4827.
^ permalink raw reply [flat|nested] 8+ messages in thread