Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Thomas Koenig <tkoenig@netcologne.de>
Newsgroups: comp.lang.fortran
Subject: Re: in gfortran, is it faster compile times with *.mod files ?
Date: Tue, 12 Nov 2024 20:59:30 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 87
Message-ID: <vh0fji$1par2$1@dont-email.me>
References: <vgtt3v$169sh$1@dont-email.me> <vgturv$16fp9$1@dont-email.me>
 <vgu2rb$16rop$2@dont-email.me> <vgv213$1g931$1@dont-email.me>
 <vh0chn$1oq8f$1@dont-email.me>
Injection-Date: Tue, 12 Nov 2024 21:59:31 +0100 (CET)
Injection-Info: dont-email.me; posting-host="fd2f8c22f4feff39877eeb97a6a348ef";
	logging-data="1878882"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/2p/CNTEMg/m8S4qH7BMIElSD0oHMgdoE="
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:cmb4n0Oa3YgSqWugLFcmI6zFHnI=
Bytes: 4279

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.