https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82628
--- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Jakub Jelinek from comment #11) > Created attachment 42428 [details] > gcc8-pr82628.patch > > Untested patch. From the above hack, I'm afraid I have no idea how to > express the SF+OF setting sbb, so I'm using UNSPEC, for the others I hope > I've done those right, but would welcome verification. If you have ideas > what to do for SF+OF, I'd appreciate it. And the patch doesn't deal with > possible needs to rename CCGZmode to something else and describe that it > only defines SF and OF flags. Or can we just use normal CCmode, when the > setter is UNSPEC anyway and thus the generic code can't argue much about it? Unfortunately it doesn't bootstrap. The problem is sub<mode>3_carry_ccc pattern which allows CONST_INT operands[2], but has zero_extend around it, which is invalid RTL. I think we'd need two patterns then, one with nonimmediate_operandand "rm" constraint (or even what it is in the patch, just have GET_MODE (operands[2]) != VOIDmode in the condition), and another pattern that would accept the valid const_int_operand (!TARGET_64BIT) or const_scalar_int_operand (TARGET_64BIT). The rule for -m32 is that it is CONST_INT with UINTVAL (operands[2]) <= 0xffffffffUL, for -m64 it is that either it is a CONST_INT with UINTVAL (operands[2]) <= 0x7fffffffUL, or it is a CONST_WIDE_INT >= 0xffffffff80000000ULL and <= 0xffffffffffffffffULL (i.e. constant integer x86_64_immediate_operand (op, DImode) zero extended from DImode to TImode).
