On Thu, Nov 10, 2016 at 10:43 AM, Nathan Sidwell <nat...@acm.org> 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? > > But as ever, I'm not going to veto it.
Do you have a better suggestion? gcc.c now imposes profile-update=atomic if -pthread is used, even if the target does not support profile-update=atomic. Either gcc.c must not impose profile-update=atomic or we need some way of differentiating between when the request should fail because the user really expects it and when the request should silently and gently be ignored. The atomic update feature is nice, but currently GCC is trying to be too smart to guess how important the feature is to the user. Thanks, David
