]> git.ipfire.org Git - thirdparty/gcc.git/commit
libstdc++: Make <stdbit.h> test use <climits> instead of <limits.h>
authorJonathan Wakely <jwakely@redhat.com>
Mon, 17 Mar 2025 15:02:12 +0000 (15:02 +0000)
committerJonathan Wakely <redi@gcc.gnu.org>
Wed, 19 Mar 2025 20:59:54 +0000 (20:59 +0000)
commit562416d8131dc9eeb4a778e7ef476157dbd9afd2
tree1de81aa6b3f7ae3e829ee2e155b0bcf560b24cb7
parent6c443e128802bd93158a3db7c4edf5fc1fc76c8d
libstdc++: Make <stdbit.h> test use <climits> instead of <limits.h>

Our <climits> ensures that LLONG_MIN, LLONG_MAX, and ULLONG_MAX are
defined even if the C library's <limits.h> doesn't define them. Our
<limits.h> then includes <climits>, which should mean that <limits.h>
and <climits> always define the same macros. However, we only install
our own version of <limits.h> for --enable-cheaders=c and not for the
default --enable-cheaders=c_global setting that everybody uses.

This means that if the C library's <limits.h> is not C++-aware, or if
the C library doesn't provide it and GCC's own gcc/glimits.h is used
instead, then <climits> defines the macros for long long types but
<limits.h> does not.

This causes the new 20_util/stdbit/1.cc test to fail for arm-non-eabi
because it uses gcc/glimits.h which is not C++-aware, only checking
__STDC_VERSION__ when deciding whether to declare the long long macros.
If gcc/glimits.h also checked __cplusplus it would be OK, and we would
not need our own <limits.h> to be installed.

This commit just changes the new test to use <climits> instead of
<limits.h>, but we should ensure that gcc/glimits.h is made to work
(i.e.  define the long long macros) for C++, and/or install our own
<limits.h> for the --enable-cheaders=c_global configuration.

libstdc++-v3/ChangeLog:

* testsuite/20_util/stdbit/1.cc: Include <climits> instead of
<limits.h>.
libstdc++-v3/testsuite/20_util/stdbit/1.cc