http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56224
Bug #: 56224
Summary: gfortran -fopenmp cannot find omp_lib.h
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dnovi...@gcc.gnu.org
CC: ja...@redhat.com
$ cat ~/a.f
include "omp_lib.h"
end
Compiled with trunk as of 2013-02-04:
$ gcc48/bin/gfortran -c a.f
a.f:1: Error: Can't open included file 'omp_lib.h'
Compiled with GCC 4.7:
$ gcc47/bin/gfortran -c a.f
$
Jakub and I discussed this on IRC:
07:58:20 dnovillo: jakub: i see the file in …./finclude/omp_lib.h, but when i
run the libgomp testsuite with the installed compiler, the #include directives
in the libgomp fortran tests can't find that file.
07:58:22 jakub: dnovillo: it is; omp_lib.h generally should be #included, so
what matters is the standard preprocessor search path, and omp_lib.h should be
there
07:58:41 richi: maybe I should code up a "discover undetected loops" routine
07:58:51 jakub: dnovillo: omp_lib without .h should be USEd
07:59:18 dnovillo: jakub: this is being included by
libgomp.fortran/appendix-a/a.18.1.f90
08:00:08 dnovillo: the problem is that when i run the testsuite standalone, I
don't see a -I to the .../finclude directory. This works when executed from
the build directory, so I may be missing some settings in my dejagnusetup.
08:00:17 jakub: dnovillo: finclude/ is for modules I thought
08:00:41 dnovillo: well, that's where the file ends up in the installed image.
08:00:54 dnovillo: fortran modules have a different search path?
08:02:22 jakub: include "omp_lib.h"
08:02:22 jakub: end
08:02:33 jakub: gfortran -fopenmp -o /tmp/a /tmp/a.f
08:02:46 jakub: works just fine for me with installed compiler (Fedora 17 one)
08:04:10 dnovillo: hmm, there may be another wrinkle here then. i'm getting
08:04:26 dnovillo: $ bin/gfortran -fopenmp -o /tmp/a.o ~/a.f
/home/dnovillo/a.f:1: Error: Can't open included file 'omp_lib.h'
08:04:50 dnovillo: with gfortran from trunk as of 4/Feb.
08:05:02 jakub: even
08:05:08 jakub: #include "omp_lib.h"
08:05:11 jakub: end
08:05:21 jakub: gfortran -fopenmp -o /tmp/a /tmp/a.F works for me
08:05:32 dnovillo: with trunk gfortran, i suppose?
08:05:51 jakub: dnovillo> 4.7, but there weren't any changes I'm aware of
08:06:00 jakub: dnovillo: let me try 4.8-RH gfortran
08:06:01 dnovillo: ah, 4.7 works fine for me.
08:06:15 dnovillo: it's 4.8 that i can't get to work.
08:09:01 jakub: dnovillo: ok, I can reproduce the problem with 4.8
08:09:35 dnovillo: i think using USE might work. I see -fintrinsic-modules-path
gcc/x86/bin/../lib/gcc/x86_64-grtev3-linux-gnu/4.8.x-google-integration/finclude
in the -v output
08:09:39 jakub: dnovillo: can you file a bug against fortran component? The
files are installed the same way as before, so it is the FE that changed in
some weirdo way
08:09:48 dnovillo: jakub: will do.
08:09:56 jakub: dnovillo: use should be used together with omp_lib, not
omp_lib.h
08:10:23 dnovillo: ah, so the test would have to change. ok. i'll file the
bug and mark these failures as expected for now in our builds. thanks.
08:10:38 jakub: dnovillo: perhaps the end of dicsussion will be that omp_lib.h
should be installed into include/ instead of finclude/, where it would
supposedly work
08:11:05 jakub: dnovillo: even in 4.7, gfortran -E with #include "omp_lib.h"
didn't work, but -c worked
08:11:30 dnovillo: heh. but we'd need it in both places, right? finclude/ is
used for USE commands?
08:11:38 jakub: dnovillo: having omp_lib.h in include/ on the other side means
that people using C/C++ might try to #include "omp_lib.h" and be very surprised
08:12:15 jakub: dnovillo: omp_lib.h isn't a module, it is a header file, it
should be used in pre-F90 Fortran only
08:12:30 dnovillo: ah
08:12:38 jakub: dnovillo: USE is F90+, needs omp_lib.f90/omp_lib.mod etc. -
i.e. a module
