https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114732
--- Comment #3 from Segher Boessenkool <segher at gcc dot gnu.org> --- 1001, 0101, 0011 I mean of course. In some ways CCmode models this better than CCFPmode, but we do not actually model the SO bit (bit 3) at all in CCmode. It is a nice feature of CCmode (that we actually use as fundamental, in the backend code) that CCmode always has exactly one of three bits "hot" (and CCFPmode always one of four). Bit 3 (SO) in CCmode is treated as not being part of the CC really, but an extra thing. This doesn't work all that well of course. So we really need st least three CC modes: -- Exactly one of bits 0..3 hot, like CCFPmode; -- Exactly one of bits 0..2 hot, bit 3 independently set, like CCmode (and that independent bit 3 modeled nicely as well, unlike what we have), and also like in the BCD insns; -- Bit 0 is all-true, bit 2 is all-false, like in the vcmp* insns. Do we need some other CC mode as well? Doe we want separately named CC modes for the different variants of this (like the integer CC mode vs. the BCD one)? We already have a separate CCUNSmode which is exactly like CCmode, as far as the hardware cares, but the meaning is different (for CCUNS the LT and GT bits are set based on an unsigned integer compare, not a signed one). There also is CCEQmode, which has only bit 2 valid (we use it for constructing one CR bit from others, like with cror or crnot).
