From patchwork Wed Nov 16 21:18:49 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christophe Lyon X-Patchwork-Id: 82612 Delivered-To: patch@linaro.org Received: by 10.140.97.165 with SMTP id m34csp391730qge; Wed, 16 Nov 2016 13:19:17 -0800 (PST) X-Received: by 10.99.164.9 with SMTP id c9mr12874781pgf.141.1479331157503; Wed, 16 Nov 2016 13:19:17 -0800 (PST) Return-Path: Received: from sourceware.org (server1.sourceware.org. [209.132.180.131]) by mx.google.com with ESMTPS id d135si33478878pfd.82.2016.11.16.13.19.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Nov 2016 13:19:17 -0800 (PST) Received-SPF: pass (google.com: domain of gcc-patches-return-441727-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) client-ip=209.132.180.131; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org; spf=pass (google.com: domain of gcc-patches-return-441727-patch=linaro.org@gcc.gnu.org designates 209.132.180.131 as permitted sender) smtp.mailfrom=gcc-patches-return-441727-patch=linaro.org@gcc.gnu.org; dmarc=fail (p=NONE dis=NONE) header.from=linaro.org DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; q=dns; s=default; b=x/Ch0c9r3Vj0Xqz Rf+ROqun6SGopI0BaWBunnik7LnLp44rBm/9JwG0SKjJt0nHMkvuJhBw0rQmqHsj OMbBglpY3CGJqs2QAj3kYTk0DF+0xT/ha54t9Y+AUxiF24f0dbBOLdrIYuu9m/23 fywZOnUysFCJv7Wq6oMSQBZv/fMA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; s=default; bh=yVZSGLowU6ZU2uJTBAmqI 4wEabM=; b=eaqTLlEq56g2MVpDxRyycU2goQdSnKUu+CmF8Gvek2xqLZc9a04C4 wT2WsQcjksIT1wEvSArXMyrApBMLVXypS/riqrlCO6Uh4kzvmWx9Zojmr8BfVI2b afd/VN/UwmCUXnrrXfUQIVGkUtbwDrDriqRb6fjGyj0slpPqtckg/o= Received: (qmail 56221 invoked by alias); 16 Nov 2016 21:19:04 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 56196 invoked by uid 89); 16 Nov 2016 21:19:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 spammy=dgskipif, dg-skip-if, *-*-*, runtestflags X-HELO: mail-qk0-f173.google.com Received: from mail-qk0-f173.google.com (HELO mail-qk0-f173.google.com) (209.85.220.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 16 Nov 2016 21:18:52 +0000 Received: by mail-qk0-f173.google.com with SMTP id q130so193174951qke.1 for ; Wed, 16 Nov 2016 13:18:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HCC0ozpqkYtdvXOg7bPbT959+3PtHtHNEEmFrPpo31s=; b=EOsOHHb8a1Qyd+fRvhbVYfG8j/TsGYr/wwdig+WsnE6FC54eaXzL2gfFcC8Vz8rVhj AjGSuVbjY11Wm9W0XE5f4Jtuck7GsY2v3vmUDq/965ab2DMTkfOlKgMJ34LxJRgPxvY3 e2nATKb0Aid7OpfGCQENKJpoxysNq8/h6pZjoAD7re3MfQyABPHgdduydycQWKSdqbAA dVTitXL/vjRJyGCyz972AbEdk2Md37/S1nerZsNwGcHztJtO6oE80sOaaTPrDkKlFWUt Z+SnkZZZM8AStCeKvnIq9V1Pb7jpOxpmsIJSK9C4yHPWs3pSTVmn7oBQFJVHRvS9yLke rnxw== X-Gm-Message-State: AKaTC01N/oGWYnP9iOrEGTOQuI0MSPhM+2qwuYipPVBnlwZ6JIJGO/atN15cAWrNJUm9vyNfCx678c+IY3TA94jw X-Received: by 10.55.120.6 with SMTP id t6mr5772127qkc.83.1479331131062; Wed, 16 Nov 2016 13:18:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.28.226 with HTTP; Wed, 16 Nov 2016 13:18:49 -0800 (PST) In-Reply-To: <20161115115025.GB3145@redhat.com> References: <20161020094008.GB2922@redhat.com> <20161020122040.GI2922@redhat.com> <20161020163417.GL2922@redhat.com> <2CE94632-C569-4F72-85ED-73AE3F95BAEC@comcast.net> <20161020174051.GN2922@redhat.com> <20161115115025.GB3145@redhat.com> From: Christophe Lyon Date: Wed, 16 Nov 2016 22:18:49 +0100 Message-ID: Subject: Re: [libstdc++, testsuite] Add dg-require-thread-fence To: Jonathan Wakely Cc: Mike Stump , "libstdc++@gcc.gnu.org" , "gcc-patches@gcc.gnu.org" , Ramana Radhakrishnan X-IsSubscribed: yes On 15 November 2016 at 12:50, Jonathan Wakely wrote: > On 14/11/16 14:32 +0100, Christophe Lyon wrote: >> >> On 20 October 2016 at 19:40, Jonathan Wakely wrote: >>> >>> On 20/10/16 10:33 -0700, Mike Stump wrote: >>>> >>>> >>>> On Oct 20, 2016, at 9:34 AM, Jonathan Wakely wrote: >>>>> >>>>> >>>>> >>>>> On 20/10/16 09:26 -0700, Mike Stump wrote: >>>>>> >>>>>> >>>>>> On Oct 20, 2016, at 5:20 AM, Jonathan Wakely >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> I am considering leaving this in the ARM backend to force people to >>>>>>> think what they want to do about thread safety with statics and C++ >>>>>>> on bare-metal systems. >>>>> >>>>> >>>>> >>>>> The quoting makes it look like those are my words, but I was quoting >>>>> Ramana from https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02751.html >>>>> >>>>>> Not quite in the GNU spirit? The port people should decide the best >>>>>> way >>>>>> to get as much functionality as possible and everything should just >>>>>> work, no >>>>>> sharp edges. >>>>>> >>>>>> Forcing people to think sounds like a sharp edge? >>>>> >>>>> >>>>> >>>>> I'm inclined to agree, but we are talking about bare metal systems, >>>> >>>> >>>> >>>> So? gcc has been doing bare metal systems for more than 2 years now. >>>> It >>>> is pretty good at it. All my primary targets today are themselves bare >>>> metal systems (I test with newlib). >>>> >>>>> where there is no one-size-fits-all solution. >>>> >>>> >>>> >>>> Configurations are like ice cream cones. Everyone gets their flavor no >>>> matter how weird or strange. Putting nails in a cone because you don't >>>> know >>>> if they like vanilla or chocolate isn't reasonable. If you want, make >>>> two >>>> flavors, and vend two, if you want to just do one, pick the flavor and >>>> vend >>>> it. Put an enum #define default_flavor vanilla, and you then have >>>> support >>>> for any flavor you want. Want to add a configure option for the flavor >>>> select, add it. You want to make a -mflavor=chocolate option, add it. >>>> gcc >>>> is literally littered with these things. >>> >>> >>> >>> Like I said, you can either build the library with >>> -fno-threadsafe-statics or you can provide a definition of the missing >>> symbol. >>> >> I gave this a try (using CXXFLAGS_FOR_TARGET=-fno-threadsafe-statics). >> It seems to do the trick indeed: almost all tests now pass, the flag is >> added >> to testcase compilation. >> >> Among the 6 remaining failures, I noticed these two: >> - experimental/type_erased_allocator/2.cc: still complains about the >> missing >> __sync_synchronize. Does it need dg-require-thread-fence? > > > Yes, I think that test actually uses atomics directly, so does depend > on the fence. > I've attached the patch to achieve this. Is it OK? >> - abi/header_cxxabi.c complains because the option is not valid for C. >> I can see the test is already skipped for other C++-only options: it is OK >> if I submit a patch to skip it if -fno-threadsafe-statics is used? > > > Yes, it makes sense there too. This one is not as obvious as I hoped. I tried: -// { dg-skip-if "invalid options for C" { *-*-* } { "-std=c++??" "-std=gnu++??" } } +// { dg-skip-if "invalid options for C" { *-*-* } { "-std=c++??" "-std=gnu++??" "-fno-threadsafe-statics" } } but it does not work. I set CXXFLAGS_FOR_TARGET=-fno-threadsafe-statics before running GCC's configure. This results in -fno-threadsafe-statics being used when compiling the tests, but dg-skip-if does not consider it: it would if I passed it via runtestflags/target-board, but then it would mean passing this flag to all tests, not only the c++ ones, leading to errors everywhere. Am I missing something? Thanks, Christophe >> I think I'm going to use this flag in validations from now on (target >> arm-none-eabi >> only, with default mode/cpu/fpu). > > > Thanks for the update on this. > libstdc++-v3/ChangeLog: 2016-11-16 Christophe Lyon * testsuite/experimental/type_erased_allocator/2.cc: Add dg-require-thread-fence. diff --git a/libstdc++-v3/testsuite/experimental/type_erased_allocator/2.cc b/libstdc++-v3/testsuite/experimental/type_erased_allocator/2.cc index 216a88c..0b73359 100644 --- a/libstdc++-v3/testsuite/experimental/type_erased_allocator/2.cc +++ b/libstdc++-v3/testsuite/experimental/type_erased_allocator/2.cc @@ -1,4 +1,5 @@ // { dg-do run { target c++14 } } +// { dg-require-thread-fence "" } // Copyright (C) 2015-2016 Free Software Foundation, Inc. //