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 [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id 015E2383300B for ; Wed, 16 Dec 2020 19:26:12 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 015E2383300B Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-414-E_FRv46TN7aHTjmuCX1WJw-1; Wed, 16 Dec 2020 14:26:10 -0500 X-MC-Unique: E_FRv46TN7aHTjmuCX1WJw-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 72879800D53; Wed, 16 Dec 2020 19:26:09 +0000 (UTC) Received: from localhost (unknown [10.33.36.115]) by smtp.corp.redhat.com (Postfix) with ESMTP id 1FB8D6294F; Wed, 16 Dec 2020 19:26:08 +0000 (UTC) Date: Wed, 16 Dec 2020 19:26:08 +0000 From: Jonathan Wakely To: libstdc++@gcc.gnu.org, gcc-patches@gcc.gnu.org Cc: Jeff Law Subject: [committed] libstdc++: Warn if __STRICT_ANSI has been undefined Message-ID: <20201216192608.GA1085206@redhat.com> MIME-Version: 1.0 X-Clacks-Overhead: GNU Terry Pratchett X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/mixed; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline X-Spam-Status: No, score=-13.9 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libstdc++@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libstdc++ mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Dec 2020 19:26:14 -0000 --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Recent changes to use __int128 as an integer-like type in and to optimize std::uniform_int_distribution mean that the library relies on __int128 more heavily than in the past. The library expects that if __int128 is supported then either __GLIBCXX_TYPE_INT_N_0 is defined (and we treat is like the standard integer types), or __STRICT_ANSI__ is defined (and we need to add special handling for __int128 as a non-standard integer type). If users compile with -std=c++NN -U__STRICT_ANSI__ then it puts the library into a broken and inconsistent state, where the compiler doesn't define the __GLIBCXX_TYPE_INT_N_0 macro, but the library thinks it doesn't need special handling for __int128. What the user should do is compile with -std=gnu++NN instead. This adds a warning if it appears that __int128 is supported but neither __GLIBCXX_TYPE_INT_N_0 nor __STRICT_ANSI__ is defined. libstdc++-v3/ChangeLog: * include/bits/c++config: Warn if __STRICT_ANSI__ state is inconsistent with __GLIBCXX_TYPE_INT_N_0. Tested powerpc64-linux. Committed to trunk. --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="patch.txt" commit 767537a8b027bcb5807bb45b0268c5da98c2c7a0 Author: Jonathan Wakely Date: Wed Dec 16 15:54:50 2020 libstdc++: Warn if __STRICT_ANSI has been undefined Recent changes to use __int128 as an integer-like type in and to optimize std::uniform_int_distribution mean that the library relies on __int128 more heavily than in the past. The library expects that if __int128 is supported then either __GLIBCXX_TYPE_INT_N_0 is defined (and we treat is like the standard integer types), or __STRICT_ANSI__ is defined (and we need to add special handling for __int128 as a non-standard integer type). If users compile with -std=c++NN -U__STRICT_ANSI__ then it puts the library into a broken and inconsistent state, where the compiler doesn't define the __GLIBCXX_TYPE_INT_N_0 macro, but the library thinks it doesn't need special handling for __int128. What the user should do is compile with -std=gnu++NN instead. This adds a warning if it appears that __int128 is supported but neither __GLIBCXX_TYPE_INT_N_0 nor __STRICT_ANSI__ is defined. libstdc++-v3/ChangeLog: * include/bits/c++config: Warn if __STRICT_ANSI__ state is inconsistent with __GLIBCXX_TYPE_INT_N_0. diff --git a/libstdc++-v3/include/bits/c++config b/libstdc++-v3/include/bits/c++config index 155d0f46b16..cd7678eb16d 100644 --- a/libstdc++-v3/include/bits/c++config +++ b/libstdc++-v3/include/bits/c++config @@ -524,6 +524,15 @@ namespace std #define _GLIBCXX_USE_ALLOCATOR_NEW +#ifdef __SIZEOF_INT128__ +#if ! defined __GLIBCXX_TYPE_INT_N_0 && ! defined __STRICT_ANSI__ +// If __int128 is supported, we expect __GLIBCXX_TYPE_INT_N_0 to be defined +// unless the compiler is in strict mode. If it's not defined and the strict +// macro is not defined, something is wrong. +#warning "__STRICT_ANSI__ seems to have been undefined; this is not supported" +#endif +#endif + #else // !__cplusplus # define _GLIBCXX_BEGIN_EXTERN_C # define _GLIBCXX_END_EXTERN_C --qDbXVdCdHGoSgWSk--