`__builtin_constant_p` fails/behaves differently from GCC

[h-2]

#include <type_traits>

#define IS_CONSTEXPR(...) std::integral_constant<bool, __builtin_constant_p((__VA_ARGS__, 0))>::value

struct S
{
    int i = 0;

    constexpr S & assign_int(int j)
    {
        i = j;
        return *this;
    }
};

inline constexpr auto s = S{}.assign_int(3);    // works
static_assert(IS_CONSTEXPR(S{}.assign_int(3))); // fails in clang, passes in GCC

The macro IS_CONSTEXPR can check whether a wide variety of expressions are well-formed in a const context. I know that __builtin_constant_p is non-standard, but based on the documentation, I assume that clang's implementation is supposed to behave like GCC's. In this case, it does not.

I don't know whether this is just a deficiency of the builtin, or whether this also means clang is less likely to evaluate such expressions at compile time (when not required).

[royjacobson]

In general we do aim for GCC compatibility with those builtins.

To quote EvaluateBuiltinConstantP in AST/ExprConstant.cpp:

// FIXME: GCC also intends to return 1 for literals of aggregate types, but
// its support for this did not work prior to GCC 9 and is not yet well
// understood.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

[llvmbot]

@llvm/issue-subscribers-c-1

[inclyc]

https://godbolt.org/z/oz4e7bobT
https://godbolt.org/z/hE6x9G49q

What does gcc actually thought about this builtin function? See godbolt links above, __builtin_constant_p may pass static assertions but evalutes to 0 (as return value)? That's quite insane.

Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107104

[JohelEGP]

Another difference is that GCC works when naming a subobject of class type of an union: https://compiler-explorer.com/z/do4Ev6eKP.

union X {
  struct Y { } y = {};
  struct Z { } z;
};
// Name a subobject of class type of an union.
static_assert(    __builtin_constant_p(X{}.y));
static_assert(not __builtin_constant_p(X{}.z));

[h-2]

In general we do aim for GCC compatibility with those builtins.

That's good 👍

// FIXME: GCC also intends to return 1 for literals of aggregate types, but

I don't think that this is related to aggregate types. It is possible to change the example so the type is no longer an aggregate:

#include <type_traits>

#define IS_CONSTEXPR(...) std::integral_constant<bool, __builtin_constant_p((__VA_ARGS__, 0))>::value

struct S
{
    constexpr S() =  default;
    constexpr S(S const & ) =  default;
    constexpr S(S && ) =  default;
    constexpr S & operator=(S const & ) =  default;
    constexpr S & operator=(S && ) =  default;

    int i = 0;

    constexpr S & assign_int(int j)
    {
        i = j;
        return *this;
    }
};

static_assert(!std::is_aggregate_v<S>);

inline constexpr auto s = S{}.assign_int(3);    // works
static_assert(IS_CONSTEXPR(S{}.assign_int(3))); // fails in clang, passes in GCC

[build with -std=c++20]

=> same behaviour

What does gcc actually thought about this builtin function?

That's interesting (and surprising), but I don't think it is related to this issue.

[inclyc]

That's interesting (and surprising), but I don't think it is related to this issue.

Since __builtin_constant_p() is an extension of GCC, we must first understand the behavior of GCC (preferably with a specification) and have enough documentation to allow us to implement it correctly.

[h-2]

Since __builtin_constant_p() is an extension of GCC, we must first understand the behavior of GCC (preferably with a specification) and have enough documentation to allow us to implement it correctly.

I didn't want to suggest that I know how to best implement this, and I agree that having a specification is always helpful of course. It is quite possible that the inconsistency you found is the reason I wrapped everything in std::integral_constant when I wrote the macro initially (it's been some time and I remember vaguely that it was necessary).

However, it does seem obvious to me that what you found is a bug in GCC (that no-one expects clang to replicate) while what I reported here seem like a bug in clang (that would be nice to get fixed), because the expression is a well-formed constant expression. Or not?

edit: I retract the last paragraph. GCC's current behaviour is by design, I think. See my comments there. [and let's maybe discuss that there further]

[inclyc]

However, it does seem obvious to me that what you found is a bug in GCC (that no-one expects clang to replicate) while what I reported here seem like a bug in clang (that would be nice to get fixed), because the expression is a well-formed constant expression. Or not?

Look at https://godbolt.org/z/oz4e7bobT and you can see that your expression (reduced) passed static assertion in GCC, but the returning value is 0 (xor eax, eax). This in itself is self-contradictory. And clang's behavior at the goal of this extension is to be consistent with GCC. clang's evaluation to 0 here is consistent with the evaluation result of the GCC (as the returning value).

[h-2]

I updated my comment and provided further comments over at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107104
I think the behaviour is by design. I would still propose that we continue discussing GCC over at GCC, and use this issue to discuss clang's behaviour on the initial example.

[inclyc]

I updated my comment and provided further comments over at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107104
I think the behaviour is by design. I would still propose that we continue discussing GCC over at GCC, and use this issue to discuss clang's behaviour on the initial example.
If you evaluate it in a non-const-context, the expression passed as argument may or may not be evaluated at compile-time, so the value of __builtin_constant_p may or may not be 1.

If this is true, we may have a completely different implementation than GCC (as can be seen in the various examples mentioned above).