https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93934
--- Comment #19 from Zoltan Vajda <vajdaz at protonmail dot com> --- (In reply to Uroš Bizjak from comment #18) > The following patch fixes the PR, see the comment inline: > > --cut here-- > diff --git a/gcc/config/i386/i386-expand.c b/gcc/config/i386/i386-expand.c > index 6e2b7920d2b..b87490fe544 100644 > --- a/gcc/config/i386/i386-expand.c > +++ b/gcc/config/i386/i386-expand.c > @@ -4094,6 +4094,15 @@ ix86_expand_fp_movcc (rtx operands[]) > && !TARGET_64BIT)) > return false; > > + /* Disable SFmode and DFmode x87 FCMOV with trapping math > + to prevent speculative load using FLDL/FLDS from uninitialized > + memory location, which can contain sNaN value. FLDL/FLDS traps > + on sNaN, see PR93934. */ > + > + if ((mode == SFmode || mode == DFmode) > + && flag_trapping_math) > + return false; > + > /* The floating point conditional move instructions don't directly > support conditions resulting from a signed integer comparison. */ > > --cut here-- The problem does not only apply for conditional moves! I can turn on sse, for example. https://gcc.godbolt.org/z/jP3Kne8T5 Then the problematic code with the conditional move disappears, but I have a similar speculative fld problem in another situation. .L10: inc esi cmp edi, esi jne .L11 test bl, bl <= test input variable 'b' fld QWORD PTR [ebp-24] <= load of (maybe) uninitialized 'result' je .L24 <= jump based on value of 'b' add esp, 20 pop ebx pop esi pop edi pop ebp ret .L24: fstp st(0) .L8: fld QWORD PTR .LC1 add esp, 20 pop ebx pop esi pop edi pop ebp ret
