On Wed, 19 Mar 2025 at 22:02, Jonathan Wakely <jwak...@redhat.com> wrote: > > On Mon, 17 Mar 2025 at 14:54, Jonathan Wakely <jwak...@redhat.com> wrote: > > > > On Mon, 17 Mar 2025 at 09:53, Jonathan Wakely <jwak...@redhat.com> wrote: > > > > > > > > > > > > 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. > > > > Hmm, except that libstdc++ provides <climits> which should add > > ULLONG_MAX if it's not defined by libc: > > https://gcc.gnu.org/cgit/gcc/tree/libstdc++-v3/include/c_global/climits > > And <limits.h> should find the libstdc++ version which includes > > <climits>., but we're not installing the libstdc++ version of > > <limits.h>. > > That's a libstdc++ bug. > > The FAIL for arm-none-eabi should be fixed at r15-8450-g562416d8131dc9
Indeed, thanks! > > I'll deal with the libstdc++ bug in stage 1. > Thanks, Christophe _______________________________________________ linaro-toolchain mailing list -- linaro-toolchain@lists.linaro.org To unsubscribe send an email to linaro-toolchain-le...@lists.linaro.org
