https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80781
--- Comment #8 from René J.V. Bertin <rjvbertin at gmail dot com> --- (In reply to Jonathan Wakely from comment #7) Good to know that there are apparently no "political" barriers. That means I can try to get my patch into the MacPorts GCC port(s) where it can see more widespread testing than I can do on my own. I think that's the 1st step to take anyway, no need to spend time on polishing a feature until there is more evidence that it is really viable. > No. Somebody has to do the work. It will get into GCC if somebody does the > work, but not before then. Can that somebody at least count on constructive support getting things implemented correctly, supposing s/he is not a seasoned GCC contributor? > > The most complex part is probably the implementation of the commandline > > argument and (esp.) getting the build system to use -stdlib=libstdc++ if > > I still think that should be the default, on all targets. What's the point of having a default that isn't adapted to the host? Users of non-X86 hosts also need not tell the compiler to generate the appropriate instruction set instead of X86, ditto for the object and executable file format. In this case I could imagine that the build system would have a default that makes libstdc++ the default, but IMHO it should be possible to configure the build such that -stdlib=libc++ becomes the default. Clang does the same: Linux users don't have to specify -stdlib=libstdc++ for every C++ compilation. > > that's indeed required to build GCC itself. But even that must be trivial > > for developers who know their way around those waters. > > Yes it's fairly simple. I'll have to take your word for it, my own experience with building GCC with custom compiler options is that it's fairly impossible ;)
