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

Mike Stump mikestump@comcast.net
Thu Oct 20 17:34:00 GMT 2016


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.

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.

> 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.



More information about the Libstdc++ mailing list