From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 7B1EE3858D28 for ; Mon, 11 Sep 2023 10:59:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7B1EE3858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1694429971; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=OYKEMuS065P4aIVo0p77tHikH9PFLJ6QXycSwj/rXxQ=; b=LUSVx3B5S83GAqkoV5CetYq0e2vSL5pysITeGzW0TTXkV3S+WQaWI0ycgjohRhBx5n5JEx Y6e9kHAIJr4u2oeNOiHJlWux7r4jSWUGMXLaxp/2npRZj4VylgKVSDK9omVhzBEzSqFyLk zwWEiIigZUmJ/5K/9pNPio7nVTmEQkM= Received: from mail-lj1-f197.google.com (mail-lj1-f197.google.com [209.85.208.197]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-643-oBD0WajCNwqoemyumIdgtg-1; Mon, 11 Sep 2023 06:59:29 -0400 X-MC-Unique: oBD0WajCNwqoemyumIdgtg-1 Received: by mail-lj1-f197.google.com with SMTP id 38308e7fff4ca-2be35b7b51aso46930591fa.2 for ; Mon, 11 Sep 2023 03:59:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1694429968; x=1695034768; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=OYKEMuS065P4aIVo0p77tHikH9PFLJ6QXycSwj/rXxQ=; b=LYS+muoU6yIvJE8PfZv9SEjqbyckRRrEKlFEyt30CJyRt6zwjSQiklch0fUiVSR8Kw Nm1WoLuMf/ud441zFVDzIxg9r4QfoRSpFPtok6GmSWriiN+pQl2EErZjf4PEvFK4zJF2 TgebEGp7tzStS6rDHchhID0iv+BnKBB/3eW4ydNlYsbi2jc678AzSI+ICb7l2TlITnGG RSr6W3LACYjz1cAoN3QoTmViiHgXcR+dzCjMBZxaQErYtzn2qKQKKB8JUcPeQHzk8FAC PoVAXEtgKYp2WAWM3rPHvmJdHSe56g6wKx/zndxfYHD1XA38iv/Unl4jCx4T2khjrUu1 pLYA== X-Gm-Message-State: AOJu0Yyo36DcQbLYW4q6ZY81DNsAkB9Kd18hgKfxqKf03Po8xrL3uhfH S1xnlsucjFG42Yn3OCrOZ6b+a14J4alEhgZXVTRVTer9e3Ni7ycfvIA4h8OaLzFHd4JQHHS3pbv 2C4dC1objersCLYF4VYEmgdyKOz66owc= X-Received: by 2002:a2e:2c13:0:b0:2bc:b75e:b88 with SMTP id s19-20020a2e2c13000000b002bcb75e0b88mr8257126ljs.18.1694429967610; Mon, 11 Sep 2023 03:59:27 -0700 (PDT) X-Google-Smtp-Source: AGHT+IGLKjipdprtDZnqw7c5AZaoMGZCNCC+xO/fyNMNln6f0fP6/WY9vi9+9Voc80GAoUbFY6By1AcY491clrdSwNE= X-Received: by 2002:a2e:2c13:0:b0:2bc:b75e:b88 with SMTP id s19-20020a2e2c13000000b002bcb75e0b88mr8257107ljs.18.1694429967280; Mon, 11 Sep 2023 03:59:27 -0700 (PDT) MIME-Version: 1.0 References: <20230910193045.3549775-1-christophe.lyon@linaro.org> <20230910193045.3549775-2-christophe.lyon@linaro.org> In-Reply-To: <20230910193045.3549775-2-christophe.lyon@linaro.org> From: Jonathan Wakely Date: Mon, 11 Sep 2023 11:59:15 +0100 Message-ID: Subject: Re: [PATCH 2/2] libstdc++: Add dg-require-thread-fence in several tests To: Christophe Lyon Cc: gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org, kyrylo.tkachov@arm.com, richard.earnshaw@arm.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-12.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Sun, 10 Sept 2023 at 20:31, Christophe Lyon 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 > #include > 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 > #include > 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 @@ > // . > > // { dg-do run { target c++14 } } > +// { dg-require-thread-fence "" } // needed by __gnu_debug::_Safe_sequence_base::_M_detach_all() > > #include > #include 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.