`__builtin_bit_cast` to `bool` diverges from GCC's behavior

[tbaederr]

This is the specific case:

constexpr bool A = __builtin_bit_cast(bool, 'A');
static_assert(A);

GCC happily compiles this while clang prints an error:

array.cpp:128:16: error: constexpr variable 'a' must be initialized by a constant expression
  128 | constexpr bool a = __builtin_bit_cast(bool, 'A');
      |                ^   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
array.cpp:128:20: note: value 65 cannot be represented in type 'bool'
  128 | constexpr bool a = __builtin_bit_cast(bool, 'A');
      |                    ^

This specific diagnostic is tested exactly once, in SemaCXX/constexpr-builtin-bit-cast.cpp. It's an edge case which clang checks for all integral types though:

llvm-project/clang/lib/AST/ExprConstant.cpp

Lines 7495 to 7507 in 0693b9e

	if (T->isIntegralOrEnumerationType()) {
	Val.setIsSigned(T->isSignedIntegerOrEnumerationType());
	unsigned IntWidth = Info.Ctx.getIntWidth(QualType(T, 0));
	if (IntWidth != Val.getBitWidth()) {
	APSInt Truncated = Val.trunc(IntWidth);
	if (Truncated.extend(Val.getBitWidth()) != Val)
	return unrepresentableValue(QualType(T, 0), Val);
	Val = Truncated;
	}
	return APValue(Val);
	}

I think the relevant part from https://eel.is/c++draft/bit.cast is

For the result and each object created within it, if there is no value of the object's type corresponding to the value representation produced, the behavior is undefined.
If there are multiple such values, which value is produced is unspecified.

Does the first sentence apply here or the second?

CC @zygoloid

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Timm Baeder (tbaederr)

This is the specific case: ```c++ constexpr bool A = __builtin_bit_cast(bool, 'A'); static_assert(A); ```

GCC happily compiles this while clang prints an error:

array.cpp:128:16: error: constexpr variable 'a' must be initialized by a constant expression
  128 | constexpr bool a = __builtin_bit_cast(bool, 'A');
      |                ^   ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
array.cpp:128:20: note: value 65 cannot be represented in type 'bool'
  128 | constexpr bool a = __builtin_bit_cast(bool, 'A');
      |                    ^

This specific diagnostic is tested exactly once, in SemaCXX/constexpr-builtin-bit-cast.cpp. It's an edge case which clang checks for all integral types though:

llvm-project/clang/lib/AST/ExprConstant.cpp

Lines 7495 to 7507 in 0693b9e

	if (T->isIntegralOrEnumerationType()) {
	Val.setIsSigned(T->isSignedIntegerOrEnumerationType());
	unsigned IntWidth = Info.Ctx.getIntWidth(QualType(T, 0));
	if (IntWidth != Val.getBitWidth()) {
	APSInt Truncated = Val.trunc(IntWidth);
	if (Truncated.extend(Val.getBitWidth()) != Val)
	return unrepresentableValue(QualType(T, 0), Val);
	Val = Truncated;
	}
	return APValue(Val);
	}

I think the relevant part from https://eel.is/c++draft/bit.cast is
> For the result and each object created within it, if there is no value of the object's type corresponding to the value representation produced, the behavior is undefined[.](https://eel.is/c++draft/bit.cast#2.sentence-5)
If there are multiple such values, which value is produced is unspecified[.](https://eel.is/c++draft/bit.cast#2.sentence-6)

Does the first sentence apply here or the second?

CC @zygoloid

[shafik]

It is usually helpful w/ language lawyer type questions to include a comparison of all implementations: https://godbolt.org/z/G4vaee56h

This may not be "conclusive" but may indicate a need for a defect report if there is significant divergence.

Considering based on the proposal this is meant to map to memcpy and memcpy'ing the value A to a bool would be undefined behavior. I think this should be ill-formed.

I don't see a way of mapping the intent otherwise.

[zygoloid]

Clang (and its supported ABIs) treat bool as having 8 bits in its value representation. The bit representation 0b00000000 maps to false, the representation 0b00000001 maps to true, and all other value representations do not represent any value. I believe Clang's behavior here is in line with that, and the other compilers seem to be getting this wrong.

[pinskia]

So GCC is treating the other bits in bool as padding bits when dealing with bit_cast.
As evidence by doing:

constexpr bool A = std::bit_cast<bool>((char)('A'&~0x1));
static_assert(A);

But at runtime treats the padding bits as required to be zero.

So the question is bool representation one bit followed by padding bits or one bit followed by zero bits. Or is this just one of the oddities of how to handle padding bits that are non-zero at compile time.

While MSVC does not treats it as non-padding bits but rather 0 or non-zero as valid values for bool. At least at constexpr time.

[pinskia]

I filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118134 for the GCC issue since there is inconsistency at compile time vs runtime.

[shafik]

So GCC is treating the other bits in bool as padding bits when dealing with bit_cast. As evidence by doing:

constexpr bool A = std::bit_cast<bool>((char)('A'&~0x1));
static_assert(A);

But at runtime treats the padding bits as required to be zero.

So the question is bool representation one bit followed by padding bits or one bit followed by zero bits. Or is this just one of the oddities of how to handle padding bits that are non-zero at compile time.

While MSVC does not treats it as non-padding bits but rather 0 or non-zero as valid values for bool. At least at constexpr time.

This is just simply undefined behavior. The standard does not specify the value representation of true or false and so this as-if we just memcpy'ed it into a bool which would be UB as well. The proposal for bit_cast makes it clear that the intent is that this is basically a constant expression memcpy.

[frederick-vs-ja]

I guess it was intended that UB in std::bit_cast is considered as library UB, so implementation divergence can be allowed.

[shafik]

I forgot we recently updated bit_cast, it now says:

... Each bit of the value representation of the result is equal to the corresponding bit in the object representation of from. Padding bits of the result are unspecified. For the result and each object created within it, if there is no value of the object's type corresponding to the value representation produced, the behavior is undefined ...

I read this to say we can't treat the from object representation bits as padding and so we should have UB here.

and expr.const p12 says this is unspecified whether this is a constant expression, so I guess both are right? I find this unsatisfying result.