PRs 88052 and 88190

[Paul Richard Thomas]

Hi All,

This correspondence touches on something that I was going to raise - how do
we incorporate experimental F202Y features?

The reason that I ask is that Reinhold Bader proposed extensions to the
processing of assumed rank objects, which became a DIN proposal to WG5 -
see attached. It made so much sense to me that, in June, I wrote an
experimental implementation. The experimental implementation added the
reshape intrinsic as well as allowing remapped pointer assignment and
associate. A testcase is attached.

In the intervening three months the experimental patch developed bit-rot to
the extent that two chunks would no longer apply. For this reason, I am
very reluctant to set up a separate branch that would have to be
synchronised over a good number of years before 202y becomes the new
standard. Additionally, the array descriptor reform branch suffered so
badly from this that I gave up on it. I propose that we introduce
-std=F202Y, which will prevent experimental F202Y features from being used
unless this standard is selected. That way they remain in mainline and are
readily identifiable for pruning come the day or maintenance as the F202Y
proposals develop. If this is not acceptable, I will open a PR in which
experimental patches can be stashed. Given previous experience, my
preference is very much for the former!

I have also drafted much of the standardese, relative to F2003, and I
suggest that, in memory of Reinhold, this continue as a DIN
proposal. @Thomas, are you willing to carry this forward or should I
transfer it to being a UK proposal?

Best regards

Paul


On Mon, 9 Sept 2024 at 18:34, Steve Kargl <sgk@troutmask.apl.washington.edu>
wrote:

> On Mon, Sep 09, 2024 at 12:26:53AM -0700, Damian Rouson wrote:
> > On Sat, Sep 7, 2024 at 22:26 Steve Kargl <
> sgk@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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://gcc.gnu.org/pipermail/fortran/attachments/20240910/9eaf366d/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: N2230.pdf
Type: application/pdf
Size: 97513 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/fortran/attachments/20240910/9eaf366d/attachment-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.f90
Type: text/x-fortran
Size: 889 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/fortran/attachments/20240910/9eaf366d/attachment-0001.bin>