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 <s...@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 < > 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 >
N2230.pdf
Description: Adobe PDF document
real :: x(2,2,2)
real, parameter :: xp(*) = [1,2,3,4,5,6,7,8]
x = reshape (xp, [2,2,2])
call my_sub (x)
if (any (reshape (x, [8]) .ne. xp(8:1:-1))) stop 1
contains
subroutine my_sub (arg)
real, target, contiguous :: arg(..)
real, allocatable :: y(:)
real, pointer :: argp(:,:)
integer :: i
if (size (arg) .ne. 8) stop 10
! Check reshape
y = reshape (arg, [size (arg)])
if (any (y .ne. xp)) stop 20
! Check pointer assignment
argp(1:2,1: size(arg)/2) => arg
if (size (argp) .ne. size (x)) stop 30
if (any ((argp) .ne. reshape (x, [2, size (x)/2]))) stop 31
! Check ASSOCIATE
i = size (arg)
associate (a(1:2,1:i/2) => arg)
if (any (a .ne. argp)) stop 40
end associate
associate (a(1:size(arg)) => arg)
if (any (a .ne. xp)) stop 41
a = a(8:1:-1)
end associate
end
end
