Handling error conditions in libgomp

Thomas Schwinge thomas@codesourcery.com
Fri Feb 28 11:38:00 GMT 2014


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:

    gomp_fatal (const char *fmt, ...)
      va_list list;
      va_start (list, fmt);
      gomp_verror (fmt, list);
      va_end (list);
      exit (EXIT_FAILURE);

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 real bugs, only/primarily dynamic resource
exhaustion?), but in the advent of libgomp using external modules (plugin
interface, for acceleration devices) I expect them to become more

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.

Does it make sense to add the option for the user to install a handler
for this?  Three quick ideas, all untested: generally use abort in
libgomp, which can then be caught with a SIGABRT handler that the user
has set up (difficult to communicate information from libgomp to the
handler); adding a weak function GOMP_error that the user can provide and
that libgomp will call in presence of an error; or provide some GOMP_init
function for registering an error handler.  The actual interface might be
something like: an enum to indicate the class (severity?) of the error, a
const char* for an error message that libgomp has generated (possibly
forwarded from a plugin), and a boolean return value to tell libgomp to
either continue or terminate the process.  Then, also libgomp's internal
initialization could be made more explicit, so that it can (be)
reinitialize(d) after an error occured.  It makes sense that the default
remains to terminate the process in presence of an error.

I have not yet researched what other OpenACC or OpenMP implementations
are doing, or other compiler support/runtime libraries.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 489 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20140228/7d9d123b/attachment.sig>

More information about the Gcc mailing list