Sujet : Re: in gfortran, is it faster compile times with *.mod files ?
De : lynnmcguire5 (at) *nospam* gmail.com (Lynn McGuire)
Groupes : comp.lang.fortranDate : 13. Nov 2024, 21:27:32
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vh323k$2cgju$1@dont-email.me>
References : 1 2 3 4 5 6
User-Agent : Mozilla Thunderbird
On 11/12/2024 2:59 PM, Thomas Koenig wrote:
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
On 11/12/2024 2:01 AM, Thomas Koenig wrote:
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
On 11/11/2024 4:01 PM, Thomas Koenig wrote:
Lynn McGuire <lynnmcguire5@gmail.com> schrieb:
In gfortran, is it faster compile times with *.mod files ? Or is it
just as fast compiling to include the module interface information in
each subroutine / function file ?
>
I haven't benchmarked this, but I think likely that there would only
be a small difference. Usually, the front end only takes a small part of
compilation time (but there are pathological cases).
>
In general, modules are better because of automatic checking.
If you want to avoid recompilation cascades, submodules (where
you can separate the definition from the implementation) might
be worth looking into.
>
Is there any chance that gfortran will automatically generate and use
module files in the future like IVF ?
>
Not sure what you're asking for. Can you give an example?
>
1. you compile abc.f in IVF
2. IVF automagically creates an abc__genmod.f90 file in your release
subdirectory with the subroutine / function module interface in it
>
I think I get the general gist (but it would help me understand
if you could post a complete example).
>
But gfortran currently does not have such a feature (which appears
to duplicate modules). It is also not immediately clear what should
happen if, for example, a procedure uses a derived type from another
module... (This may not be relevant to your case, but as a compiler
writer, you have to think about this kind of thing :-|)
>
What would go wrong if you simply encapsulated abc.f in
>
MODULE ABC
CONTAINS
C Your code here
END MODULE ABC
>
?
>
I am not sure what that would get me.
Automated checking, according to the language definition. You might
even find a bug or 300.
I have 6,000+ subroutines and
functions in 5,000+ files. And I would still have to modify each file.
Yes.
I am going to write a C++ program to put a USE statement in each
subroutine / function with the name of the subroutine / function to be
excluded. It should not take me more than a day or three.
I scanned through the Fortran Language doc but it did not have a USE
case for this.
https://j3-fortran.org/doc/year/24/24-007.pdf
It is notoriously hard to read the standard if you want to find
anything in particular...
Hm... maybe another point. If you want to find discrepancies in
argument lists, you could concatenate all your Fortran source files
into one (which will be large, I presume) and then run "gfortran
-fsyntax-only" on it. You could then get error messages like
$ cat mismatch.f
subroutine foo(a)
real a
end
subroutine bar
call foo(42)
end
$ gfortran -fsyntax-only mismatch.f
mismatch.f:6:72:
6 | call foo(42)
| 1
Error: Type mismatch in argument 'a' at (1); passed INTEGER(4) to REAL(4)
which you could then investigate.
Yeah, I really do not want to do that as it will be only a special run. I want the errors to show up during each compile so that the programmer will fix them right then and there.
And we had a user run into an unbalanced argument call to a subroutine on Monday. One of us had changed a subroutine argument list and fixed 8 out of the 9 calls. No telling how many of those land mines are sitting in our software.
Thanks,
Lynn McGuire