On Mon, Sep 09, 2024 at 12:26:53AM -0700, Damian Rouson wrote:
> On Sat, Sep 7, 2024 at 22:26 Steve Kargl <s...@troutmask.apl.washington.edu>
> wrote:
>
> > On Sat, Sep 07, 2024 at 08:17:42PM -0700, Jerry D wrote:
> >
> >
> > I personally would like to see -std=f2023 made the default.
>
> I would absolutely love that too. I’ve lost countless hours chasing down
> issues (in other compilers) that didn’t make standard behavior the default.
>
> > Any, and all, extensions would require an explicit option to
> > accept the non-standard Fortran construct.
>
> This would be awesome.
>
> > Unfortuantely, the -std=gnu ship sailed years ago.
>
> What makes it a closed issue?
>
POLA
As Janne mentioned, INTEGER*4 etc would lead to significant traffic
in fortran@ and bugzilla about breaking people's code. Back in
2004, when I started contributing to gfortran development, the
prevailing thought was "if g77 accepted it, then gfortran should
also accept it" for backwards compatibility. Here, 'it' was a
large number of vendor extensions. Some have been put behind options
such as Cray pointers and DEC Fortran extensions.
% grep GFC_STD_GNU gcc/fortran/*.cc | wc -l
340
There are 340 occurences of GFC_STD_GNU that we would need to review
to determine what to do (e.g., a new option or put it under the blank
-std=legacy). 338 of these occur in the front-end before the red-black
trees are translated to tree-ssa and handled to the middle-end.
Perhaps, an opportunity for lurkers on the list to get involve with
a simple review of the code.
Consider,
data x/1/
data x/42/ ! <-- Should be an error
print *, x
end
The above compiles without a warning (even if -Wall -Wextra
-Wsurprising are used).
% gfcx -c -std=f2018 a.f90
a.f90:2:12:
2 | data x/42/
| 1
Error: GNU Extension: re-initialization of 'x' at (1)
When Thomas introduced the ability to build interfaces, he had to
include the -fallow-argument-mismatch option. When I reworked
gfortran's BOZ code, I added -fallow-invalid-boz. There were a few
annoyed users. They had a choice: use an option to compile their
code or fix thier code. Many people chose the former, and now Makefiles
all over the internet are enshired with these options.
The ship has sailed. I think Harald's response sums up what
needs to happen, and I agree with him. Use caution when moving
an extension under -std=legacy. A request to add a new extension,
which is not on a path to standardization, will likely get little
attention.
--
Steve
