This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On 16/11/16 22:18 +0100, Christophe Lyon wrote:
On 15 November 2016 at 12:50, Jonathan Wakely <jwakely@redhat.com> wrote:On 14/11/16 14:32 +0100, Christophe Lyon wrote:On 20 October 2016 at 19:40, Jonathan Wakely <jwakely@redhat.com> wrote:On 20/10/16 10:33 -0700, Mike Stump wrote: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.htmlNot 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?
Yes, OK, thanks.
- 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?
I'm not sure how to deal with that.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |