[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Regarding Fortran Compiler Characteristics

From: Tobias Burnus
Subject: Re: Regarding Fortran Compiler Characteristics
Date: Sat, 30 May 2009 13:11:19 +0200
User-agent: Thunderbird (X11/20090310)

Hello Ralf,

As a quick summary:

a) I think AC_FC_MAIN/AC_F77_MAIN does the right thing, but the
documentation - especially the example - is misleading. (And it is of no
harm but of little use with all(?) newer compilers.)

b) A test to find out how the library initialization function is called
would be useful.

Ralf Wildenhues wrote:
>> There one can find for AC_FC_MAIN/AC_F77_MAIN:
>> [...]
>>           int F77_MAIN(int argc, char *argv[]);
> AFAIU you are saying that for these compilers: [....]
> calling this special function is not necessary, but it also is no
> problem at all if the user does this; right?

Well, not quite. I think using

FC_MAIN(argc, argv);

will presumably never fully work.

a) Assuming that you don't have a Fortran main PROGRAM but only a stack
of procedures written in Fortran. Then MAIN__ is not defined and one
tries to call an undefined symbol. (linking error)

b) The call will work, if you have a Fortran main PROGRAM but then the
arguments are likely to be ignored. Additionally, the call might be not
possible, if the Fortran compiler generates main(argc,argv) alongside
MAIN__() as some compilers do. Besides, it does not make conceptionally
sense to have a Fortran main PROGRAM and, e.g., a C "main()" program.

c) The symbol FC_MAIN can be useful, if the you have a Fortran library
which also contains a "main()", which calls e.g. MAIN__ as you then get
linking errors, unless you provide a stub. I think this is the only real
legitimate use of FC_MAIN. With all compilers I know, this is not an
issue as they either have "main" in a separate library, in a separate .o
file or generate main() along MAIN__. However, I don't want to rule out
that such compilers still exists, which have main() in the same library
as the rest.

Thus regarding FC_MAIN, I think the configure check and also the
documentation is OK, except for the example where passing "(argc, argv)"
is misleading: The arguments are likely to get ignored and calling
MAIN__ is also a doubtful exercise. (Do you have a C or a Fortran main
program? If the former, one should change PROGRAM to SUBROUTINE in Fortran.)

* * *

The other point was: It would be indeed useful to provide an AC_* to
find out which initialization function to call, if one has e.g. a C main
program and calls some Fortran routines. That is rather an omission that
a bug of autoconf, but related to the misleading MAIN__(argc,argv)
example above. And to the misleading text in the comment, see below.

* * *

> Well, there are many more Fortran compilers and systems out there,
> and the MAIN__ was definitely required for some of them at some point.
Well, MAIN__ still exists in many compilers do to backward
compatibility; I think only NAG f95 does not have it.

I think is goes back to the time when it was seen to be easier to have a
complicated "main()" function in the library which does some
initialization and then calls the actual Fortran program ("MAIN__"). I
don't quite see why they not simply generated a "main()" for the Fortran
program and then did as first action an initialization call to the
library. But due to this history, most compilers have a MAIN__.

> The macro has this in the comment:
> # What is technically happening is that the Fortran libraries provide
> # their own main() function, which usually initializes Fortran I/O and
> # similar stuff, and then calls MAIN__, which is the entry point of
> # your program.
That is still the case, except that main() might not only be in the
library, but can also be in another .o file or be generated along the
MAIN__ function.

> # Usually, a C program will override this with its own
> # main() routine, but the linker sometimes complain if you don't
> # provide a dummy (never-called) MAIN__ routine anyway.
I think that does not happen anymore with newer Fortran libraries; they
usually have "main()" not in the standard lib<fortran>.{a,so} file but
separately. That means if you link lib<fortran>.so along with some
Fortran routines (*.o) you should not have the need to provide a MAIN__

> # Of course, programs that want to allow Fortran subroutines to do
> # I/O, etcetera, should call their main routine MAIN__() (or whatever)
> # instead of main().  A separate autoconf test (_AC_FC_MAIN) checks
> # for the routine to use in this case (since the semantics of the test
> # are slightly different).  To link to e.g. purely numerical
> # libraries, this is normally not necessary, however, and most C/C++
> # programs are reluctant to turn over so much control to Fortran.  =)

That is quite incomprehensible and I think at least partially wrong. If
I understand it correctly, it is about having a "main()" which is
written e.g. in C but one accesses a few Fortran procedures
(subroutines, functions). In this case MAIN__ should not be available
(no Fortran main PROGRAM but just SUBROUTINEs/FUNCTIONs). And as written
above, the library is initialized using different calls and not by a
call to MAIN__ (which was never part of the library).

> # The name variants we check for are (in order):
> #   MAIN__ (g77, MAIN__ required on some systems; IRIX, MAIN__ optional)
> #   MAIN_, __main (SunOS)
> #   MAIN _MAIN __MAIN main_ main__ _main (we follow DDD and try these too)

That looks ok. You can also add gfortran, sunf95, ifort to the list
which have a MAIN__; but at least those three don't need a stub MAIN__.

> Also, have you tried or looked at the Sun Studio, IBM, Portland,
> PathScale Fortran compilers?

No, I didn't check the documentation. I know that Sun Studio puts the
PROGRAM into MAIN__ (for backward compatibility) and generates a
"main()" alongside. Conceptionally it does not make any sense to have
(a) a MAIN__ without having a Fortran main PROGRAM and (b) passing the
arguments to MAIN__ to initialize the Fortran library.

For the name of the initialization functions, one should look at the
documentation; I'm sure they have some function to do so.

> If OTOH calling this other main function poses a problem for gfortran,
> then we would need to do something about this (most likely: file a bug
> report with gfortran for breaking backward compatibility :-).

Well, calling MAIN__ at some arbitrary point poses a problem for all
Fortran compilers which I know as it is expected that MAIN__ is only
called once at the beginning of the program and not several times. (I'm
sure that one can also produce some strange results if one calls
"main()" in C several times.) Though it probably won't break in the
library but in the user code. And I sincerely doubt that there was any
Fortran compiler which generated a MAIN__ which read the argc/argv
arguments - or at least I cannot see any use of doing so. It does not
make sense if the actual "main()" is in the library.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]