Re: [Linaro-TCWG-CI] gcc-15-8035-g7ee31bc9276: 2 regressions on master-thumb_m23_soft_eabi
On Sun, 16 Mar 2025 at 13:16, ci_notify@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 jwakely@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?
On Sun, 16 Mar 2025 at 21:54, Jonathan Wakely jwakely@redhat.com wrote:
On Sun, 16 Mar 2025 at 13:16, ci_notify@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 jwakely@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%3Ba=blob%3Bf=gcc/glimits.h%3Bh=d5877602bf...
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?
Christophe
linaro-toolchain mailing list -- linaro-toolchain@lists.linaro.org To unsubscribe send an email to linaro-toolchain-leave@lists.linaro.org
On Monday, 17 March 2025, Christophe Lyon christophe.lyon@linaro.org wrote:
On Sun, 16 Mar 2025 at 21:54, Jonathan Wakely jwakely@redhat.com wrote:
On Sun, 16 Mar 2025 at 13:16, ci_notify@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 jwakely@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%3Ba=blob%3Bf=gcc/glimits.h%3Bh=d5877602bf...
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-toolchain@lists.linaro.org To unsubscribe send an email to linaro-toolchain-leave@lists.linaro.org
On Mon, 17 Mar 2025 at 09:53, Jonathan Wakely jwakely@redhat.com wrote:
On Monday, 17 March 2025, Christophe Lyon christophe.lyon@linaro.org wrote:
On Sun, 16 Mar 2025 at 21:54, Jonathan Wakely jwakely@redhat.com wrote:
On Sun, 16 Mar 2025 at 13:16, ci_notify@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 jwakely@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%3Ba=blob%3Bf=gcc/glimits.h%3Bh=d5877602bf...
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.
On Mon, 17 Mar 2025 at 14:54, Jonathan Wakely jwakely@redhat.com wrote:
On Mon, 17 Mar 2025 at 09:53, Jonathan Wakely jwakely@redhat.com wrote:
On Monday, 17 March 2025, Christophe Lyon christophe.lyon@linaro.org wrote:
On Sun, 16 Mar 2025 at 21:54, Jonathan Wakely jwakely@redhat.com wrote:
On Sun, 16 Mar 2025 at 13:16, ci_notify@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 jwakely@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%3Ba=blob%3Bf=gcc/glimits.h%3Bh=d5877602bf...
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
I'll deal with the libstdc++ bug in stage 1.
On Wed, 19 Mar 2025 at 22:02, Jonathan Wakely jwakely@redhat.com wrote:
On Mon, 17 Mar 2025 at 14:54, Jonathan Wakely jwakely@redhat.com wrote:
On Mon, 17 Mar 2025 at 09:53, Jonathan Wakely jwakely@redhat.com wrote:
On Monday, 17 March 2025, Christophe Lyon christophe.lyon@linaro.org wrote:
On Sun, 16 Mar 2025 at 21:54, Jonathan Wakely jwakely@redhat.com wrote:
On Sun, 16 Mar 2025 at 13:16, ci_notify@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 jwakely@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%3Ba=blob%3Bf=gcc/glimits.h%3Bh=d5877602bf...
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@lists.linaro.org
-
Christophe Lyon -
Jonathan Wakely