Silverfrost Forums

Welcome to our forums

MOVE_ALLOC - error 984

2 Feb 2025 9:17 #31893

The following program P1 runs as expected, returning the output shown.

program p1
use iso_fortran_env
implicit none
real, allocatable :: a(:), temp(:)
print*, compiler_version()
print*
allocate(a(2))
a = [1.0,2.0]
print*, 'a after allocate and assignment' 
print*, a
print*
allocate(temp(4))
temp(1:2) = a
temp(3) = 3.0
temp(4) = 4.0
print*, 'temp after allocate and assignment'
print*, temp
print*
call move_alloc(temp,a)
print*, 'after move_alloc'
print*, 'allocated(temp) = ', allocated(temp)
print*, 'allocated(a)    = ', allocated(a)
print*
print*, 'a after move_alloc'
print*, a
end program p1

 FTN95 v9.06.0

 a after allocate and assignment
      1.00000         2.00000

 temp after allocate and assignment
      1.00000         2.00000         3.00000         4.00000

 after move_alloc
 allocated(temp) =   F
 allocated(a)    =   T

 a after move_alloc
      1.00000         2.00000         3.00000         4.00000

The second program P2 below has the declaration of a and temp in a module, which is used by the main program, otherwise all other executable statements in P2 are the same as P1.

module data_mod
real, allocatable :: a(:), temp(:)
end module data_mod

program p2
use data_mod
use iso_fortran_env
implicit none
print*, compiler_version()
print*
allocate(a(2))
a = [1.0,2.0]
print*, 'a after allocate and assignment' 
print*, a
print*
allocate(temp(4))
temp(1:2) = a
temp(3) = 3.0
temp(4) = 4.0
print*, 'temp after allocate and assignment'
print*, temp
print*
call move_alloc(temp,a)     ! ### error 984
print*, 'after move_alloc'
print*, 'allocated(temp) = ', allocated(temp)
print*, 'allocated(a)    = ', allocated(a)
print*
print*, 'a after move_alloc'
print*, a
end program p2

When compiled, the following error is generated error 984 - DATA_MOD cannot appear here as it has been used in a USE statement as a MODULE name

The error message does not seem to be sensible in the context of the code, and I cannot see anything wrong with the code.

Adding IMPLICIT NONE to the module changes the error message at the same line to error 174 - Unexpected '!' in expression

I recall that we discussed various ways of extending an array in a pervious post:

https://forums.silverfrost.com/Forum/Topic/4384&postdays=0&postorder=asc&highlight=movealloc&start=0

John's program from Wed Jan 31, 2024 no longer runs with the present 9.06 FTN - which is a change. error 84 - Name of END SUBROUTINE is not the same as the name of the matching SUBROUTINE ('END SUBROUTINE EXTEND_ALLOC_AUTO' instead of 'EXTEND_ALLOC_AUTO') Compilation or linking failed.

3 Feb 2025 7:18 #31895

Thanks Ken. I have made a note of this.

I can't see a program from John dated 31 January. The one that I can see with subroutine extend_alloc compiles correctly for me.

3 Feb 2025 7:57 #31897

This bug has now been fixed for a future release of FTN95 but will probably not get into v9.10. In the mean time MOVE_ALLOC cannot be used with module variables.

3 Feb 2025 10:46 #31898

Paul,

Thanks for the fix. That will simplify the recursive function in the arcing program!.

Re John's program. Here is a reduced version which generates error 84.

As USE ISO_FORTRAN_ENV is removed, with autocheck enabled in Plato an error is reported at the line with the call to MOVE_ALLOC in extend_alloc_move. Autocheck reports 'Absolute address is not recognised in keyword allocate' which seems to refer to the previous line.

If the call to MOVE_ALLOC is commented out the program will compile (but generate a runtime error which is to be expected).

If the unused subroutine extend_alloc_move is commented out, the program runs as expected.

The error persists in the case where A is not passed as a dummy argument to the subroutines.

I am now not 100% sure that I tested the original program with a previous version of FTN95.

Devilry at its best I think.

program extend
  implicit none
  real, allocatable :: a(:)

    call extend_alloc_auto ( a, 5000 )
    print*, size(a), a(size(a))

contains

  subroutine extend_alloc_move ( a, nn )     ! using move_alloc

!  extend vector A by nn using auto-allocate

    integer, intent(in) :: nn
    real, allocatable, intent(inout) :: a(:)
    real, allocatable :: extra(:)
    real, allocatable :: copy(:)
    integer :: i
    
    extra = [ (0.0, i=1,nn) ]
    if ( allocated (a) ) then
       call move_alloc ( a, copy )
       a = [ copy, extra ]
    else
       a = extra
    end if
    write (*,*) 'extend_alloc_move', size(a)

  end subroutine extend_alloc_move
  

  subroutine extend_alloc_auto ( a, nn )     ! using auto-allocate

!  extend vector A by nn using auto-allocate

    real, allocatable, intent(inout) :: a(:)
    integer, intent(in) :: nn
    real, allocatable :: extra(:)
    real, allocatable :: copy(:)
    integer :: i
    
    extra = [ (0.0, i=1,nn) ]
    if ( allocated (a) ) then
       a = [ a, extra ]
    else
       a = extra
    end if
    write (*,*) 'extend_alloc_auto', size(a)

  end subroutine extend_alloc_auto

end program extend
3 Feb 2025 11:59 #31899

Ken

This code fails for me and I don't know why at the moment. It may relate to the fact that the MOVE_ALLOC is being applied to an argument.

I have logged this for investigation.

8 May 2025 9:40 #32104

When using the current developers' version of FTN95 this code fails because of the presence of MOVE_ALLOC even though MOVE_ALLOC is not called.

Pending further investigation, the use of MOVE_ALLOC for an argument in a contained routine has been disabled.

9 Jul 2025 2:44 #32212

This failure has now been fixed for the next release of FTN95.

8 Dec 2025 7:15 #32539

This is purely for FYI in case anybody experiences similar error messages: I tried using Move_Alloc from within a module subroutine on a variable Used from another module, and the subsequent function or subroutine would generate a spurious error message. For example, if I had a function called foo, the error message would be:

error 84 - Name of END FUNCTION is not the same as the name of the matching FUNCTION ('END FUNCTION FOO' instead of 'FOO')

I was using FTN95 version 9.10.

Please login to reply.