On Mon, Jun 23, 2014 at 01:09:41PM -0600, Jeff Law wrote: > On 06/20/14 09:33, Tom Tromey wrote: > >>>>>>"Trevor" == Trevor Saunders <tsaund...@mozilla.com> writes: > > > >Trevor> I'm curious, what is the reason you choose not to write this in > >C++11 or > >Trevor> later? Its distributed with gcc, so the only case where you aren't > >Trevor> building with the in tree compiler and libraries is when your cross > >Trevor> compiling gcc, and it doesn't seem particularly important to support > >Trevor> building the plugin or library in that configuration. So istm you > >could > >Trevor> go all the way and assume you are being built with trunk gcc and > >Trevor> libraries. > > > >The plugin has to be ABI compatible with GCC itself, and my > >understanding was that C++11 and "however GCC is built" are not > >necessarily compatible. > Presumably you're referring to the upcoming abi breakage for C++ pair & > list. > > There's ways around that with the ABI tagging we're using, but at least for > now, the safe thing to do for something that must be ABI compatibile with > GCC itself is to stick with C++03 mode. >
hrm, I know basically nothing about the upcoming changes, but I would have expected linking c++03 code against c++11 code would be fine especially when the interface doesn't involve any stl. > >Switching to C++11 would be an improvement -- variadic templates would > >simplify the RPC code (with a complicated caveat). So if it is possible > >I am interested. > There'll probably be a day when we can bless C++11 for building GCC itself > and any associated plugins, but we're not at that point right now. > > >Trevor> So can we add C++ stuff to libiberty and allow building > >Trevor> libiberty without it for binutils / gdb, or can we do something > >Trevor> else to avoid this kind of stuff? > > > >One way would be to just make a new top-level directory for a new > >library. > Seems like the easiest solution, at least for now. ugh more autotools, but wfm. > >Thanks. I changed it to do a NULL check. It's nothrow because nothing > >in libcc1 or gdb is prepared for a C++ exception. While I like > >exceptions (gdb uses its own longjmp-based exception system > >extensively), my understanding is that they aren't currently used in > >gcc. > Right. Or if we're using them in GCC, any such use is well buried in > non-critical , not widely known & marginally, if at all, tested code. Well, we build everything or at least everything I've seen with -fno-exceptions, so if something does throw we'll just crash right? istm we certainly write code calling the throwing new with that expectation. Trev > > Jeff >
