https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113043
Uroš Bizjak <ubizjak at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|target |sanitizer
Last reconfirmed| |2023-12-17
Ever confirmed|0 |1
CC| |dodji at gcc dot gnu.org,
| |dvyukov at gcc dot gnu.org,
| |jakub at gcc dot gnu.org,
| |kcc at gcc dot gnu.org,
| |marxin at gcc dot gnu.org
Status|UNCONFIRMED |NEW
--- Comment #1 from Uroš Bizjak <ubizjak at gmail dot com> ---
Middle-end is calling emit_move_insn from:
(gdb) f 3
#3 0x0000000000aac95c in expand_gimple_stmt_1 (stmt=0x7fffe9fe70a0) at
../../git/gcc/gcc/cfgexpand.cc:4030
4030 emit_move_insn (target, temp);
(gdb) list
4026 else
4027 {
4028 temp = force_operand (temp, target);
4029 if (temp != target)
4030 emit_move_insn (target, temp);
4031 }
target =
(reg:SI 99 [ _5 ])
temp =
(mem/f/c:DI (plus:DI (reg/f:DI 93 virtual-stack-vars)
(const_int -8 [0xfffffffffffffff8])) [8 d+0 S4 A32])
and triggeres gcc_assert in emit_move_insn due to mode mismatch.
This happens when expanding:
unsigned int _5;
__builtin___ubsan_handle_type_mismatch_v1 (&*.Lubsan_data0, _5);
where sanitizer builtin expects PTR.
DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HANDLE_TYPE_MISMATCH_V1,
"__ubsan_handle_type_mismatch_v1",
BT_FN_VOID_PTR_PTR,
ATTR_COLD_NOTHROW_LEAF_LIST)
Confirmed as a sanitizer issue.
