This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH 5/5] add libcc1
- From: Trevor Saunders <tsaunders at mozilla dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: Jeff Law <law at redhat dot com>, gcc-patches at gcc dot gnu dot org
- Date: Tue, 24 Jun 2014 14:10:13 -0400
- Subject: Re: [PATCH 5/5] add libcc1
- Authentication-results: sourceware.org; auth=none
- References: <1400254001-12038-1-git-send-email-tromey at redhat dot com> <87oayx4l0x dot fsf at fleche dot redhat dot com> <87bntobp1f dot fsf at fleche dot redhat dot com> <20140620031058 dot GA12633 at tsaunders-iceball dot corp dot tor1 dot mozilla dot com> <87vbrv8uje dot fsf at fleche dot redhat dot com> <53A87B75 dot 4090705 at redhat dot com> <20140624031231 dot GA1815 at tsaunders-iceball dot corp dot tor1 dot mozilla dot com> <87mwd22pvd dot fsf at fleche dot redhat dot com>
On Tue, Jun 24, 2014 at 11:12:38AM -0600, Tom Tromey wrote:
> Trevor> hrm, I know basically nothing about the upcoming changes, but I would
> Trevor> have expected linking c++03 code against c++11 code would be fine
> Trevor> especially when the interface doesn't involve any stl.
> This warns against mixing with C++98, which seems to be how GCC is
> While I agree that in this specific case it is probably safe, since gcc
> in general isn't a heavy user of libstdc++, I think it's reasonable to
> simply follow gcc. This is safer in case gcc changes; and the benefit
yeah, I'm not disagreeing at this point.
> from C++11 in libcc1 is modest, especially when you consider the extra
> template magic we'd need in order to actually use variadic templates for
> the RPC stuff.
It would get a little more than that, actually deleting the copy ctors
and stuff you don't want people to call is one thing that comes to mind.
> Trevor> Well, we build everything or at least everything I've seen with
> Trevor> -fno-exceptions, so if something does throw we'll just crash right?
> Trevor> istm we certainly write code calling the throwing new with that
> Trevor> expectation.
> Gcc's coding conventions say that code ought to be exception-safe in
> case exceptions are used in the future. Search for "Exceptions" here:
I think that's a good idea in general, mostly because it results in
simpler code, I think the idea gcc will be exception safe in a
reasonable amount of time is a bit of a pipe dream.
> I think retaining the std::nothrow is safer in view of this, and doesn't
> cause any problems.
I think in general trying to handle allocator failure is a waste of
time, that is all the places we call the throwing new today we'd want
to keep doing that in a world with exceptions and just let the
exception kill us. So assuming you actually want to handle allocator
failure in this particular case for some reason that seems reasonable.