Ping**2: [PATCH] Install error handler for out-of-memory when using STL containers

[Tobias SchlÃter <tobias dot schlueter at physik dot uni-muenchen dot de>]

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