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.

Reply via email to