https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88190
Bug ID: 88190
Summary: compile_options.allow_std does not allow to
distinguish between GFC_STD_GNU and GFC_STD_LEGACY
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: dominiq at lps dot ens.fr
Target Milestone: ---
While playing with pr88052 I have found that the value of
compile_options.allow_std passed to libgfortran is the same (4095) when
compiling with -std=gnu or -std=legacy.
I suspect this is the same at the frontend level.
IMO the value should be 4095-64 (no backward compatibility) when the code is
compiled with -std=gnu so that we can distinguish between -std=gnu and
-std=legacy.
Presently the only way to distinguish is through compile_options.warn_std set
to 0 when the code is compiled with -std=legacy. Since compile_options.warn_std
is non-zero if the code is compiled with -pedantic, the condition
(compile_options.warn_std == 0) is false with -std=legacy -pedantic. This may
be expected, but is surprising.
Note that the gfortran manual says
-pedantic
Issue warnings for uses of extensions to Fortran. -pedantic also applies to
C-language constructs where they occur in GNU Fortran source files, such as use
of ‘\e’ in a character constant within a directive like #include.
Valid Fortran programs should compile properly with or without this option.
However, without this option, certain GNU extensions and traditional Fortran
features are supported as well. With this option, many of them are rejected.
Some users try to use -pedantic to check programs for conformance. They soon
find that it does not do quite what they want—it finds some nonstandard
practices, but not all. However, improvements to GNU Fortran in this area are
welcome.
This should be used in conjunction with -std=f95, -std=f2003, -std=f2008 or
-std=f2018.
The wording could probably be improved.
