https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86937
--- Comment #2 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Daniel Barboza <[email protected]>: https://gcc.gnu.org/g:e7b77e39552d82141f71f039f70885754de72093 commit r17-3337-ge7b77e39552d82141f71f039f70885754de72093 Author: Daniel Barboza <[email protected]> Date: Fri Aug 14 18:14:42 2026 -0300 fold-const-call.cc: add strnlen in fold_const_call [PR86937] We're not trying to fold builtin_strnlen calls into constants like we do with builtin_strlen. This results in missed optimizations where we have a strnlen that uses a PHI as input: const char a[4] = "123"; int g (int i) { return __builtin_strnlen (i ? a : "", 4); } The strnlen call could be folded into a single PHI <0, 3> but instead we're calling strnlen with the PHI result: # iftmp.1_2 = PHI <&aD.4472(3), ""(2)> # VUSE <.MEM_4(D)> # RANGE [irange] long unsigned int [0, 4] MASK 0x7 VALUE 0x0 # USE = nonlocal escaped const-pool { D.4472 } (nonlocal) _1 = strnlenD.1862 (iftmp.1_2, 4); # RANGE [irange] int [0, 4] MASK 0x7 VALUE 0x0 _5 = (intD.7) _1; # VUSE <.MEM_4(D)> return _5; After this change: # RANGE [irange] int [0, 0][3, 3] MASK 0x3 VALUE 0x0 # prephitmp_7 = PHI <3(3), i_3(D)(2)> # VUSE <.MEM_4(D)> return prephitmp_7; Bootstrapped and regression tested in x86_64. PR tree-optimization/86937 gcc/ChangeLog: * fold-const-call.cc (fold_const_call): fold CFN_BUILT_IN_STRNLEN calls. gcc/testsuite/ChangeLog: * gcc.dg/warn-strnlen-no-nul.c: warnings were added/removed/changed due to the new STRNLEN folding. * gcc.dg/tree-ssa/pr86937.c: New test.
