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.