public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Stephan Bergmann <sbergman@redhat.com>
To: Jonathan Wakely <jwakely@redhat.com>,
	libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org
Cc: Pranav Kant <prka@google.com>
Subject: Re: [committed] libstdc++: Define std::numeric_limits<_FloatNN> before C++23
Date: Wed, 4 Oct 2023 17:54:38 +0200	[thread overview]
Message-ID: <097e48f1-b915-4d6c-b68e-8ee282bc6de5@redhat.com> (raw)
In-Reply-To: <20230817203213.1131496-1-jwakely@redhat.com>

On 8/17/23 22:32, Jonathan Wakely via Libstdc++ wrote:
> Tested x86_64-linux. Pushed to trunk.
> 
> -- >8 --
> 
> The extended floating-point types such as _Float32 are supported by GCC
> prior to C++23, you just can't use the standard-conforming names from
> <stdfloat> to refer to them. This change defines the specializations of
> std::numeric_limits for those types for older dialects, not only for
> C++23.
> 
> libstdc++-v3/ChangeLog:
> 
> 	* include/bits/c++config (__gnu_cxx::__bfloat16_t): Define
> 	whenever __BFLT16_DIG__ is defined, not only for C++23.
> 	* include/std/limits (numeric_limits<bfloat16_t>): Likewise.
> 	(numeric_limits<_Float16>, numeric_limits<_Float32>)
> 	(numeric_limits<_Float64>): Likewise for other extended
> 	floating-point types.
> ---
>   libstdc++-v3/include/bits/c++config |   4 +-
>   libstdc++-v3/include/std/limits     | 194 +++++++++++++++-------------
>   2 files changed, 103 insertions(+), 95 deletions(-)
> 
[...]
> diff --git a/libstdc++-v3/include/std/limits b/libstdc++-v3/include/std/limits
> index 52b19ef8264..7a59e7520eb 100644
> --- a/libstdc++-v3/include/std/limits
> +++ b/libstdc++-v3/include/std/limits
> @@ -1890,189 +1890,197 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
[...]
>   __glibcxx_float_n(64)
>   #endif
> -#ifdef __STDCPP_FLOAT128_T__
> +#ifdef __FLT128_DIG__
>   __glibcxx_float_n(128)
>   #endif
>   #undef __glibcxx_float_n
[...]

The above change (from __STDCPP_FLOAT128_T__ to __FLT128_DIG__) now 
started to cause issues with Clang on Clang 18 trunk:

* Clang does not support a _Float128 type.

* Clang does not predefine __STDCPP_FLOAT128_T__.

* But since 
<https://github.com/llvm/llvm-project/commit/457f582ffe23e951380bc345c4c96ec053c09681> 
"[clang] Predefined macros for float128 support (#67196)", Clang 18 
trunk does predefine __FLT128_DIG__ now.  Which causes

> $ cat test.cc
> #include <limits>

> $ clang++ -fsyntax-only test.cc
> In file included from test.cc:1:
> /home/sbergman/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/14.0.0/../../../../include/c++/14.0.0/limits:1995:1: error: use of undeclared identifier '_Float128'
>  1995 | __glibcxx_float_n(128)
>       | ^
> /home/sbergman/gcc/trunk/inst/lib/gcc/x86_64-pc-linux-gnu/14.0.0/../../../../include/c++/14.0.0/limits:1903:27: note: expanded from macro '__glibcxx_float_n'
>  1903 |     struct numeric_limits<_Float##BITSIZE>                              \
>       |                           ^
> <scratch space>:36:1: note: expanded from here
>    36 | _Float128
>       | ^
> 1 error generated.

(I don't know whether or not it is useful for Clang to predefine 
__FLT128_DIG__ when not providing a _Float128 type.  I assume 
<https://www.iso.org/standard/65615.html> "ISO/IEC TS 18661-3:2015", as 
referenced by the C++ standard, might be relevant here, but don't know 
that document.  I added Pranav, the author of the relevant Clang commit, 
in cc here.)


  reply	other threads:[~2023-10-04 15:55 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-17 20:32 Jonathan Wakely
2023-10-04 15:54 ` Stephan Bergmann [this message]
2023-10-04 15:56   ` Jonathan Wakely
2023-10-04 16:47     ` Pranav Kant
2023-10-04 16:57       ` Jakub Jelinek
2023-10-04 17:00         ` Pranav Kant
2023-10-04 18:21           ` Pranav Kant

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=097e48f1-b915-4d6c-b68e-8ee282bc6de5@redhat.com \
    --to=sbergman@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jwakely@redhat.com \
    --cc=libstdc++@gcc.gnu.org \
    --cc=prka@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).