This is the mail archive of the
mailing list for the GCC project.
Re: using C++ STL containers in GCC/gfortran source code
- From: Pedro Alves <palves at redhat dot com>
- To: Jakub Jelinek <jakub at redhat dot com>, "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: Janus Weil <janus at gcc dot gnu dot org>, "N.M. Maclaren" <nmm1 at cam dot ac dot uk>, gcc mailing list <gcc at gcc dot gnu dot org>, gfortran <fortran at gcc dot gnu dot org>
- Date: Sat, 17 Dec 2016 20:14:58 +0000
- Subject: Re: using C++ STL containers in GCC/gfortran source code
- Authentication-results: sourceware.org; auth=none
- References: <CAKwh3qgUN=mTFPg6Ew6Yk9RXgS3CttE7O3cGMQRcLKNqUOjBng@mail.gmail.com> <Prayer.email@example.com> <CAKwh3qhj-y5U9RrJ+nP45fGjRL2JbEKGKcVw4nsXMp-=h8jq-Q@mail.gmail.com> <firstname.lastname@example.org> <CAKwh3qiAGVjGVg0FKakEFmdmdJjPw=KQ7j0jYbB0qp2SPN__Aw@mail.gmail.com> <email@example.com> <firstname.lastname@example.org> <20161217172455.GL21933@tucnak>
On 12/17/2016 05:24 PM, Jakub Jelinek wrote:
> On Sat, Dec 17, 2016 at 11:17:25AM -0500, Frank Ch. Eigler wrote:
>> Pedro Alves <email@example.com> writes:
>>> malloc will fail, new will throw bad_alloc, and GCC will abort and
>>> maybe generate a core dump, instead of gracefully printing
>>> something like:
>>> cc1: out of memory allocating NNNNNNNN bytes ...
>>> and existing with error status.
>> Consider having the main() function catch bad_alloc etc. and print
>> prettier error messages than the builtin uncaught-exception aborter?
> GCC is built with -fno-exceptions -fno-rtti, so no catching...
Right. Let me expand on that:
- GCC wants to build with -fno-exceptions, so that can't work.
- Even if GCC was built with -fexceptions, I'd suspect that there'll
be GCC code that could throw an exception that would try to cross
some non-C++/C code that is not built with -fexceptions, via callbacks.
(Think qsort, but also all the C libraries in the repo). That problem
tends to be missed on x86_64 GNU/Linux, since the ABI
mandates -fexceptions. But it's a real problem on other systems.
That's fixable, but if you're not using exceptions for anything else,
you'll usually only notice it when things are already pretty down south.
- You'd have to do this in the entry point of all threads. Not sure GCC
ever spins threads today, but I'd avoid a design that prevents it,
because who knows what support and run time libraries do internally.
- Lastly, even if the technical details above were all resolved,
I'd still recommend against the top level catch(bad_alloc) approach, since
by the time the exception is caught, you've lost context of where the
exception was originally thrown, i.e., where the bad allocation is
coming from. The operator new approach allows for example having
gcc automatically print its own backtrace for bug reports,
with e.g., glibc's backtrace() or libbacktrace or some such.