Hi Hugh, well, there are a number of features in Fortran I/O which make it difficult to allow full recursive I/O. An example I know from a clf posting:
open( 10, file = ;'dump.bin', form = 'unformatted' ) write( 10 ) (f(i), i = 1,n) close( 10 ) Unformatted files often use an encoding such that the start of a record contains the number of bytes. If the function f() would write to the same file, that number could not be deduced from the mere statement itself. Of course compilers differ in their capabilities of checking these occurrences. Regards, Arjen Op di 28 apr. 2020 om 14:01 schreef Hugh Sasse <h...@dmu.ac.uk>: > Ah, yes, that would explain it. Thank you, Arjen. I thought the > arguments were being built in the way you suggested I do that, i.e., before > the write function call, so it would not count as recursion, so the > possibility did not occur to me. > (I tried looking at the assembler output, but have not done enough > assembly for many years for that to help!) > > Thank you, > Hugh > ------------------------------ > *From:* Arjen Markus <arjen.markus...@gmail.com> > *Sent:* 28 April 2020 10:54 > *To:* Hugh Sasse <h...@dmu.ac.uk> > *Cc:* msys2-users@lists.sourceforge.net <msys2-users@lists.sourceforge.net > > > *Subject:* Re: [Msys2-users] gfortran hangs if I add write statements. > > > This message was sent from outside of DMU. Please do not click links or open > attachments unless you recognise the source of this email and know the > content is safe. > > Hi Hugh, > > it is a problem with the recursive I/O that you introduce this way. > Fortran (at least up to a very recent standard and even then there are > restrictions) does not allow for such things, in this case: the write > statement in the main program that invokes the function f() and inside that > function (via the subroutine g) you write to the console. > Intel Fortran is more permissive and the program runs fine when I compile > it with that compiler. > > Changing the write statement to: > > p1 = f() > p2 = f(42) > write(*,*) p1, p2 > > produces the results you would expect. > > So this is more a matter of the fine details of the Fortran standard than > something odd in MinGW/MSYS2 or Cygwin. (Probably more useful to post such > questions to comp.lang.fortran :)). > > Regards, > > Arjen > > Op di 28 apr. 2020 om 12:16 schreef Hugh Sasse <h...@dmu.ac.uk>: > > Hello, > > I'm exploring Fortran 2008, having done most of my Fortran in IV and 77, > and some on 90/95 more recently. In exploring optional arguments I have > come to this case, where testing the results of the example in the GNU > Fortran manual for PRESENT works, until I add WRITE statements. When I add > them the program hangs. > > [machine name and path elided from the copy and paste below] > > > $ make > gfortran -o test_present_with_select.exe -Wall -Wextra -Wargument-mismatch > -Wcompare-reals -Wdeprecated -Wdo-subscript -Wmisleading-indentation > -Woverflow -Wsuggest-attribute=pure -Wunused -Wzerotrip > test_present_with_select.f08 -lm > gfortran -o test_present_with_select2.exe -Wall -Wextra > -Wargument-mismatch -Wcompare-reals -Wdeprecated -Wdo-subscript > -Wmisleading-indentation -Woverflow -Wsuggest-attribute=pure -Wunused > -Wzerotrip test_present_with_select2.f08 -lm > > > $ ls > Makefile test_present_with_select2.exe > test_present_with_select.exe test_present_with_select2.f08 > test_present_with_select.f08 > > $ ./test_present_with_select.exe > F T > > > $ ./test_present_with_select2.exe > > > [<ctrl-C> pressed here] > $ cat -n test_present_with_select.f08 > 1 PROGRAM test_present > 2 WRITE(*,*) f(), f(42) ! "F T" > 3 CONTAINS > 4 LOGICAL FUNCTION f(x) result(answer) > 5 INTEGER, INTENT(IN), OPTIONAL :: x > 6 call g(present(x), answer) > 7 END FUNCTION > 8 > 9 subroutine g(x, y) > 10 logical, intent(in) ::x > 11 logical, intent(out)::y > 12 select case(x) > 13 case(.true.) > 14 y = .true. > 15 case(.false.) > 16 y = .false. > 17 end select > 18 end subroutine > 19 END PROGRAM > > $ cat -n test_present_with_select2.f08 > 1 PROGRAM test_present > 2 WRITE(*,*) f(), f(42) ! "F T" > 3 CONTAINS > 4 LOGICAL FUNCTION f(x) result(answer) > 5 INTEGER, INTENT(IN), OPTIONAL :: x > 6 call g(present(x), answer) > 7 > 8 END FUNCTION > 9 > 10 subroutine g(x, y) > 11 logical, intent(in) ::x > 12 logical, intent(out)::y > 13 select case(x) > 14 case(.true.) > 15 y = .true. > 16 write (*,*) "true" > 17 case(.false.) > 18 y = .false. > 19 write (*,*) "false" > 20 end select > 21 end subroutine > 22 END PROGRAM > $ > > I obtained the same results when I used the compiler from the mingw site. > I've not put Cygwin on here, so have not tried it. > (I used the -n option of cat to make the discussion of where my bug is a > bit easier, hopefully that won't make it too annoying to reproduce.) > I can't square getting no errors from the compiler with the different > results. If I've done something basically wrong here, I'd have expected it > to have been picked up with these warning options. > > I'm running Windows 10 on an Intel Core-i5 system with 8GB of ram, if that > helps. > > Can someone see why I'm barking up the wrong tree here? Is this even > reproducible by other people? I'm reluctant to hypothesize a compiler > bug, and I don't have any other (non-gnu) compilers with which to falsify > that, so it would be superstition, not science 🙂 > > Thank you, > Hugh > > _______________________________________________ > Msys2-users mailing list > Msys2-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/msys2-users > > _______________________________________________ > Msys2-users mailing list > Msys2-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/msys2-users >
_______________________________________________ Msys2-users mailing list Msys2-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/msys2-users
