* [committed] libstdc++: Warn if __STRICT_ANSI has been undefined
@ 2020-12-16 19:26 Jonathan Wakely
0 siblings, 0 replies; only message in thread
From: Jonathan Wakely @ 2020-12-16 19:26 UTC (permalink / raw)
To: libstdc++, gcc-patches; +Cc: Jeff Law
[-- Attachment #1: Type: text/plain, Size: 1065 bytes --]
Recent changes to use __int128 as an integer-like type in <ranges> 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.
[-- Attachment #2: patch.txt --]
[-- Type: text/plain, Size: 2075 bytes --]
commit 767537a8b027bcb5807bb45b0268c5da98c2c7a0
Author: Jonathan Wakely <jwakely@redhat.com>
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 <ranges> 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
^ permalink raw reply [flat|nested] only message in thread
only message in thread, other threads:[~2020-12-16 19:26 UTC | newest]
Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-16 19:26 [committed] libstdc++: Warn if __STRICT_ANSI has been undefined Jonathan Wakely
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).