aboutsummaryrefslogtreecommitdiff
path: root/gcc/config.gcc
diff options
context:
space:
mode:
authorJonathan Wakely <jwakely@redhat.com>2020-12-16 15:54:50 +0000
committerJonathan Wakely <jwakely@redhat.com>2020-12-16 19:25:09 +0000
commit767537a8b027bcb5807bb45b0268c5da98c2c7a0 (patch)
tree6b0ef58634ac26c6e2575c1f60427f56248ffea9 /gcc/config.gcc
parente128aaa6e5d792425afffdeac421f5076c15b9f0 (diff)
downloadgcc-767537a8b027bcb5807bb45b0268c5da98c2c7a0.zip
gcc-767537a8b027bcb5807bb45b0268c5da98c2c7a0.tar.gz
gcc-767537a8b027bcb5807bb45b0268c5da98c2c7a0.tar.bz2
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.
Diffstat (limited to 'gcc/config.gcc')
0 files changed, 0 insertions, 0 deletions