[gfortran, RFC] A few issues that need a decision

[FX <fxcoudert at gmail dot com>]

Hi all,

Having some time today I did some triaging in our bugzilla, and have  
encountered a few issues that really need some sort of high-level  
decision to be taken (and I thought stage 1 was the right moment for  
that). Thus, and because I have not read the list for some time, I  
thought the most efficient way I could help would be to prepare a sort  
of briefing to help the discussion, with lists of pros and cons,  
status of other compilers and opinions already expressed. I also  
propose a course of action for each item, not to impose my view but as  
a way to get the discussion started.

So, please make your opinion & comments known, and forgive me if any  
of these issues was already decided and/or if my presentation is  
missing some elements that I'm not aware of.

Regards,
FX

------------------------------------------------------


PR 35707 -- Do we want to put /usr/include and /usr/local/include in  
gfortran's search patch for modules and INCLUDE'd files?

Pros:
  - some distros put header files and modules there; I see fftw3.f,  
netcdf.mod, typesizes.mod, netcdf.inc
  - we already search for #include'd files in these directories
Cons:
  - .mod files are arch-dependent (think -m32/-m64) and don't belong  
in a non-arch directory like /usr/include
  - .mod files are compiler-dependent (and version-of-compiler- 
dependent), so they belong in compiler-specific directories
  - we already have a directory designed for module files (/usr/lib/ 
gcc/$target/$version/finclude)

Status of other compilers: YES for g95, NAG, ifort.
Opinions so far: NO for Mikael Morin, FX and Daniel Franke

What I propose: YES for INCLUDE'd files, NO for module files

------------------------------------------------------


PR 39178 -- Do we want to generate main() from the front-end rather  
than using a main in libgfortran?

Advantages of emitting main() from the front-end:
  - "gcc *.o -lgfortran -lmain" will then work
Advantages of keeping a MAIN__():
  - in gdb, declare MAIN__() as main program, avoiding the user  
stepping through libgfortran's initialization routines
  - codes that try to provide their own main(), and call MAIN__(),  
will continue to work
Things we break:
  - codes that provide a MAIN__(), link with gfortran, and expect  
their MAIN__() to be called; I don't think it's very common
  - people who link in libgfortranbegin explicitly; I find only a few  
occurences of that by

Status of other compilers:
  - Sun generates a MAIN_() and a main()
  - Intel has its main() in a private object file, that it adds to  
command line
Opinions so far: not sure

What I propose:
  1. Have the front-end generate MAIN__() and main(), have main() do  
the initialization (by a single function in libgfortran, instead of  
the store_exe_path/set_args duo).
  2. Either we remove libgfortranbegin altogether, or we remove its  
content and keep it as an empty static library, allowing for user  
Makefiles with "-lgfortranbegin". (The second is a kludge but sounds  
better to me, and rather harmless.)

------------------------------------------------------


PR 38830 / PR 20618 -- Do we want to add "Variable Format Expression",  
i.e. formats like '(<n>I4.0)'

Pros:
  - It's a legacy features, some compilers support it.
Cons:
  - It's a legacy feature
  - It has questionable semantics
  - It was submitted for standardization, but rejected
  - It is not too widely used (we haven't been asked to implement it  
very often)
  - There are many others way to do this (using format strings, and  
either internal writes or character-by-character manipulation).

Status of other compilers: YES for Intel and Portland, NO for g95
Opinions so far: all against

What I propose: NO, and add some documentation about alternatives in  
the "Extensions not implemented in GNU Fortran" section of our doc.

------------------------------------------------------

PR 35385 -- Do we want gfortran to perform COCO-preprocessing?

Pros:
  - It's part of the standard
  - We only need to change the driver to call Dan Nagle's GPL  
implementation and hand over the result to the compiler itself
Cons:
  - Users can compile and run coco directly, for example from a  
Makefile (it's already what our doc says)
  - Tobias Burnus said on IRC that the committee is considering  
dropping it

Status of other compilers: NO as far as I know
Opinions so far: a lot of people (including me) used to be in favour  
in the past, don't know now (I, for one, changed my mind)

What I propose: keep the doc, close the PR as WONTFIX, and let the few  
coco users run it themselves.