On 9/26/26 3:17 PM, Steve Sudit wrote:
On Fri, Sep 25, 2026 at 6:43 PM Jason Merrill <[email protected]
<mailto:[email protected]>> wrote:
> Rather than add a new variable, it seems like we could clear strret if
> we didn't end up with &"..." where we expected it?
Yes, that is simpler. v2 clears strret after the argument loop's string
handling when the argument it refers to is not the address of a
STRING_CST, and leaves the re-basing block itself untouched. The check
sits after the strop branch rather than inside it because an offset
argument such as a + 1 is not an ADDR_EXPR, so it takes the earlier
strop = false path and never reaches that branch; the check looks at the
argument as it will be passed to fold.
Changes since v1 (https://gcc.gnu.org/pipermail/gcc-patches/2026-
September/730074.html <https://gcc.gnu.org/pipermail/gcc-patches/2026-
September/730074.html>): dropped the strret_op variable; clear strret in
the loop instead. The test is unchanged.
Still written with the assistance of an LLM (Assisted-by: tag kept per
https://gcc.gnu.org/ai-policy.html <https://gcc.gnu.org/ai-
policy.html>); I reviewed the change and ran the testing below.
Bootstrapped and regression-tested on x86_64-pc-linux-gnu against trunk
r17-3939-g08794c636095 (default languages, --disable-multilib), with the
g++ testsuite run in all standard levels (98, 11, 14, 17, 20, 23, 26 and
26 -fimplicit-constexpr, as check-c++-all does). compare_tests against
an unpatched run of the same revision shows no regressions; the new test
passes in every level from C++11 up.
OK for trunk?
Pushed, thanks.
Jason
