On 20/10/16 10:33 -0700, Mike Stump wrote:
On Oct 20, 2016, at 9:34 AM, Jonathan Wakely <jwak...@redhat.com> wrote:
On 20/10/16 09:26 -0700, Mike Stump wrote:
On Oct 20, 2016, at 5:20 AM, Jonathan Wakely <jwak...@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.
