https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116358
--- Comment #2 from Manolis Tsamis <tsamismanolis at gmail dot com> --- This is indeed due to r15-2890-g72c9b5f438f22c, but it is a different issue from PR116353 (the fix for PR116353 doesn't solve this issue). For some additional context, the basic block from the testcase that causes the issue looks like this: if (r204 == 0) { r205 = (sign_extend:DI) r345 r146 = (plus:DI) ((umin:DI) r205 (const_int 16)) (const_int -16) } And when the rhs for r146 is given to ifcvt's try_emit_cmove_seq, we get back the __umindi3 call, and the results is: r205 = (sign_extend:DI) r345 x0 = r205 x1 = (const_int 16) x0 = call __umindi3 ... r357 = x0 r355 = (plus:DI) (r357) (const_int -16) cc = (r204 == 0) r146 = (if_then_else:DI) (ne (cc) (const_int 0)) (r355) (r146) Now, I don't know why emit_conditional_move returns the __umindi3 call (maybe something to do with aarch64's md file?), but I believe we should reject a sequence with a call in noce_convert_multiple_sets anyway.