[Bug tree-optimization/80548] -Wmaybe-uninitialized false positive when an assignment is added

2022-11-23 Thread vincent-gcc at vinc17 dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548 --- Comment #12 from Vincent Lefèvre --- (In reply to Jeffrey A. Law from comment #11) > As I said in my previous comment, the best way forward is to get those two > new instances filed as distinct bugs in BZ. See PR107838 and PR107839.

[Bug tree-optimization/80548] -Wmaybe-uninitialized false positive when an assignment is added

2022-11-22 Thread law at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548 --- Comment #11 from Jeffrey A. Law --- Thanks! So the change in question improves the decisions in the predicate analysis code, which can be best thought of as a filter for the false positives that are still in the IL. As I said in my

[Bug tree-optimization/80548] -Wmaybe-uninitialized false positive when an assignment is added

2022-11-22 Thread vincent-gcc at vinc17 dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548 --- Comment #10 from Vincent Lefèvre --- (In reply to Jeffrey A. Law from comment #9) > These warnings are certainly sensitive to all kinds of things, so it's > possible it's just gone latent. The only way to be sure would be to bisect > all

[Bug tree-optimization/80548] -Wmaybe-uninitialized false positive when an assignment is added

2022-11-21 Thread law at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548 --- Comment #9 from Jeffrey A. Law --- These warnings are certainly sensitive to all kinds of things, so it's possible it's just gone latent. The only way to be sure would be to bisect all the work between gcc-12 and the trunk and pour over the

[Bug tree-optimization/80548] -Wmaybe-uninitialized false positive when an assignment is added

2022-11-21 Thread vincent-gcc at vinc17 dot net via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548 --- Comment #8 from Vincent Lefèvre --- Indeed, compared to GCC 12.2.0, the trunk no longer warns on the simple testcase I provided. However, I cannot see any change of the warnings on my original file (to myself: tmd/binary32/hrcases.c), except

[Bug tree-optimization/80548] -Wmaybe-uninitialized false positive when an assignment is added

2022-11-19 Thread law at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548 Jeffrey A. Law changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug tree-optimization/80548] -Wmaybe-uninitialized false positive when an assignment is added

2021-12-01 Thread aldyh at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548 --- Comment #6 from Aldy Hernandez --- (In reply to Aldy Hernandez from comment #4) > Created attachment 51908 [details] > untested patch > > Like this. It fixes the problem at least for -O2. Richi responded that the current BB copier won't

[Bug tree-optimization/80548] -Wmaybe-uninitialized false positive when an assignment is added

2021-11-30 Thread aldyh at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548 --- Comment #5 from Aldy Hernandez --- (In reply to Aldy Hernandez from comment #4) > Created attachment 51908 [details] > untested patch > > Like this. It fixes the problem at least for -O2. For -O1 y'all are on your own because there are no

[Bug tree-optimization/80548] -Wmaybe-uninitialized false positive when an assignment is added

2021-11-30 Thread aldyh at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548 --- Comment #4 from Aldy Hernandez --- Created attachment 51908 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51908=edit untested patch Like this. It fixes the problem at least for -O2.

[Bug tree-optimization/80548] -Wmaybe-uninitialized false positive when an assignment is added

2021-11-30 Thread aldyh at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80548 Aldy Hernandez changed: What|Removed |Added CC||aldyh at gcc dot gnu.org,