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 

Compiler abort with /64 /undef

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



Joined: 31 Oct 2006
Posts: 1483

PostPosted: Mon Dec 07, 2020 3:38 pm    Post subject: Compiler abort with /64 /undef Reply with quote

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.

Code:
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
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Mon Dec 07, 2020 5:32 pm    Post subject: Reply with quote

mecej4

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

The failure concerns the line

Code:
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.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


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

PostPosted: Mon Jan 11, 2021 12:42 pm    Post subject: Reply with quote

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 http://forums.silverfrost.com/viewtopic.php?t=4315.
Back to top
View user's profile Send private message AIM Address
mecej4



Joined: 31 Oct 2006
Posts: 1483

PostPosted: Tue Jan 12, 2021 3:00 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Tue Jan 12, 2021 9:20 am    Post subject: Reply with quote

mecej4

Quote:
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.
Back to top
View user's profile Send private message AIM Address
mecej4



Joined: 31 Oct 2006
Posts: 1483

PostPosted: Tue Jan 12, 2021 11:14 am    Post subject: Reply with quote

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.

Code:
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
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Tue Jan 12, 2021 1:42 pm    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message AIM Address
mecej4



Joined: 31 Oct 2006
Posts: 1483

PostPosted: Tue Jan 12, 2021 5:01 pm    Post subject: Reply with quote

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.
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 -> 64-bit 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