The use -std=f202y seems like a reasonable approach to wall off experimental implementations of proposed changes to the Fortran standard. Thomas has introduced -funsigned for this purpose, which I suppose can be thought of a more fine-grained wall.
BTW, J3 passed 24-136r1.txt, which is marked as DIN-4, "Generic processing of assumed-rank objects". Malcohm Cohen is listed as the author, but he may have taken the reins from Reinhold. I believe Malcohm is the UK rep to J3. -- steve On Tue, Sep 10, 2024 at 08:49:45AM +0100, Paul Richard Thomas wrote: > 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 > > > 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 -- Steve
