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 interface of the handler itself... I dunno. I'd hate to make it
too complicated to actually use. If severity is restricted to a single bit
meaning "cannot possibly continue" or "transient error". Maybe with the error
string, since who knows what kind of weirdness is going on in the plugin.
I wonder whether there should be 2 separate handlers -- one for the diagnostic
and one for fatality? Something like:
typedef void omp_diag_t (void *usr_data, unsigned flags, const char *, va_list);
void *OMP_diag_data;
omp_diag_t *OMP_diag_fn = OMP_diag_default;
void (*OMP_fatal_fn) (void) = abort;
then in gomp:
void OMP_error (unsigned flags, const char *fmt, ...) {
va_list args;
...
OMP_diag_fn (OMP_diag_data, flags, fmt, args);
}
void __attribute__ ((noreturn))
OMP_fatal (const char *fmt, ...) {
...
OMP_diag_fn (OMP_diag_data, SOMETHING, fmt, args);
OMP_fatal_fn ();
}
That way the non-returning nature of OMP_fatal can be exposed to the compiler
(I'm sure that'll kill a lot of false positive compiler warnings).
nathan
--
Nathan Sidwell
