On Thu, Nov 10, 2016 at 11:14 AM, Nathan Sidwell <nat...@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