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 

Bugs related to allocatable arrays as subroutine arguments

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

PostPosted: Thu Feb 29, 2024 5:40 pm    Post subject: Bugs related to allocatable arrays as subroutine arguments Reply with quote

The following test program fails to work correctly when built with FTN95 9.02.

Code:
program allocarg                 ! Expects compiler to support "(re)allocate on assignment"
   implicit none
   real, allocatable :: u(:), v(:)
!
   allocate (u(2))
   u = [1.0,2.0]
   call sub (u,v)
   print 20,'After return from SUB,    u = ',u
   print 20,'   and                    v = ',v
 20 format(1x,A,T35,2f4.1)

CONTAINS
   subroutine sub(p,q)
   implicit none
   real, dimension(:), allocatable :: p, q
!
   if (allocated(p)) print 10,'p is allocated, size = ',size(p)
   if (allocated(q)) print 10,'q is allocated, size = ',size(q)

   q = p*3  ! q is not allocated earlier, but allocate-on-assignment makes statement OK

   print 20,'After assigning q = p*3, v = ',v
 10 format(1x,A,T35,2i4)
 20 format(1x,A,T35,2f4.1)
   return
   end subroutine
end program


The expected output:

Code:
 p is allocated, size =              2
 After assigning q = p*3, v =     3.0 6.0
 After return from SUB,    u =     1.0 2.0
    and                    v =     3.0 6.0


When compiled by FTN95, with or without /64, the program runs into "Access Violation: attempted to write to location 00000000.

When compiled with /check, the 32-bit EXE aborts with " Nonconformant arrays on line 20", and the 64-bit EXE built with /check gives the output:
Code:
              p is allocated, size =              2
              After assigning q = p*3, v =
              After return from SUB,    u =     1.0 2.0
              and                       v =

Note the blanks in the last output line after "v =".

When the program is built with /debug and run in SDBG/SDBG64, more defects are seen.

When line-6 has been executed, U is shown in the Variables pane of SDBG64 as "REAL*4 POINTER :: (2)" , and V is shown as "NULL [REAL*4 POINTER :: (Subscripts not valid)]". A user may prefer to have allocatable arrays treated not in terms of pointers but in terms of attributes such as "allocated", "size", etc. (even if pointers underlie the compiler's implementation of allocatable arrays).

On compilation with /debug and entering SUB in SDBG-32, P is shown in the Variables pane as REAL*4 (4214812:8429624).
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7924
Location: Salford, UK

PostPosted: Tue Mar 19, 2024 2:03 pm    Post subject: Reply with quote

mecej4

Thank you for this bug report which I some how missed.
Back to top
View user's profile Send private message AIM Address
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