On 7/11/2026 1:02 PM, Jeffrey Law wrote:
On 7/10/2026 6:55 PM, Andrea Pinski wrote:
Can you tell why it's restricted to the last full fold?
Restriction to the last full fold comes at the recommendation of Drea
Pinski in comment 6 on the PR
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92408#c6). Perhaps this
doesn't warrant inclusion in the test case? I'm impartial regardless.
Yes, my suggestion was just in case the folding gets in the way of the
strlen pass. I didn't know if the strlen pass would like the checking
done like `*a == 0` or `strlen(a) == 0`. And I didn't want to
introduce a regression due to that.
Makes sense as it's the kind of thing we've seen causing problems in
the past. We could drop the restriction and see if there's fallout,
and if so, how bad. In fact that's so trivial to do, I'll just fire
it up in my tester. It's got a while to go but it already flagged
this on x86_64:
Tests that now fail, but worked before (2 tests):
gcc: gcc.dg/strlenopt-89.c scan-tree-dump-not strlen1 "a1\\] = 0;"
gcc: gcc.dg/strlenopt-89.c scan-tree-dump-times strlen1 "strlen \\(s_" 36
Given the nature of that test, I wouldn't be surprised if it's a
pervasive failure.
Yea, it's pervasive. But after a quick look at the test, it may simply
be the case that the test will need updating to account for the new
optimization.
That was the only fallout from allowing it to trigger earlier.
jeff
