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 <t...@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
