From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57968 invoked by alias); 10 Nov 2016 15:58:41 -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 57949 invoked by uid 89); 10 Nov 2016 15:58:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1593 X-HELO: mx2.suse.de Received: from mx2.suse.de (HELO mx2.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 10 Nov 2016 15:58:39 +0000 Received: from relay1.suse.de (charybdis-ext.suse.de [195.135.220.254]) by mx2.suse.de (Postfix) with ESMTP id BD33EACE6; Thu, 10 Nov 2016 15:58:37 +0000 (UTC) Subject: Re: [PATCH] Introduce -fprofile-update=maybe-atomic To: Nathan Sidwell , Jeff Law , Andi Kleen 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> Cc: gcc-patches@gcc.gnu.org, jh@suse.cz, David Edelsohn From: =?UTF-8?Q?Martin_Li=c5=a1ka?= Message-ID: <8e2214bb-3944-7bc7-0d61-098f9f4cadae@suse.cz> Date: Thu, 10 Nov 2016 15:58:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <36aaf074-5042-c4b9-8d47-9f52313765d6@acm.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2016-11/txt/msg00954.txt.bz2 On 11/10/2016 04:43 PM, Nathan Sidwell wrote: > On 11/10/2016 05:19 AM, Martin Liška wrote: > >>> On 10/13/2016 05:34 PM, Martin Liška 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'? > > It's also not clear what problem it's solving for the user? If the user needs atomic update, they should get a hard error if the target doesn't support it. If they don't need atomic, why ask for it? My initial motivation was to automatically selected -fprofile-update=atomic if supported by a target and when '-pthread' is present on command line. As it's very problematic to identify (from GCC driver) whether a target supports or not atomic updates, 'maybe' option is the only possible we can guess. > > But as ever, I'm not going to veto it. Other option is to disable selection of -fprofile-update=atomic automatically. Martin > > nathan >