Re: [PATCH] xen/mm: Remove claim that INVALID_{MFN,GFN}_INITIALIZER is for older toolchains

[Jan Beulich <jbeulich@xxxxxxxx>]

On 25.02.2026 17:35, Andrew Cooper wrote:
> On 25/02/2026 2:34 pm, Jan Beulich wrote:
>> On 25.02.2026 13:59, Andrew Cooper wrote:
>>> This was never because of a bug in GCC.
>>>
>>> C requires that static objects are initialised with constant expressions;
>>> _mfn(), as a static inline, is not and cannot be made to be.
>> Of course, and I think the comments were meant differently. What wasn't 
>> possible
>> to use (with -std=gnu99) due to the referenced bug is apparently
>>
>> #define INVALID_GFN ((gfn_t){ ~0UL })
>>
>> Now that gcc5 is our baseline, do we perhaps want to use that and do away 
>> with
>> INVALID_GFN_INITIALIZER?
> 
> Oh.  Yeah that's very much not what the comment suggested.
> 
> Changing like that almost works, but there's one snag.  common/memory.c has
> 
>     BUILD_BUG_ON(INVALID_GFN_RAW + 1);
> 
> and with the _RAW constant wanting to go, the obvious:
> 
>     BUILD_BUG_ON(gfn_x(INVALID_GFN) + 1);
> 
> doesn't compile as it's no longer a constant expression.
> 
> It's not clear what to do here.  I don't think we want to keep
> INVALID_GFN_RAW around for just this, but nor am I completely happy
> dropping the BUILD_BUG_ON() either.

One option may be to have separate forms for release and debug builds,
with the debug one open-coding gfn_x. Except that this doesn't work: In

    BUILD_BUG_ON(INVALID_GFN._gfn + 1);

the expression is a constant-expression, but not an integer constant
expression.

Hence the next "best" thing I can think of is

    if ( gfn_x(INVALID_GFN) + 1 )
        BUILD_ERROR("bad INVALID_GFN");

It's not quite clear to me whether it would be worthwhile to abstract
this further, e.g. by introducing BUILD_{ERROR,BUG}_IF(). If so,
perhaps we would want to spell out somewhere that BUILD_BUG_ON() is to
be preferred whenever it's usable.

Jan