ompstub causes problems with existing OpenMP code

[JonMarbach]

I'm part of a larger project where we use OpenMP and someone added a dependency to OpenBLAS recently, and I've just noticed that now omp_get_max_threads, omp_get_thread_num, and omp_get_num_threads return unexpected results (1, 0, and 1 respectively), presumably due to ompstub.dll overriding these functions. Our OpenMP code does appear to run with multiple threads despite omp_get_max_threads returning 1 which is a bit confusing if nothing else. (This is on Windows, using dynamic linking; I don't know how the other parts of our team are using OpenBLAS unfortunately.)

I don't see much documented about this ompstub library or why it's needed (other than a few old issues here.) Can someone explain? If it can't be avoided, what are the strategies for working around the inconsistent omp function returns. (And apologies in advance since I don't know anything about OpenBLAS itself.)

[martin-frbg]

Are you compiling OpenBLAS yourself, or are using some provided binary ? There is nothing in our build files that expressly links in ompstub, so this is probably some compiler default based on the options it was started with (I strongly suspect the stub comes in automatically when not; building with OpenMP support, i.e.when USE_OPENMP is not set.)

[martin-frbg]

see also #3069

[JonMarbach]

Thanks for the replies. I don't know if we compiled it ourselves - I'm guessing not but I can ask around internally (but unfortunately, since it's a big distributed project, things tend to appear "out of nowhere").

I've seen #3069 but I don't follow all the details. Can you help "bottom line" it for me? Sounds like if we rebuild OpenBLAS ourselves against a newer version of flang (maybe with the mp flag?) this might be resolved...?

[brada4]

At least worth trying to build everything with same compiler, using same OMP library.