On 20 October 2016 at 19:40, Jonathan Wakely <jwak...@redhat.com> wrote: > 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. > 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? - 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? 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, Christophe >> 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. > >
