Compiler abort with /64 /undef

The subroutine source below has been drastically pared down, so it is definitely not going to run meaningfully even though it has correct syntax. With /undef or other options, 32-bit compilations run fine. With /64 /undef, the current compiler aborts after attempting to read from address 0x00000018.

subroutine plqdb1(nf, ix, ic, ica, h, idecf, eta2)
   implicit none
   integer, parameter :: double = kind(0.d0)
   integer  :: nf,idecf,ix(*),ic(*),ica(*)
   real(double) , intent(in) :: eta2
   real(double), dimension(*)  :: h
!-----------------------------------------------
   integer :: nca, ncr, j, inf,  kc
   real(double) :: temp
   integer , allocatable :: kc1u(:), k1u(:)
!-----------------------------------------------
   if (idecf == 0) then
      temp = eta2
      call mxdpgf (nf, h, inf, temp)
      idecf = 1
   endif
   if (nca > 0) then
      allocate(k1u(nca),kc1u(nca))
      kc1u = ica(:nca)
      where (kc1u > 0)
         k1u = ic(kc1u)
      elsewhere
         k1u = ix((-kc1u))
      end where
   endif
   ncr  = ncr - nca
   nca  = nca - 1
   do j = 1, nca
      kc = ica(j)
      if (kc > 0) then
         ic(kc) = -ic(kc)
      else
         kc     = -kc
         ix(kc) = -ix(kc)
      endif
   end do
   return
end subroutine plqdb1

mecej4

Thank you for the feedback. I have logged this for investigation.

The failure concerns the line

k1u = ix((-kc1u))

where there is something wrong with the temporary array for -kc1u.

A work-around would be to switch off /UNDEF for this subroutine or alternatively, copy -kc1u into your own temporary array.

This failure arises from the fact that FTN95 is not able to process vector subscripts in the context of a WHERE construct. I assume that the authors of FTN95 simply did not anticipate this construction.

Pending a fix for this issue, the response from FTN95 will be to acknowledge this limitation.

This will also apply to https://forums.silverfrost.com/Forum/Topic/3846.

Paul,

Each new temporary array that is introduced to overcome this limitation may require the addition of declaration, allocation and deallocation statements for that array.

In other threads we had discussed the feature of automatic allocation on assignment, which is allowed in more recent versions of standard Fortran, and automatic deallocation at subprogram exit. Having this feature in FTN95 would make the usage of additional temporary arrays less of a chore.

mecej4

Having this feature in FTN95...

Does this refer to vector subscripts within a WHILE construct?

My first thought was that a temporary work-around would involve replacing WHILE by DO with IF.

No, Paul, I meant the feature that causes a variable declared as ALLOCATABLE to become allocated when a value is assigned to it. The details are spelled out in the Fortran 2018 Standard ( Section 9.7.1.3, 'Allocation of allocatable variables' ).

The feature allows us to have allocation and deallocation take place automatically. The above subroutine could be rewritten as shown below; I have marked lines that cause automatic allocation with '!AA'.

When the subroutine is entered, the variables kc1u, k1u, mkcnu are unallocated. Returning from the subroutine causes these variables to be deallocated.

subroutine plqdb1(nf, ix, ic, ica, h, idecf, eta2)
   implicit none
   integer, parameter :: double = kind(0.d0)
   integer  :: nf,idecf,ix(*),ic(*),ica(*)
   real(double) , intent(in) :: eta2
   real(double), dimension(*)  :: h
!-----------------------------------------------
   integer :: nca, ncr, j, inf,  kc
   real(double) :: temp
   integer , allocatable :: kc1u(:), k1u(:), mkcnu(:)
!-----------------------------------------------
...
   if (nca > 0) then
      kc1u = ica(:nca) !AA
      mkcnu = -kc1u   !AA
...
  return
end subroutine plqdb1

mecej4

Again just to clarify, 'allocate on assignment' was added to FTN95 at v8.70.

Whether or not it works or is useful in this context remains to be seen.

The root cause of this particular failure is not (as I first thought) the minus sign (and hence the need for a temporary array) but rather the fact that the array index is a vector subscript.

At the moment FTN95 can't process vector subscripts in the context of a WHERE construct.

Ah, I had not noticed that 'allocate on assignment' was present in 8.70 -- I downloaded the new version quite recently. I'll try it out on examples that use this feature.

Thanks.

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