[Bug tree-optimization/103464] ICE on valid code at -O1 (with -ftree-vrp and ulimit -s 512) on x86_64-linux-gnu: Segmentation fault since r12-5522-g661c02e54ea72fb5
rguenth at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Mon Nov 29 10:13:48 GMT 2021
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103464
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
What we should avoid is recursion depths worse than that, but it's quite hard
to assess this. I've added some prints to fold_using_range::range_of_phi with
>>> entering and <<< exiting the function, printing the PHI address and the basic-block the PHI is in. That results in
PHI 0x7ffff6681400 >>> 3
PHI 0x7ffff6681600 >>> 7
PHI 0x7ffff6681800 >>> 10
PHI 0x7ffff6681700 >>> 9
PHI 0x7ffff6681500 >>> 6
PHI 0x7ffff6681d00 >>> 10
PHI 0x7ffff6681c00 >>> 9
PHI 0x7ffff6681a00 >>> 6
PHI 0x7ffff6681900 >>> 3
PHI 0x7ffff66af500 >>> 7
PHI 0x7ffff66af600 >>> 10
PHI 0x7ffff66af900 >>> 9
PHI 0x7ffff66af700 >>> 6
PHI 0x7ffff66afb00 >>> 3
PHI 0x7ffff66afd00 >>> 7
PHI 0x7ffff66aff00 >>> 10
PHI 0x7ffff66afe00 >>> 9
PHI 0x7ffff66afc00 >>> 6
PHI 0x7ffff66af200 >>> 10
PHI 0x7ffff66af100 >>> 9
Segmentation fault (core dumped)
which shows that while we never recurse to the same PHI we seem to recursively
go between PHIs in a CFG cycle thus the recursion depth is
CFG cycle size * "PHI width".
It might make sense to simply limit the recursion depth with a --param or
to avoid visiting backedges at all.
More information about the Gcc-bugs
mailing list