[libstdc++, testsuite] Add dg-require-thread-fence
Kyrill Tkachov
kyrylo.tkachov@foss.arm.com
Fri Oct 21 11:14:00 GMT 2016
Hi all,
On 21/10/16 09:00, Christophe Lyon wrote:
> [ccying Ramana]
Ramana is currently OoO all of this week.
Kyrill
> On 20 October 2016 at 18:34, 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,
>> where there is no one-size-fits-all solution. 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.
>>
>> Either way, I don't think disabling 50% of the testsuite is the
>> answer. If you don't like the failures, configure the library to build
>> without threadsafe statics, or configure it to depend on libatomic, or
>> something else. (We might want new --enable-xxx switches to simplify
>> doing that).
>>
> So if we say that the current behaviour has to keep being the default,
> so that users think about what they are really doing, I can certainly
> patch my validation scripts to add a configure flag for this particular
> configuration.
>
> Is arm-none-eabi the only target having this problem?
>
> Thanks,
>
> Christophe
>
More information about the Libstdc++
mailing list