[gcc/gcc-TEST] Discussion summary of #28 Add new C23 headers for C++26 (P3370R1)

[Jonathan Wakely via Claudio Bantaloukas]

This is a summary of discussions relative to the merge request titled
Add new C23 headers for C++26 (P3370R1)
since its creation. The merge request was created by Jonathan Wakely (redi).
The full and up to date discussion can be found at https://forge.sourceware.org/gcc/gcc-TEST/pulls/28

------------8<------------
On 2025-03-05 14:39:58+00:00,  (tkaminsk) commented on the code:




> +++ libstdc++-v3/src/c++23/std.compat.cc.in
> @@ -27,0 +29,4 @@
> +// <stdbit.h>
> +export
> +{
> +  using __gnu_cxx::stdc_leading_zeros_uc;

Could you consider using an XMACRO for defining them, similary to what is done in `stdbit.h`.


------------8<------------
On 2025-03-06 16:50:18+00:00,  (ppalka) requested changes to the code:




> +++ libstdc++-v3/include/c_compatibility/stdckdint.h
> @@ -0,0 +47,4 @@
> +  template<typename _Tp>
> +    concept __cv_unqual_signed_or_unsigned_integer_type
> +      = std::same_as<_Tp, std::remove_cvref_t<_Tp>>
> +       && __signed_or_unsigned_integer_type<_Tp>;

Could we just use `__is_standard_integer<_Tp>::value`?

> +++ libstdc++-v3/include/c_compatibility/stdckdint.h
> @@ -0,0 +47,4 @@
> +  template<typename _Tp>
> +    concept __cv_unqual_signed_or_unsigned_integer_type
> +      = std::same_as<_Tp, std::remove_cvref_t<_Tp>>
> +       && __signed_or_unsigned_integer_type<_Tp>;

Hmm, yes. The C++26 draft says "cv-unqualified signed or unsigned integer type" but that's a tautology because the signed and unsigned integer types are all cv-unqualified.


> +++ libstdc++-v3/include/c_compatibility/stdckdint.h
> @@ -0,0 +47,4 @@
> +  template<typename _Tp>
> +    concept __cv_unqual_signed_or_unsigned_integer_type
> +      = std::same_as<_Tp, std::remove_cvref_t<_Tp>>
> +       && __signed_or_unsigned_integer_type<_Tp>;

I meant use the existing `__is_standard_integer` trait instead of introducing the new `__signed_or_unsigned_integer` which is essentially the concept version of the former?

IIUC we'd still need the cv-qual check since `__is_standard_integer` itself isn't sensitive to cv-quals, but perhaps `remove_cv_t` would suffice instead of `remove_cvref_t`.

I don't feel strongly about either of these suggestions though :)

> +++ libstdc++-v3/include/c_compatibility/stdckdint.h
> @@ -0,0 +47,4 @@
> +  template<typename _Tp>
> +    concept __cv_unqual_signed_or_unsigned_integer_type
> +      = std::same_as<_Tp, std::remove_cvref_t<_Tp>>
> +       && __signed_or_unsigned_integer_type<_Tp>;

@ppalka wrote in https://forge.sourceware.org/gcc/gcc-TEST/pulls/28#issuecomment-763:

> I meant use the existing `__is_standard_integer` trait instead of introducing the new `__signed_or_unsigned_integer` which is essentially the concept version of the former?

Oh right, I thought you meant to completely replace `__cv_unqual_signed_or_unsigned_integer_type`, because I missed that ...

>
>  `__is_standard_integer` itself isn't sensitive to cv-quals,

Well that's confusingly inconsistent with the definition of _signed integer type_ and _unsigned integer type_ in the standard.

> but perhaps `remove_cv_t` would suffice instead of `remove_cvref_t`.

Indeed.

I've pushed a new version.


> +++ libstdc++-v3/include/c_compatibility/stdckdint.h
> @@ -0,0 +106,4 @@
> +using __gnu_cxx::ckd_sub;
> +using __gnu_cxx::ckd_mul;
> +
> +#endif // C++23

C++26

> +++ libstdc++-v3/include/c_compatibility/stdckdint.h
> @@ -0,0 +46,4 @@
> +
> +  template<typename _Tp>
> +    concept __cv_unqual_signed_or_unsigned_integer_type
> +      = std::same_as<_Tp, std::remove_cvref_t<_Tp>>

Seems `remove_cv_t` would be sufficient?

> +++ libstdc++-v3/include/c_compatibility/stdckdint.h
> @@ -0,0 +46,4 @@
> +
> +  template<typename _Tp>
> +    concept __cv_unqual_signed_or_unsigned_integer_type
> +      = std::same_as<_Tp, std::remove_cvref_t<_Tp>>

Never mind,  it's more understandable to directly reject reference types via `remove_cvref_t` instead of indirectly through the next constraint.

> +++ libstdc++-v3/include/c_compatibility/stdckdint.h
> @@ -0,0 +35,4 @@
> +
> +#define __STDC_VERSION_STDCKDINT_H__ 202311L
> +
> +namespace __gnu_cxx _GLIBCXX_VISIBILITY(default)

I guess we could use the `_GLIBCXX_DOXYGEN` in this header too

> +++ libstdc++-v3/include/c_compatibility/stdbit.h
> @@ -0,0 +577,4 @@
> +_GLIBCXX_STDBIT_FUNC(stdc_bit_ceil);
> +#undef _GLIBCXX_STDBIT_FUNC
> +#endif // !DOXYGEN
> +#endif // C++23

C++26


------------8<------------
On 2025-03-13 14:13:55+00:00,  (ppalka) wrote:

LGTM


------------8<------------
On 2025-09-08 20:59:29+00:00, Linaro TCWG CI (linaroci) wrote:

<!-- linaro-ci-status CI bot tcwg_gnu_cross_build--master-aarch64 -->
CI state: fail :x:
CI bot tcwg_gnu_cross_build--master-aarch64 : CI bot tcwg_gnu_cross_build--master-aarch64: Patch failed to apply
See: https://ci.linaro.org/job/tcwg_gnu_cross_build--master-aarch64-precommit/27/artifact/artifacts/jenkins/precommit-forge-apply.log



------------8<------------
On 2025-09-08 22:19:44+00:00, Linaro TCWG CI (linaroci) wrote:

<!-- linaro-ci-status CI bot tcwg_gnu_cross_build--master-arm -->
CI state: fail :x:
CI bot tcwg_gnu_cross_build--master-arm : CI bot tcwg_gnu_cross_build--master-arm: Patch failed to apply
See: https://ci.linaro.org/job/tcwg_gnu_cross_build--master-arm-precommit/46/artifact/artifacts/jenkins/precommit-forge-apply.log



------------8<------------
On 2025-09-08 22:27:20+00:00, Jonathan Wakely (redi) wrote:

These headers were already pushed to trunk so I'm closing this
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.