Ping?
On 16 November 2016 at 22:18, Christophe Lyon <christophe.l...@linaro.org> wrote: > On 15 November 2016 at 12:50, Jonathan Wakely <jwak...@redhat.com> wrote: >> On 14/11/16 14:32 +0100, Christophe Lyon wrote: >>> >>> 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? >> >> >> Yes, I think that test actually uses atomics directly, so does depend >> on the fence. >> > I've attached the patch to achieve this. > Is it OK? > >>> - 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. > > This one is not as obvious as I hoped. I tried: > -// { dg-skip-if "invalid options for C" { *-*-* } { "-std=c++??" > "-std=gnu++??" } } > +// { dg-skip-if "invalid options for C" { *-*-* } { "-std=c++??" > "-std=gnu++??" "-fno-threadsafe-statics" } } > > but it does not work. > > I set CXXFLAGS_FOR_TARGET=-fno-threadsafe-statics > before running GCC's configure. > > This results in -fno-threadsafe-statics being used when compiling the tests, > but dg-skip-if does not consider it: it would if I passed it via > runtestflags/target-board, but then it would mean passing this flag > to all tests, not only the c++ ones, leading to errors everywhere. > > Am I missing something? > > Thanks, > > Christophe > >>> 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. >>