 |
forums.silverfrost.com
Welcome to the Silverfrost forums
|
| View previous topic :: View next topic |
| Author |
Message |
mecej4
Joined: 31 Oct 2006
Posts: 1896
|
 Posted: Mon Dec 07, 2020 3:38 pm Post subject: 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.
| 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 |
|
 |
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8012
Location: Salford, UK
|
| Posted: Mon Dec 07, 2020 5:32 pm Post subject: |
|
|
mecej4
Thank you for the feedback. I have logged this for investigation.
The failure concerns the line
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 |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8012
Location: Salford, UK
|
| Posted: Mon Jan 11, 2021 12:42 pm Post subject: |
|
|
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 |
|
|
mecej4
Joined: 31 Oct 2006
Posts: 1896
|
| Posted: Tue Jan 12, 2021 3:00 am Post subject: |
|
|
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 |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8012
Location: Salford, UK
|
| Posted: Tue Jan 12, 2021 9:20 am Post subject: |
|
|
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 |
|
|
mecej4
Joined: 31 Oct 2006
Posts: 1896
|
| Posted: Tue Jan 12, 2021 11:14 am Post subject: |
|
|
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 |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8012
Location: Salford, UK
|
| Posted: Tue Jan 12, 2021 1:42 pm Post subject: |
|
|
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 |
|
|
mecej4
Joined: 31 Oct 2006
Posts: 1896
|
| Posted: Tue Jan 12, 2021 5:01 pm Post subject: |
|
|
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 |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8012
Location: Salford, UK
|
| Posted: Fri Aug 06, 2021 10:28 am Post subject: |
|
|
| This failure in FTN95 has now been fixed for the next release. |
|
| Back to top |
|
|
|
|
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
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
