http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47495
--- Comment #10 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-01-29 13:10:32 UTC --- (In reply to comment #8) > > b) A .mod file is read when a USE statement is encountered; the file > > must exist and is searched for in the include search paths. > > With any kind of module? Even special-case ones like iso_c_binding? Well, intrinsic modules are handled differently; some only exist virtually (iso_fortran_env, iso_c_binding) while others exist as file (OpenMP modules); if they exist as file, they are searched for in a target-dependent default directory,* unless -fintrinsic-modules-path is given. (A .mod placed into this directory is regarded as intrinsic module.) Using "USE, INTRINSIC ::" and "USE, NON_INTRINSIC ::" one can force which module is searched for; following the Fortran standard, a non_intrinsic module has higher precedence. * On my system: $GCC_PATH/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/finclude > And are not compatible across major/minor/any compiler release/version? I tend to forget what is minor in version "n.m.l", but "4.x" and "4.(x+1)" are usually not compatible while "4.x.y" and "4.x.(y+1)" are (unless a serious wrong-code bug is found, which cannot be fixed otherwise). In principle, the format is such that it should allow modifications (new options skipped over, old files can be read). However, in practice, it turned out that the new features required changes which are not backward compatible. To avoid strange errors, the module version number is bumped if in the new experimental version a change is (potentially) incompatible. I would highly welcome a backward compatible solution, but I do not see any. (A compilation on demand w/o .o generation would be one possibility, but that requires that there is a one-to-one correlation between a module name and a file name.) > If you want one rule to update multiple outputs, see > <http://www.gnu.org/software/automake/manual/html_node/Multiple-Outputs.html> That sounds as if a huge number of lines is needed *per file* if one wants to be compatible with POSIX make and avoid compilation cascades. :-(
