This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC 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]

Re: using C++ STL containers in GCC/gfortran source code


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 <palves@redhat.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.

Thanks,
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]