This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [patch,libgomp] Make libgomp Fortran modules multilib-aware
- From: FX <fxcoudert at gmail dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Jack Howarth <howarth dot at dot gcc at gmail dot com>, GCC Development <gcc at gcc dot gnu dot org>, Richard Henderson <rth at redhat dot com>
- Date: Tue, 31 May 2016 16:49:45 +0200
- Subject: Re: [patch,libgomp] Make libgomp Fortran modules multilib-aware
- Authentication-results: sourceware.org; auth=none
- References: <4795FF84-EC6B-448F-991E-AAA8948D5EE4 at gmail dot com> <CAJMcOU-k8ni+y05YH6CaxH3KAmHNjSYkXAqs-NYPWaNztK+Xtw at mail dot gmail dot com> <93D9F5BF-2BFD-4DC9-957E-EB3CAA41E7D9 at gmail dot com> <904796F1-1527-4424-8425-22592F65B075 at gmail dot com> <20160531134715 dot GZ28550 at tucnak dot redhat dot com>
> Why? It should look for it first in 32/finclude, sure, but if not found,
> should fall back to finclude dir, where it is found.
> Does it differ between 32-bit and 64-bit compilation?
Module files are target- and ABI-dependent and can differ between multilibs. Thus gfortran only looks for intrinsic .mod files in the 32/finclude, and not the parent. This was the design choice made when we introduced them (the driver passes the one and only valid finclude directory to the compiler through the -fintrinsic-modules-path option.)
So, the best practice is for libgomp to store its .mod files into the multilib-specific finclude directory, just like libgfortran does.
FX