[Bug libgomp/60670] omp.h may differ between multilibs

[radfordneal at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60670

Radford Neal <radfordneal at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |radfordneal at gmail dot com

--- Comment #17 from Radford Neal <radfordneal at gmail dot com> ---
I'd like to add some urgency to getting this fixed.  

The problem with omp.h defining an incorrect omp_lock_t type shows up when gcc
is installed with Homebrew (https://brew.sh) on macOS, for any modern 64-bit
system, since the omp_lock_t type is set up for 32-bit builds.  It also shows
up with the Rtools package for installing R on Windows.  It probably shows up
in various other contexts too.  The consequence is that OpenMP doesn't work
correctly, in ways that may well be non-obvious, and very hard to diagnose for
anyone who doesn't realize what is going on.

One could say that these package providers ought to provide separate 32-bit and
64-bit versions of omp.h, but the fact is that they don't.  And it's not really
unreasonable for them to think that omp.h will correctly define the types for
both 32-bit and 64-bit builds - that's the way just about every other package
works.  What you're doing with keeping omg_log_t "private" by defining it as a
byte array with length filled in during the build is decidedly not a standard
approach, and it's unsurprising that it ends up causing problems.  You ought to
change to a different approach.

If that's not possible immediately, however, you should implement a kludge -
just set @OMP_LOCK_SIZE@ to the maximum that it might be for any platform.