On Mon, Sep 9, 2024 at 10:10 AM Janne Blomqvist
<blomqvist.ja...@gmail.com> wrote:
>
> 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.

The C and C++ frontends use -pedantic and -pedantic-erros for this,
they accept a subset of extensions even with -std=c++20 and only
with -pedantic are strict and give warnings while -pedantic-errors
makes those diagnostics errors.

I would expect -std=legacy to cover extensions that people should avoid
when writing new code and -std=legacy generally be combined with
an old fortran standard (usually even F77 I guess)?

Richard.

> --
> Janne Blomqvist

Reply via email to