https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120924
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |false-positive
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #2)
> So shouldn't we just revert PR120003 on 15 branch? Breaking kernel builds
> is serious problem, sure, the kernel can work around that, but maybe it
> isn't worth it and we could live with the missed optimization on the branch?
It did look like an important optimization regression. As said in the
description the diagnostic can be avoided by upping --param
uninit-max-chain-len
the uninit limits were last adjusted for GCC 13 (max-chain-len upped from 5 to
8, for similar reasons).
I cannot quickly find the PRs we added the limits for, but IIRC I chose
them so the uninit time was <1% for them.
So I'd propose to up --param uninit-max-chain-len from 8 to 12 on trunk for now
so we can consider backporting that as well.
