[PATCH 1/2] eal: provide macro for GCC builtin constant intrinsic

[Morten Brørup]

PING for Review/ACK.

Come on fellow reviewers, it's only 5 lines of code!

The mempool library cannot build with MSVC without this patch series.

Other patches are also being held back, waiting for this MSVC compatible DPDK macro for __builtin_constant_p().

The macro for MSVC can be improved as suggested by Stephen later.

> From: Morten Brørup [mailto:mb at smartsharesystems.com]
> Sent: Monday, 1 April 2024 10.35
> 
> > From: Stephen Hemminger [mailto:stephen at networkplumber.org]
> > Sent: Monday, 1 April 2024 00.03
> >
> > On Wed, 20 Mar 2024 14:33:35 -0700
> > Tyler Retzlaff <roretzla at linux.microsoft.com> wrote:
> >
> > > +#ifdef RTE_TOOLCHAIN_MSVC
> > > +#define __rte_constant(e) 0
> > > +#else
> > > +#define __rte_constant(e) __extension__(__builtin_constant_p(e))
> > > +#endif
> > > +
> >
> >
> > I did some looking around and some other project have macros
> > for expressing constant expression vs constant.
> >
> > Implementing this with some form of sizeof math is possible.
> > For example in linux/compiler.h
> >
> > /*
> >  * This returns a constant expression while determining if an argument
> > is
> >  * a constant expression, most importantly without evaluating the
> > argument.
> >  * Glory to Martin Uecker <Martin.Uecker at med.uni-goettingen.de>
> >  *
> >  * Details:
> >  * - sizeof() return an integer constant expression, and does not
> > evaluate
> >  *   the value of its operand; it only examines the type of its operand.
> >  * - The results of comparing two integer constant expressions is also
> >  *   an integer constant expression.
> >  * - The first literal "8" isn't important. It could be any literal
> > value.
> >  * - The second literal "8" is to avoid warnings about unaligned
> > pointers;
> >  *   this could otherwise just be "1".
> >  * - (long)(x) is used to avoid warnings about 64-bit types on 32-bit
> >  *   architectures.
> >  * - The C Standard defines "null pointer constant", "(void *)0", as
> >  *   distinct from other void pointers.
> >  * - If (x) is an integer constant expression, then the "* 0l" resolves
> >  *   it into an integer constant expression of value 0. Since it is cast
> > to
> >  *   "void *", this makes the second operand a null pointer constant.
> >  * - If (x) is not an integer constant expression, then the second
> > operand
> >  *   resolves to a void pointer (but not a null pointer constant: the
> > value
> >  *   is not an integer constant 0).
> >  * - The conditional operator's third operand, "(int *)8", is an object
> >  *   pointer (to type "int").
> >  * - The behavior (including the return type) of the conditional
> > operator
> >  *   ("operand1 ? operand2 : operand3") depends on the kind of
> > expressions
> >  *   given for the second and third operands. This is the central
> > mechanism
> >  *   of the macro:
> >  *   - When one operand is a null pointer constant (i.e. when x is an
> > integer
> >  *     constant expression) and the other is an object pointer (i.e. our
> >  *     third operand), the conditional operator returns the type of the
> >  *     object pointer operand (i.e. "int *). Here, within the sizeof(),
> > we
> >  *     would then get:
> >  *       sizeof(*((int *)(...))  == sizeof(int)  == 4
> >  *   - When one operand is a void pointer (i.e. when x is not an integer
> >  *     constant expression) and the other is an object pointer (i.e. our
> >  *     third operand), the conditional operator returns a "void *" type.
> >  *     Here, within the sizeof(), we would then get:
> >  *       sizeof(*((void *)(...)) == sizeof(void) == 1
> >  * - The equality comparison to "sizeof(int)" therefore depends on (x):
> >  *     sizeof(int) == sizeof(int)     (x) was a constant expression
> >  *     sizeof(int) != sizeof(void)    (x) was not a constant expression
> >  */
> > #define __is_constexpr(x) \
> > 	(sizeof(int) == sizeof(*(8 ? ((void *)((long)(x) * 0l)) : (int
> > *)8)))
> 
> Nice!
> If the author is willing to license it under the BSD license, we can copy it
> as is.
> 
> We might want to add a couple of build time checks to verify that it does what
> is expected; to catch any changes in compiler behavior.