On Tue, Apr 20, 2021 at 8:43 PM David Edelsohn <dje....@gmail.com> wrote: > > On Tue, Apr 20, 2021 at 8:23 PM Thomas Rodgers > <rodg...@appliantology.com> wrote: > > > > On 2021-04-20 17:09, David Edelsohn wrote: > > > > On Tue, Apr 20, 2021 at 7:52 PM Thomas Rodgers > > <rodg...@appliantology.com> 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 <gcc@gcc.gnu.org> > > 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 <semaphore> 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<ptrdiff_t>; > #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
