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
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 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 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
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
