Re: [PATCH v9 1/5] x86/boot: Remove "cc" clobber from memcmp()

[Mauricio Faria de Oliveira <mfo@igalia.com>]

On 2026-09-02 10:29, Michael Matz wrote:
> Hello,
> 
> On Tue, 1 Sep 2026, Borislav Petkov wrote:
> 
>> On Sat, Aug 22, 2026 at 03:33:17PM -0300, Mauricio Faria de Oliveira wrote:
>> > According to the GCC documentation, conditions in the flags register
>> > (e.g., "=@ccnz") are output operands [1] and the compiler is aware [2].
>> > 
>> > Also, clobbers (e.g., "cc") may not overlap with an output operand [2].
>> > 
>> > Thus, remove the "cc" clobber as it is redudant, and overlaps with, the
>> > "=@ccnz" output operand.
> 
> Strictly speaking, on x86, the '=@ccXY' constraints are register outputs 
> into normal random integer registers (though they are of course 
> initialized in a funny way), while the 'cc' clobber is not a register at 
> all, but rather a fuzzy idea of "state" in old cc0-based compilers (which 
> the x86 backend isn't anymore since, ... well, about forever, 1999).  As 
> such they both really don't conflict and ...
> 
>> But then I'd expect that gcc would enforce that. I know it can't have it 
>> when the clobbers contain input or output regs:
>> 
>> In function ‘__memcmp’,
>>     inlined from ‘main’ at memcmp.c:25:6:
>> memcmp.c:11:9: error: ‘asm’ operand has impossible constraints or there are not enough registers
>>    11 |         asm volatile("test %3, %3\n\t"
>>       |         ^~~
>> 
>> but with "cc" clobbers it works.
> 
> ... hence there's nothing to report.  In fact what an explicit 'cc' 
> clobber once meant in cc0 backends (that indiscriminated flag "state") is 
> manufactured by the non-cc0 backends (all of them now) automatically 
> whenever an asm has no flag output constraints at all.  (On x86 that means 
> it adds the "flags" register (internal name for the collection of flag 
> status bits) to the clobber set automatically when there are no =@ccXY 
> constraints).
> 
> You can regard all 'cc' clobbers as pure source compatibility, they have 
> no meaning anymore.  But as they are so ubiquitous (even in our own docu), 
> they remain recognized.

Michael, thanks for the detailed explanation; that's very nice to know.

Boris, I guess this may be added as clarification in the commit message.
Would you prefer another version with it?

Thanks,

> 
> 
> Ciao,
> Michael.

-- 
Mauricio