Loading...

fortran@gcc.gnu.org

[Prev] Thread [Next]  |  [Prev] Date [Next]

[gfortran, RFC] A few issues that need a decision FX Tue Mar 31 11:02:39 2009

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.