User account creation filtered due to spam.

Bug 39178

Summary: Generate main() rather than using a main in libgfortran/fmain.c
Product: gcc Reporter: Tobias Burnus <burnus>
Component: fortranAssignee: Tobias Burnus <burnus>
Severity: enhancement CC: d, gcc-bugs
Priority: P3    
Version: 4.4.0   
Target Milestone: ---   
Host: Target:
Build: Known to work:
Known to fail: Last reconfirmed: 2009-05-26 19:32:26
Bug Depends on: 36825    
Bug Blocks:    

Description Tobias Burnus 2009-02-13 14:43:51 UTC
Topic brought up on #gfortran by Janne.

There are some potential issues in using main.c in a library; thus one should have only link a "main()" if the *.o files don't have a "main".

See also:

The solution of SUN is to generate for PROGRAM not only a "MAIN_" but also a main() which does the initialization and calls then MAIN_. ("MAIN_" should be present for backward compatibility.)

I think we could do likewise, especially as the code is rather short (libgfortran/fmain.c):

main (int argc, char *argv[]) {
  store_exe_path (argv[0]);
  set_args (argc, argv);
  MAIN__ (); /* The Fortran PROGRAM */
  return 0;

Intel's solution is to link "for_main-o", but that is not as elegant as for "ifort *.o" one needs to specify "-nofor-main" if there is a non-fortran C library.

 * * *

Independent of all, I think one should document the gfortran_init() functions to make the full library functions available even if the "main()" program is written in C. Besides
  store_exe_path (argv[0]);
  set_args (argc, argv);
(which should be combined to one function) one also has

 * * *

Marked as depending on the array descriptor stuff as with the ABI break one can get also rid of fmain.c's main(). It might also help with -fwhole-program (cf. PR fortran/26682) as a "main()" shouldn't be optimized away ;-)
Comment 1 Tobias Burnus 2009-02-13 14:57:15 UTC

 * * *

> Intel's solution is to link "for_main-o", but that is not as elegant as for
> "ifort *.o" one needs to specify "-nofor-main" if there is a non-fortran C

The last line should read: 'if there is a non-fortran "main()"'.

  * * *

Regarding MAIN__:
- gdb assumes that this is the main function for Fortran programs; as gfortran now sets "main_program_symbol" this might be not an issue.
- For stepping through the code, having a separate MAIN_ avoids that the user enters libgfortran for the initialization, which can be a bit confusing.
Comment 2 Tobias Burnus 2009-02-13 15:11:44 UTC
Note: Moving main() to f951 will break programs which assume that MAIN__ will be called, compile e.g. the following program with gcc:
#include <stdio.h>
int MAIN__( int argc, char* argv[] )
{printf("argc is %i:0 %s\n", argc,argv[0]);
 printf("argc is %i:1 %s\n", argc,argv[1]);
and link it with gfortran. If you run it, MAIN__ will be executed and by some magic the arguments are passed to MAIN__.  (That the arguments are available is a complete puzzle to me.) -- Found in c.l.f thread linked above.
Comment 3 Tobias Burnus 2009-05-20 06:01:20 UTC
Comment 4 Tobias Burnus 2009-05-26 21:20:12 UTC
Subject: Bug 39178

Author: burnus
Date: Tue May 26 21:19:57 2009
New Revision: 147883

2009-05-26  Tobias Burnus  <>

        PR fortran/39178
        * gfortranspec.c (lang_specific_driver): Stop linking
        * trans-decl.c (gfc_build_builtin_function_decls): Stop
        making MAIN__ publicly visible.
        (gfc_build_builtin_function_decls): Add
        (create_main_function) New function.
        (gfc_generate_function_code): Use it.

2009-05-26  Tobias Burnus  <>

        PR fortran/39178
        * runtime/main.c (store_exe_path): Make static
        and multiple-times callable.
        (set_args): Call store_exe_path.
        * libgfortran.h: Remove store_exe_path prototype.
        * fmain.c (main): Remove store_exe_path call.


Comment 5 Tobias Burnus 2009-05-27 07:29:30 UTC
FIXED on the trunk (4.5).

Regarding libgfortranbegin.a, see PR 40267.