https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112581
--- Comment #13 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The trunk branch has been updated by Andrew Pinski <pins...@gcc.gnu.org>: https://gcc.gnu.org/g:113475d03b0ab1ab18a509e8e5844c1a43983b24 commit r14-7114-g113475d03b0ab1ab18a509e8e5844c1a43983b24 Author: Andrew Pinski <quic_apin...@quicinc.com> Date: Fri Nov 17 20:06:37 2023 -0800 reassoc vs uninitialized variable [PR112581] Like r14-2293-g11350734240dba and r14-2289-gb083203f053f16, reassociation can combine across a few bb and one of the usage can be an uninitializated variable and if going from an conditional usage to an unconditional usage can cause wrong code. This uses maybe_undef_p like other passes where this can happen. Note if-to-switch uses the function (init_range_entry) provided by ressociation so we need to call mark_ssa_maybe_undefs there; otherwise we assume almost all ssa names are uninitialized. Bootstrapped and tested on x86_64-linux-gnu. gcc/ChangeLog: PR tree-optimization/112581 * gimple-if-to-switch.cc (pass_if_to_switch::execute): Call mark_ssa_maybe_undefs. * tree-ssa-reassoc.cc (can_reassociate_op_p): Uninitialized variables can not be reassociated. (init_range_entry): Check for uninitialized variables too. (init_reassoc): Call mark_ssa_maybe_undefs. gcc/testsuite/ChangeLog: PR tree-optimization/112581 * gcc.c-torture/execute/pr112581-1.c: New test. Signed-off-by: Andrew Pinski <quic_apin...@quicinc.com>
