https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127851
--- Comment #5 from Uroš Bizjak <ubizjak at gmail dot com> --- (In reply to Uroš Bizjak from comment #3) > (In reply to Vineet Gupta from comment #2) > > > so y is read before x. Since -ffuse-ops-with-volatile-access is > > target-independent, it would be better to plug this in combine itself. > Yes, this should be fixed in combine pass. Combine is just a fancy forward propagator, it creates more or less sensible combined patterns (and performs some RTX simplifications) and leaves it to the target-dependent code to check if the combined pattern is acceptable. Following this approach, the target should *also* check if the combined pattern is acceptable when volatile operands are combined. x86 code is apparently almost clean regarding volatile operands handling (otherwise linux would break left and right), but there are some corner cases remaining, and this patch tries to handle one of them in a generic way. Since targets can handle volatiles in different ways, a generic approach is IMO not the correct way. To solve the presented problem for x86, we should prevent combinations where any of two memory operands is volatile. So, just add: !(MEM_P (operands[0]) && MEM_P (operands[1]) && (MEM_VOLATILE_P (operands[0]) || MEM_VOLATILE_P (operands[1]))) to the insn constraint of *cmp<mode>_1 and *cmp<mode>_minus_1 insn patterns (and apparently also @ccmp<mode>). This will prevent unwanted combinations of memory operands where one of them is volatile, while still allowing all other non-problematic combinations, including two non-volatile mems.
