[Bug tree-optimization/86241] duplicate strlen-like snprintf calls not folded

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86241

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-09-05

--- Comment #3 from Andrew Pinski  ---
Confirmed.

[Bug tree-optimization/86241] duplicate strlen-like snprintf calls not folded

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86241

--- Comment #2 from Martin Sebor  ---
Unlike bug 86203, the test case here uses local variables for the results of
the calls to eliminate the possibility of aliasing between them and what the
char pointer points to.

More important, unlike strlen, the specification for snprintf is clear that the
%s argument must point to an object with a character type, so the kind of
aliasing that might be possible in the test case in bug 86203(*) would make the
call to snprintf undefined.

[*] I raised the question of the strlen aliasing in bug 86203 in WG14 and will
propose to tighten up the language to make it invalid.

[Bug tree-optimization/86241] duplicate strlen-like snprintf calls not folded

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86241

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #1 from Richard Biener  ---
The alias machinery knows nothing about "type" rules for function calls so I
don't see how this is possible w/o running into the same issue as with removing
the redundant strlen call.

That is, for g() hopefully we fold the snprintf to strlen.  Not sure why
that's done only late during the strlen pass and not by gimple_fold ().