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 ?
Is there any chance that gfortran will automatically generate and use
module files in the future like IVF ?
Is there any chance that gfortran will automatically generate and use
module files in the future like IVF ?
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?
On Mon, 11 Nov 2024 15:31:43 -0600, Lynn McGuire wrote:
Is there any chance that gfortran will automatically generate and use
module files in the future like IVF ?
gfortran already does .mod files.
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
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
?
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.
I have 6,000+ subroutines and
functions in 5,000+ files. And I would still have to modify each file.
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
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.
On 11/12/2024 2:59 PM, Thomas Koenig wrote:
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.
| Sysop: | DaiTengu |
|---|---|
| Location: | Appleton, WI |
| Users: | 991 |
| Nodes: | 10 (0 / 10) |
| Uptime: | 119:37:11 |
| Calls: | 12,958 |
| Files: | 186,574 |
| Messages: | 3,265,637 |