https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114753
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> --- I wouldn't call it a hack, I'd say it is the right fix. Though, we have tons of those in internal-fn.cc ops.code = MULT_EXPR; ops.code = MULT_EXPR; ops.code = MULT_EXPR; ops.code = MULT_EXPR; ops.code = MULT_EXPR; ops.code = WIDEN_MULT_EXPR; ops.code = MULT_HIGHPART_EXPR; ops.code = MULT_EXPR; ops.code = WIDEN_MULT_EXPR; ops.code = MULT_EXPR; ops.code = MULT_EXPR; ops.code = PLUS_EXPR; ops.code = TRUNC_DIV_EXPR; ops.code = TRUNC_MOD_EXPR; plus some which reuse earlier set ops.code plus some which use just some variable as ops.code. Sure, I think WIDEN_MULT_EXPR/MULT_HIGHPART_EXPR and the div/mod neither probably consider flag_trapv, but MULT_EXPR/PLUS_EXPR does (though, perhaps the PLUS_EXPR is for vectors only). So, the question is where to put that. To cover everything, bet best would be to put it into expand_mul_overflow and expand_arith_overflow and expand_vector_ubsan_overflow.