[Bug tree-optimization/56654] uninit warning behaves erratically (always executed block, "is" vs "may", order when walking uses)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56654 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Richard Biener --- Fixed.
[Bug tree-optimization/56654] uninit warning behaves erratically (always executed block, "is" vs "may", order when walking uses)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56654 --- Comment #6 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:8a63343a744a8584a9dfcbc3817f66755baafe8a commit r13-2261-g8a63343a744a8584a9dfcbc3817f66755baafe8a Author: Richard Biener Date: Mon Aug 29 16:16:44 2022 +0200 tree-optimization/56654 - sort uninit candidates after RPO The following sorts the immediate uses of a possibly uninitialized SSA variable after their RPO order so we prefer warning for an earlier occuring use rather than issueing the diagnostic for the first uninitialized immediate use. The sorting will inevitably be imperfect but it also allows us to optimize the expensive predicate check for the case where there are multiple uses in the same basic-block which is a nice side-effect. PR tree-optimization/56654 * tree-ssa-uninit.cc (cand_cmp): New. (find_uninit_use): First process all PHIs and collect candidate stmts, then sort those after RPO. (warn_uninitialized_phi): Pass on bb_to_rpo. (execute_late_warn_uninitialized): Compute and pass on reverse lookup of RPO number from basic block index.
[Bug tree-optimization/56654] uninit warning behaves erratically (always executed block, "is" vs "may", order when walking uses)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56654 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #5 from Richard Biener --- We do now diagnose "is used uninitialized", the ordering issue remains and I have a patch for that that sorts after RPO but doesn't sort within the block if there is more than one candidate.
[Bug tree-optimization/56654] uninit warning behaves erratically (always executed block, "is" vs "may", order when walking uses)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56654 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Last reconfirmed|2014-09-12 00:00:00 |2021-3-26 Known to fail||10.2.0, 11.0, 4.9.3, 5.3.0, ||6.2.0, 7.5.0, 8.3.0, 9.3.0 CC||msebor at gcc dot gnu.org --- Comment #4 from Martin Sebor --- Reconfirming with GCC 11.
[Bug tree-optimization/56654] uninit warning behaves erratically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56654 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-09-12 Ever confirmed|0 |1 --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Anyway, it is at least one bug, perhaps more.
[Bug tree-optimization/56654] uninit warning behaves erratically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56654 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #1 from Manuel López-Ibáñez manu at gcc dot gnu.org --- But while this is not simple a is used because of if (b 40)? That seems to be the major bug here.
[Bug tree-optimization/56654] uninit warning behaves erratically
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56654 --- Comment #2 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Manuel López-Ibáñez from comment #1) But while this is not simple a is used because of if (b 40)? That seems to be the major bug here. Wow, I should not type in a hurry. What I meant to say is: Given if (b 40), why is this not warned as is used uninit?
