It has been noticed that the libgomp omp.h header that is generated at build time may differ between different multilibs. E.g. * i386-pc-solaris2.11: --- omp.h 2014-03-21 14:27:34.522529041 +0100 +++ ../amd64/libgomp/omp.h 2014-03-21 14:27:56.903263206 +0100 @@ -34,13 +34,13 @@ typedef struct { unsigned char _x[48] - __attribute__((__aligned__(4))); + __attribute__((__aligned__(8))); } omp_lock_t; typedef struct { - unsigned char _x[56] - __attribute__((__aligned__(4))); + unsigned char _x[64] + __attribute__((__aligned__(8))); } omp_nest_lock_t; #endif * sparc-sun-solaris2.11: --- omp.h 2014-03-21 15:26:13.738263000 +0100 +++ ../sparcv9/libgomp/omp.h 2014-03-21 15:26:49.743545700 +0100 @@ -39,7 +39,7 @@ typedef struct { - unsigned char _x[56] + unsigned char _x[64] __attribute__((__aligned__(8))); } omp_nest_lock_t; #endif * x86_64-unknown-linux-gnu: --- omp.h 2014-03-21 19:02:19.351059178 +0100 +++ ../32/libgomp/omp.h 2014-03-21 19:02:30.432588699 +0100 @@ -39,8 +39,8 @@ typedef struct { - unsigned char _x[16] - __attribute__((__aligned__(8))); + unsigned char _x[12] + __attribute__((__aligned__(4))); } omp_nest_lock_t; #endif Unfortunately, only the version for the default multilib is installed. Given that variables of those types can be allocated by user code and size and/or alignment can differ between different multilibs, this can lead to all sorts of errors when the allocations performed are smaller than what libgomp assumes. It seems like different per-multilib headers need to be installed into separate hierarchies to handle this. Rainer
Or the header needs to include all variants with proper #ifdef-ery
> --- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> --- > Or the header needs to include all variants with proper #ifdef-ery This is difficult for a header generated per multilib at build time. Rainer
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #2) > > --- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> --- > > Or the header needs to include all variants with proper #ifdef-ery > > This is difficult for a header generated per multilib at build time. A similar issue potentially arises for OpenMP's Fortran libraries under finclude/, i.e. omp_lib.h, omp_lib.f90, omp_lib.mod, omp_lib_kinds.mod. Recall that the module files (.mod) are not preprocessed - and the .h files are not if one uses "include 'omp_lib'" (instead of "#include") However, I think for currently used type there should be no problem (with all/most targets).
> --- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> --- > (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #2) >> > --- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> --- >> > Or the header needs to include all variants with proper #ifdef-ery >> >> This is difficult for a header generated per multilib at build time. > > A similar issue potentially arises for OpenMP's Fortran libraries under > finclude/, i.e. omp_lib.h, omp_lib.f90, omp_lib.mod, omp_lib_kinds.mod. > > Recall that the module files (.mod) are not preprocessed - and the .h files are > not if one uses "include 'omp_lib'" (instead of "#include") > > However, I think for currently used type there should be no problem (with > all/most targets). Right, at least on Solaris/SPARC and x86 the 32-bit and 64-bit omp_lib.{h,mod} are identical. Rainer
GCC 4.9.0 has been released
This also happens on Darwin (i386/x86_64 multilib).
GCC 4.9.1 has been released.
GCC 4.9.2 has been released.
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #2) > > --- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> --- > > Or the header needs to include all variants with proper #ifdef-ery > > This is difficult for a header generated per multilib at build time. > GNU diff can can merge two C/C++ header files with the proper ifdef-ery: see: http://www.gnu.org/software/diffutils/manual/html_mono/diff.html#If-then-else and also: http://www.gnu.org/software/diffutils/manual/html_mono/diff.html#Detailed%20If-then-else This could be done as part of the generation of the header at build time.
Or better yet change @OMP_LOCK_SIZE@ and @OMP_LOCK_ALIGN@ from being a configured generated to one which is done in a header file. See how libffi handles this. Confirmed.
GCC 4.9.3 has been released.
The Fortran module files are not installed in the right place, and that leads to error upon compilation of valid user code (not finding the module files). $ ls /usr/local/gfortran/lib/**/libgomp.dylib /usr/local/gfortran/lib/i386/libgomp.dylib /usr/local/gfortran/lib/libgomp.dylib $ ls /usr/local/gfortran/lib/**/omp_lib.mod /usr/local/gfortran/lib/gcc/x86_64-apple-darwin15/6.1.0/finclude/omp_lib.mod It’s because the Makefile machinery is wrong. libgomp/Makefile.am has: fincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/finclude while the corresponding libgfortran has: fincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/finclude notice the extra $(MULTISUBDIR).
Showing how the module files are not found when a non default multilib is chosen: $ gfortran a.f90 -fopenmp $ gfortran a.f90 -fopenmp -m32 a.f90:1:6: use omp_lib 1 Fatal Error: Can't open module file ‘omp_lib.mod’ for reading at (1): No such file or directory compilation terminated. $ cat a.f90 use omp_lib end
Based on libgfortran build machinery, the following patch should be applied to libgomp: Index: libgomp/Makefile.am =================================================================== --- libgomp/Makefile.am (revision 235843) +++ libgomp/Makefile.am (working copy) @@ -10,7 +10,7 @@ config_path = @config_path@ search_path = $(addprefix $(top_srcdir)/config/, $(config_path)) $(top_srcdir) \ $(top_srcdir)/../include -fincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/finclude +fincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/finclude libsubincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include vpath % $(strip $(search_path))
Author: fxcoudert Date: Mon Jan 9 20:29:06 2017 New Revision: 244239 URL: https://gcc.gnu.org/viewcvs?rev=244239&root=gcc&view=rev Log: PR libgomp/60670 * Makefile.am: Make fincludedir multilib-aware. * Makefile.in: Regenerate. Modified: trunk/libgomp/ChangeLog trunk/libgomp/Makefile.am trunk/libgomp/Makefile.in
The Fortran part is now fixed.
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.