[PATCH 2/2] libstdc++: Add dg-require-thread-fence in several tests

[Jonathan Wakely]

On Sun, 10 Sept 2023 at 20:31, Christophe Lyon
<christophe.lyon@linaro.org> wrote:
>
> Some targets like arm-eabi with newlib and default settings rely on
> __sync_synchronize() to ensure synchronization.  Newlib does not
> implement it by default, to make users aware they have to take special
> care.
>
> This makes a few tests fail to link.

Does this mean those features are unusable on the target, or just that
users need to provide their own __sync_synchronize to use them?

>
> This patch requires the missing thread-fence effective target in the
> tests that need it, making them UNSUPPORTED instead of FAIL and
> UNRESOLVED.

Some of the modified tests should not be using
__gnu_debug::_Safe_sequence_base::_M_detach_all(), because they don't
use the Debug Mode. I don't know where those linker errors come from.
For example, the 23_containers/span/*assert_neg.cc and
26_numerics/valarray/* tests shouldn't use debug iterators or atomics.
Neither should 25_algorithms/sample/2.cc nor
26_numerics/bit/bit.pow.two/bit_ceil_neg.cc

The last three in the patch shouldn't use it either:

> diff --git a/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc b/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
> index cb818708aef..372ed6e0c00 100644
> --- a/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
> +++ b/libstdc++-v3/testsuite/experimental/net/timer/waitable/dest.cc
> @@ -18,6 +18,7 @@
>  // { dg-do run { target c++14 } }
>  // { dg-add-options libatomic }
>  // { dg-xfail-if "poll not available" { *-*-rtems* } }
> +// { dg-require-thread-fence "" } // needed by __gnu_debug::_Safe_sequence_base::_M_detach_all()
>
>  #include <experimental/timer>
>  #include <testsuite_hooks.h>
> diff --git a/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc b/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc
> index ae51979c3b4..8383e0be6a4 100644
> --- a/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc
> +++ b/libstdc++-v3/testsuite/experimental/net/timer/waitable/ops.cc
> @@ -18,6 +18,7 @@
>  // { dg-do run { target c++14 } }
>  // { dg-add-options libatomic }
>  // { dg-xfail-if "poll not available" { *-*-rtems* } }
> +// { dg-require-thread-fence "" } // needed by __gnu_debug::_Safe_sequence_base::_M_detach_all()
>
>  #include <experimental/timer>
>  #include <testsuite_hooks.h>
> diff --git a/libstdc++-v3/testsuite/experimental/polymorphic_allocator/construct_pair.cc b/libstdc++-v3/testsuite/experimental/polymorphic_allocator/construct_pair.cc
> index 960c1d253b5..42de45619a8 100644
> --- a/libstdc++-v3/testsuite/experimental/polymorphic_allocator/construct_pair.cc
> +++ b/libstdc++-v3/testsuite/experimental/polymorphic_allocator/construct_pair.cc
> @@ -16,6 +16,7 @@
>  // <http://www.gnu.org/licenses/>.
>
>  // { dg-do run { target c++14 } }
> +// { dg-require-thread-fence "" } // needed by __gnu_debug::_Safe_sequence_base::_M_detach_all()
>
>  #include <experimental/memory_resource>
>  #include <utility>


I'm concerned with how much of the testsuite is being completely
disabled for this target.

Any tests with "debug" in the path are probably relying on the debug
mode, and any that use -D_GLIBCXX_DEBUG in dg-options are. And I
suppose it's expected that 29_atomics/* tests rely on atomic
synchronization, but it's unfortunate that those now can't be tested
for arm-eabi, and I don't understand why it only affects eight of the
atomics tests not all the other ones.

Something doesn't seem right here.