From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47635 invoked by alias); 10 Nov 2016 16:17:17 -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 47617 invoked by uid 89); 10 Nov 2016 16:17:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-qt0-f196.google.com Received: from mail-qt0-f196.google.com (HELO mail-qt0-f196.google.com) (209.85.216.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 10 Nov 2016 16:17:06 +0000 Received: by mail-qt0-f196.google.com with SMTP id m48so10533621qta.2 for ; Thu, 10 Nov 2016 08:17:06 -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=xKvRVRQhYml/K5GUh62bCpspZJ9sPTNzqs0OFynhZB0=; b=Eb/EStOHtNzpDbsCtcIwJRUX2reim270vh6yJ6BxpbqBM8Ucg6yn9ojHSglc0cycmY KxLWjXw4xZr2GN0bqKXU9bTa9Mjh0qtV6PKw9RXrO4yxKl63EYrJ/D0D/FVNVb/wr8h1 OsF1lCsY5PQXxEHx+QDAUQOMCFW6UlgIC1Bp0/SLTjQM0vZzZV0rTJnRuPC1FkvZqf5y ONAaEKy8QjPRJOKeXqUuGx7G0jWzLH3GvbXRpRoeoyRYW9Wz31wVvwSQB+xz87IY18Yo e0F7TzD93Qf6kTyZRBgd4NhuFD8befDo9+N0totnuJlBNkPcWvATOWZrj9Q08EzhFwgu rjKw== X-Gm-Message-State: ABUngvfetHY7YdAgd8K1y2CbhygPnvdf1ZpS30lgTHQzQApM+pd3jHiNk7eEtoJ1wN9rUe4GBP1pZ6OjLySjpQ== X-Received: by 10.237.36.170 with SMTP id t39mr6855969qtc.115.1478794624798; Thu, 10 Nov 2016 08:17:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.163.1 with HTTP; Thu, 10 Nov 2016 08:17:04 -0800 (PST) In-Reply-To: <8e2214bb-3944-7bc7-0d61-098f9f4cadae@suse.cz> 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> <8e2214bb-3944-7bc7-0d61-098f9f4cadae@suse.cz> From: David Edelsohn Date: Thu, 10 Nov 2016 16:17:00 -0000 Message-ID: Subject: Re: [PATCH] Introduce -fprofile-update=maybe-atomic To: =?UTF-8?Q?Martin_Li=C5=A1ka?= Cc: Nathan Sidwell , 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/msg00959.txt.bz2 On Thu, Nov 10, 2016 at 10:58 AM, Martin Li=C5=A1ka wrote: > On 11/10/2016 04:43 PM, 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 com= mand line. >>>>> >>>>> That should fix all tests failures seen on AIX target. >>>>> >>>>> Patch can bootstrap on ppc64le-redhat-linux and survives regression t= ests. >>>>> >>>>> Ready to be installed? >> >> I dislike this. If it's hard for gcc itself to know, how much harder fo= r 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 su= pport it. If they don't need atomic, why ask for it? > > My initial motivation was to automatically selected -fprofile-update=3Dat= omic if supported by a target and when '-pthread' is present on command lin= e. > As it's very problematic to identify (from GCC driver) whether a target s= upports or not atomic updates, 'maybe' option is the only possible we can g= uess. > >> >> But as ever, I'm not going to veto it. > > Other option is to disable selection of -fprofile-update=3Datomic automat= ically. Unfortunately, this cannot use a configure test or manually set value based on target because the same gcc.c driver is invoked with different options that may provide atomic update in some variants and no atomic update in other (e.g., -m64) because the profile counter is 64 bits. Maybe instead of adding "maybe", we need to change the severity of the warning so that the warning is not emitted by default. - David