From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 619893857026 for ; Wed, 4 Oct 2023 15:56:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 619893857026 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1696435007; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=yLsVQTgqnL6hICBohmWCMVc3j+NuNmTl9wxKkTAbnME=; b=gcG+rXWsc6C9eTOr07uVmTOu3cdyaXz+kgxLbMJE/XCT91TexqwZ3YBmxGY2deTfUABYvS 2ymqkXGTxL0h1PurywRg1BjvGCCxrX3hbzsvOi8P9yLkJkou9BAsAT/C2FSZiWAvxrWr9a zXrrz4OZFYtncKYEgh1cZ8EbkFS0q+Q= Received: from mail-lj1-f200.google.com (mail-lj1-f200.google.com [209.85.208.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-397-DwnE51rlM6yTPvq9RRoGyw-1; Wed, 04 Oct 2023 11:56:45 -0400 X-MC-Unique: DwnE51rlM6yTPvq9RRoGyw-1 Received: by mail-lj1-f200.google.com with SMTP id 38308e7fff4ca-2c2abc078ecso9831fa.3 for ; Wed, 04 Oct 2023 08:56:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696435004; x=1697039804; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=yLsVQTgqnL6hICBohmWCMVc3j+NuNmTl9wxKkTAbnME=; b=YZL34ZoOhYSc3i83eGgEU4enCwsiIdFwQngblBx+LnjGcadwcgTV5KoB2o7spFt8HE gfH6NRzjcrOOMoQy+A7Ix/vEb9cERA456Qp+dzLOmtAnD/uej8dtwXF6vcaYmn03fqaV FZL+xKWOf1Yfkbmspfy815oAoGWXvgp2XvbKGHHjaKbj4UH4DfisjmI63dBuKwByhOYe JYz48nfXV4t6pdE+xj5UAU0+pUq2+s7aM/795V6hSB1pkJdTHcTnZ5LueRDH+Hpjahia 3lyY3BVlkEnaw+gIikX5A8pFX9IaPhTmXIzmEuecsr749Z3QdLQddf1B0ohDOgT/gdcV FTyA== X-Gm-Message-State: AOJu0YwXc12a1v5zDVIuSr8vV1prs0UfkMY8cfXBUUbyMnWwAld8blNX 4y/dPFs3ilw3HeC5oN20h3Oj/RnAyOakUIYmHnVOfL/jRotQ7SpHjs+dkGd5zdtZe3I/7fTbKAN M4dIzg+hR1Bo1ZgJp4/kacK1s118Hh5w= X-Received: by 2002:a2e:96c7:0:b0:2bc:c4af:36b7 with SMTP id d7-20020a2e96c7000000b002bcc4af36b7mr2624884ljj.39.1696435004280; Wed, 04 Oct 2023 08:56:44 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHC+sH57d2GaiSCm+TA++zOETSVYt383WWWFcHjmgUCksWGXl20lLHehxltizvIptYBTUaEyOIsjbly3wboqXo= X-Received: by 2002:a2e:96c7:0:b0:2bc:c4af:36b7 with SMTP id d7-20020a2e96c7000000b002bcc4af36b7mr2624875ljj.39.1696435003901; Wed, 04 Oct 2023 08:56:43 -0700 (PDT) MIME-Version: 1.0 References: <20230817203213.1131496-1-jwakely@redhat.com> <097e48f1-b915-4d6c-b68e-8ee282bc6de5@redhat.com> In-Reply-To: <097e48f1-b915-4d6c-b68e-8ee282bc6de5@redhat.com> From: Jonathan Wakely Date: Wed, 4 Oct 2023 16:56:32 +0100 Message-ID: Subject: Re: [committed] libstdc++: Define std::numeric_limits<_FloatNN> before C++23 To: Stephan Bergmann Cc: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org, Pranav Kant X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-12.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,KAM_NUMSUBJECT,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, 4 Oct 2023 at 16:54, Stephan Bergmann wrote: > > 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 > > 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): 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 > > "[clang] Predefined macros for float128 support (#67196)", Clang 18 > trunk does predefine __FLT128_DIG__ now. Which causes > > > $ cat test.cc > > #include > > > $ 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> \ > > | ^ > > :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 > "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.) It's completely wrong or Clang to define a macro describing properties of a non-existent type. This was reported as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111687 and closed as INVALID, it needs to be fixed in Clang. >