On Sun, Sep 8, 2024 at 10:37 PM Harald Anlauf <anl...@gmx.de> wrote:
> The default ("-std=gnu") is IMHO *not* a real standard; it merely
> describes the set of Fortranish-looking stuff (including standard
> stuff) that is handled by gfortran if no -std= is given and then
> gives *no* warning.
>
> A way forward I could imagine is triaging the differences between
> what is accepted by default (i.e. -std=gnu) and the real standard,
> and if we think that extension should for some reason be downgraded
> to -std=legacy, then we do that.  (E.g. if it violates a constraint,
> then it is a primary candidate.)  That would allow a smooth, although
> slow, transition to better compile-time diagnostics.
>
> That said, having no real (since undefined) gnu standard, would offer
> the option that the runtime should see either -std=legacy being passed,
> or a real -std=f20xy would enforce standard-conforming behavior.
> I currently see no sense in having a special -std=gnu in the runtime:
> either standard (with warning/error), or legacy (silent unless hard
> error).  Or does anyone see a point differentiating gnu/legacy here?

Back in the day, IIRC the intention was that std=gnu would include
extensions that are per se not dangerous and do not conflict with
standard semantics. E.g. extra intrinsic procedures. The std=legacy
was for stuff which changes the standard semantics, or is otherwise
error-prone and dangerous. At some point we discussed whether std=gnu
should be split up similar to how the C and C++ frontends do it, with,
say, -std=gnu2003 would mean F2003 + GNU extensions but in the end
that wasn't done as there seemed to be no real demand for such a
thing. There is probably some virtue in being able to distinguish
between "benign" extensions and dangerous ones, though there might be
improvements to be made of how the bitflags are handled and passed to
the runtime.

I can sympathize with the desire to make the standard behavior the
default, but the reality is probably that you'll drown in bug reports
if something like INTEGER*8 becomes a compile-time error by default.

-- 
Janne Blomqvist

Reply via email to