Ping**2: [PATCH] Install error handler for out-of-memory when using STL containers
Tobias Schlüter
tobias.schlueter@physik.uni-muenchen.de
Sat Nov 3 09:17:00 GMT 2012
Hi,
any comments appreciated, also if you think it's unnecessary. This
issue came up when I submitted a patch for PR fortran/51727 that uses
std::map. If this isn't approved within the next few days, I'll fix PR
fortran/51727 in a way that doesn't use C++ and thus needs more
boilerplate code (see
<http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01284.html> for context.)
I'm CCing Ian as the last person who approved a patch to toplev.c and
also Jakub as a global write maintainer and as the person who brought up
this subject.
Link to patch: <http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02515.html>
On 2012-10-28 16:28, Tobias Schlüter wrote:
>
> Ping. This issue stands in the way of a very simple solution of PR
> fortran/51727. I've re-attached the patch for your convenience.
>
> On 15 Oct 2012 at 22:51:05 +0200 Tobias Schlüter wrote:
>> The attached patch adds out-of-memory diagnostics for code using STL
>> containers by using set_new_handler. Since the intended allocation
>> size is not available to a new_handler, I had to forego a more
>> detailed error message such as the one from xmalloc_failed().
>> fatal_error() and abort() don't give a meaningful location when the
>> new_handler is called, so I chose to put together the error message
>> manually as is done in xmalloc_failed(). I would have found it more
>> appealing to have operator new call xmalloc() unless a custom
>> allocator is given, but I don't think there's a standard way of doing
>> this.
>>
>> Built and tested on the C and Fortran testsuites. Ok for trunk?
>
> Best regards,
> - Tobi
>
> 2012-10-15 Tobias Schlüter <tobi@gcc.gnu.org>
>
> * toplev.c: Add '#include <new>'.
> (cxx_out_of_memory): New function.
> (general_init): Install cxx_out_of_memory as handler for
> out-of-memory condition.
Cheers,
- Tobi
More information about the Fortran
mailing list