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.
