Can't explain this?

[jski]

I've been translating some Runge-Kutta vibration analysis code from C
to Fortran 2003/08. Finally, I got it up and running - all was fine.
The C code and Fortran code were producing nearly identical numbers.

Then, while perusing the software "add/remove package" utility on
Fedora 16, searching under gfortran, I noticed and added
"Compatibility Fortran 95 runtime library version 4.1.2" and "Static
Fortran libraries". After I rebooted, the Fortran code I wrote (that
I was running), wouldn't compile:

$ gfortran plates.f95
plates.f95:91.12:

use geometry
1
Fatal Error: Can't open module file 'geometry.mod' for reading at (1):
No such file or directory

My client had insisted that all the code be in 1 file. So I placed
all 8 modules + program (main) in 1 file ... not worrying about the
order of the modules in the file. I had wondered about the module
order but since it compiled I assume - no problem: the order of the
modules in the file didn't matter.

Now, because of this compile time error, I moved "module geometry" up
front and all is fine ... again.

Go figure?

---John

[Arjen Markus]

The information that a compiler needs about a module is usually stored in
an external file (geometry.mod or something similar). These files are created
as the compiler processes the file. If the module is USED, before its
declaration occurs, then an existing version of this intermediate file may
be used by the compiler instead. Which might be out-of-date.

So, in general, if your source files contain more than one module, make
sure they physically appear before they are used. If you have more than
one source file, make sure the files are compiled in the right order.

Regards,

Arjen

[jski]

But in this case (by customer request) all the source was in 1 file.
---John

[Wolfgang Kilian]

The generated module files (usually with the extension .mod) resemble
the header files of C/C++. They hold similar information. But there
are important differences:

1) They are generated by the compiler, not by the programmer.
2) The order of compilation does matter, because modules depend on other
modules.
3) The file format is non-portable between compilers. In particular, it
is often non-portable between different versions of the same compiler.

Nothing of this is mentioned in the standard. The standard does not
even mention the existence of module files, IIRC.

Likewise, it doesn't matter how you distribute modules among source
files. The concept of a source file is not a matter of the standard,
either. It is the dependency tree of modules which is important.

If you don't have old gfortran-compiled binaries and module files, there
is no need to install gfortran-4.1 runtime libraries. That was an old
compiler version, current is 4.6/7/8.

-- Wolfgang

--
E-mail: firstnameini...@domain.de
Domain: yahoo

[jski]

> E-mail: firstnameinitial.lastn...@domain.de
> Domain: yahoo

I was just exploring and playing with gfortran (I'm a newbie BUT very
impressed with Fortran vs. C for numerical coding).

But what about the order of the modules, if all the code is in 1 file?

[Gordon Sande]

Compile it TWICE!

For one compile the order of the modules matters. Declare it before using it.

But if you forget to delete the .mod files then the declaration from the
first compile will be there as a .mod file for the use in the second compile.

If you are a tidy sort and delete all the .mod files at the end then the two
compile scheme will not work.

[Wolfgang Kilian]

On 09/18/2012 04:02 PM, jski wrote:

> I was just exploring and playing with gfortran (I'm a newbie BUT very
> impressed with Fortran vs. C for numerical coding).
>
> But what about the order of the modules, if all the code is in 1 file?

The compiler is likely (but, strictly speaking, not require to) compile
the modules in the order that they have been written in the file. If
the file looks like

module a
...
end module a

module b
use module a
...
end module b

everything is probably fine, because a.mod will be available in time for
the compilation of b. But if the file looks like

module b
use module a
...
end module b

module a
...
end module a

a.mod will either not be available or, even worse, the compiler may read
a file a.mod that was left over from a previous compilation. This may
result in anything from everything ok, strange warnings, errors, to
apparently successful compilation with wrong results (the worst case).

So, make sure that the order is correct.

[jski]

That brings up an interesting question: assume geometry.mod exited so
the compiler could find the required *.mod file but the modules are
misordered. So the compiler doesn't recognize the misorder and
continues compiling. Then I modify the code within geometry, so the
compiler sees geometry.mod and proceeds to compile. When it gets to
the modified code in geometry it builds a new geometry.mod file and
all in seemingly fine?

---John

[Wolfgang Kilian]

Don't count on that. Simply get the order right. If uncertain, delete
all .mod files and then compile once.

[dpb]

On 9/18/2012 8:45 AM, jski wrote:
...

> But in this case (by customer request) all the source was in 1 file.

Must have had a previous version of the module for it to have found,
then. Having previously compiled the file containing the module before
adding a USE statement could have done that or having first had the
module in another file before placing it in the one...

Any number of ways but the source for the module will have had to have
been compiled prior to the first USE of the module or the "not found"
message will happen.

--

[Gordon Sande]

The compile it twice is a hack to compensate for a dumb/lazy programmer.

The two compiles need to be one after the other with the same source
and assume that there is no deeper dependency. That might need more compiles!

If you change the code and there is an old .mod floating around you deserve
whatever happens as a result of your laziness. You will get no sympathy
from me.

I would believe you have not figured out the purpose of the .mod files if
you are thinking of playing such tricks. If you claim you are just
playing devil's
advocate then you have been a very slow learner.

The sensible policy is to always clean out the .mod files. If you are shipping
object then you will have the problem of shipping matching object and
.mod files.
Perhaps you client who wants a clean single file compile knows
something that you have
not quite groacked yet.

[Richard Maine]

Wolfgang Kilian <see...@domain.invalid> wrote:

> 2) The order of compilation does matter, because modules depend on other
> modules.

...

> Nothing of this is mentioned in the standard. The standard does not
> even mention the existence of module files, IIRC.

That part about the order of compilation mattering is alluded to in the
standard in vague terms. It doesn't say anything so clear as "order of
compilation". Heck, the standard doesn't even define a concept of
compilation in so many words.

It does say , in 11.2.1 of f2003,

"At the time a USE statement is processed, the public portions of the
specified module shall be available."

Read "processed" as roughly standard-speak for "compiled" (with emphasis
on the "roughly"). Exactly what it means for the public portions to be
"available" is not defined by the standard. But that's at least a hint
that something relating to the used module has to exist when compiling
the USE statement. There has been at least one implementation (a
horribly poorly done one for many reasons) where that just meant that
the source code for the used module was directly accessed when compiling
the USE statement. Most often, it means what you describe, that the
module is "available" when the .mod file has been created (and is in the
seach path for such files).

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

[dpb]

If the compiler can't recognize the module source has been modified,
then if the USE is before the source in the compilation order it will
have an outdated .mod file to USE...whether there's anything that's
changed in the source that matters will depend entirely on what those
changes are--if you modified an interface then it may matter a lot.

Fix the compilation order correctly; do _not_ let something like this
go--it's rife w/ hard-to-diagnose possible problems.

--

[Richard Maine]

dpb <no...@non.net> wrote:

> Fix the compilation order correctly; do _not_ let something like this
> go--it's rife w/ hard-to-diagnose possible problems.

Heck. It is asking for problems of a type I have seen plenty of times:
the programmer can't figure out why the code he is studying gives the
results that he sees... because the code he is looking at isn't actually
what ran to get those results. That can happen all kinds of ways. One of
the easiest variants is to edit the code, but fail to recompile it, so
that you are running a different version of the code than you are
looking at. There are other ways to have the same kind of error.

Another variant I have seen is to finally get a debugged and tested
version of your program, but then package up and send out the wrong
version of the source. That can make for puzzlement when the person you
send it to gets different results than you did.

Just assuming that recompiling the code multiple times will work
provides yet another path to that kind of error.

[Paul van Delst]

On 09/18/12 12:52, Gordon Sande wrote:
> The sensible policy is to always clean out the .mod files. If you are
> shipping object then you will have the problem of shipping matching
> object and .mod files. Perhaps you client who wants a clean single
> file compile knows something that you have not quite groacked yet.

You know, I would "blame" the client for this sort of dilemma.

Tools exist (e.g. makefile) that allow for dependencies to be checked
automatically if anything is modified. By specifying that all the code
has to be in one file the efficacy of those tools is curtailed ... which
suggests to me the client is, uh, not as knowledable as he/she should be.

I mean, why should they care how the delivered code is organised as long as:
1) It is easy breezy to build the executable, and
2) The results are correct.

?

Why constrain the developer?

Anyhoo...


cheers,

paulv

[Gordon Sande]

On 2012-09-18 14:24:52 -0300, Paul van Delst said:

> On 09/18/12 12:52, Gordon Sande wrote:
>> The sensible policy is to always clean out the .mod files. If you are
>> shipping object then you will have the problem of shipping matching
>> object and .mod files. Perhaps you client who wants a clean single
>> file compile knows something that you have not quite groacked yet.
>
> You know, I would "blame" the client for this sort of dilemma.
>
> Tools exist (e.g. makefile) that allow for dependencies to be checked
> automatically if anything is modified. By specifying that all the code
> has to be in one file the efficacy of those tools is curtailed ...
> which suggests to me the client is, uh, not as knowledable as he/she
> should be.
>
> I mean, why should they care how the delivered code is organised as long as:
> 1) It is easy breezy to build the executable, and

One man's "easy breezy" is another's "how in the hell do you do that?" The
assumption that the client is running a full extensive set of software
engineering
tools is a very pleasant but not very realistic dream. It may be that
the client
can not get things past the local system administrator/purchasing crowd
and having
a single file is the only "easy breezy" way that has been found to work. Been
awfully close to that and heard repetitions of the story too often!

The extreme case I once visited and heard war stories from was a drug
company that
had to keep one machine "clean" for the analysis of trials for
submitting to the
drug regulation agency. Rather sharp folks who knew both how to do
things and how
to get their products through the approval process. Somehow I would not apply
"not as knowledable as he/she should be" to that group. Not all shoes
are equally
confortable for walking.

> 2) The results are correct.
>
> ?
>
> Why constrain the developer?

Who claims to be professional and is taking money for their effort? Some things
should be very tight and others quite loose. If they only speak German they can
probably find a good German translator with experince in the field much quicker
than I could to give an instance where I would be fussy on a side issue. But I
would expect them to have considerable freedom on at least some aspects of the
content.

> Anyhoo...
>
>
> cheers,
>
> paulv

[glen herrmannsfeldt]

Richard Maine <nos...@see.signature> wrote:
> Wolfgang Kilian <see...@domain.invalid> wrote:

>> 2) The order of compilation does matter, because modules depend on other
>> modules.
> ...
>> Nothing of this is mentioned in the standard. The standard does not
>> even mention the existence of module files, IIRC.

> That part about the order of compilation mattering is alluded to in the
> standard in vague terms. It doesn't say anything so clear as "order of
> compilation". Heck, the standard doesn't even define a concept of
> compilation in so many words.

> It does say , in 11.2.1 of f2003,

> "At the time a USE statement is processed, the public portions of the
> specified module shall be available."

> Read "processed" as roughly standard-speak for "compiled" (with emphasis
> on the "roughly"). Exactly what it means for the public portions to be
> "available" is not defined by the standard. But that's at least a hint
> that something relating to the used module has to exist when compiling
> the USE statement.

So a compiler might not write the MOD file (or however it got the
data to subsequent USE) right away at the end of the module?
Possibly not until EOF on the input source file?

In that case, it might not be possible to compile a single file
containing modules and module users.

In any case, within the same file MODULEs should come before USErs
of each module.

-- glen

[Steven G. Kargl]

On Tue, 18 Sep 2012 23:03:39 +0000, glen herrmannsfeldt wrote:

> Richard Maine <nos...@see.signature> wrote:
>> Wolfgang Kilian <see...@domain.invalid> wrote:
>
>>> 2) The order of compilation does matter, because modules depend on other
>>> modules.
>> ...
>>> Nothing of this is mentioned in the standard. The standard does not
>>> even mention the existence of module files, IIRC.
>
>> That part about the order of compilation mattering is alluded to in the
>> standard in vague terms. It doesn't say anything so clear as "order of
>> compilation". Heck, the standard doesn't even define a concept of
>> compilation in so many words.
>
>> It does say , in 11.2.1 of f2003,
>
>> "At the time a USE statement is processed, the public portions of the
>> specified module shall be available."
>
>> Read "processed" as roughly standard-speak for "compiled" (with emphasis
>> on the "roughly"). Exactly what it means for the public portions to be
>> "available" is not defined by the standard. But that's at least a hint
>> that something relating to the used module has to exist when compiling
>> the USE statement.
>
> So a compiler might not write the MOD file (or however it got the
> data to subsequent USE) right away at the end of the module?
> Possibly not until EOF on the input source file?

You need to define what you mean by "write". A processor in theory
can process a module and keep the contents in memory or even
the aether. AFAIK, the standard only states that when a processor
processes a 'USE <module>' statement that whatever is needed from
<module> is available. In principle, one could build a multi-pass
processor that will recursively try to compile Fortran source
possibly repeatly skipping a scoping unit until all modules are
available.

--
steve

[glen herrmannsfeldt]

Steven G. Kargl <s...@removetroutmask.apl.washington.edu> wrote:

>> Richard Maine <nos...@see.signature> wrote:

(snip)

>>> It does say , in 11.2.1 of f2003,

>>> "At the time a USE statement is processed, the public portions of the
>>> specified module shall be available."

(snip, then I wrote)

>> So a compiler might not write the MOD file (or however it got the
>> data to subsequent USE) right away at the end of the module?
>> Possibly not until EOF on the input source file?

> You need to define what you mean by "write". A processor in theory
> can process a module and keep the contents in memory or even
> the aether.

OK, "make available." Consider an example:

module this
integer :: i=3
end module this; use this
print *,i
end

Note that the USE is on the same line as the END MODULE.

If a compiler didn't "make available" the module until it finished
processing the line (record), then it wouldn't be ready for the USE.

Previously, I considered that it wouldn't be "available" until
the end of processing the given input file (reach EOF).

> AFAIK, the standard only states that when a processor
> processes a 'USE <module>' statement that whatever is needed from
> <module> is available. In principle, one could build a multi-pass
> processor that will recursively try to compile Fortran source
> possibly repeatly skipping a scoping unit until all modules are
> available.

-- glen

[Steven G. Kargl]

On Wed, 19 Sep 2012 02:49:17 +0000, glen herrmannsfeldt wrote:

> Steven G. Kargl <s...@removetroutmask.apl.washington.edu> wrote:
>
>>> Richard Maine <nos...@see.signature> wrote:
>
> (snip)
>>>> It does say , in 11.2.1 of f2003,
>
>>>> "At the time a USE statement is processed, the public portions of the
>>>> specified module shall be available."
>
>
> (snip, then I wrote)
>
>>> So a compiler might not write the MOD file (or however it got the
>>> data to subsequent USE) right away at the end of the module?
>>> Possibly not until EOF on the input source file?
>
>> You need to define what you mean by "write". A processor in theory
>> can process a module and keep the contents in memory or even
>> the aether.
>
> OK, "make available." Consider an example:
>
> module this
> integer :: i=3
> end module this; use this
> print *,i
> end
>
> Note that the USE is on the same line as the END MODULE.
>

Think in terms of scoping unit! The semicolon marks the end of
a statement. A processor can and some do process statements.
At the conclusion of processing the 'end module' statement, the
processor knows one scoping unit is complete and parsing has
started with a new scoping unit.

--
steve

[glen herrmannsfeldt]

Steven G. Kargl <s...@removetroutmask.apl.washington.edu> wrote:

(snip, then I wrote)

>> OK, "make available." Consider an example:

>> module this
>> integer :: i=3
>> end module this; use this
>> print *,i
>> end

>> Note that the USE is on the same line as the END MODULE.

> Think in terms of scoping unit! The semicolon marks the end of
> a statement. A processor can and some do process statements.
> At the conclusion of processing the 'end module' statement, the
> processor knows one scoping unit is complete and parsing has
> started with a new scoping unit.

Yes it is a different scoping unit, but so far I haven't seen
it required that the module information be available for the
new scoping unit right away. That is the question.

There used to be, and maybe still are, some funny restrictions
on END statements, such as no continuations. That might be to
avoid problems with record boundaries and scoping units.

-- glen

[Richard Maine]

glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:

> Yes it is a different scoping unit, but so far I haven't seen
> it required that the module information be available for the
> new scoping unit right away. That is the question.

And there is no answer. The standard is deliberately vague about such
things. If you are hoping for some actual answer with specifics about
how the standard allows implementations to act in this regard, you
aren't going to get it. I see little point in speculating about what
obscure things implementations might or might not do and whether the
standard says anything about it. Because I can answer the bit about what
the standard says without hearing the speculations. Yes, the standard
allows any such behaviors you might imagine and others that you probably
can't.

The standard just has a hint that dependencies can exist. That's really
all. I quoted the entire normative material from the standard on the
subject, although I recall there was some elaboration in the section
nores in an Annex.

[glen herrmannsfeldt]

Richard Maine <nos...@see.signature> wrote:

(snip, after I wrote)

>> Yes it is a different scoping unit, but so far I haven't seen
>> it required that the module information be available for the
>> new scoping unit right away. That is the question.

> And there is no answer. The standard is deliberately vague about such
> things. If you are hoping for some actual answer with specifics about
> how the standard allows implementations to act in this regard, you
> aren't going to get it.

That is close enough for me.

> I see little point in speculating about what
> obscure things implementations might or might not do and whether the
> standard says anything about it. Because I can answer the bit about what
> the standard says without hearing the speculations. Yes, the standard
> allows any such behaviors you might imagine and others that you probably
> can't.

It is sometimes nice to have a specific example to discuss, but, yes,
it doesn't matter much either way.

> The standard just has a hint that dependencies can exist. That's really
> all. I quoted the entire normative material from the standard on the
> subject, although I recall there was some elaboration in the section
> nores in an Annex.

-- glen

[Dieter Britz]

This seems logical in a way but in fact I think it is a
weakness of the compiler. We don't have to have defined a
function, for example, before we use it, so why are modules
different?

--
Dieter Britz

[Dieter Britz]

On Tue, 18 Sep 2012 16:19:13 +0200, Wolfgang Kilian wrote:

[...]

> module b
> use module a
> ...
> end module b
>
> module a ...
> end module a
>
> a.mod will either not be available or, even worse, the compiler may read
> a file a.mod that was left over from a previous compilation. This may
> result in anything from everything ok, strange warnings, errors, to
> apparently successful compilation with wrong results (the worst case).
>
> So, make sure that the order is correct.
>
> -- Wolfgang

This seems logical in a way but in fact I think it is a

weakness of the compiler (or the Fortran definition?).

We don't have to have defined a function, for example,

before we use it, so why should modules be different?
I admit it's nice to have the module at the top, for an
easy overview of what we have up there.
--
Dieter Britz

[Dieter Britz]

On Tue, 18 Sep 2012 16:19:13 +0200, Wolfgang Kilian wrote:

This seems logical in a way but in fact I think it is a

[Dieter Britz]

On Tue, 18 Sep 2012 16:19:13 +0200, Wolfgang Kilian wrote:

[...]

> module b
> use module a
> ...
> end module b
>
> module a ...
> end module a
>
> a.mod will either not be available or, even worse, the compiler may read
> a file a.mod that was left over from a previous compilation. This may
> result in anything from everything ok, strange warnings, errors, to
> apparently successful compilation with wrong results (the worst case).
>
> So, make sure that the order is correct.
>
> -- Wolfgang

This seems logical in a way but in fact I think it is a

weakness of the compiler (or the Fortran definition?).

We don't have to have defined a function, for example,

[Dieter Britz]

On Tue, 18 Sep 2012 16:19:13 +0200, Wolfgang Kilian wrote:

This seems logical in a way but in fact I think it is a

[Richard Maine]

Dieter Britz <dieterh...@gmail.com> wrote:

> This seems logical in a way but in fact I think it is a
> weakness of the compiler (or the Fortran definition?).
> We don't have to have defined a function, for example,
> before we use it, so why should modules be different?
> I admit it's nice to have the module at the top, for an
> easy overview of what we have up there.

Because a module can have things that fundamentally affect the
compilation. So you really can't compile without it.

And yes, by the way, you do have to define the interface of a function
before you can use it, at least if the function is one that requires an
explicit interface as pretty much all newish features do. You don't have
to have the function body, but you do have to have the interface.

See submodules for how to do what amounts to the interface for a module
without filling in the body. "Interface" isn't a term the standard uses
in reference to modules, but what the standard calls something like the
"public part" or a module has much in common with interfaces.

[Dieter Britz]

On Thu, 20 Sep 2012 08:25:51 +0000, Dieter Britz wrote:


... the same thing many times. Sorry! I didn't send it
that many times. The system seemed to be hung, but was
in fact sending the message a number of times for some
reason. I did resend it once only, believinging that I had
killed the first send, which I thought was hung because
I had included too much quote.
--
Dieter Britz

[Richard Maine]

Richard Maine <nos...@see.signature> wrote:

> And yes, by the way, you do have to define the interface of a function
> before you can use it, at least if the function is one that requires an
> explicit interface as pretty much all newish features do. You don't have
> to have the function body, but you do have to have the interface.

Oops. Let me correct that before someone else does it for me. Perhaps I
shouldn't post at 1 AM just because I'm having trouble sleeping. :-)

That's the case for external functions, but not entirely so for module
or internal ones. You can forward reference a module or internal
function from within the same module or host. I've seen compilers that
didn't always get it right, but the standard allows it.

To avoid some related compiler bugs, I got in the habit of explicitly
mentioning all the module procedures up in the module scope. For public
procedures, I needed to explicitly have a public declaration anyway
because of my habit of making the default accessibility private. For any
private module procedures, I normally reinforce that default by an
explicit private declaration. Thus all my module procedures are at least
mentioned in the module scope; that seemed to be enough hint to avoid
the compiler bugs that were probably long fixed by now.

[glen herrmannsfeldt]

Dieter Britz <dieterh...@gmail.com> wrote:

(snip)

> This seems logical in a way but in fact I think it is a
> weakness of the compiler (or the Fortran definition?).
> We don't have to have defined a function, for example,
> before we use it, so why should modules be different?
> I admit it's nice to have the module at the top, for an
> easy overview of what we have up there.

You have to define a function before you use (call) it, but
not before you write the call.

Now, the standard pretty much doesn't include working such
as "compile time" and "run time" but it is still written such
as to allow them to be separate. Somethings need to be known
at compile time, such as the types of variables. Some don't,
such as the actual code for a function to be called. (Most often
done at link time, which the standard also doesn't define.)

-- glen

[Richard Maine]

You mention types of variables as something that has to be known at
compile time. I might note that applies to functions as well. You don't
need to know the inner details of the function, but you do need to know
its type (perhaps implicitly).

And although the type is a pretty important thing to know at compile
time, modules can have even more fundamental things than that. There are
cases where you need the module to even know whether something is a type
or some other sort of thing. For a simple example, consider

program main
use a_module
write (*,*) something(2)
end program

Without information from the module, you can't tell whether something(2)
is a structure constructor (when something is a type), an array element,
or a function reference.