[Bug tree-optimization/94166] New: [10 Regression] random -fcompare-debug failures since r10-1913
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94166
Bug ID: 94166
Summary: [10 Regression] random -fcompare-debug failures since
r10-1913
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhroma at gcc dot gnu.org
CC: jakub at redhat dot com, linkw at gcc dot gnu.org
Target Milestone: ---
Target: powerpc64le-*-linux-gnu
I've regtested recent r10-7146 version on powerpc64le with -fcompare-debug.
pr88497-*.c and pr92618.c tests give some kind of random results - they may
fail or pass.
So, after running one compilation manually several times like this:
gcc -O2 -fcompare-debug gcc/testsuite/gcc.c-torture/execute/pr92618.c
--save-temps
I finally managed to see final-dumps with difference like "a=b+c" vs "a=c+b".
Than I've added -fdump-tree-all and than found that the difference starts from
'reassoc1' dump. Investigation shows r10-1913 causes that. I've checked that
reverting r10-1913 and related r10-4930 (but without removing their tests,
which were actually under investigation) solved the problem.
I think the problem is using
for(hash_map::iterator it = v_info_map.begin ) {
...
valid_vecs.quick_push (cand_vec);
}
That loop gives unpredictable order in hash_map iterator and we got random
order of elements in valid_vecs. Later we sort it, but in pr92618.c example it
seems there are two elements are their comparison result is 'equal'.
PS. Actually, I've checked the difference between usual regtest results and
-fcompare-debug and there are a lot of other "more stable" failures, I'll also
file another PR.
[Bug tree-optimization/94167] New: pr71109.c -fcompare-debug failures on x86_64 and powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94167 Bug ID: 94167 Summary: pr71109.c -fcompare-debug failures on x86_64 and powerpc64le Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zhroma at gcc dot gnu.org Target Milestone: --- Running gcc -O2 -fcompare-debug gcc/testsuite/gcc.c-torture/compile/pr71109.c fails with recent master on powerpc64le. I also checked that same happens on x86 with recent 9.3.0 and old 5.5.0 ubuntu. On master, first dump file with difference is fixup_cfg3 -- I've compared (on powerpc64le) usual regtest results and '-fcompare-debug' results and there are like ~10 more failures, two of them already reported as PR94166. Certainly, there are actually a lot of cases when -fcompare-debug dumps differs, but .o files have same code, so that can only be catched "manually" (e.g. using RUNTESTFLAGS="--target_board=unix/-fcompare-debug" or bootstrapping --with-build-config=bootstrap-debug-lean). And I'm not sure how much community bothers about fixing issues like this one.
[Bug rtl-optimization/94189] New: [9/10 Regression] -fcompare-debug failure Wstrict-overflow-22.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94189 Bug ID: 94189 Summary: [9/10 Regression] -fcompare-debug failure Wstrict-overflow-22.c Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zhroma at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- This command: gcc -c -O2 -fcompare-debug gcc/testsuite/gcc.dg/Wstrict-overflow-22.c fails on master, 9.2 and 9.3, but not in 8.4 or earlier versions. -- Great thanks to Jakub for looking at PR94166 and PR94167! Unfortunately, those patches actually fixed only the tests I have reported and thus doesn't decrease much the amount of broken tests in -fcompare-debug regtest. Here is the next one, an it seems to be a real ".text" difference in this case, not only final-dump. Brief investigation shows difference since ".expand" dumps, while tree dumps look fine.
[Bug rtl-optimization/94189] [9/10 Regression] -fcompare-debug failure on Wstringop-overflow-22.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94189 Roman Zhuykov changed: What|Removed |Added Summary|[9/10 Regression] |[9/10 Regression] |-fcompare-debug failure |-fcompare-debug failure on |Wstrict-overflow-22.c |Wstringop-overflow-22.c --- Comment #2 from Roman Zhuykov --- I've screwed up too, sorry :) It should be gcc/testsuite/gcc.dg/Wstringop-overflow-22.c, file is rather new, available only in master. Just rechecked it fails on master on powerpc64le and using 9.2-9.3 on x86_64.
[Bug sanitizer/94191] New: ubsan bootstrap memory hog with -enable-checking=rtl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94191 Bug ID: 94191 Summary: ubsan bootstrap memory hog with -enable-checking=rtl Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: zhroma at gcc dot gnu.org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- On 64Gb RAM x86_64 box using 9.3 sources and running: /configure --enable-languages=c,c++ --with-build-config=bootstrap-ubsan --enable-checking=rtl; make During stage2 insn-extract.c compilation was stopped by OOM killer. It really wants 60+ Gb of memory. -- Yeah, it's a bit crazy checking options and not sure we have to bother about it.
[Bug tree-optimization/94211] New: [9/10 Regression] -fcompare-debug failure on phi-opt-13.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94211
Bug ID: 94211
Summary: [9/10 Regression] -fcompare-debug failure on
phi-opt-13.c
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhroma at gcc dot gnu.org
Target Milestone: ---
This command:
gcc -c -O2 -fcompare-debug gcc/testsuite/gcc.dg/tree-ssa/phi-opt-13.c
fails on todays master (r10-7237) on ppc64le, fails on 9.3 on x86_64, but not
in 7.4. Haven't checked version 8.x.
long f(long a, long b) {
if (__builtin_expect(b == 1, 1)) return a;
return a / b;
}
Tree .phiopt2 is the first dump which seems buggy.
[Bug c++/94223] New: [10 Regression] -fcompare-debug -O0 failure on cpp1z/init-statement6.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94223 Bug ID: 94223 Summary: [10 Regression] -fcompare-debug -O0 failure on cpp1z/init-statement6.C Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: zhroma at gcc dot gnu.org Target Milestone: --- This commands: gcc -c -O0 -std=c++20 -fcompare-debug gcc/testsuite/g++.dg/cpp1z/init-statement6.C gcc -c -O0 -std=c++2a -fcompare-debug gcc/testsuite/g++.dg/cpp1z/init-statement6.C fail on master (r10-7271) on ppc64le, work on 9.3 (only have -std=c++2a) on x86_64. Running with -O1, -O2 or -std=c++17 goes smoothly.
[Bug debug/94340] New: [9/10 Regression] -fcompare-debug -O failure on cpp1z/nodiscard3.C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94340 Bug ID: 94340 Summary: [9/10 Regression] -fcompare-debug -O failure on cpp1z/nodiscard3.C Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: zhroma at gcc dot gnu.org Target Milestone: --- This command: gcc -c -fcompare-debug -O gcc/testsuite/g++.dg/cpp1z/nodiscard3.C fails on master (r10-7374) and 9 branch on powerpc64le, works fine on current 8 branch.
[Bug rtl-optimization/93264] [10 Regression] ICE in cfg_layout_redirect_edge_and_branch_force, at cfgrtl.c:4522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93264
--- Comment #11 from Roman Zhuykov ---
(In reply to Richard Biener from comment #9)
Thank you, I'm glad to see new ideas and some discussion.
> On the testcase itself
>
> diff --git a/gcc/modulo-sched.c b/gcc/modulo-sched.c
> index 77254b31b42..66260fa34f1 100644
> --- a/gcc/modulo-sched.c
> +++ b/gcc/modulo-sched.c
> @@ -1347,8 +1347,7 @@ sms_schedule (void)
>edge latch_edge;
>HOST_WIDE_INT trip_count, max_trip_count;
>
> - loop_optimizer_init (LOOPS_HAVE_PREHEADERS
> - | LOOPS_HAVE_RECORDED_EXITS);
> + loop_optimizer_init (AVOID_CFG_MODIFICATIONS);
>if (number_of_loops (cfun) <= 1)
> {
>loop_optimizer_finalize ();
>
> works.
Unfortunately, this brokes the whole SMS workflow. See e.g. loop_canon_p
function and a call to single_exit inside. I've actually tried only improved
(with all my patches) master version and only few examples, but with
AVOID_CFG_MODIFICATIONS some of them bailout with "SMS loop many exits" instead
of succesfully passing analysis and transformation phases with "SMS succeeded".
[Bug tree-optimization/94775] New: [8/9/10 Regression] ICE in strip_typedefs, at cp/tree.c:1734
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94775
Bug ID: 94775
Summary: [8/9/10 Regression] ICE in strip_typedefs, at
cp/tree.c:1734
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhroma at gcc dot gnu.org
Target Milestone: ---
At least ubuntu v8.3.0 and trunk v10.0.1 (20200402) ICE on Linux x86-64 with
the following reduced testcase while emitting diagnostic:
$ cat bug.ii
template using a = int;
template using b = int;
typedef char d;
template using e = int;
template struct h { using i = b>, e>; };
template using j = typename h::i;
long ab, k, aj;
const d l[]{};
class m {
public:
m(int);
};
class n {
m ad() const;
template void o(long) const {
using c __attribute__((aligned(1))) = const ae;
}
long p;
template
auto s(unsigned long, unsigned long, unsigned long, unsigned long) const;
template auto q(unsigned long, unsigned long) const;
};
template
auto n::s(unsigned long, unsigned long, unsigned long, unsigned long t) const {
o(p);
return t;
}
template auto n::q(unsigned long p1, unsigned long p2) const {
using r = j<4, false>;
using ai = j<4, g>;
return s(ab, k, p1, p2);
}
m n::ad() const {
long f(l[aj]);
m(q(8, f));
}
$ g++ -std=c++17 -Wall -O2 -c -fsanitize=address bug.ii
bug.ii: In member function 'void n::o(long int) const':
bug.ii:16:11: warning: typedef 'using c = const ae' locally defined but not
used [-Wunused-local-typedefs]
16 | using c __attribute__((aligned(1))) = const ae;
| ^
bug.ii: In member function 'm n::ad() const':
bug.ii:36:1: warning: no return statement in function returning non-void
[-Wreturn-type]
36 | }
| ^
'
during GIMPLE pass: vrp
in strip_typedefs, at cp/tree.c:1734
33 | m n::ad() const {
| ^
0x9b4eeb strip_typedefs(tree_node*, bool*, unsigned int)
...
7.5.0 seems to work fine.
[Bug tree-optimization/94775] [8/9/10 Regression] ICE in strip_typedefs, at cp/tree.c:1734
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94775 --- Comment #1 from Roman Zhuykov --- Additionally checked that vanilla gcc-9.3.0 version is also affected.
[Bug c++/94775] [8/9/10/11 Regression] ICE in strip_typedefs, at cp/tree.c:1734 since r8-4668-g8a5ee94a082b3d48
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94775 --- Comment #15 from Roman Zhuykov --- (In reply to Marek Polacek from comment #14) > Patch reverted from 10/11. Maybe I've missed something in gcc-patches, but why it was reverted? I can imagine reasons to revert in 10 branch, but in master...
[Bug rtl-optimization/92591] ICE in optimize_sc, at modulo-sched.c:1063
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92591 Roman Zhuykov changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-11-27 Assignee|unassigned at gcc dot gnu.org |zhroma at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Roman Zhuykov --- Oops, it seems that non-zero sms-dfa-history is untested since modulo-sched was added in 2004. This bugs is latent since r177235 in 2011, and logic is similar to bug 84032 comment #4. When we schedule some insn into row R we check that DFA can't see any conflicts in rows R-H .. R+H (modulo II), where H=sms-dfa-history. So, when we schedule branch into row R some of its neighbours were not yet scheduled and DFA tells OK. While scheduling neighbours DFA may check some nearby rows, for example, rows [R+1-H .. R+1+H] or something like that, but not exactly [R-H .. R+H]. Later we decide to temporarily remove branch insn from schedule and are pretty sure we could put it back (if rescheduling to another row fails). And this time DFA shows a conflict, because now all branch neighbours are scheduled already. Attached untested patch fixes this by running extra DFA checks for all rows [x-H..x+H] where X is any value in range [R-H,R+H], thus eliminating the issue. Certainly, these checks are expensive enough, so I also prepated a patch about modulo-sched params, which will set max sms-dfa-history value to 16. While at it, the patch also fixes other issues about sms parameters.
[Bug rtl-optimization/92591] ICE in optimize_sc, at modulo-sched.c:1063
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92591 --- Comment #2 from Roman Zhuykov --- Created attachment 47379 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47379&action=edit Proposed patch
[Bug rtl-optimization/92591] ICE in optimize_sc, at modulo-sched.c:1063
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92591 --- Comment #3 from Roman Zhuykov --- Created attachment 47380 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47380&action=edit Parameters patch
[Bug tree-optimization/90264] [9/10 Regression] -Wnull-dereference QoI issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90264 --- Comment #6 from Roman Zhuykov --- Ok, this seems quite clear from compiler developer point of view. But I still want to add, that for compiler user, who knows how asprintf function works, "Line A" version is correct and warning seems unnecessary. While "Line B" version where user forget about bail-out is compiled smoothly.
[Bug rtl-optimization/92591] ICE in optimize_sc, at modulo-sched.c:1063
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92591 Roman Zhuykov changed: What|Removed |Added Attachment #47379|0 |1 is obsolete|| --- Comment #4 from Roman Zhuykov --- Created attachment 47386 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47386&action=edit Proposed patch v2 Found a mistake in previous patch
[Bug rtl-optimization/92591] ICE in optimize_sc, at modulo-sched.c:1063
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92591 --- Comment #6 from Roman Zhuykov --- Patches are still testing. Arm (both 32 and 64 bit) cross compilers are OK, and I want to test some additional scenarios for powerpc. Probably I'll post patches next week.
[Bug rtl-optimization/90001] Compile-time hog in swing modulo scheduler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90001 --- Comment #6 from Roman Zhuykov --- Author: zhroma Date: Fri Dec 13 17:02:53 2019 New Revision: 279375 URL: https://gcc.gnu.org/viewcvs?rev=279375&root=gcc&view=rev Log: modulo-sched: speed up DDG analysis (PR90001) PR rtl-optimization/90001 * ddg.c (create_ddg): Init max_dist array for each node. (free_ddg): Free max_dist array. (create_ddg_edge): Use bool field instead of aux union. (set_recurrence_length): Use prepared max_dist information instead of calling longest_simple_path. (create_scc): Remove graph argument, fill node's aux.count with SCC id, and move set_recurrence_length call to... (create_ddg_all_sccs): ...here, after filling all max_dist arrays using Floyd–Warshall-like algorithm. (update_dist_to_successors): Remove the whole function. (longest_simple_path): Likewise. * ddg.h (struct ddg_node): Add max_dist pointer. (struct ddg_edge): Use bool field instead of unused aux union. Modified: trunk/gcc/ChangeLog trunk/gcc/ddg.c trunk/gcc/ddg.h
[Bug rtl-optimization/92591] ICE in optimize_sc, at modulo-sched.c:1063
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92591 --- Comment #7 from Roman Zhuykov --- Author: zhroma Date: Fri Dec 13 17:33:38 2019 New Revision: 279377 URL: https://gcc.gnu.org/viewcvs?rev=279377&root=gcc&view=rev Log: modulo-sched: fix branch rescheduling issue (PR92591) PR rtl-optimization/92591 * modulo-sched.c (ps_add_node_check_conflicts): Improve checking for history > 0 case. testsuite: PR rtl-optimization/92591 * gcc.dg/pr92951-1.c: New test. * gcc.dg/pr92951-2.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr92951-1.c trunk/gcc/testsuite/gcc.dg/pr92951-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/modulo-sched.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/90001] Compile-time hog in swing modulo scheduler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90001 Roman Zhuykov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |zhroma at gcc dot gnu.org --- Comment #8 from Roman Zhuykov --- Fixed. Yes, I'm closing the PR, I suppose this should not be backported. It's a pity we don't have an ability to create regression test for such situation.
[Bug rtl-optimization/92591] ICE in optimize_sc, at modulo-sched.c:1063
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92591 --- Comment #9 from Roman Zhuykov --- Started discussion in mailing list: https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01223.html
[Bug rtl-optimization/90040] [meta-bug] modulo-scheduler and partitioning issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90040 Roman Zhuykov changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #1 from Roman Zhuykov --- I want to ping this meta-bug and kindly ask Jakub/Honza to look at it. I've just rechecked that ICE described in bug 85426 comment 4 presents on current trunk. While PR89116 example "unfortunately" shows no ICE at the moment. Issue is still the same - we ask cfg_layout_redirect_edge_and_branch_force to redirect a crossing jump. With my local (still WIP) modulo-sched features, SMS pass can be used on x86, where -freorder-blocks-and-partition is enabled by default. So, this assertion failure becomes much more annoying, even bootstrap failed on it in some specific conditions.
[Bug rtl-optimization/92591] ICE in optimize_sc, at modulo-sched.c:1063
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92591 --- Comment #10 from Roman Zhuykov --- Author: zhroma Date: Fri Dec 20 15:05:12 2019 New Revision: 279642 URL: https://gcc.gnu.org/viewcvs?rev=279642&root=gcc&view=rev Log: modulo-sched: backport PR92591 fix from mainline 2019-12-20 Roman Zhuykov modulo-sched: fix branch rescheduling issue (PR92591) PR rtl-optimization/92591 * modulo-sched.c (ps_add_node_check_conflicts): Improve checking for history > 0 case. * params.def (sms-dfa-history): Limit to 16. gcc/testsuite: PR rtl-optimization/92591 * gcc.dg/pr92951-1.c: New test. * gcc.dg/pr92951-2.c: New test. Added: branches/gcc-9-branch/gcc/testsuite/gcc.dg/pr92951-1.c branches/gcc-9-branch/gcc/testsuite/gcc.dg/pr92951-2.c Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/modulo-sched.c branches/gcc-9-branch/gcc/params.def branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/92591] ICE in optimize_sc, at modulo-sched.c:1063
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92591 --- Comment #11 from Roman Zhuykov --- Author: zhroma Date: Fri Dec 20 15:07:58 2019 New Revision: 279643 URL: https://gcc.gnu.org/viewcvs?rev=279643&root=gcc&view=rev Log: modulo-sched: backport PR92591 fix from mainline 2019-12-20 Roman Zhuykov modulo-sched: fix branch rescheduling issue (PR92591) PR rtl-optimization/92591 * modulo-sched.c (ps_add_node_check_conflicts): Improve checking for history > 0 case. * params.def (sms-dfa-history): Limit to 16. gcc/testsuite: PR rtl-optimization/92591 * gcc.dg/pr92951-1.c: New test. * gcc.dg/pr92951-2.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr92951-1.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr92951-2.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/modulo-sched.c branches/gcc-8-branch/gcc/params.def branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug c++/2019] Wrong line number warning listing the previous declaration of a befriended function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2019 --- Comment #10 from Roman Zhuykov --- Author: zhroma Date: Fri Dec 20 15:40:46 2019 New Revision: 279645 URL: https://gcc.gnu.org/viewcvs?rev=279645&root=gcc&view=rev Log: Rename tests to reference the correct PR 2019-12-20 Roman Zhuykov * gcc.dg/pr92951-1.c: Rename to ... * gcc.dg/pr92591-1.c: ... this. * gcc.dg/pr92951-2.c: Rename to ... * gcc.dg/pr92591-2.c: ... this. Added: trunk/gcc/testsuite/gcc.dg/pr92591-1.c - copied unchanged from r279644, trunk/gcc/testsuite/gcc.dg/pr92951-1.c trunk/gcc/testsuite/gcc.dg/pr92591-2.c - copied unchanged from r279644, trunk/gcc/testsuite/gcc.dg/pr92951-2.c Removed: trunk/gcc/testsuite/gcc.dg/pr92951-1.c trunk/gcc/testsuite/gcc.dg/pr92951-2.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/2019] Wrong line number warning listing the previous declaration of a befriended function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2019 --- Comment #11 from Roman Zhuykov --- Author: zhroma Date: Fri Dec 20 15:50:44 2019 New Revision: 279646 URL: https://gcc.gnu.org/viewcvs?rev=279646&root=gcc&view=rev Log: Backport: rename tests to reference the correct PR 2019-12-20 Roman Zhuykov * gcc.dg/pr92951-1.c: Rename to ... * gcc.dg/pr92591-1.c: ... this. * gcc.dg/pr92951-2.c: Rename to ... * gcc.dg/pr92591-2.c: ... this. Added: branches/gcc-9-branch/gcc/testsuite/gcc.dg/pr92591-1.c - copied unchanged from r279645, branches/gcc-9-branch/gcc/testsuite/gcc.dg/pr92951-1.c branches/gcc-9-branch/gcc/testsuite/gcc.dg/pr92591-2.c - copied unchanged from r279645, branches/gcc-9-branch/gcc/testsuite/gcc.dg/pr92951-2.c Removed: branches/gcc-9-branch/gcc/testsuite/gcc.dg/pr92951-1.c branches/gcc-9-branch/gcc/testsuite/gcc.dg/pr92951-2.c Modified: branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug c++/2019] Wrong line number warning listing the previous declaration of a befriended function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=2019 --- Comment #12 from Roman Zhuykov --- Author: zhroma Date: Fri Dec 20 15:52:02 2019 New Revision: 279647 URL: https://gcc.gnu.org/viewcvs?rev=279647&root=gcc&view=rev Log: Backport: rename tests to reference the correct PR 2019-12-20 Roman Zhuykov * gcc.dg/pr92951-1.c: Rename to ... * gcc.dg/pr92591-1.c: ... this. * gcc.dg/pr92951-2.c: Rename to ... * gcc.dg/pr92591-2.c: ... this. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr92591-1.c - copied unchanged from r279646, branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr92951-1.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr92591-2.c - copied unchanged from r279646, branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr92951-2.c Removed: branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr92951-1.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr92951-2.c Modified: branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/92591] ICE in optimize_sc, at modulo-sched.c:1063
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92591 Roman Zhuykov changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Roman Zhuykov --- Sorry for mistake in test names (was 92951 instead of 92591). Obvious rename patch committed as r279645, r279646, r279647 into 10/9/8 branches. PR is now fixed in all branches.
[Bug rtl-optimization/90040] [meta-bug] modulo-scheduler and partitioning issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90040 --- Comment #2 from Roman Zhuykov --- Same ICE also appears when compiling gcc.c-torture/execute/pr71550.c with -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions -fmodulo-sched -freorder-blocks-and-partition on several targets: aarch64, powerpc, powerpc64, s390.
[Bug libgcc/93053] New: libgcc build failure with old binutils on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93053 Bug ID: 93053 Summary: libgcc build failure with old binutils on aarch64 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: zhroma at gcc dot gnu.org Target Milestone: --- On cfarm gcc115 machine (aarch64): using trunk source (r279717), running "./configure --prefix=... --enable-languages=c,c++,fortran; make -j3" got: /home/zhroma/build/base/./gcc/xgcc -B/home/zhroma/build/base/./gcc/ -B/home/zhroma/inst/base/aarch64-unknown-linux-gnu/bin/ -B/home/zhroma/inst/base/aarch64-unknown-linux-gnu/lib/ -isystem /home/zhroma/inst/base/aarch64-unknown-linux-gnu/include -isystem /home/zhroma/inst/base/aarch64-unknown-linux-gnu/sys-include -fno-checking -g -O2 -O2 -g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -I. -I. -I../.././gcc -I../../../../src/base/libgcc -I../../../../src/base/libgcc/. -I../../../../src/base/libgcc/../gcc -I../../../../src/base/libgcc/../include -DHAVE_CC_TLS -o cas_4_1.o -MT cas_4_1.o -MD -MP -MF cas_4_1.dep -DL_cas -DSIZE=4 -DMODEL=1 -c ../../../../src/base/libgcc/config/aarch64/lse.S ../../../../src/base/libgcc/config/aarch64/lse.S: Assembler messages: ../../../../src/base/libgcc/config/aarch64/lse.S:52: Error: unknown architectural extension `lse' ../../../../src/base/libgcc/config/aarch64/lse.S:149: Error: unknown mnemonic `casb' -- `casb w0,w1,[x2]' $ cat stage_current stage1 $/usr/bin/as --version GNU assembler (GNU Binutils for Ubuntu) 2.24 Copyright 2013 Free Software Foundation, Inc. I think it should happen since r275967, but haven't actually checked that.
[Bug libgcc/93053] libgcc build failure with old binutils on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93053 --- Comment #1 from Roman Zhuykov --- Now I can confirm it started with r275967.
[Bug libgcc/93053] libgcc build failure with old binutils on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93053 --- Comment #4 from Roman Zhuykov --- Maybe this should be catched earlier in configure scripts? Are there any simple workaround without patching the gcc source? I'm not familiar with different armvN -march option values. Probably it can help choosing some cpu family which doesn't support lse? PS. Cfarm gcc117 and 118 are not available at the moment, and 113-116 have same hardware and old binutils 2.24.
[Bug libgcc/93053] [10 Regression] libgcc build failure with old binutils on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93053 Roman Zhuykov changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-01-09 Summary|libgcc build failure with |[10 Regression] libgcc |old binutils on aarch64 |build failure with old ||binutils on aarch64 Ever confirmed|0 |1 --- Comment #6 from Roman Zhuykov --- Setting regression mark, I see that configure scripts usually catch stuff like this.
[Bug rtl-optimization/93088] [10 Regression] Compile time hog on gcc/testsuite/gcc.target/i386/pr56348.c w/ -O3 -funroll-loops -fno-tree-dominator-opts -fno-tree-vrp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93088 Roman Zhuykov changed: What|Removed |Added CC||zhroma at gcc dot gnu.org --- Comment #4 from Roman Zhuykov --- That's great this was finally catched on trunk! Noticed it probably a year ago, with my modulo-sched changes g++.dg/pr78088.C compilation runs into that infinite loop. And yes, my local solution was to organize a "regset visited = ..." to prevent visiting registers again. Now will continue with applying Jakub's solution. Although no failing example exist, IMO we should backport this into 8 and 9 brances.
[Bug rtl-optimization/93264] New: [10 Regression] ICE in cfg_layout_redirect_edge_and_branch_force, at cfgrtl.c:4522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93264 Bug ID: 93264 Summary: [10 Regression] ICE in cfg_layout_redirect_edge_and_branch_force, at cfgrtl.c:4522 Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: zhroma at gcc dot gnu.org Blocks: 90040 Target Milestone: --- Opening bug 90040 comment 2 as a separate regression PR to achieve more attention to the issue. As modulo-scheduler maintainer I cannot solve it, issue happens early in the pass when loop_optimizer_init is called after bbro finished its job. There are much more discussion in the meta-bug itself (PR90040). Although I'm pretty sure this was latent before, technically, since r10-4447 we have a regression (ICE on valid code): $ aarch64-unknown-linux-gnueabi-gcc -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions -fmodulo-sched -freorder-blocks-and-partition -S gcc/testsuite/gcc.c-torture/execute/pr71550.c gcc/testsuite/gcc.c-torture/execute/pr71550.c: In function 'main': gcc/testsuite/gcc.c-torture/execute/pr71550.c:26:1: internal compiler error: in cfg_layout_redirect_edge_and_branch_force, at cfgrtl.c:4522 26 | } | ^ 0xb4a9d9 cfg_layout_redirect_edge_and_branch_force /mnt/scratch/zhroma/gcc/src/master/gcc/cfgrtl.c:4522 0xb2e57d redirect_edge_and_branch_force(edge_def*, basic_block_def*) /mnt/scratch/zhroma/gcc/src/master/gcc/cfghooks.c:490 0xb2f2fe make_forwarder_block(basic_block_def*, bool (*)(edge_def*), void (*)(basic_block_def*)) /mnt/scratch/zhroma/gcc/src/master/gcc/cfghooks.c:897 0xb33214 merge_latch_edges /mnt/scratch/zhroma/gcc/src/master/gcc/cfgloop.c:780 0xb33314 disambiguate_multiple_latches /mnt/scratch/zhroma/gcc/src/master/gcc/cfgloop.c:831 0xb3335d disambiguate_loops_with_multiple_latches() /mnt/scratch/zhroma/gcc/src/master/gcc/cfgloop.c:844 0xf1d3d0 apply_loop_flags /mnt/scratch/zhroma/gcc/src/master/gcc/loop-init.c:54 0xf1d539 loop_optimizer_init(unsigned int) /mnt/scratch/zhroma/gcc/src/master/gcc/loop-init.c:123 0x1f339f6 sms_schedule /mnt/scratch/zhroma/gcc/src/master/gcc/modulo-sched.c:1350 0x1f38a16 execute /mnt/scratch/zhroma/gcc/src/master/gcc/modulo-sched.c:3341 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90040 [Bug 90040] [meta-bug] modulo-scheduler and partitioning issues
[Bug rtl-optimization/93264] [10 Regression] ICE in cfg_layout_redirect_edge_and_branch_force, at cfgrtl.c:4522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93264
Roman Zhuykov changed:
What|Removed |Added
CC||abel at gcc dot gnu.org
--- Comment #2 from Roman Zhuykov ---
So I decide to share my thoughts here to prevent silently dropping this to P2
before gcc-10 release. Some of the following is already presented in meta-bug
(PR90040).
(In reply to Jakub Jelinek from comment #1)
> It tries to redirect a crossing jump from cold to hot partition to a new bb
> that is in cold partition.
> The generic code really doesn't know what it should remove to replace it
> with the fallthru edge.
Thank you for looking at it. In 2018 Andrey helps me with looking at PR85408
and PR85426 and we together came to the same conclusion. That time we decide
RTL folks will eventually look at those bugs and find some solution. A year
later I've opened a meta-bug, and now in 2020 we still have those issues.
> cfg_layout_redirect_edge_and_branch has code to handle this case, but only
> if the
> branch is simplejump:
> 4429if (e->flags & EDGE_CROSSING
> 4430&& BB_PARTITION (e->src) == BB_PARTITION (dest)
> 4431&& simplejump_p (BB_END (src)))
> 4432 {
> 4433if (dump_file)
> 4434 fprintf (dump_file,
> 4435 "Removing crossing jump while redirecting edge form %i
> to %i\n",
> 4436 e->src->index, dest->index);
> 4437delete_insn (BB_END (src));
> 4438remove_barriers_from_footer (src);
> 4439e->flags |= EDGE_FALLTHRU;
> 4440 }
Yep, and this code is rather new, it was also added in 2018 half a year before
PR87475 fix. I mentioned the quoted hunk in meta-bug discussion in [Appendix
1]. Although Honza created that patch as a fix for PR84058 which was open as
code quality issue, same hunk also solved an ICE in PR83886.
Bug 84058 comment 9 lefts that PR open to track enhancements, but hopefully ICE
issues will also have some attention.
> So, I'd say something in the caller or a few callers up should have punted
> on it before, but no idea what.
Quoting bug 85408 comment 2: "Honza, thoughts on this?" :)
Here I will also desribe some alternative ways to fix the issue, from simplest
to hardest. IMHO all those ideas are ugly.
(1) We can prohibit usage of -freorder-blocks-and-partition and -fmodulo-sched
together. Maybe it should issue a note and enable only the pass which goes
last in compile options. This behaviour will be much more confusing when my
sms changes goes in, which will allow to use sms on x86, where partitioning is
enabled by default.
(2) We can move pass_sms before pass_partition_blocks. Althougt this will
eventually prevent another entering/exiting cfg_layout mode, it is a bad idea.
It was discussed previously (see meta-bug), probably sms will become less
accurate. It's better to keep sms pass as closer as possible to register
allocation pass.
(3) As mentioned in meta-bug [Appendix 2] we probably have some latent issues
with entering cfg_layout. Sms doesn't guard entering, while all other passes
which run after partitioning have some logic like this (hw-doloop.c):
/* We can't enter cfglayout mode anymore if basic block partitioning
already happened. */
if (do_reorder && !crtl->has_bb_partition)
...
SMS wants loop_optimizer_init, and it may call loop_version when succeeded, so
it actually can't proceed without entering cfg_layout. If we add a guard like
that, we will stop sms to process any function where has_bb_partition is true.
Mostly this have same problems as solution (1), but it will also silently
prioritize partitioning over sms instead of noting the user.
(4) We can add another pass_sms item in passes.def before pass_partition_blocks
and add some confusing logic: when paritioning is enabled, sms will run
earlier. Certainly, it will run as usual otherwise.
(5) Approach (4) can be extended if we somehow split pass_partition_blocks into
separate 'analyze' and 'change_cfg' phases. Than "earlier sms" should take
effect only when 'analyze' is successfull. And certainly as "earlier sms" will
itself change the cfg, we than have to re-run 'analyze' again.
[Bug rtl-optimization/93264] [10 Regression] ICE in cfg_layout_redirect_edge_and_branch_force, at cfgrtl.c:4522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93264 --- Comment #5 from Roman Zhuykov --- Created attachment 47820 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47820&action=edit Considered "moving sms earlier" patch I haven't tested "moving sms earlier" patch since 2011. But I remember there were some testsuite items where it makes difference, not sure whether it was arm or ia64 platform. I decided those passes between substantially change the loop code and DDG. I'll run some cross-testing to check how it works for now. > In general it's a bad idea to try go "back" to CFG layout mode and the fix is > to not do that. Also qouting https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00714.html: > I think the expectation that you can go back to CFG layout mode > and then work with CFG layout tools after we've lowered to CFG RTL > is simply bogus. Yeah, you can probably do analysis things but > I wouldn't be surprised if a CFG RTL -> CFG layout -> CFG RTL cycle > can wreck things. Undoubtedly doing CFG manipulations is not going > to work since CFG layout does not respect CFG RTL restrictions. > Partitioning simply uncovered latent bugs, there's nothing wrong > with it IMHO. There are two more passes re-entering cfg layout: pass_reorder_blocks and pass_machine_reorg.
[Bug rtl-optimization/90040] [meta-bug] modulo-scheduler and partitioning issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90040 --- Comment #3 from Roman Zhuykov --- (In reply to Roman Zhuykov from comment #2) > Same ICE also appears when compiling gcc.c-torture/execute/pr71550.c with So, I've opened separate PR93264 for that example, and now we have some related discussion there. Another discussion was in mailing list, starting from https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00666.html > With my local (still WIP) modulo-sched features, SMS pass can be used on > x86, where -freorder-blocks-and-partition is enabled by default. So, this > assertion failure becomes much more annoying, even bootstrap failed on it in > some specific conditions. I've found some mistake in my patches. For testing purpose I've tried to make some extreme conditions for modulo-scheduler and modified the way loop_version is called. And that help me to find a way to make the latent issue more obvious. Imagine a scenario when modulo-sched.c code calls loop_version with always-true condition, e.q. get_rtx_GEU(left, right), where 'right' can eventually be a compile-time zero constant. It this situation there are a lot of tests on different platforms where problematic assertion failure appears as an ICE. It tries to redirect (with _force) a basic block, where last instruction is barrier, and the previous instruction is a fallthrough jump. After fixing my mistake the ICE doesn't impede further SMS enhancements.
[Bug rtl-optimization/93264] [10 Regression] ICE in cfg_layout_redirect_edge_and_branch_force, at cfgrtl.c:4522
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93264 Roman Zhuykov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #6 from Roman Zhuykov --- First, I want here to mention that Richard have recently discussed partitioning in mailing list with Segher, starting from https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00666.html > I'll run some cross-testing to check how it works for now. Second, those tests have finished and there is nothing to say about the results. From correctness aspect everything looks fine. But I haven't tried to look at each example where it prevents/allows loops to be scheduled, and know nothing about performance impact. (In reply to rsand...@gcc.gnu.org from comment #4) > Yeah, it ought to be better to do mode switching first. But I think > the more important ones are: > > NEXT_PASS (pass_split_all_insns); > NEXT_PASS (pass_lower_subreg3); > > Scheduling should happen on the split form of insns rather than the > unsplit form. lower_subreg should also improve "schedulability". Agreed, so it would be much better to fix the issue conservatively without moving the pass.
[Bug middle-end/92410] Invalid access to df->insns[] in regstat_bb_compute_calls_crossed (caught by hwasan)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92410 Roman Zhuykov changed: What|Removed |Added CC||zhroma at gcc dot gnu.org --- Comment #10 from Roman Zhuykov --- (In reply to Martin Liška from comment #3) > Confirmed also with r247015 (GCC 7 branch point). (In reply to Martin Liška from comment #9) > I would close this as fixed. Asked about backporting, see https://gcc.gnu.org/ml/gcc-patches/2020-02/msg01523.html
[Bug rtl-optimization/84032] ICE in optimize_sc, at modulo-sched.c:1064
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84032 --- Comment #5 from Roman Zhuykov --- Author: zhroma Date: Tue Apr 23 12:53:43 2019 New Revision: 270511 URL: https://gcc.gnu.org/viewcvs?rev=270511&root=gcc&view=rev Log: modulo-sched: fix branch scheduling issue (PR84032) PR rtl-optimization/84032 * modulo-sched.c (ps_insn_find_column): Change condition so that branch will always be the last insn in a row inside partial schedule. testsuite: PR rtl-optimization/84032 * gcc.dg/pr84032.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr84032.c Modified: trunk/gcc/ChangeLog trunk/gcc/modulo-sched.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/84032] ICE in optimize_sc, at modulo-sched.c:1064
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84032 Roman Zhuykov changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |zhroma at gcc dot gnu.org --- Comment #6 from Roman Zhuykov --- Fixed.
[Bug rtl-optimization/87979] ICE in compute_split_row at modulo-sched.c:2393
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87979 --- Comment #3 from Roman Zhuykov --- Author: zhroma Date: Tue Apr 23 13:14:57 2019 New Revision: 270512 URL: https://gcc.gnu.org/viewcvs?rev=270512&root=gcc&view=rev Log: modulo-sched: prevent division by zero (PR87979) PR rtl-optimization/87979 * modulo-sched.c (sms_schedule): Start ii value "mii" should not equal zero. testsuite: PR rtl-optimization/87979 * gcc.dg/pr87979.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr87979.c Modified: trunk/gcc/ChangeLog trunk/gcc/modulo-sched.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/87979] ICE in compute_split_row at modulo-sched.c:2393
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87979 Roman Zhuykov changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Roman Zhuykov --- Fixed.
[Bug rtl-optimization/87979] ICE in compute_split_row at modulo-sched.c:2393
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87979 --- Comment #5 from Roman Zhuykov --- Author: zhroma Date: Fri Apr 26 16:04:54 2019 New Revision: 270609 URL: https://gcc.gnu.org/viewcvs?rev=270609&root=gcc&view=rev Log: Backport modulo-sched fixes from mainline 2019-04-23 Roman Zhuykov modulo-sched: prevent division by zero (PR87979) PR rtl-optimization/87979 * modulo-sched.c (sms_schedule): Start ii value "mii" should not equal zero. modulo-sched: fix branch scheduling issue (PR84032) PR rtl-optimization/84032 * modulo-sched.c (ps_insn_find_column): Change condition so that branch will always be the last insn in a row inside partial schedule. gcc/testsuite: PR rtl-optimization/87979 * gcc.dg/pr87979.c: New test. PR rtl-optimization/84032 * gcc.dg/pr84032.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr84032.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr87979.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/modulo-sched.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug rtl-optimization/84032] ICE in optimize_sc, at modulo-sched.c:1064
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84032 --- Comment #7 from Roman Zhuykov --- Author: zhroma Date: Fri Apr 26 16:04:54 2019 New Revision: 270609 URL: https://gcc.gnu.org/viewcvs?rev=270609&root=gcc&view=rev Log: Backport modulo-sched fixes from mainline 2019-04-23 Roman Zhuykov modulo-sched: prevent division by zero (PR87979) PR rtl-optimization/87979 * modulo-sched.c (sms_schedule): Start ii value "mii" should not equal zero. modulo-sched: fix branch scheduling issue (PR84032) PR rtl-optimization/84032 * modulo-sched.c (ps_insn_find_column): Change condition so that branch will always be the last insn in a row inside partial schedule. gcc/testsuite: PR rtl-optimization/87979 * gcc.dg/pr87979.c: New test. PR rtl-optimization/84032 * gcc.dg/pr84032.c: New test. Added: branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr84032.c branches/gcc-8-branch/gcc/testsuite/gcc.dg/pr87979.c Modified: branches/gcc-8-branch/gcc/ChangeLog branches/gcc-8-branch/gcc/modulo-sched.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/90264] New: [9/10 Regression] -Wnull-dereference false positive after r270574
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90264
Bug ID: 90264
Summary: [9/10 Regression] -Wnull-dereference false positive
after r270574
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhroma at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, law at redhat dot com, rguenth at
gcc dot gnu.org
Blocks: 86172
Target Milestone: ---
Reduced manually from lib/colors.c in util-linux 2.33.1
int like_asprintf(char **strp);
int cn_sequence(char **seq) {
char *out;
int len;
*seq = 0;
/* Warning disappears when using second line
(comment line A and uncomment line B). */
if ((len = like_asprintf(seq)) < 1) return -1; //line A
//len = like_asprintf(seq);//line B
for (out = *seq; out && *out; out++);
if ((out - *seq) > len) return -2;
*out = '\0';
return 0;
}
with "-O2 -Wnull-dereference"
: In function 'cn_sequence':
:13:8: warning: potential null pointer dereference [-Wnull-dereference]
13 | *out = '\0';
| ~^~
It seems odd to have warning with "line A" version and not to warn in "line B"
example.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86172
[Bug 86172] [meta-bug] issues with -Wnull-dereference
[Bug tree-optimization/90264] [9/10 Regression] -Wnull-dereference false positive after r270574
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90264 --- Comment #3 from Roman Zhuykov --- (In reply to Jeffrey A. Law from comment #1) > We set *seq = 0. > > Assume we do not return -1 from line A. > > The for loop's initial test will be false because out = *seq = 0 > > out - *seq must also be zero and if that's <= len, then we'll *out = `\0' > which dereferences a NULL pointer. The point is, that if "line A" is not a false positive, then "line B" version also must be warned. Let me than say it is a false negative. Originally it was asprintf, which always sets *seq to non-null, or returns negative when ENOMEM. But compiler doesn't know that logic.
[Bug middle-end/86172] [meta-bug] issues with -Wnull-dereference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86172 Bug 86172 depends on bug 90264, which changed state. Bug 90264 Summary: [9/10 Regression] -Wnull-dereference QoI issue https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90264 What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |---
[Bug tree-optimization/90264] [9/10 Regression] -Wnull-dereference QoI issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90264 Roman Zhuykov changed: What|Removed |Added Status|RESOLVED|REOPENED Last reconfirmed||2019-04-29 Resolution|INVALID |--- Summary|[9/10 Regression] |[9/10 Regression] |-Wnull-dereference false|-Wnull-dereference QoI |positive after r270574 |issue Ever confirmed|0 |1 --- Comment #4 from Roman Zhuykov --- Let me perhaps explain better. Function asprintf should set *s to point allocated memory and return non-negative amount of printed chars. When allocation fails it will return -1. So, there are really no issue in the original code, but compiler isn’t clever enough to know how asprintf works. Gcc 8 doesn’t warn, thats why I’ve created this bugreport as false-positive. So, here trunk gives a warning: https://godbolt.org/z/-o6UMv If we decide that warning is correct, we must also warn same code, when -1 bailout removed: https://godbolt.org/z/ayb9pS Than we have a false negative and it is *not* a “9 Regression”, but we have to fix it. I also want to note, that when -2 bail out is removed from both examples, 8.3 and trunk give a warning. There is a separate issue with gcc 8.3 here, it warns two times. : In function 'cn_sequence': :11:8: warning: potential null pointer dereference [-Wnull-dereference] *out = '\0'; ~^~ :11:8: warning: potential null pointer dereference [-Wnull-dereference] Compiler returned: 0 But I haven’t checked recent 8-branch, maybe that was fixed and backported after 8.3.
[Bug rtl-optimization/97421] aarch64: Wrong code with -O2 -fmodulo-sched
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97421 Roman Zhuykov changed: What|Removed |Added CC||zhroma at gcc dot gnu.org --- Comment #5 from Roman Zhuykov --- Created attachment 49604 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49604&action=edit Proposed patch
[Bug rtl-optimization/97421] aarch64: Wrong code with -O2 -fmodulo-sched
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97421 Roman Zhuykov changed: What|Removed |Added Last reconfirmed||2020-11-20 CC||abel at gcc dot gnu.org, ||amonakov at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Assignee|unassigned at gcc dot gnu.org |zhroma at gcc dot gnu.org --- Comment #6 from Roman Zhuykov --- Thanks for catching this! When modulo sched succeded and found that counter register is const-initialized in prologue it wrongly directly adjust the initization without checking that register may be read a bit later in prologue. I've attached the patch I'm testing.
[Bug rtl-optimization/97851] aarch64: Wrong code with -Os -fmodulo-sched since r7-879-g43c0068e60
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97851 Roman Zhuykov changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Roman Zhuykov --- (In reply to Alex Coplan from comment #0) > Possibly related to PR97440 or PR97421. Yep, all those are actually duplicates. Thanks Richard for CCing! *** This bug has been marked as a duplicate of bug 97421 ***
[Bug rtl-optimization/97421] aarch64: Wrong code with -O2 -fmodulo-sched
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97421 --- Comment #7 from Roman Zhuykov --- *** Bug 97851 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/97440] aarch64: Wrong code with -Os -fmodulo-sched -fno-dce -fno-strict-aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97440 Roman Zhuykov changed: What|Removed |Added Resolution|--- |DUPLICATE CC||zhroma at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #2 from Roman Zhuykov --- Same issue as PR97421 *** This bug has been marked as a duplicate of bug 97421 ***
[Bug rtl-optimization/97421] aarch64: Wrong code with -O2 -fmodulo-sched
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97421 --- Comment #8 from Roman Zhuykov --- *** Bug 97440 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/97421] aarch64: Wrong code with -O2 -fmodulo-sched
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97421 Roman Zhuykov changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #13 from Roman Zhuykov --- Fixed on all active branches.
[Bug rtl-optimization/100225] [8/9/10/11/12 Regression] ICE in add_cross_iteration_register_deps, at ddg.c:291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100225 --- Comment #4 from Roman Zhuykov --- Created attachment 50704 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50704&action=edit Tested patch Fix in https://gcc.gnu.org/pipermail/gcc-patches/2021-April/569110.html, pushing to trunk tomorrow
[Bug rtl-optimization/100225] [8/9/10/11 Regression] ICE in add_cross_iteration_register_deps, at ddg.c:291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100225 Roman Zhuykov changed: What|Removed |Added Status|NEW |RESOLVED Assignee|unassigned at gcc dot gnu.org |zhroma at gcc dot gnu.org Resolution|--- |FIXED --- Comment #10 from Roman Zhuykov --- Now fixed on all branches.
[Bug rtl-optimization/100647] ICE during sms pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100647 --- Comment #1 from Roman Zhuykov --- Thanks, I'll take a closer look in a few days, but this should be a dup of PR93264 (see also PR90040), which doesn't have any easy solution...
[Bug rtl-optimization/100554] [9/10/11/12 Regression] -fcompare-debug failure w/ -Os -fmodulo-sched -fno-tree-loop-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100554 Roman Zhuykov changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=100533, ||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=100523 CC||abel at ispras dot ru, ||jakub at redhat dot com, ||zhroma at gcc dot gnu.org --- Comment #1 from Roman Zhuykov --- > Is it an issue at all? > Should I report more issues of this kind in the future? I think the answer is "yes" for both questions, thanks for your reports! A year ago when I bothered about regtesting with -fcompare-debug I've created a few issues unrelated to modulo scheduler and Jakub fixed most of them. Short summary is available at https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542389.html, there I've also investigated everything on modulo sched side, but small patch2.txt was never committed. Given now we are in stage1 and have three PRs (I'll check PR100533 and PR100523, they should be same), now it's time to push that.
[Bug c++/111525] New: Inconsistent Wsign-compare in c++ with ubsan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111525
Bug ID: 111525
Summary: Inconsistent Wsign-compare in c++ with ubsan
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zhroma at gcc dot gnu.org
Target Milestone: ---
$ cat test.cc
extern long global;
int foo (unsigned x) {
return x == ((global ? 64 : 32) - 1) / 8;
}
$ gcc -x c -c -Werror=sign-compare test.cc
$ gcc -x c -c -Werror=sign-compare test.cc -fsanitize=undefined
$ gcc -x c++ -c -Werror=sign-compare test.cc
$ gcc -x c++ -c -Werror=sign-compare test.cc -fsanitize=undefined
test.cc: In function ‘int foo(unsigned int)’:
test.cc:4:12: error: comparison of integer expressions of different signedness:
‘unsigned int’ and ‘int’ [-Werror=sign-compare]
4 | return x == ((global ? 64 : 32) - 1) / 8;
| ~~^~~
cc1plus: some warnings being treated as errors
Warning appears only for C++ with ubsan enabled. It seems that both sanitizer
and warning are implemented in front-end part, and C++ somehow issues warning
after instrumentation.
This actually breaks ubsan-bootstrap with -Werror enabled, from what I know all
versions since gcc-8 are affected.
configure --enable-languages=c,c++ --disable-multilib
--with-build-config=bootstrap-ubsan --enable-werror=yes && make
BOOT_CFLAGS="-Wno-error=array-bounds -Wno-error=format-overflow"
-Wno-error=array-bounds and -Wno-error=format-overflow are necessary as these
warnings have known issues under ubsan.
[Bug c++/98533] [11/12/13/14 Regression] ICE: 'verify_type' failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98533
Roman Zhuykov changed:
What|Removed |Added
CC||zhroma at gcc dot gnu.org
--- Comment #9 from Roman Zhuykov ---
Just adding another example where I caught the same error:
$ cat test.cc
class IR;
class Pass {
public:
explicit Pass(IR *ir) : ir_(ir) {}
virtual ~Pass() = default;
IR *ir_ {nullptr};
};
class PassManager {
public:
template void RunPass() { T pass(ir_); }
IR *ir_ {nullptr};
};
class IR final {
public:
template void RunPass() { pass_manager_.RunPass(); }
PassManager pass_manager_;
};
class ThePass : Pass {
public:
explicit ThePass(IR *ir) : Pass(ir) {}
ThePass(const ThePass &) = delete;
template void Bar(void *inst, Func func
= [](void *) {});
};
void foo(IR *ir) { ir->RunPass(); }
$ g++ -fchecking -g -c test.cc # any g++ from 8 to 13
test.cc:18:7: error: type variant has different ‘TYPE_FIELDS’
18 | class ThePass : Pass {
| ^~~
