https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93934
Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |uros at gcc dot gnu.org --- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> --- Btw, it seems to require -march=x86-64 to produce the fcmov. It's RTL that creates that so this might be an angle of attack for a fix. We expand from ;; basic block 9, loop depth 0 ;; pred: 8 if (b_12(D) != 0) goto <bb 11>; [56.18%] else goto <bb 10>; [43.82%] ;; succ: 11 ;; 10 ;; basic block 10, loop depth 0 ;; pred: 9 ;; 2 ;; succ: 11 ;; basic block 11, loop depth 0 ;; pred: 9 ;; 10 # iftmp.0_6 = PHI <result_3(9), 7.0e+0(10)> return iftmp.0_6; and in split3 we seem to have jump threaded the exit in BB reorder which should be fine but then we somehow if-converted the other check. Disabling both CE1 and CE2 avoids that. CE1 does IF-THEN-JOIN block found, pass 1, test 5, then 7, join 9 scanning new insn with uid = 69. scanning new insn with uid = 70. if-conversion succeeded through noce_try_cmove Removing jump 25. deleting insn with uid = 25. deleting insn with uid = 8. deleting block 7 Conversion succeeded on pass 1. IF-THEN-JOIN block found, pass 1, test 6, then 8, join 9 IF-CASE-2 found, start 6, else 8 maybe the backend should not advertise conditional moves with DF/SFmode and x87 math ...