Hi!
Currently when libgomp hits an error (that is, an internal error,
possibly due to the user doing "stupid" things), after printing a message
libgomp/error.c:gomp_fatal terminates the executing process:
void
gomp_fatal (const char *fmt, ...)
{
va_list list;
va_start
On 02/28/2014 03:37 AM, Thomas Schwinge wrote:
> The process cannot recover from this, trying to continue despite the
> error. (It is of course questionable what exactly to do in this case, as
> libgomp's internal state may now be corrupt.) So far, such errors may
> have been rare (aside from rea
On 02/28/14 16:05, Richard Henderson wrote:
I'd be ok with some kind of registration interface, like
old = omp_set_error_handler (new);
so that a library can set and restore the handler around its own omp usage.
I agree. An explicit API should be exposed to do this.
As for the interfac
On Fri, 2014-02-28 at 12:37 +0100, Thomas Schwinge wrote:
> Does it make sense to add the option for the user to install a handler
> for this?
The problem with calling a handler is that it's often hard to define
which state the program is in during the handler. If libgomp had to
terminate because
On Fri, 28 Feb 2014, Thomas Schwinge wrote:
> That aside, it is also an hurdle for ourselves if in libgomp's testsuite
> we want to test that the library does the right thing (abort) for
> non-sensible requests.
If you want to verify that a program exits with an error (so that exit
with an error
