Path: ...!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Lynn McGuire <lynnmcguire5@gmail.com>
Newsgroups: comp.lang.fortran
Subject: Re: in gfortran, is it faster compile times with *.mod files ?
Date: Wed, 13 Nov 2024 14:27:32 -0600
Organization: A noiseless patient Spider
Lines: 101
Message-ID: <vh323k$2cgju$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> <vh0fji$1par2$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 13 Nov 2024 21:27:33 +0100 (CET)
Injection-Info: dont-email.me; posting-host="c53a046a5d84cbd6efa921e77fb55335";
	logging-data="2507390"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19o7/ILJZ4B5WOi0xKwHyUE2P3gTPNcSU0="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:c9QfXZkq0+tz21GtsazOtZfwp7A=
In-Reply-To: <vh0fji$1par2$1@dont-email.me>
Content-Language: en-US
Bytes: 5109

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