[Bug fortran/54687] Use gcc option machinery for gfortran

[manu at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54687

Manuel López-Ibáñez <manu at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|44054                       |

--- Comment #5 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Tobias Burnus from comment #4)
> At least all warnings should be handled now (work done as part of PR44054
> and in the separate but related commit r218188).
> 
> Is there still something missing?

Note that the options machinery has ways to encode String->Enum options, so
things like gfc_handle_coarray_option and the handling of OPT_finit_real_ are
redundant (and others).

(Personally, I think the way to describe such options in the .opt file is a bit
ugly, but incremental improvements like your '||' patch are possible)

The options machinery can also handle Alias options transparently such as
OPT_fdump_fortran_original and OPT_fdump_parse_tree.

Also, my intuition tells me that any explicit handling of optimization options
that does not use the common machinery such as:

  if (gfc_option.flag_protect_parens == -1)
    gfc_option.flag_protect_parens = !optimize_fast;

  if (gfc_option.flag_stack_arrays == -1)
    gfc_option.flag_stack_arrays = optimize_fast;

will at some moment, if not already, miss any automatic merging of optimization
options for LTO or automatic setting via #pragma and attribute "optimize"
https://gcc.gnu.org/onlinedocs/gcc/Function-Specific-Option-Pragmas.html (see
also generated file options-save.c)

In the future, it would be ideal to have separate option structs for
FE-specific options, such that not all FEs have to see all options from all
other FEs. Although moving options from gfc_option_t to the globally generated
option struct may seem a step backward in that respect, it is actually a step
forward, since those separated structs should be generated directly from the
*.opt files. 

Finally, most, if not all, of gfc_option_t and gfc_handle_option seems
redundant given the features of opt files (and the possibility of improving the
generators). There is the chance to remove a lot of code from the Fortran FE,
which should be always a good thing, no?

But ultimately, this is up to the Fortran devs. This doesn't block PR44054
anymore since all the warning flags have been moved.