This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Introduce -fprofile-update=maybe-atomic
- From: David Edelsohn <dje dot gcc at gmail dot com>
- To: Nathan Sidwell <nathan at acm dot org>
- Cc: Martin Liška <mliska at suse dot cz>, Jeff Law <law at redhat dot com>, Andi Kleen <andi at firstfloor dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>, Jan Hubicka <jh at suse dot cz>
- Date: Thu, 10 Nov 2016 11:16:36 -0500
- Subject: Re: [PATCH] Introduce -fprofile-update=maybe-atomic
- Authentication-results: sourceware.org; auth=none
- References: <87f2bc4f-c4df-eadd-aec6-a937ed0ccaba@acm.org> <1253ac69-3301-f185-e43a-a34cadf8f51e@suse.cz> <67fda6d2-9b3e-a0d1-effc-34e1115030b2@acm.org> <b62f3336-b332-048f-ed2f-9392824f0b84@suse.cz> <1ff3cc75-7cee-79f3-395b-ef7a4d286a3d@acm.org> <04a05835-4666-4d7d-c1a9-d4bcc4ea924a@suse.cz> <ac9182f6-7164-9426-c55b-c13a1a30d3bd@suse.cz> <87k2fpdatl.fsf@tassilo.jf.intel.com> <6f8b1905-818b-bfff-1bf3-5ba04f3b4b64@suse.cz> <c526f177-0304-787d-c57d-3fd3e49a57e5@redhat.com> <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> <b716bb45-fb57-63e4-d36a-8d86389d7739@acm.org>
On Thu, Nov 10, 2016 at 11:14 AM, Nathan Sidwell <nathan@acm.org> wrote:
> On 11/10/2016 07:43 AM, 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'?
>
>
> Thinking further. why isn't the right solution for -fprofile-update=atomic
> 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 particular
> warning?
Because that incorrectly breaks a huge portion of the testsuite.
that's not what the user intended.
- David