[Bug tree-optimization/103161] [12 Regression] Better ranges cause builtin-sprintf-warn-16.c failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103161 Aldy Hernandez changed: What|Removed |Added CC||amacleod at redhat dot com --- Comment #4 from Aldy Hernandez --- (In reply to Martin Sebor from comment #3) > Confirmed. It's a failure in what looks like a paranoia test that tries to > verify that the sprintf pass isn't making overly aggressive assumptions > about the width field. The sprintf pass calls get_range_expr() to determine > the range. It runs as part of the strlen pass which still uses EVRP for > ranges. It's strange that the range is different for some targets than > others (the IL is otherwise identical). Since the code is using the same > EVRP analyzer as before I'd expect the GIMPLE statement passed to > get_range_expr() to be ignored and the range to be "global" for the whole > function body. I haven't looked into this in enough detail to understand > what's different. As of now this is just as puzzling to me as the false > positive reported in pr102831. I'd expect converting the strlen pass to use > ranger to fix this. I plan to work on it sometime soon. strlen is no longer using evrp. The only remaining uses of the evrp engine are DOM and evrp running in classic mode (which is off by default): $ grep evrp_range_analyzer * -l gimple-ssa-evrp-analyze.c gimple-ssa-evrp-analyze.h gimple-ssa-evrp.c tree-ssa-dom.c
[Bug tree-optimization/103161] [12 Regression] Better ranges cause builtin-sprintf-warn-16.c failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103161 Martin Sebor changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=102831 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #3 from Martin Sebor --- Confirmed. It's a failure in what looks like a paranoia test that tries to verify that the sprintf pass isn't making overly aggressive assumptions about the width field. The sprintf pass calls get_range_expr() to determine the range. It runs as part of the strlen pass which still uses EVRP for ranges. It's strange that the range is different for some targets than others (the IL is otherwise identical). Since the code is using the same EVRP analyzer as before I'd expect the GIMPLE statement passed to get_range_expr() to be ignored and the range to be "global" for the whole function body. I haven't looked into this in enough detail to understand what's different. As of now this is just as puzzling to me as the false positive reported in pr102831. I'd expect converting the strlen pass to use ranger to fix this. I plan to work on it sometime soon.
[Bug tree-optimization/103161] [12 Regression] Better ranges cause builtin-sprintf-warn-16.c failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103161 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-11-10 Ever confirmed|0 |1
[Bug tree-optimization/103161] [12 Regression] Better ranges cause builtin-sprintf-warn-16.c failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103161 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Target Milestone|--- |12.0 --- Comment #2 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/103161] [12 Regression] Better ranges cause builtin-sprintf-warn-16.c failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103161 --- Comment #1 from Jeffrey A. Law --- I suspect the same underlying issue is affecting the test on line #243 as well.
