[libstdc++, testsuite] Add dg-require-thread-fence

[Jonathan Wakely]

On 20/10/16 10:33 -0700, Mike Stump wrote:
>On Oct 20, 2016, at 9:34 AM, Jonathan Wakely <jwakely@redhat.com> wrote:
>>
>> On 20/10/16 09:26 -0700, Mike Stump wrote:
>>> On Oct 20, 2016, at 5:20 AM, Jonathan Wakely <jwakely@redhat.com> wrote:
>>>>
>>>> I am considering leaving this in the ARM backend to force people to
>>>> think what they want to do about thread safety with statics and C++
>>>> on bare-metal systems.
>>
>> The quoting makes it look like those are my words, but I was quoting
>> Ramana from https://gcc.gnu.org/ml/gcc-patches/2015-05/msg02751.html
>>
>>> Not quite in the GNU spirit?  The port people should decide the best way to get as much functionality as possible and everything should just work, no sharp edges.
>>>
>>> Forcing people to think sounds like a sharp edge?
>>
>> I'm inclined to agree, but we are talking about bare metal systems,
>
>So?  gcc has been doing bare metal systems for more than 2 years now.  It is pretty good at it.  All my primary targets today are themselves bare metal systems (I test with newlib).
>
>> where there is no one-size-fits-all solution.
>
>Configurations are like ice cream cones.  Everyone gets their flavor no matter how weird or strange.  Putting nails in a cone because you don't know if they like vanilla or chocolate isn't reasonable.  If you want, make two flavors, and vend two, if you want to just do one, pick the flavor and vend it.  Put an enum #define default_flavor vanilla, and you then have support for any flavor you want.  Want to add a configure option for the flavor select, add it.  You want to make a -mflavor=chocolate option, add it.  gcc is literally littered with these things.

Like I said, you can either build the library with
-fno-threadsafe-statics or you can provide a definition of the missing
symbol.

>Anything vended should just work.  If it doesn't, that's a bug that needs fixing.  If a port person doesn't understand, we can educate them why _it just works_, is a nice design philosophy; maybe it is new to them.

Which is basically what I'm saying. Marking 3000 tests UNSUPPORTED to
make some test results look clean is not a fix for anything.


>> Choosing something that makes most of the library unusable will upset one group of people, and
>> choosing something that adds overhead that could be avoided will upset
>> another group.
>
>No, this is a misunderstanding.  Users want things to just work, really.  Bosses often like it when things just work as well; so it's not just users.  Customers often like it as well.  Anyway, that's my experience.


OK, I'll put it another way. Under no circumstances am I going to
accept a patch that requires adding the same redundant directive to
every single 'do-dg run' test in libstdc++-v3/testsuite/.

Right now I don't care how or if the FAILs get fixed, but it won't be
by individually marking every file as UNSUPPORTED.