soccer jersey forums.silverfrost.com :: View topic - Program hangs on entering ASSOCIATE construct
forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Program hangs on entering ASSOCIATE construct

 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support
View previous topic :: View next topic  
Author Message
mecej4



Joined: 31 Oct 2006
Posts: 1897
PostPosted: Fri Feb 16, 2024 4:51 pm    Post subject: Program hangs on entering ASSOCIATE construct Reply with quote
When an "associate name" is used as an actual argument in order to pass an array section to a subprogram, FTN95 may generate code that hangs or quits abruptly, even when the /check or /undef options are used. This problem occurs with 32- as well as 64-bit EXEs.

Here is a reproducer (100 lines source + an unformatted input data file about 200 K in size, in two versions - one for FTN95, and the other for compilers that use 4-byte record markers for Fortran unformatted sequential files).

https://www.dropbox.com/scl/fi/3k5jbwaawxnlexn7vpvx6/grist.zip?rlkey=va7n5ro733atugkig3kgwhqpq&dl=0

The zip file contains instructions to build and run using (a) FTN95 and (b) another compiler, e.g., Gfortran.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8018
Location: Salford, UK
PostPosted: Sat Feb 17, 2024 8:54 am    Post subject: Reply with quote
mecej4

Many thanks for the feedback. I have made a note of your report.
Back to top
View user's profile Send private message AIM Address
mecej4



Joined: 31 Oct 2006
Posts: 1897
PostPosted: Sat Feb 17, 2024 2:01 pm    Post subject: Reply with quote
Paul, here is a shorter reproducer that also generates its own input data instead of reading a large input data file.

Code:
program gcgtst         ! demonstrates bug(s) related to ASSOCIATE
   implicit none
   integer, parameter :: kdp = kind(0.0d0)
   integer nrn, nbn, nxyz, i, j
   real (kind=kdp), allocatable :: rhs(:), xx(:), w(:), rr(:), va(:, :)
   integer, allocatable :: ci(:, :)

   call getint(nrn) ! get integer in range 1-9999 from command line argument
   nbn = nrn
   nxyz = nrn+nbn
   allocate (rhs(nxyz), xx(nxyz), va(7,nxyz), ci(6,nxyz), w(nbn), rr(nbn))
   do i = 1, nxyz
      xx(i) = real(i)/nxyz
      va(:,i) = [(j*xx(i), j=1,7)]
   end do
   ci = 0
   call gcgr()

contains
   subroutine getint(n)
      use iso_fortran_env
      implicit none
      integer, intent(out) :: n
      character(len=4) :: str
      character(len=1), parameter :: sl = '/'

      if(command_argument_count() .eq. 1)then
         call get_command_argument(1, str)
         read (str,'(I4)')n
      else
         n = 80
      endif
      print '(a,A1,a,A1,4x,i5)', compiler_version(),sl, compiler_options(),sl,n
      return
   end subroutine getint

   subroutine gcgr()
      implicit none
      integer nrnp1

      nrnp1 = nrn + 1
      associate (rhs_r => rhs(1:nrn), rhs_b => rhs(nrnp1:nxyz), &  ! rhs_r and rhs_b never used again
        xx_b => xx(nrnp1:nxyz))                                    ! undef. var. reported here!
         rr = 0.0
         call armult(w, rr)      ! w is never used again; this call could be commented out, but that kills bug
         call dbmult(rr, xx_b)
      end associate
      print '(1x,5ES12.4)', rr(1:min(5,nbn))
      return
   end subroutine gcgr

   subroutine dbmult(x, y)
      implicit none
      real (kind=kdp), dimension (:), intent (out) :: x
      real (kind=kdp), dimension (:), intent (in)  :: y
      integer :: i, j

      do i = 1, nbn
         j = i + nrn
         x(i) = y(i)*va(7, j)
      end do
   end subroutine dbmult

   subroutine armult(x, y)
      implicit none
      real (kind=kdp), dimension (:), intent (out) :: x
      real (kind=kdp), dimension (:), intent (in)  :: y
      integer :: i, ii, j, jcol
      real (kind=kdp) :: s

      do i = 1, nbn
         ii = i + nrn
         s = 0.0_kdp
         do j = 1, 6
            jcol = ci(j, ii)
            if (jcol>0) s = s + va(j, ii)*y(jcol)   ! never executed since ci = 0
         end do
         x(i) = s                                   ! when ci == 0, x(:) is set to 0
      end do
   end subroutine armult

end program

[post limit reached, continued in next post]
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1897
PostPosted: Sat Feb 17, 2024 2:04 pm    Post subject: Reply with quote
[continued from previous post]
This program may be compiled and linked with several compiler options. The compiled program may be run with one command line argument -- an integer from 1 to 9999. If no argument is provided, the program uses 80. The program is bug free (as far as I know, after testing with other compilers with checking turned on). Here are a few of the peculiar symptoms displayed:
    Display compiler information, results (5 real numbers) and terminate (expected, normal)
    Display compiler information and hang
    Display compiler information, results and hang
    Display pop-up for access violation
    If compiled with /undef, flag spurious error (undefined variable used) with pop up window.

The last item merits some discussion. I think that the compiler implements ASSOCIATE by making a temporary copy. While doing so, if /undef has been specified, making the copy triggers "undefined". Strictly speaking, the user's program did not itself access the undefined variable, but passed a reference to it. The NAG compiler, with -C=undefined, seems to agree.

These circumstances are rather tough to negotiate for the compiler, so users need to be forgiving, I think. On the other hand, if the compiler knows that copy-in/copy-out is something to which it cannot reliably apply /undef checking, perhaps it could skip that checking for just those lines of code that trigger copy-in/copy out.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8018
Location: Salford, UK
PostPosted: Mon Feb 19, 2024 8:30 am    Post subject: Reply with quote
mecej4

Many thanks for the new code which is a great help.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 8018
Location: Salford, UK
PostPosted: Wed Feb 28, 2024 10:19 am    Post subject: Reply with quote
FTN95 does not currently implement pointers to array sections within an ASSOCIATE statement. This feature has now been added for the next release of FTN95 but it has not yet been tested on the above code.

p.s. The above test program appears to run successfully.
Back to top
View user's profile Send private message AIM Address
mecej4



Joined: 31 Oct 2006
Posts: 1897
PostPosted: Wed May 15, 2024 1:46 am    Post subject: Reply with quote
Update on 19 May 2024:

The two test programs posted above (grist.f90 and gcgtst.f90) work correctly with FTN95 version 9.03.

Thanks to Silverfrost for enhancing the compiler to enable the ASSOCIATE construct to work with arrays.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Support All times are GMT + 1 Hour
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group