From: lynnmcguire5@gmail.com
On 11/12/2024 2:59 PM, Thomas Koenig wrote:
> Lynn McGuire schrieb:
>> On 11/12/2024 2:01 AM, Thomas Koenig wrote:
>>> Lynn McGuire schrieb:
>>>> On 11/11/2024 4:01 PM, Thomas Koenig wrote:
>>>>> Lynn McGuire 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
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
