https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91767
--- Comment #5 from Dimitry Andric <dimitry at andric dot com> ---
Hmm, it appears that this diff "fixes" it:
diff --git a/gcc/config/i386/i386-features.c b/gcc/config/i386/i386-features.c
index 9505b4a1330..091a59f3cb9 100644
--- a/gcc/config/i386/i386-features.c
+++ b/gcc/config/i386/i386-features.c
@@ -1166,7 +1166,11 @@ general_scalar_chain::convert_registers ()
bitmap_iterator bi;
unsigned id;
EXECUTE_IF_SET_IN_BITMAP (defs_conv, 0, id, bi)
- defs_map.put (regno_reg_rtx[id], gen_reg_rtx (smode));
+ {
+ rtx key = regno_reg_rtx[id];
+ rtx val = gen_reg_rtx (smode);
+ defs_map.put (key, val);
+ }
EXECUTE_IF_SET_IN_BITMAP (insns_conv, 0, id, bi)
for (df_ref ref = DF_INSN_UID_DEFS (id); ref; ref = DF_REF_NEXT_LOC (ref))
if (bitmap_bit_p (defs_conv, DF_REF_REGNO (ref)))
but obviously that can't be right, unless gen_reg_rtx() is doing something
horrible to regno_reg_rtx[]. I only see it adding another element at the end,
though.
I think this might indeed be some clang code generation bug, as the assembly
looks a little different with the above patch applied.
Digging further...
