diff options
author | Andrew Pinski <quic_apinski@quicinc.com> | 2023-11-17 20:06:37 -0800 |
---|---|---|
committer | Andrew Pinski <quic_apinski@quicinc.com> | 2024-01-10 09:00:27 -0800 |
commit | 113475d03b0ab1ab18a509e8e5844c1a43983b24 (patch) | |
tree | 520adbb92c2f148ff206ec3ee8f464d34222188a /gcc/c | |
parent | 3353e7d28447f4591a752859ddea96b308561c0a (diff) | |
download | gcc-113475d03b0ab1ab18a509e8e5844c1a43983b24.zip gcc-113475d03b0ab1ab18a509e8e5844c1a43983b24.tar.gz gcc-113475d03b0ab1ab18a509e8e5844c1a43983b24.tar.bz2 |
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_apinski@quicinc.com>
Diffstat (limited to 'gcc/c')
0 files changed, 0 insertions, 0 deletions