Re: GCC 11.1 Release Candidate available from gcc.gnu.org
On 2021-04-20 18:08, David Edelsohn wrote: On Tue, Apr 20, 2021 at 8:43 PM David Edelsohn wrote: On Tue, Apr 20, 2021 at 8:23 PM Thomas Rodgers wrote: On 2021-04-20 17:09, David Edelsohn wrote: On Tue, Apr 20, 2021 at 7:52 PM Thomas Rodgers wrote: On 2021-04-20 15:25, David Edelsohn via Gcc wrote: On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc wrote: The first release candidate for GCC 11.1 is available from https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/ ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420 and shortly its mirrors. It has been generated from git revision r11-8265-g246abba01f302eb453475b650ba839ec905be76d. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 11.1 on Tuesday, April 27th. As I have reported in Bugzilla, the last minute libstdc++: Refactor/cleanup of C++20 atomic wait implementation has severely regressed libstdc++ on AIX due to changes to bits/semaphore_base.h header. - David I posted a patch to BZ that should disable entirely for AIX (and other targets where there's not a supported implementation strategy). This patch isn't the best way of addressing this for a variety of reasons, but this support is intended as experimental for GCC11 anyway. Unfortunately I can't test it on AIX because it would seem that my ssh keys never landed on the AIX cfarm machines. I am testing the patch on an AIX system inside IBM. But it seems that you are disabling semaphore entirely on AIX, which is an unnecessary regression. AIX has POSIX semaphores. libstdc++ configure defines _GLIBCXX_HAVE_POSIX_SEMAPHORE I don't understand your comments about disabling semaphore on AIX while the comment about experimental for GCC11 implies that this is some new, experimental feature. I could understand disabling the experimental feature, but not disabling all semaphore support. Thanks, David The #error would not be hit if _GLIBCXX_HAVE_POSIX_SEMAPHORE were defined, but it shows up in your error report. You now have pinpointed the problem. It's not that AIX doesn't have semaphore, but that the code previously had a fallback that hid a bug in the macros: #if defined _GLIBCXX_HAVE_LINUX_FUTEX && !_GLIBCXX_REQUIRE_POSIX_SEMAPHORE // Use futex if available and didn't force use of POSIX using __fast_semaphore = __atomic_semaphore<__detail::__platform_wait_t>; #elif _GLIBCXX_HAVE_POSIX_SEMAPHORE using __fast_semaphore = __platform_semaphore; #else using __fast_semaphore = __atomic_semaphore; #endif The problem is that libstdc++ configure defines _GLIBCXX_HAVE_POSIX_SEMAPHORE in config.h. libstdc++ uses sed to rewrite config.h to c++config.h and prepends _GLIBCXX_, so c++config.h contains #define _GLIBCXX__GLIBCXX_HAVE_POSIX_SEMAPHORE 1 And bits/semaphore_base.h is not testing that corrupted macro. Either semaphore_base.h needs to test for the corrupted macro, or libtsdc++ configure needs to define HAVE_POSIX_SEMAPHORE without itself prepending _GLIBCXX_ so that the c++config.h rewriting works correctly and defines the correct macro for semaphore_base.h. Thanks, David By the way, you can see the bug in the macro name on any Linux system and reproduce the failure on any Linux system if you force it to fallback to POSIX semaphores instead of Linux Futex or atomic wait. Thanks, David I think the attached patch (also in BZ) addresses the issue in bits/semaphore_base.h, but I'm going to defer to Jonathan on why the macro name is being transformed incorrectly in the first place.From b1892fe84fb702ff3085eee8a062bc8606e5566a Mon Sep 17 00:00:00 2001 From: Thomas Rodgers Date: Tue, 20 Apr 2021 21:56:21 -0700 Subject: [PATCH] [libstdc++] Work around for PR100164 As dje@gmail.com pointed out, the _GLIBCXX_HAVE_POSIX_SEMAPHORE macro is being munged into _GLIBCXX__GLIBCXX_HAVE_POSIX_SEMAPHORE. This caused the detection logic in bits/semaphore_base.h to not define __platform_semaphore. Fixing this uncovered the issue that __platform_semaphore::_M_try_wait() was missing. This patch works around the former issue and addresses the latter issue. libstdc++-v3/ChangeLog: * include/bits/semaphore_base.h: Define __platform_semaphore::_M_try_wait(), temporarily adjust detection macro to reflect the actual name being generated during configuration. * testsuite/30_threads/semaphore/try_acquire_posix.cc: Force use of Posix semaphores if available and always run the test. --- libstdc++-v3/include/bits/semaphore_base.h| 27 --- .../30_threads/semaphore/try_acquire_posix.cc | 15 --- 2 files changed, 36 insertions(+), 6 deletions(-) diff --git a/libstdc++-v3/include/bits/semaphore_base.h b/libstdc++-v3/include/bits/semaphore_base.h index 7e3235d182e..5c687bfae6f 100644 --- a/libstdc++-v3/include/bits/semaphore_base.h +++ b/libstdc++-v3/include/bits/semaphore_bas
Re: GCC 11.1 Release Candidate available from gcc.gnu.org
On 2021-04-20 18:08, David Edelsohn wrote: On Tue, Apr 20, 2021 at 8:43 PM David Edelsohn wrote: On Tue, Apr 20, 2021 at 8:23 PM Thomas Rodgers wrote: On 2021-04-20 17:09, David Edelsohn wrote: On Tue, Apr 20, 2021 at 7:52 PM Thomas Rodgers wrote: On 2021-04-20 15:25, David Edelsohn via Gcc wrote: On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc wrote: The first release candidate for GCC 11.1 is available from https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/ ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420 and shortly its mirrors. It has been generated from git revision r11-8265-g246abba01f302eb453475b650ba839ec905be76d. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 11.1 on Tuesday, April 27th. As I have reported in Bugzilla, the last minute libstdc++: Refactor/cleanup of C++20 atomic wait implementation has severely regressed libstdc++ on AIX due to changes to bits/semaphore_base.h header. - David I posted a patch to BZ that should disable entirely for AIX (and other targets where there's not a supported implementation strategy). This patch isn't the best way of addressing this for a variety of reasons, but this support is intended as experimental for GCC11 anyway. Unfortunately I can't test it on AIX because it would seem that my ssh keys never landed on the AIX cfarm machines. I am testing the patch on an AIX system inside IBM. But it seems that you are disabling semaphore entirely on AIX, which is an unnecessary regression. AIX has POSIX semaphores. libstdc++ configure defines _GLIBCXX_HAVE_POSIX_SEMAPHORE I don't understand your comments about disabling semaphore on AIX while the comment about experimental for GCC11 implies that this is some new, experimental feature. I could understand disabling the experimental feature, but not disabling all semaphore support. Thanks, David The #error would not be hit if _GLIBCXX_HAVE_POSIX_SEMAPHORE were defined, but it shows up in your error report. You now have pinpointed the problem. It's not that AIX doesn't have semaphore, but that the code previously had a fallback that hid a bug in the macros: #if defined _GLIBCXX_HAVE_LINUX_FUTEX && !_GLIBCXX_REQUIRE_POSIX_SEMAPHORE // Use futex if available and didn't force use of POSIX using __fast_semaphore = __atomic_semaphore<__detail::__platform_wait_t>; #elif _GLIBCXX_HAVE_POSIX_SEMAPHORE using __fast_semaphore = __platform_semaphore; #else using __fast_semaphore = __atomic_semaphore; #endif The problem is that libstdc++ configure defines _GLIBCXX_HAVE_POSIX_SEMAPHORE in config.h. libstdc++ uses sed to rewrite config.h to c++config.h and prepends _GLIBCXX_, so c++config.h contains #define _GLIBCXX__GLIBCXX_HAVE_POSIX_SEMAPHORE 1 And bits/semaphore_base.h is not testing that corrupted macro. Either semaphore_base.h needs to test for the corrupted macro, or libtsdc++ configure needs to define HAVE_POSIX_SEMAPHORE without itself prepending _GLIBCXX_ so that the c++config.h rewriting works correctly and defines the correct macro for semaphore_base.h. Thanks, David By the way, you can see the bug in the macro name on any Linux system and reproduce the failure on any Linux system if you force it to fallback to POSIX semaphores instead of Linux Futex or atomic wait. Thanks, David Ok, I'll see if I can get a patch out before calling it a night. Thanks! Tom.
Re: GCC 11.1 Release Candidate available from gcc.gnu.org
On Tue, Apr 20, 2021 at 8:43 PM David Edelsohn wrote: > > On Tue, Apr 20, 2021 at 8:23 PM Thomas Rodgers > wrote: > > > > On 2021-04-20 17:09, David Edelsohn wrote: > > > > On Tue, Apr 20, 2021 at 7:52 PM Thomas Rodgers > > wrote: > > > > > > On 2021-04-20 15:25, David Edelsohn via Gcc wrote: > > > > On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc > > wrote: > > > > > > The first release candidate for GCC 11.1 is available from > > > > https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/ > > ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420 > > > > and shortly its mirrors. It has been generated from git revision > > r11-8265-g246abba01f302eb453475b650ba839ec905be76d. > > > > I have so far bootstrapped and tested the release candidate on > > x86_64-linux and i686-linux. Please test it and report any issues to > > bugzilla. > > > > If all goes well, I'd like to release 11.1 on Tuesday, April 27th. > > > > > > As I have reported in Bugzilla, the last minute > > > > libstdc++: Refactor/cleanup of C++20 atomic wait implementation > > > > has severely regressed libstdc++ on AIX due to changes to > > bits/semaphore_base.h header. > > > > - David > > > > > > I posted a patch to BZ that should disable entirely for AIX > > (and other targets where there's not a supported implementation strategy). > > > > This patch isn't the best way of addressing this for a variety of reasons, > > but this support is intended as experimental for GCC11 anyway. > > Unfortunately I can't test it on AIX because it would seem that my ssh keys > > never landed on the AIX cfarm machines. > > > > > > I am testing the patch on an AIX system inside IBM. > > > > But it seems that you are disabling semaphore entirely on AIX, which > > is an unnecessary regression. AIX has POSIX semaphores. libstdc++ > > configure defines > > > > _GLIBCXX_HAVE_POSIX_SEMAPHORE > > > > I don't understand your comments about disabling semaphore on AIX > > while the comment about experimental for GCC11 implies that this is > > some new, experimental feature. I could understand disabling the > > experimental feature, but not disabling all semaphore support. > > > > Thanks, David > > > > > > The #error would not be hit if _GLIBCXX_HAVE_POSIX_SEMAPHORE were defined, > > but it shows up in your error report. > > You now have pinpointed the problem. > > It's not that AIX doesn't have semaphore, but that the code previously > had a fallback that hid a bug in the macros: > > #if defined _GLIBCXX_HAVE_LINUX_FUTEX && !_GLIBCXX_REQUIRE_POSIX_SEMAPHORE > // Use futex if available and didn't force use of POSIX > using __fast_semaphore = __atomic_semaphore<__detail::__platform_wait_t>; > #elif _GLIBCXX_HAVE_POSIX_SEMAPHORE > using __fast_semaphore = __platform_semaphore; > #else > using __fast_semaphore = __atomic_semaphore; > #endif > > The problem is that libstdc++ configure defines > _GLIBCXX_HAVE_POSIX_SEMAPHORE in config.h. libstdc++ uses sed to > rewrite config.h to c++config.h and prepends _GLIBCXX_, so c++config.h > contains > > #define _GLIBCXX__GLIBCXX_HAVE_POSIX_SEMAPHORE 1 > > And bits/semaphore_base.h is not testing that corrupted macro. Either > semaphore_base.h needs to test for the corrupted macro, or libtsdc++ > configure needs to define HAVE_POSIX_SEMAPHORE without itself > prepending _GLIBCXX_ so that the c++config.h rewriting works > correctly and defines the correct macro for semaphore_base.h. > > Thanks, David By the way, you can see the bug in the macro name on any Linux system and reproduce the failure on any Linux system if you force it to fallback to POSIX semaphores instead of Linux Futex or atomic wait. Thanks, David
Re: GCC 11.1 Release Candidate available from gcc.gnu.org
On Tue, Apr 20, 2021 at 8:23 PM Thomas Rodgers wrote: > > On 2021-04-20 17:09, David Edelsohn wrote: > > On Tue, Apr 20, 2021 at 7:52 PM Thomas Rodgers > wrote: > > > On 2021-04-20 15:25, David Edelsohn via Gcc wrote: > > On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc > wrote: > > > The first release candidate for GCC 11.1 is available from > > https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/ > ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420 > > and shortly its mirrors. It has been generated from git revision > r11-8265-g246abba01f302eb453475b650ba839ec905be76d. > > I have so far bootstrapped and tested the release candidate on > x86_64-linux and i686-linux. Please test it and report any issues to > bugzilla. > > If all goes well, I'd like to release 11.1 on Tuesday, April 27th. > > > As I have reported in Bugzilla, the last minute > > libstdc++: Refactor/cleanup of C++20 atomic wait implementation > > has severely regressed libstdc++ on AIX due to changes to > bits/semaphore_base.h header. > > - David > > > I posted a patch to BZ that should disable entirely for AIX (and > other targets where there's not a supported implementation strategy). > > This patch isn't the best way of addressing this for a variety of reasons, > but this support is intended as experimental for GCC11 anyway. Unfortunately > I can't test it on AIX because it would seem that my ssh keys never landed on > the AIX cfarm machines. > > > I am testing the patch on an AIX system inside IBM. > > But it seems that you are disabling semaphore entirely on AIX, which > is an unnecessary regression. AIX has POSIX semaphores. libstdc++ > configure defines > > _GLIBCXX_HAVE_POSIX_SEMAPHORE > > I don't understand your comments about disabling semaphore on AIX > while the comment about experimental for GCC11 implies that this is > some new, experimental feature. I could understand disabling the > experimental feature, but not disabling all semaphore support. > > Thanks, David > > > The #error would not be hit if _GLIBCXX_HAVE_POSIX_SEMAPHORE were defined, > but it shows up in your error report. You now have pinpointed the problem. It's not that AIX doesn't have semaphore, but that the code previously had a fallback that hid a bug in the macros: #if defined _GLIBCXX_HAVE_LINUX_FUTEX && !_GLIBCXX_REQUIRE_POSIX_SEMAPHORE // Use futex if available and didn't force use of POSIX using __fast_semaphore = __atomic_semaphore<__detail::__platform_wait_t>; #elif _GLIBCXX_HAVE_POSIX_SEMAPHORE using __fast_semaphore = __platform_semaphore; #else using __fast_semaphore = __atomic_semaphore; #endif The problem is that libstdc++ configure defines _GLIBCXX_HAVE_POSIX_SEMAPHORE in config.h. libstdc++ uses sed to rewrite config.h to c++config.h and prepends _GLIBCXX_, so c++config.h contains #define _GLIBCXX__GLIBCXX_HAVE_POSIX_SEMAPHORE 1 And bits/semaphore_base.h is not testing that corrupted macro. Either semaphore_base.h needs to test for the corrupted macro, or libtsdc++ configure needs to define HAVE_POSIX_SEMAPHORE without itself prepending _GLIBCXX_ so that the c++config.h rewriting works correctly and defines the correct macro for semaphore_base.h. Thanks, David
Re: GCC 11.1 Release Candidate available from gcc.gnu.org
On 2021-04-20 17:23, Thomas Rodgers wrote: On 2021-04-20 17:09, David Edelsohn wrote: On Tue, Apr 20, 2021 at 7:52 PM Thomas Rodgers wrote: On 2021-04-20 15:25, David Edelsohn via Gcc wrote: On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc wrote: The first release candidate for GCC 11.1 is available from https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/ ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420 and shortly its mirrors. It has been generated from git revision r11-8265-g246abba01f302eb453475b650ba839ec905be76d. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 11.1 on Tuesday, April 27th. As I have reported in Bugzilla, the last minute libstdc++: Refactor/cleanup of C++20 atomic wait implementation has severely regressed libstdc++ on AIX due to changes to bits/semaphore_base.h header. - David I posted a patch to BZ that should disable entirely for AIX (and other targets where there's not a supported implementation strategy). This patch isn't the best way of addressing this for a variety of reasons, but this support is intended as experimental for GCC11 anyway. Unfortunately I can't test it on AIX because it would seem that my ssh keys never landed on the AIX cfarm machines. I am testing the patch on an AIX system inside IBM. But it seems that you are disabling semaphore entirely on AIX, which is an unnecessary regression. AIX has POSIX semaphores. libstdc++ configure defines _GLIBCXX_HAVE_POSIX_SEMAPHORE I don't understand your comments about disabling semaphore on AIX while the comment about experimental for GCC11 implies that this is some new, experimental feature. I could understand disabling the experimental feature, but not disabling all semaphore support. Thanks, David The #error would not be hit if _GLIBCXX_HAVE_POSIX_SEMAPHORE were defined, but it shows up in your error report. Specifically - /tmp/GCC/powerpc-ibm-aix7.2.3.0/libstdc++-v3/include/bits/semaphore_base.h:259: error: #error "No suitable semaphore implementation available"
Re: GCC 11.1 Release Candidate available from gcc.gnu.org
On 2021-04-20 17:09, David Edelsohn wrote: On Tue, Apr 20, 2021 at 7:52 PM Thomas Rodgers wrote: On 2021-04-20 15:25, David Edelsohn via Gcc wrote: On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc wrote: The first release candidate for GCC 11.1 is available from https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/ ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420 and shortly its mirrors. It has been generated from git revision r11-8265-g246abba01f302eb453475b650ba839ec905be76d. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 11.1 on Tuesday, April 27th. As I have reported in Bugzilla, the last minute libstdc++: Refactor/cleanup of C++20 atomic wait implementation has severely regressed libstdc++ on AIX due to changes to bits/semaphore_base.h header. - David I posted a patch to BZ that should disable entirely for AIX (and other targets where there's not a supported implementation strategy). This patch isn't the best way of addressing this for a variety of reasons, but this support is intended as experimental for GCC11 anyway. Unfortunately I can't test it on AIX because it would seem that my ssh keys never landed on the AIX cfarm machines. I am testing the patch on an AIX system inside IBM. But it seems that you are disabling semaphore entirely on AIX, which is an unnecessary regression. AIX has POSIX semaphores. libstdc++ configure defines _GLIBCXX_HAVE_POSIX_SEMAPHORE I don't understand your comments about disabling semaphore on AIX while the comment about experimental for GCC11 implies that this is some new, experimental feature. I could understand disabling the experimental feature, but not disabling all semaphore support. Thanks, David The #error would not be hit if _GLIBCXX_HAVE_POSIX_SEMAPHORE were defined, but it shows up in your error report.
Re: GCC 11.1 Release Candidate available from gcc.gnu.org
On Tue, Apr 20, 2021 at 7:52 PM Thomas Rodgers wrote: > > On 2021-04-20 15:25, David Edelsohn via Gcc wrote: > > On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc > wrote: > > > The first release candidate for GCC 11.1 is available from > > https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/ > ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420 > > and shortly its mirrors. It has been generated from git revision > r11-8265-g246abba01f302eb453475b650ba839ec905be76d. > > I have so far bootstrapped and tested the release candidate on > x86_64-linux and i686-linux. Please test it and report any issues to > bugzilla. > > If all goes well, I'd like to release 11.1 on Tuesday, April 27th. > > > As I have reported in Bugzilla, the last minute > > libstdc++: Refactor/cleanup of C++20 atomic wait implementation > > has severely regressed libstdc++ on AIX due to changes to > bits/semaphore_base.h header. > > - David > > > I posted a patch to BZ that should disable entirely for AIX (and > other targets where there's not a supported implementation strategy). > > This patch isn't the best way of addressing this for a variety of reasons, > but this support is intended as experimental for GCC11 anyway. Unfortunately > I can't test it on AIX because it would seem that my ssh keys never landed on > the AIX cfarm machines. I am testing the patch on an AIX system inside IBM. But it seems that you are disabling semaphore entirely on AIX, which is an unnecessary regression. AIX has POSIX semaphores. libstdc++ configure defines _GLIBCXX_HAVE_POSIX_SEMAPHORE I don't understand your comments about disabling semaphore on AIX while the comment about experimental for GCC11 implies that this is some new, experimental feature. I could understand disabling the experimental feature, but not disabling all semaphore support. Thanks, David
Re: GCC 11.1 Release Candidate available from gcc.gnu.org
On 2021-04-20 15:25, David Edelsohn via Gcc wrote: On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc wrote: The first release candidate for GCC 11.1 is available from https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/ ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420 and shortly its mirrors. It has been generated from git revision r11-8265-g246abba01f302eb453475b650ba839ec905be76d. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 11.1 on Tuesday, April 27th. As I have reported in Bugzilla, the last minute libstdc++: Refactor/cleanup of C++20 atomic wait implementation has severely regressed libstdc++ on AIX due to changes to bits/semaphore_base.h header. - David I posted a patch to BZ that should disable entirely for AIX (and other targets where there's not a supported implementation strategy). This patch isn't the best way of addressing this for a variety of reasons, but this support is intended as experimental for GCC11 anyway. Unfortunately I can't test it on AIX because it would seem that my ssh keys never landed on the AIX cfarm machines.
Re: D build on powerpc broken (was Re: GCC 11.1 Release Candidate available from gcc.gnu.org)
On 4/20/21 4:20 PM, Jakub Jelinek wrote: On Tue, Apr 20, 2021 at 03:27:08PM -0500, William Seurer via Gcc wrote: On 4/20/21 10:24 AM, Jakub Jelinek via Gcc wrote: The first release candidate for GCC 11.1 is available from https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/ ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420 and shortly its mirrors. It has been generated from git revision r11-8265-g246abba01f302eb453475b650ba839ec905be76d. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 11.1 on Tuesday, April 27th. I am seeing at least one compilation failure when building the RC. Note that trunk built fine for me yesterday morning. libtool: compile: /home/seurer/gcc/git/build/gcc-11.1.0-RC-20210420/./gcc/gdc -B/home/seurer/gcc/git/build/gcc-11.1.0-RC-20210420/./gcc/ -B/home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/bin/ -B/home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/lib/ -isystem /home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/include -isystem /home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/sys-include -fchecking=1 -fversion=Shared -Wall -frelease -ffunction-sections -fdata-sections -O2 -g -nostdinc -I /home/seurer/gcc/git/gcc-11.1.0-RC-20210420/libphobos/libdruntime -I . -c /home/seurer/gcc/git/gcc-11.1.0-RC-20210420/libphobos/libdruntime/core/thread/osthread.d -fPIC -fversion=Shared -o core/thread/.libs/osthread.o /tmp/cc8zG8DV.s: Assembler messages: /tmp/cc8zG8DV.s:2566: Error: unsupported relocation against r13 /tmp/cc8zG8DV.s:2570: Error: unsupported relocation against r14 /tmp/cc8zG8DV.s:2574: Error: unsupported relocation against r15 /tmp/cc8zG8DV.s:2578: Error: unsupported relocation against r16 /tmp/cc8zG8DV.s:2582: Error: unsupported relocation against r17 /tmp/cc8zG8DV.s:2586: Error: unsupported relocation against r18 /tmp/cc8zG8DV.s:2590: Error: unsupported relocation against r19 /tmp/cc8zG8DV.s:2594: Error: unsupported relocation against r20 /tmp/cc8zG8DV.s:2598: Error: unsupported relocation against r21 /tmp/cc8zG8DV.s:2602: Error: unsupported relocation against r22 /tmp/cc8zG8DV.s:2606: Error: unsupported relocation against r23 /tmp/cc8zG8DV.s:2610: Error: unsupported relocation against r24 /tmp/cc8zG8DV.s:2614: Error: unsupported relocation against r25 /tmp/cc8zG8DV.s:2618: Error: unsupported relocation against r26 /tmp/cc8zG8DV.s:2622: Error: unsupported relocation against r27 /tmp/cc8zG8DV.s:2626: Error: unsupported relocation against r28 /tmp/cc8zG8DV.s:2630: Error: unsupported relocation against r29 /tmp/cc8zG8DV.s:2634: Error: unsupported relocation against r30 /tmp/cc8zG8DV.s:2638: Error: unsupported relocation against r31 So do we need to change +else version (PPC) +{ +void*[19] regs = void; +asm pure nothrow @nogc +{ +"stw r13, %0" : "=m" (regs[ 0]); +"stw r14, %0" : "=m" (regs[ 1]); ... +else version (PPC64) +{ +void*[19] regs = void; +asm pure nothrow @nogc +{ +"std r13, %0" : "=m" (regs[ 0]); +"std r14, %0" : "=m" (regs[ 1]); ... to "stw 13, %0" and "std 13, %0" etc. unconditionally, or to "stw %%r13, %0" etc. under some conditions? Jakub I tried that and I did get a clean build. The only additional errors seen when test were run (compared to a build yesterday) were: FAIL: g++.dg/cpp0x/constexpr-52830.C -std=c++14 (test for excess errors) FAIL: g++.dg/cpp0x/constexpr-52830.C -std=c++14 (test for excess errors) FAIL: g++.dg/cpp0x/constexpr-52830.C -std=c++17 (test for excess errors) FAIL: g++.dg/cpp0x/constexpr-52830.C -std=c++17 (test for excess errors) FAIL: g++.dg/cpp0x/constexpr-52830.C -std=c++2a (test for excess errors) FAIL: g++.dg/cpp0x/constexpr-52830.C -std=c++2a (test for excess errors)
Re: D build on powerpc broken (was Re: GCC 11.1 Release Candidate available from gcc.gnu.org)
Peter Bergner via Gcc wrote: On 4/20/21 4:20 PM, Jakub Jelinek via Gcc wrote: On Tue, Apr 20, 2021 at 03:27:08PM -0500, William Seurer via Gcc wrote: /tmp/cc8zG8DV.s: Assembler messages: /tmp/cc8zG8DV.s:2566: Error: unsupported relocation against r13 /tmp/cc8zG8DV.s:2570: Error: unsupported relocation against r14 [snip] So do we need to change +else version (PPC) +{ +void*[19] regs = void; +asm pure nothrow @nogc +{ +"stw r13, %0" : "=m" (regs[ 0]); +"stw r14, %0" : "=m" (regs[ 1]); ... +else version (PPC64) +{ +void*[19] regs = void; +asm pure nothrow @nogc +{ +"std r13, %0" : "=m" (regs[ 0]); +"std r14, %0" : "=m" (regs[ 1]); ... to "stw 13, %0" and "std 13, %0" etc. unconditionally, or to "stw %%r13, %0" etc. under some conditions? Yes, I think so. The "r13", etc. names are not accepted by gas unless you use the -mregnames option. It's easier to just remove the 'r’. which would break it on Darwin. Either that section needs to be conditional on “version Darwin” and a second one general - or the existing fall-back can be used for Linux (but the comments still stand that there are disadvantages on PPC from using the fallback). Iain (S)
Re: D build on powerpc broken (was Re: GCC 11.1 Release Candidate available from gcc.gnu.org)
> On 21/04/2021 00:02 Peter Bergner wrote: > > > On 4/20/21 4:20 PM, Jakub Jelinek via Gcc wrote: > > On Tue, Apr 20, 2021 at 03:27:08PM -0500, William Seurer via Gcc wrote: > >> /tmp/cc8zG8DV.s: Assembler messages: > >> /tmp/cc8zG8DV.s:2566: Error: unsupported relocation against r13 > >> /tmp/cc8zG8DV.s:2570: Error: unsupported relocation against r14 > [snip] > > So do we need to change > > +else version (PPC) > > > > > > +{ > > > > > > +void*[19] regs = void; > > > > > > +asm pure nothrow @nogc > > > > > > +{ > > > > > > +"stw r13, %0" : "=m" (regs[ 0]); > > > > > > +"stw r14, %0" : "=m" (regs[ 1]); > > > > > > ... > > +else version (PPC64) > > > > > > +{ > > > > > > +void*[19] regs = void; > > > > > > +asm pure nothrow @nogc > > > > > > +{ > > > > > > +"std r13, %0" : "=m" (regs[ 0]); > > > > > > +"std r14, %0" : "=m" (regs[ 1]); > > > > > > ... > > to "stw 13, %0" and "std 13, %0" etc. unconditionally, or > > to "stw %%r13, %0" etc. under some conditions? > > Yes, I think so. The "r13", etc. names are not accepted by gas unless you > use the -mregnames option. It's easier to just remove the 'r'. > OK, unless told otherwise, I'll keep them in for darwin though. --- a/libphobos/libdruntime/core/thread/osthread.d +++ b/libphobos/libdruntime/core/thread/osthread.d @@ -1444,55 +1444,35 @@ in (fn) else version (PPC) { void*[19] regs = void; -asm pure nothrow @nogc -{ -"stw r13, %0" : "=m" (regs[ 0]); -"stw r14, %0" : "=m" (regs[ 1]); -"stw r15, %0" : "=m" (regs[ 2]); -"stw r16, %0" : "=m" (regs[ 3]); -"stw r17, %0" : "=m" (regs[ 4]); -"stw r18, %0" : "=m" (regs[ 5]); -"stw r19, %0" : "=m" (regs[ 6]); -"stw r20, %0" : "=m" (regs[ 7]); -"stw r21, %0" : "=m" (regs[ 9]); -"stw r22, %0" : "=m" (regs[ 9]); -"stw r23, %0" : "=m" (regs[10]); -"stw r24, %0" : "=m" (regs[11]); -"stw r25, %0" : "=m" (regs[12]); -"stw r26, %0" : "=m" (regs[13]); -"stw r27, %0" : "=m" (regs[14]); -"stw r28, %0" : "=m" (regs[15]); -"stw r29, %0" : "=m" (regs[16]); -"stw r30, %0" : "=m" (regs[17]); -"stw r31, %0" : "=m" (regs[18]); -} +version (Darwin) +enum regname = "r"; +else +enum regname = ""; +static foreach (i; 0 .. regs.length) +{{ +enum int j = 13 + i; // source register +asm pure nothrow
Re: GCC 11.1 Release Candidate available from gcc.gnu.org
On Tue, Apr 20, 2021 at 12:43 PM Jakub Jelinek via Gcc wrote: > > The first release candidate for GCC 11.1 is available from > > https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/ > ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420 > > and shortly its mirrors. It has been generated from git revision > r11-8265-g246abba01f302eb453475b650ba839ec905be76d. > > I have so far bootstrapped and tested the release candidate on > x86_64-linux and i686-linux. Please test it and report any issues to > bugzilla. > > If all goes well, I'd like to release 11.1 on Tuesday, April 27th. As I have reported in Bugzilla, the last minute libstdc++: Refactor/cleanup of C++20 atomic wait implementation has severely regressed libstdc++ on AIX due to changes to bits/semaphore_base.h header. - David
Re: D build on powerpc broken (was Re: GCC 11.1 Release Candidate available from gcc.gnu.org)
On 4/20/21 4:20 PM, Jakub Jelinek via Gcc wrote: > On Tue, Apr 20, 2021 at 03:27:08PM -0500, William Seurer via Gcc wrote: >> /tmp/cc8zG8DV.s: Assembler messages: >> /tmp/cc8zG8DV.s:2566: Error: unsupported relocation against r13 >> /tmp/cc8zG8DV.s:2570: Error: unsupported relocation against r14 [snip] > So do we need to change > +else version (PPC) > > > +{ > > > +void*[19] regs = void; > > > +asm pure nothrow @nogc > > > +{ > > > +"stw r13, %0" : "=m" (regs[ 0]); > > > +"stw r14, %0" : "=m" (regs[ 1]); > > > ... > +else version (PPC64) > > > +{ > > > +void*[19] regs = void; > > > +asm pure nothrow @nogc > > > +{ > > > +"std r13, %0" : "=m" (regs[ 0]); > > > +"std r14, %0" : "=m" (regs[ 1]); > > > ... > to "stw 13, %0" and "std 13, %0" etc. unconditionally, or > to "stw %%r13, %0" etc. under some conditions? Yes, I think so. The "r13", etc. names are not accepted by gas unless you use the -mregnames option. It's easier to just remove the 'r'. Peter
D build on powerpc broken (was Re: GCC 11.1 Release Candidate available from gcc.gnu.org)
On Tue, Apr 20, 2021 at 03:27:08PM -0500, William Seurer via Gcc wrote: > > On 4/20/21 10:24 AM, Jakub Jelinek via Gcc wrote: > > The first release candidate for GCC 11.1 is available from > > > > https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/ > > ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420 > > > > and shortly its mirrors. It has been generated from git revision > > r11-8265-g246abba01f302eb453475b650ba839ec905be76d. > > > > I have so far bootstrapped and tested the release candidate on > > x86_64-linux and i686-linux. Please test it and report any issues to > > bugzilla. > > > > If all goes well, I'd like to release 11.1 on Tuesday, April 27th. > > > I am seeing at least one compilation failure when building the RC. Note > that trunk built fine for me yesterday morning. > > libtool: compile: > /home/seurer/gcc/git/build/gcc-11.1.0-RC-20210420/./gcc/gdc > -B/home/seurer/gcc/git/build/gcc-11.1.0-RC-20210420/./gcc/ > -B/home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/bin/ > > -B/home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/lib/ > -isystem > /home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/include > -isystem > /home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/sys-include > -fchecking=1 -fversion=Shared -Wall -frelease -ffunction-sections > -fdata-sections -O2 -g -nostdinc -I > /home/seurer/gcc/git/gcc-11.1.0-RC-20210420/libphobos/libdruntime -I . -c > /home/seurer/gcc/git/gcc-11.1.0-RC-20210420/libphobos/libdruntime/core/thread/osthread.d > -fPIC -fversion=Shared -o core/thread/.libs/osthread.o > /tmp/cc8zG8DV.s: Assembler messages: > /tmp/cc8zG8DV.s:2566: Error: unsupported relocation against r13 > /tmp/cc8zG8DV.s:2570: Error: unsupported relocation against r14 > /tmp/cc8zG8DV.s:2574: Error: unsupported relocation against r15 > /tmp/cc8zG8DV.s:2578: Error: unsupported relocation against r16 > /tmp/cc8zG8DV.s:2582: Error: unsupported relocation against r17 > /tmp/cc8zG8DV.s:2586: Error: unsupported relocation against r18 > /tmp/cc8zG8DV.s:2590: Error: unsupported relocation against r19 > /tmp/cc8zG8DV.s:2594: Error: unsupported relocation against r20 > /tmp/cc8zG8DV.s:2598: Error: unsupported relocation against r21 > /tmp/cc8zG8DV.s:2602: Error: unsupported relocation against r22 > /tmp/cc8zG8DV.s:2606: Error: unsupported relocation against r23 > /tmp/cc8zG8DV.s:2610: Error: unsupported relocation against r24 > /tmp/cc8zG8DV.s:2614: Error: unsupported relocation against r25 > /tmp/cc8zG8DV.s:2618: Error: unsupported relocation against r26 > /tmp/cc8zG8DV.s:2622: Error: unsupported relocation against r27 > /tmp/cc8zG8DV.s:2626: Error: unsupported relocation against r28 > /tmp/cc8zG8DV.s:2630: Error: unsupported relocation against r29 > /tmp/cc8zG8DV.s:2634: Error: unsupported relocation against r30 > /tmp/cc8zG8DV.s:2638: Error: unsupported relocation against r31 So do we need to change +else version (PPC) +{ +void*[19] regs = void; +asm pure nothrow @nogc +{ +"stw r13, %0" : "=m" (regs[ 0]); +"stw r14, %0" : "=m" (regs[ 1]); ... +else version (PPC64) +{ +void*[19] regs = void; +asm pure nothrow @nogc
Re: GCC 11.1 Release Candidate available from gcc.gnu.org
On Apr 20 2021, William Seurer via Gcc wrote: > On 4/20/21 10:24 AM, Jakub Jelinek via Gcc wrote: >> The first release candidate for GCC 11.1 is available from >> >> https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/ >> ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420 >> >> and shortly its mirrors. It has been generated from git revision >> r11-8265-g246abba01f302eb453475b650ba839ec905be76d. >> >> I have so far bootstrapped and tested the release candidate on >> x86_64-linux and i686-linux. Please test it and report any issues to >> bugzilla. >> >> If all goes well, I'd like to release 11.1 on Tuesday, April 27th. >> > I am seeing at least one compilation failure when building the RC. Note > that trunk built fine for me yesterday morning. > > libtool: compile: > /home/seurer/gcc/git/build/gcc-11.1.0-RC-20210420/./gcc/gdc > -B/home/seurer/gcc/git/build/gcc-11.1.0-RC-20210420/./gcc/ > -B/home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/bin/ > > -B/home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/lib/ > -isystem > /home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/include > -isystem > /home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/sys-include > -fchecking=1 -fversion=Shared -Wall -frelease -ffunction-sections > -fdata-sections -O2 -g -nostdinc -I > /home/seurer/gcc/git/gcc-11.1.0-RC-20210420/libphobos/libdruntime -I . -c > /home/seurer/gcc/git/gcc-11.1.0-RC-20210420/libphobos/libdruntime/core/thread/osthread.d > -fPIC -fversion=Shared - > o core/thread/.libs/osthread.o > /tmp/cc8zG8DV.s: Assembler messages: > /tmp/cc8zG8DV.s:2566: Error: unsupported relocation against r13 > /tmp/cc8zG8DV.s:2570: Error: unsupported relocation against r14 > /tmp/cc8zG8DV.s:2574: Error: unsupported relocation against r15 > /tmp/cc8zG8DV.s:2578: Error: unsupported relocation against r16 > /tmp/cc8zG8DV.s:2582: Error: unsupported relocation against r17 > /tmp/cc8zG8DV.s:2586: Error: unsupported relocation against r18 > /tmp/cc8zG8DV.s:2590: Error: unsupported relocation against r19 > /tmp/cc8zG8DV.s:2594: Error: unsupported relocation against r20 > /tmp/cc8zG8DV.s:2598: Error: unsupported relocation against r21 > /tmp/cc8zG8DV.s:2602: Error: unsupported relocation against r22 > /tmp/cc8zG8DV.s:2606: Error: unsupported relocation against r23 > /tmp/cc8zG8DV.s:2610: Error: unsupported relocation against r24 > /tmp/cc8zG8DV.s:2614: Error: unsupported relocation against r25 > /tmp/cc8zG8DV.s:2618: Error: unsupported relocation against r26 > /tmp/cc8zG8DV.s:2622: Error: unsupported relocation against r27 > /tmp/cc8zG8DV.s:2626: Error: unsupported relocation against r28 > /tmp/cc8zG8DV.s:2630: Error: unsupported relocation against r29 > /tmp/cc8zG8DV.s:2634: Error: unsupported relocation against r30 > /tmp/cc8zG8DV.s:2638: Error: unsupported relocation against r31 That comes from commit 6eae7549b8a. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
Re: GCC 11.1 Release Candidate available from gcc.gnu.org
On 4/20/21 10:24 AM, Jakub Jelinek via Gcc wrote: The first release candidate for GCC 11.1 is available from https://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420/ ftp://gcc.gnu.org/pub/gcc/snapshots/11.1.0-RC-20210420 and shortly its mirrors. It has been generated from git revision r11-8265-g246abba01f302eb453475b650ba839ec905be76d. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 11.1 on Tuesday, April 27th. I am seeing at least one compilation failure when building the RC. Note that trunk built fine for me yesterday morning. libtool: compile: /home/seurer/gcc/git/build/gcc-11.1.0-RC-20210420/./gcc/gdc -B/home/seurer/gcc/git/build/gcc-11.1.0-RC-20210420/./gcc/ -B/home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/bin/ -B/home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/lib/ -isystem /home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/include -isystem /home/seurer/gcc/git/install/gcc-11.1.0-RC-20210420/powerpc64-unknown-linux-gnu/sys-include -fchecking=1 -fversion=Shared -Wall -frelease -ffunction-sections -fdata-sections -O2 -g -nostdinc -I /home/seurer/gcc/git/gcc-11.1.0-RC-20210420/libphobos/libdruntime -I . -c /home/seurer/gcc/git/gcc-11.1.0-RC-20210420/libphobos/libdruntime/core/thread/osthread.d -fPIC -fversion=Shared -o core/thread/.libs/osthread.o /tmp/cc8zG8DV.s: Assembler messages: /tmp/cc8zG8DV.s:2566: Error: unsupported relocation against r13 /tmp/cc8zG8DV.s:2570: Error: unsupported relocation against r14 /tmp/cc8zG8DV.s:2574: Error: unsupported relocation against r15 /tmp/cc8zG8DV.s:2578: Error: unsupported relocation against r16 /tmp/cc8zG8DV.s:2582: Error: unsupported relocation against r17 /tmp/cc8zG8DV.s:2586: Error: unsupported relocation against r18 /tmp/cc8zG8DV.s:2590: Error: unsupported relocation against r19 /tmp/cc8zG8DV.s:2594: Error: unsupported relocation against r20 /tmp/cc8zG8DV.s:2598: Error: unsupported relocation against r21 /tmp/cc8zG8DV.s:2602: Error: unsupported relocation against r22 /tmp/cc8zG8DV.s:2606: Error: unsupported relocation against r23 /tmp/cc8zG8DV.s:2610: Error: unsupported relocation against r24 /tmp/cc8zG8DV.s:2614: Error: unsupported relocation against r25 /tmp/cc8zG8DV.s:2618: Error: unsupported relocation against r26 /tmp/cc8zG8DV.s:2622: Error: unsupported relocation against r27 /tmp/cc8zG8DV.s:2626: Error: unsupported relocation against r28 /tmp/cc8zG8DV.s:2630: Error: unsupported relocation against r29 /tmp/cc8zG8DV.s:2634: Error: unsupported relocation against r30 /tmp/cc8zG8DV.s:2638: Error: unsupported relocation against r31