On Monday, 17 March 2025, Christophe Lyon <christophe.l...@linaro.org> wrote: > On Sun, 16 Mar 2025 at 21:54, Jonathan Wakely <jwak...@redhat.com> wrote: >> >> On Sun, 16 Mar 2025 at 13:16, <ci_not...@linaro.org> wrote: >> > >> > Dear contributor, >> > >> > Our automatic CI has detected problems related to your patch(es). Please find some details below. >> > >> > In arm-eabi cortex-m23 soft, after: >> > | commit gcc-15-8035-g7ee31bc9276 >> > | Author: Jonathan Wakely <jwak...@redhat.com> >> > | Date: Thu Mar 13 13:34:55 2025 +0000 >> > | >> > | libstdc++: Implement <stdbit.h> for C++26 (P3370R1) >> > | >> > | This is the first part of the P3370R1 proposal just approved by the >> > | committee in Wrocław. This adds C++ equivalents of the functions added >> > | to C23 by WG14 N3022. >> > | ... 16 lines of the commit log omitted. >> > >> > Produces 2 regressions: >> > | >> > | regressions.sum: >> > | Running libstdc++:libstdc++-dg/conformance.exp ... >> > | FAIL: 20_util/stdbit/1.cc -std=gnu++26 (test for excess errors) >> > | UNRESOLVED: 20_util/stdbit/1.cc -std=gnu++26 compilation failed to produce executable >> > >> > Used configuration : >> > *CI config* tcwg_gnu_embed_check_gcc arm-eabi -mthumb -march=armv8-m.base -mtune=cortex-m23 -mfloat-abi=soft -mfpu=auto >> > *configure and test flags:* --target arm-eabi --disable-multilib --with-mode=thumb --with-cpu=cortex-m23 --with-float=soft --target_board=-mthumb/-march=armv8-m.base/-mtune=cortex-m23/-mfloat-abi=soft/-mfpu=auto qemu_cpu=cortex-m33 >> > >> > We track this bug report under https://linaro.atlassian.net/browse/GNU-1543. Please let us know if you have a fix. >> >> All the errors are of the form: >> error: 'ULLONG_MAX' was not declared in this scope >> but the test includes <limits.h>. >> >> So this target doesn't support long long? Or just doesn't define ULLONG_MAX? >> > > It does... > > I've manually reproduced it, and ISTM the problem is __STDC_VERSION__ > is not defined, > as gcc/glimits.h expects: > https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/glimits.h;h=d5877602bf741383cfddb13236fbba1cf0b5b520;hb=HEAD#l102
Aha! Thanks. > Compiling > ============== > #include <limits.h> > unsigned long long var = ULLONG_MAX; > ================ > works with the same compiler, in C mode. > > But why would that work on arm-linux-gnueabihf and not on arm-none-eabi? I think glimits.h use only used if libc doesn't provide one, and I guess glibc's limits.h is used for gnueabihf The C++ standard says it's implementation-defined whether __STDC_VERSION__ is defined by a C++ compiler, and if defined, it's implementation-defined what is value is GCC/glimits.h should check || (defined(__cplusplus) && __cplusplus >= 201103L)) i.e. long long should be supported for C++11 and later. Libstdc++ actually assumes long long is always supported even for C++98 so I'm surprised we've never noticed this before! I think we probably use the type without using the LLONG_MAX macro, so it just happens to work. I can adjust the test to be agnostic to that macro, but I'll also propose a patch to check __cplusplus in glimits.h Thanks again for finding the cause here. > > Christophe > >> _______________________________________________ >> linaro-toolchain mailing list -- linaro-toolch...@lists.linaro.org >> To unsubscribe send an email to linaro-toolchain-le...@lists.linaro.org > >