Re: GCC 11.1 Release Candidate available from gcc.gnu.org
On Thu, Apr 22, 2021 at 01:27:40PM +0100, Jonathan Wakely wrote: > I'm just finishing testing this on various targets and will push to > trunk. I'd like to backport it to gcc-11 too, to fix PR100179. Ok for 11.1. > commit 50070d8602a07160cece5890899929e9f210244d > Author: Jonathan Wakely > Date: Thu Apr 22 11:10:06 2021 > > libstdc++: Remove #error from implementation [PR 100179] > > This removes the #error from for the case where > neither __atomic_semaphore nor __platform_semaphore is defined. > > Also rename the _GLIBCXX_REQUIRE_POSIX_SEMAPHORE macro to > _GLIBCXX_USE_POSIX_SEMAPHORE for consistency with the similar > _GLIBCXX_USE_CXX11_ABI macro that can be used to request an alternative > (ABI-changing) implementation. > > libstdc++-v3/ChangeLog: > > PR libstdc++/100179 > * include/bits/semaphore_base.h: Remove #error. > * include/std/semaphore: Do not define anything unless one of > the implementations is available. Jakub
Re: GCC 11.1 Release Candidate available from gcc.gnu.org
On 21/04/21 15:30 +0100, Jonathan Wakely wrote:
On 21/04/21 13:12 +0100, Jonathan Wakely wrote:
On 21/04/21 12:38 +0100, Jonathan Wakely wrote:
On 20/04/21 22:12 -0700, Thomas Rodgers wrote:
@@ -86,6 +88,24 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
}
+_GLIBCXX_ALWAYS_INLINE bool
+_M_try_acquire() noexcept
+{
+ for (;;)
+ {
+ auto __err = sem_trywait(&_M_semaphore);
+ if (__err && (errno == EINTR))
+ continue;
+ else if (__err && (errno == EAGAIN))
+ return false;
+ else if (__err)
+ std::terminate();
+ else
+ break;
+ }
+ return true;
+}
+
_GLIBCXX_ALWAYS_INLINE void
_M_release(std::ptrdiff_t __update) noexcept
{
Please just commit this part to trunk and gcc-11, not the macro
renaming (as that's been fixed by Jakub already).
I think on trunk I'd prefer to do the attached. WDYT?
In fact I think something like this is neded even on gcc-11 branch,
otherwise anything that tries to include without atomics
or sem_t gets hard errors:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100179
And includes which includes , meaning
is unusable on those targets.
So I think removing this #error is essential:
-// Note: the _GLIBCXX_REQUIRE_POSIX_SEMAPHORE macro can be used to force the
-// use of Posix semaphores (sem_t). Doing so however, alters the ABI.
-#if defined __cpp_lib_atomic_wait && !_GLIBCXX_REQUIRE_POSIX_SEMAPHORE
using __semaphore_impl = __atomic_semaphore;
-#elif _GLIBCXX_HAVE_POSIX_SEMAPHORE
- using __semaphore_impl = __platform_semaphore;
-#else
-# error "No suitable semaphore implementation available"
-#endif
+#endif // __cpp_lib_atomic_wait
Here's a simpler patch which just removes the #error and renames the
REQUIRE macro to USE. This still dumps the whole of and
in the global namespace when is included, but
we'll have to live with that for the 11.1 release.
I'm just finishing testing this on various targets and will push to
trunk. I'd like to backport it to gcc-11 too, to fix PR100179.
commit 50070d8602a07160cece5890899929e9f210244d
Author: Jonathan Wakely
Date: Thu Apr 22 11:10:06 2021
libstdc++: Remove #error from implementation [PR 100179]
This removes the #error from for the case where
neither __atomic_semaphore nor __platform_semaphore is defined.
Also rename the _GLIBCXX_REQUIRE_POSIX_SEMAPHORE macro to
_GLIBCXX_USE_POSIX_SEMAPHORE for consistency with the similar
_GLIBCXX_USE_CXX11_ABI macro that can be used to request an alternative
(ABI-changing) implementation.
libstdc++-v3/ChangeLog:
PR libstdc++/100179
* include/bits/semaphore_base.h: Remove #error.
* include/std/semaphore: Do not define anything unless one of
the implementations is available.
diff --git a/libstdc++-v3/include/bits/semaphore_base.h b/libstdc++-v3/include/bits/semaphore_base.h
index 84b33423fff..4948f0fd0bc 100644
--- a/libstdc++-v3/include/bits/semaphore_base.h
+++ b/libstdc++-v3/include/bits/semaphore_base.h
@@ -263,14 +263,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
};
#endif // __cpp_lib_atomic_wait
-// Note: the _GLIBCXX_REQUIRE_POSIX_SEMAPHORE macro can be used to force the
+// Note: the _GLIBCXX_USE_POSIX_SEMAPHORE macro can be used to force the
// use of Posix semaphores (sem_t). Doing so however, alters the ABI.
-#if defined __cpp_lib_atomic_wait && !_GLIBCXX_REQUIRE_POSIX_SEMAPHORE
+#if defined __cpp_lib_atomic_wait && !_GLIBCXX_USE_POSIX_SEMAPHORE
using __semaphore_impl = __atomic_semaphore;
#elif _GLIBCXX_HAVE_POSIX_SEMAPHORE
using __semaphore_impl = __platform_semaphore;
-#else
-# error "No suitable semaphore implementation available"
#endif
_GLIBCXX_END_NAMESPACE_VERSION
diff --git a/libstdc++-v3/include/std/semaphore b/libstdc++-v3/include/std/semaphore
index a1560915d83..52addca742c 100644
--- a/libstdc++-v3/include/std/semaphore
+++ b/libstdc++-v3/include/std/semaphore
@@ -34,6 +34,7 @@
#if __cplusplus > 201703L
#include
+#if __cpp_lib_atomic_wait || _GLIBCXX_HAVE_POSIX_SEMAPHORE
namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
@@ -89,5 +90,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
_GLIBCXX_END_NAMESPACE_VERSION
} // namespace
+#endif // cpp_lib_atomic_wait || _GLIBCXX_HAVE_POSIX_SEMAPHORE
#endif // C++20
#endif // _GLIBCXX_SEMAPHORE
Re: GCC 11.1 Release Candidate available from gcc.gnu.org
On 21/04/21 13:12 +0100, Jonathan Wakely wrote:
On 21/04/21 12:38 +0100, Jonathan Wakely wrote:
On 20/04/21 22:12 -0700, Thomas Rodgers wrote:
@@ -86,6 +88,24 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
}
+_GLIBCXX_ALWAYS_INLINE bool
+_M_try_acquire() noexcept
+{
+ for (;;)
+ {
+ auto __err = sem_trywait(&_M_semaphore);
+ if (__err && (errno == EINTR))
+ continue;
+ else if (__err && (errno == EAGAIN))
+ return false;
+ else if (__err)
+ std::terminate();
+ else
+ break;
+ }
+ return true;
+}
+
_GLIBCXX_ALWAYS_INLINE void
_M_release(std::ptrdiff_t __update) noexcept
{
Please just commit this part to trunk and gcc-11, not the macro
renaming (as that's been fixed by Jakub already).
I think on trunk I'd prefer to do the attached. WDYT?
In fact I think something like this is neded even on gcc-11 branch,
otherwise anything that tries to include without atomics
or sem_t gets hard errors:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100179
And includes which includes , meaning
is unusable on those targets.
So I think removing this #error is essential:
-// Note: the _GLIBCXX_REQUIRE_POSIX_SEMAPHORE macro can be used to force the
-// use of Posix semaphores (sem_t). Doing so however, alters the ABI.
-#if defined __cpp_lib_atomic_wait && !_GLIBCXX_REQUIRE_POSIX_SEMAPHORE
using __semaphore_impl = __atomic_semaphore;
-#elif _GLIBCXX_HAVE_POSIX_SEMAPHORE
- using __semaphore_impl = __platform_semaphore;
-#else
-# error "No suitable semaphore implementation available"
-#endif
+#endif // __cpp_lib_atomic_wait
Re: GCC 11.1 Release Candidate available from gcc.gnu.org
Hi, Jonathan
Thanks for the further investigation. I definitely encountered the
missing _M_try_acquire in __platform_semaphore.
Thanks, David
On Wed, Apr 21, 2021 at 8:12 AM Jonathan Wakely wrote:
>
> On 21/04/21 12:38 +0100, Jonathan Wakely wrote:
> >On 20/04/21 22:12 -0700, Thomas Rodgers wrote:
> >>@@ -86,6 +88,24 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
> >> }
> >>}
> >>
> >>+_GLIBCXX_ALWAYS_INLINE bool
> >>+_M_try_acquire() noexcept
> >>+{
> >>+ for (;;)
> >>+ {
> >>+ auto __err = sem_trywait(&_M_semaphore);
> >>+ if (__err && (errno == EINTR))
> >>+ continue;
> >>+ else if (__err && (errno == EAGAIN))
> >>+ return false;
> >>+ else if (__err)
> >>+ std::terminate();
> >>+ else
> >>+ break;
> >>+ }
> >>+ return true;
> >>+}
> >>+
> >>_GLIBCXX_ALWAYS_INLINE void
> >>_M_release(std::ptrdiff_t __update) noexcept
> >>{
> >
> >Please just commit this part to trunk and gcc-11, not the macro
> >renaming (as that's been fixed by Jakub already).
>
> I think on trunk I'd prefer to do the attached. WDYT?
>
>
Re: GCC 11.1 Release Candidate available from gcc.gnu.org
On 2021-04-21 05:12, Jonathan Wakely wrote:
On 21/04/21 12:38 +0100, Jonathan Wakely wrote: On 20/04/21 22:12
-0700, Thomas Rodgers wrote: @@ -86,6 +88,24 @@
_GLIBCXX_BEGIN_NAMESPACE_VERSION
}
}
+_GLIBCXX_ALWAYS_INLINE bool
+_M_try_acquire() noexcept
+{
+ for (;;)
+{
+ auto __err = sem_trywait(&_M_semaphore);
+ if (__err && (errno == EINTR))
+continue;
+ else if (__err && (errno == EAGAIN))
+return false;
+ else if (__err)
+std::terminate();
+ else
+break;
+}
+ return true;
+}
+
_GLIBCXX_ALWAYS_INLINE void
_M_release(std::ptrdiff_t __update) noexcept
{
Please just commit this part to trunk and gcc-11, not the macro
renaming (as that's been fixed by Jakub already).
I think on trunk I'd prefer to do the attached. WDYT?
Looks good to me.
Re: GCC 11.1 Release Candidate available from gcc.gnu.org
On 21/04/21 12:38 +0100, Jonathan Wakely wrote:
On 20/04/21 22:12 -0700, Thomas Rodgers wrote:
@@ -86,6 +88,24 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
}
+_GLIBCXX_ALWAYS_INLINE bool
+_M_try_acquire() noexcept
+{
+ for (;;)
+ {
+ auto __err = sem_trywait(&_M_semaphore);
+ if (__err && (errno == EINTR))
+ continue;
+ else if (__err && (errno == EAGAIN))
+ return false;
+ else if (__err)
+ std::terminate();
+ else
+ break;
+ }
+ return true;
+}
+
_GLIBCXX_ALWAYS_INLINE void
_M_release(std::ptrdiff_t __update) noexcept
{
Please just commit this part to trunk and gcc-11, not the macro
renaming (as that's been fixed by Jakub already).
I think on trunk I'd prefer to do the attached. WDYT?
commit 07241d79b6720d4f392d5a8ba6e9c21d2801c8c7
Author: Jonathan Wakely
Date: Wed Apr 21 13:04:05 2021
libstdc++: Streamline implementation [PR 100164]
This adds the missing _M_try_acquire member function so that
__platform_semaphore works.
Also adjust the implementation so that __platform_semaphore
is not defined unless we're going to use it, which avoids including
(and polluting he global namespace) when we don't need it.
Also rename the _GLIBCXX_REQUIRE_POSIX_SEMAPHORE macro to
_GLIBCXX_USE_POSIX_SEMAPHORE for consistency with the similar
_GLIBCXX_USE_CXX11_ABI macro that can be used to request an alternative
(ABI-changing) implementation.
libstdc++-v3/ChangeLog:
PR libstdc++/100164
* include/bits/semaphore_base.h: Only define at most one of
__platform_semaphore and __atomic_semaphore.
(__platform_semaphore::_M_try_acquire()): Add missing function.
* include/std/semaphore: Do not define anything unless one of
the implementations is available.
* testsuite/30_threads/semaphore/try_acquire_posix.cc: Define
macro to request POSIX semaphore implementation. Use standard
API, not private implementation.
diff --git a/libstdc++-v3/include/bits/semaphore_base.h b/libstdc++-v3/include/bits/semaphore_base.h
index 7e3235d182e..80134d7fc4c 100644
--- a/libstdc++-v3/include/bits/semaphore_base.h
+++ b/libstdc++-v3/include/bits/semaphore_base.h
@@ -1,4 +1,4 @@
-// -*- C++ -*- header.
+// std::counting_semaphore implementation -*- C++ -*- header.
// Copyright (C) 2020-2021 Free Software Foundation, Inc.
//
@@ -32,25 +32,32 @@
#pragma GCC system_header
-#include
-#if __cpp_lib_atomic_wait
-#include
-#include
-#endif // __cpp_lib_atomic_wait
-
-#ifdef _GLIBCXX_HAVE_POSIX_SEMAPHORE
-# include
-# include
-#endif
-
#include
#include
+// Note: the _GLIBCXX_USE_POSIX_SEMAPHORE macro can be used to force the
+// use of Posix semaphores (sem_t). Doing so however, alters the ABI.
+
+#ifndef _GLIBCXX_HAVE_POSIX_SEMAPHORE
+# undef _GLIBCXX_USE_POSIX_SEMAPHORE
+#endif
+
+#include
+#if __cpp_lib_atomic_wait && ! _GLIBCXX_USE_POSIX_SEMAPHORE
+# include
+# include
+#elif _GLIBCXX_HAVE_POSIX_SEMAPHORE
+# include
+# include
+# undef _GLIBCXX_USE_POSIX_SEMAPHORE
+# define _GLIBCXX_USE_POSIX_SEMAPHORE 1
+#endif
+
namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
-#ifdef _GLIBCXX_HAVE_POSIX_SEMAPHORE
+#if _GLIBCXX_USE_POSIX_SEMAPHORE
struct __platform_semaphore
{
using __clock_t = chrono::system_clock;
@@ -76,23 +83,44 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
for (;;)
{
- auto __err = sem_wait(&_M_semaphore);
- if (__err && (errno == EINTR))
- continue;
- else if (__err)
- std::terminate();
+ if (auto __err = sem_wait(&_M_semaphore))
+ {
+ if (errno == EINTR)
+ continue;
+ else
+ std::terminate();
+ }
else
break;
}
}
+_GLIBCXX_ALWAYS_INLINE bool
+_M_try_acquire() noexcept
+{
+ for (;;)
+ {
+ if (auto __err = sem_trywait(&_M_semaphore))
+ {
+ if (errno == EINTR)
+ continue;
+ else if (errno == EAGAIN)
+ return false;
+ else
+ std::terminate();
+ }
+ else
+ break;
+ }
+ return true;
+}
+
_GLIBCXX_ALWAYS_INLINE void
_M_release(std::ptrdiff_t __update) noexcept
{
for(; __update != 0; --__update)
{
- auto __err = sem_post(&_M_semaphore);
- if (__err)
+ if (auto __err = sem_post(&_M_semaphore))
std::terminate();
}
}
@@ -162,9 +190,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
private:
sem_t _M_semaphore;
};
-#endif // _GLIBCXX_HAVE_POSIX_SEMAPHORE
-#if __cpp_lib_atomic_wait
+ using __semaphore_impl = __platform_semaphore;
+
+#elif __cpp_lib_atomic_wait
+
struct __atomic_semaphore
{
static constexpr ptrdiff_t _S_max = __gnu_cxx::__int_traits::__max;
@@ -245,19 +275,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
private:
alignas(__detail::__platform_wait_alignment)
-
Re: GCC 11.1 Release Candidate available from gcc.gnu.org
On 20/04/21 22:12 -0700, Thomas Rodgers wrote:
@@ -86,6 +88,24 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
}
}
+_GLIBCXX_ALWAYS_INLINE bool
+_M_try_acquire() noexcept
+{
+ for (;;)
+ {
+ auto __err = sem_trywait(&_M_semaphore);
+ if (__err && (errno == EINTR))
+ continue;
+ else if (__err && (errno == EAGAIN))
+ return false;
+ else if (__err)
+ std::terminate();
+ else
+ break;
+ }
+ return true;
+}
+
_GLIBCXX_ALWAYS_INLINE void
_M_release(std::ptrdiff_t __update) noexcept
{
Please just commit this part to trunk and gcc-11, not the macro
renaming (as that's been fixed by Jakub already).
Re: GCC 11.1 Release Candidate available from gcc.gnu.org
On 21/04/21 10:56 +0200, Jakub Jelinek via Libstdc++ wrote:
On Tue, Apr 20, 2021 at 10:12:33PM -0700, Thomas Rodgers wrote:
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.
Jonathan's call, but for me it looks much better to fix up the
macro name on the configure side.
The include/Makefile.am sed is:
sed -e 's/HAVE_/_GLIBCXX_HAVE_/g' \
-e 's/PACKAGE/_GLIBCXX_PACKAGE/g' \
-e 's/VERSION/_GLIBCXX_VERSION/g' \
-e 's/WORDS_/_GLIBCXX_WORDS_/g' \
-e 's/_DARWIN_USE_64_BIT_INODE/_GLIBCXX_DARWIN_USE_64_BIT_INODE/g' \
-e 's/_FILE_OFFSET_BITS/_GLIBCXX_FILE_OFFSET_BITS/g' \
-e 's/_LARGE_FILES/_GLIBCXX_LARGE_FILES/g' \
-e 's/ICONV_CONST/_GLIBCXX_ICONV_CONST/g' \
-e '/[ ]_GLIBCXX_LONG_DOUBLE_COMPAT[ ]/d' \
-e '/[ ]_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT[]/d' \
< ${CONFIG_HEADER} >> $@ ;\
so for many macros one needs _GLIBCXX_ prefixes already in configure,
as can be seen in grep AC_DEFINE.*_GLIBCXX configure.ac acinclude.m4
But _GLIBCXX_HAVE_POSIX_SEMAPHORE is the only one that shouldn't have
that prefix because the sed is adding that.
E.g. on i686-linux, I see
grep _GLIBCXX__GLIBCXX c++config.h
#define _GLIBCXX__GLIBCXX_HAVE_POSIX_SEMAPHORE 1
that proves it is the only broken one.
So, I think the right fix is:
2021-04-21 Jakub Jelinek
PR libstdc++/100164
* acinclude.m4: For POSIX semaphores AC_DEFINE HAVE_POSIX_SEMAPHORE
rather than _GLIBCXX_HAVE_POSIX_SEMAPHORE.
* configure: Regenerated.
* config.h.in: Regenerated.
--- libstdc++-v3/acinclude.m4.jj2020-12-16 14:42:46.501084530 +0100
+++ libstdc++-v3/acinclude.m4 2021-04-21 10:51:52.450419650 +0200
@@ -4097,7 +4097,7 @@ AC_DEFUN([GLIBCXX_CHECK_GTHREADS], [
[ac_have_posix_semaphore=no])
if test $ac_have_posix_semaphore = yes ; then
-AC_DEFINE(_GLIBCXX_HAVE_POSIX_SEMAPHORE,
+AC_DEFINE(HAVE_POSIX_SEMAPHORE,
1,
[Define to 1 if POSIX Semaphores with sem_timedwait are available in
.])
fi
Yes, this is correct. Please push.
Re: GCC 11.1 Release Candidate available from gcc.gnu.org
On Tue, Apr 20, 2021 at 10:12:33PM -0700, Thomas Rodgers wrote:
> 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.
Jonathan's call, but for me it looks much better to fix up the
macro name on the configure side.
The include/Makefile.am sed is:
sed -e 's/HAVE_/_GLIBCXX_HAVE_/g' \
-e 's/PACKAGE/_GLIBCXX_PACKAGE/g' \
-e 's/VERSION/_GLIBCXX_VERSION/g' \
-e 's/WORDS_/_GLIBCXX_WORDS_/g' \
-e 's/_DARWIN_USE_64_BIT_INODE/_GLIBCXX_DARWIN_USE_64_BIT_INODE/g' \
-e 's/_FILE_OFFSET_BITS/_GLIBCXX_FILE_OFFSET_BITS/g' \
-e 's/_LARGE_FILES/_GLIBCXX_LARGE_FILES/g' \
-e 's/ICONV_CONST/_GLIBCXX_ICONV_CONST/g' \
-e '/[ ]_GLIBCXX_LONG_DOUBLE_COMPAT[ ]/d' \
-e '/[ ]_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT[]/d' \
< ${CONFIG_HEADER} >> $@ ;\
so for many macros one needs _GLIBCXX_ prefixes already in configure,
as can be seen in grep AC_DEFINE.*_GLIBCXX configure.ac acinclude.m4
But _GLIBCXX_HAVE_POSIX_SEMAPHORE is the only one that shouldn't have
that prefix because the sed is adding that.
E.g. on i686-linux, I see
grep _GLIBCXX__GLIBCXX c++config.h
#define _GLIBCXX__GLIBCXX_HAVE_POSIX_SEMAPHORE 1
that proves it is the only broken one.
So, I think the right fix is:
2021-04-21 Jakub Jelinek
PR libstdc++/100164
* acinclude.m4: For POSIX semaphores AC_DEFINE HAVE_POSIX_SEMAPHORE
rather than _GLIBCXX_HAVE_POSIX_SEMAPHORE.
* configure: Regenerated.
* config.h.in: Regenerated.
--- libstdc++-v3/acinclude.m4.jj2020-12-16 14:42:46.501084530 +0100
+++ libstdc++-v3/acinclude.m4 2021-04-21 10:51:52.450419650 +0200
@@ -4097,7 +4097,7 @@ AC_DEFUN([GLIBCXX_CHECK_GTHREADS], [
[ac_have_posix_semaphore=no])
if test $ac_have_posix_semaphore = yes ; then
-AC_DEFINE(_GLIBCXX_HAVE_POSIX_SEMAPHORE,
+AC_DEFINE(HAVE_POSIX_SEMAPHORE,
1,
[Define to 1 if POSIX Semaphores with sem_timedwait are available
in .])
fi
--- libstdc++-v3/configure.jj 2021-04-09 10:18:15.701265030 +0200
+++ libstdc++-v3/configure 2021-04-21 10:52:06.730259672 +0200
@@ -75836,7 +75836,7 @@ fi
if test $ac_have_posix_semaphore = yes ; then
-$as_echo "#define _GLIBCXX_HAVE_POSIX_SEMAPHORE 1" >>confdefs.h
+$as_echo "#define HAVE_POSIX_SEMAPHORE 1" >>confdefs.h
fi
{ $as_echo "$as_me:${as_lineno-$LINENO}: result: $ac_have_posix_semaphore"
>&5
--- libstdc++-v3/config.h.in.jj 2020-12-17 16:06:39.808526661 +0100
+++ libstdc++-v3/config.h.in2021-04-21 10:52:09.709226370 +0200
@@ -291,6 +291,10 @@
/* Define to 1 if you have the `posix_memalign' function. */
#undef HAVE_POSIX_MEMALIGN
+/* Define to 1 if POSIX Semaphores with sem_timedwait are available in
+ . */
+#undef HAVE_POSIX_SEMAPHORE
+
/* Define to 1 if you have the `powf' function. */
#undef HAVE_POWF
@@ -818,10 +822,6 @@
/* Define if gthreads library is available. */
#undef _GLIBCXX_HAS_GTHREADS
-/* Define to 1 if POSIX Semaphores with sem_timedwait are available in
- . */
-#undef _GLIBCXX_HAVE_POSIX_SEMAPHORE
-
/* Define to 1 if a full hosted library is built, or 0 if freestanding. */
#undef _GLIBCXX_HOSTED
Jakub
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 +++
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
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
