From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 46045 invoked by alias); 10 Nov 2016 16:16:50 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 46031 invoked by uid 89); 10 Nov 2016 16:16:49 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=Hx-languages-length:1541, opportunity X-HELO: mail-qt0-f193.google.com Received: from mail-qt0-f193.google.com (HELO mail-qt0-f193.google.com) (209.85.216.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 10 Nov 2016 16:16:39 +0000 Received: by mail-qt0-f193.google.com with SMTP id m48so10532877qta.2 for ; Thu, 10 Nov 2016 08:16:39 -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:content-transfer-encoding; bh=r7/OW7XbiSBmNqiiv2Ja074QefMkD+5zblYB7dwT104=; b=cMDMwIEFDqQnvK6zzjbmwWxCyYVNW7T4F/om4eK5uEmXPpOPjC7pQMXfEOpyAXL5Se NAgivCXZRerMIv35CPiFgo+uBMLCB11lsz+4d+kKD/2ZHrL9XExfBqTyEIuwMEbSWHOW pBYCZgJfI9vxhKFC8tXMzdWjXvrBxTDpZcL1qqyTPLTuPySQPLFka0Z3nyvEvb2umyYs +TCHeMDl3W2e9CFUMwq7T45uWSGSTg/hf0REBARzwjCWi/Sb/MmTNfM8Yhup+qXR84gq eyzsi5Z4obxc+hjxgtTwgsgIMmDo2Ppm7NNE5klzqqhqJb5fEGGz74/PEt1FyJrCTkPc Wc7w== X-Gm-Message-State: ABUngvf1UnWP91Hwx5P1gnSsW8BkbQgcH4/L2eAwkN3uhw+mV8cWa2P6IA1+vspxqRJSXxpklrirXj1KX2DjDQ== X-Received: by 10.237.51.3 with SMTP id u3mr6600987qtd.12.1478794597567; Thu, 10 Nov 2016 08:16:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.163.1 with HTTP; Thu, 10 Nov 2016 08:16:36 -0800 (PST) In-Reply-To: References: <87f2bc4f-c4df-eadd-aec6-a937ed0ccaba@acm.org> <1253ac69-3301-f185-e43a-a34cadf8f51e@suse.cz> <67fda6d2-9b3e-a0d1-effc-34e1115030b2@acm.org> <1ff3cc75-7cee-79f3-395b-ef7a4d286a3d@acm.org> <04a05835-4666-4d7d-c1a9-d4bcc4ea924a@suse.cz> <87k2fpdatl.fsf@tassilo.jf.intel.com> <6f8b1905-818b-bfff-1bf3-5ba04f3b4b64@suse.cz> <20160818155130.GE5871@two.firstfloor.org> <631cf1bd-8ae9-f07b-5672-5084b699f650@redhat.com> <2c750f4c-c96c-2b22-43ae-53bbebf18af8@suse.cz> <73aa44d7-5287-e4b8-6188-a87d52d3d6b9@acm.org> <9aca1f7c-e7eb-e101-249e-8b5edd21cd48@suse.cz> <2419555f-7271-d64d-94ac-ac97ee7cb953@suse.cz> <4cbaad58-421d-cef5-e1b1-6c78a56d18b8@suse.cz> <5b7cdf6c-54e4-126b-1461-26f88b45dbbb@suse.cz> <36aaf074-5042-c4b9-8d47-9f52313765d6@acm.org> From: David Edelsohn Date: Thu, 10 Nov 2016 16:16:00 -0000 Message-ID: Subject: Re: [PATCH] Introduce -fprofile-update=maybe-atomic To: Nathan Sidwell Cc: =?UTF-8?Q?Martin_Li=C5=A1ka?= , Jeff Law , Andi Kleen , GCC Patches , Jan Hubicka Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2016-11/txt/msg00958.txt.bz2 On Thu, Nov 10, 2016 at 11:14 AM, Nathan Sidwell wrote: > On 11/10/2016 07:43 AM, Nathan Sidwell wrote: >> >> On 11/10/2016 05:19 AM, Martin Li=C5=A1ka wrote: >> >>>> On 10/13/2016 05:34 PM, Martin Li=C5=A1ka wrote: >>>>> >>>>> Hello. >>>>> >>>>> As it's very hard to guess from GCC driver whether a target supports >>>>> atomic updates >>>>> for GCOV counter or not, I decided to come up with a new option >>>>> value (maybe-atomic), >>>>> that would be transformed in a corresponding value (single or >>>>> atomic) in tree-profile.c. >>>>> The GCC driver selects the option when -pthread is present in the >>>>> command line. >>>>> >>>>> That should fix all tests failures seen on AIX target. >>>>> >>>>> Patch can bootstrap on ppc64le-redhat-linux and survives regression >>>>> tests. >>>>> >>>>> Ready to be installed? >> >> >> I dislike this. If it's hard for gcc itself to know, how much harder >> for the user must it be? (does gcc have another instance of an option >> that behaves 'prefer-A-or-B-if-you-can't'? > > > Thinking further. why isn't the right solution for -fprofile-update=3Dat= omic > when faced with a target that cannot support it to: > a) issue an error and bail out at the first opportunity > b) or issue a warning and fall back to single threaded update? > > For #b presumably there'll be the capability of suppressing that particul= ar > warning? Because that incorrectly breaks a huge portion of the testsuite. that's not what the user intended. - David