See thread starting at: https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603616.html Issue: Fatal errors inside mutex-locked regions (i.e. basically anything in the plugin) will cause it to hang up trying to take the lock to clean everything up. Possible solutions: would be not use gomp_fatal from within the plugins, but use gomp_error instead and through possibly adjusted plugin APIs tell libgomp that there was a fatal error and let libgomp unlock anything that needs unlocking and exit (EXIT_FAILURE); afterwards. another possibility would be not use gomp_fatal from within the plugins, but use gomp_error instead and through possibly adjusted plugin APIs tell libgomp that there was a fatal error and let libgomp unlock anything that needs unlocking and exit (EXIT_FAILURE); afterwards.
Once done, we might want to change some error propagation from a chain of boolean-returning functions to just GOMP_PLUGIN_fatal – or not. Cf. for instance: https://gcc.gnu.org/pipermail/gcc-patches/2023-April/616992.html
Wild idea: switch libgomp to C++, and use 'throw' and other C++ idioms for proper error propagation and unlocking as part of that?