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

[Jonathan Wakely]

On 14/11/16 14:32 +0100, Christophe Lyon wrote:
>On 20 October 2016 at 19:40, Jonathan Wakely <jwakely@redhat.com> wrote:
>> 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.
>>
>I gave this a try (using CXXFLAGS_FOR_TARGET=-fno-threadsafe-statics).
>It seems to do the trick indeed: almost all tests now pass, the flag is added
>to testcase compilation.
>
>Among the 6 remaining failures, I noticed these two:
>- experimental/type_erased_allocator/2.cc: still complains about the missing
>__sync_synchronize. Does it need dg-require-thread-fence?

Yes, I think that test actually uses atomics directly, so does depend
on the fence.

>- abi/header_cxxabi.c complains because the option is not valid for C.
>I can see the test is already skipped for other C++-only options: it is OK
>if I submit a patch to skip it if -fno-threadsafe-statics is used?

Yes, it makes sense there too.

>I think I'm going to use this flag in validations from now on (target
>arm-none-eabi
>only, with default mode/cpu/fpu).

Thanks for the update on this.