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<mailto: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<mailto: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
