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
>
>

Reply via email to