https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115876
--- Comment #18 from GCC Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jeff Law <l...@gcc.gnu.org>: https://gcc.gnu.org/g:f10d2ee95356b9de6c44d701c4dfa8fb088714d2 commit r15-2989-gf10d2ee95356b9de6c44d701c4dfa8fb088714d2 Author: Jeff Law <j...@ventanamicro.com> Date: Sun Aug 18 16:55:52 2024 -0600 [PR rtl-optimization/115876] Avoid ubsan in ext-dce.cc This fixes two general ubsan issues in ext-dce, both related to use-side processsing of modes > DImode. In ext_dce_process_uses we can be presented with something like this as a use (subreg:SI (reg:TF) 12) That will result in an out of range shift for a HOST_WIDE_INT object. Where this happens is safe to just break from the SET context and process the subjects. This will ultimately result in seeing (reg:TF) and we'll mark all bit groups as live. In carry_backpropagate we can be presented with a TImode shift (for example) and the shift count can be > 63 for such a shift. This naturally trips ubsan as well as we're operating on 64 bit objects. We can just return mmask in this case noting that every bit group is live. The combination of these two fixes eliminates all the reported ubsan issues in ext-dce seen in a bootstrap and regression test on x86. While I was in there I went ahead and fixed the various hardcoded 63/64 values to be HOST_BITS_PER_WIDE_INT based. Bootstrapped and regression tested on x86 with no regressions. Also built with ubsan enabled and verified the build logs and testsuite logs don't call out any issues in ext-dce anymore. Pushing to the trunk. PR rtl-optimization/115876 gcc * ext-dce.cc (ext_dce_process_sets): Replace hardcoded 63/64 instances with HOST_BITS_PER_WIDE_INT based values. (carry_backpropagate): Handle modes with more bits than HOST_BITS_PER_WIDE_INT gracefully, avoiding undefined behavior. (ext_dce_process_uses): Handle subreg offsets which would result in ubsan shifts gracefully, avoiding undefined behavior.
