 |
forums.silverfrost.com
Welcome to the Silverfrost forums
|
| View previous topic :: View next topic |
| Author |
Message |
Kenneth_Smith
Joined: 18 May 2012
Posts: 753
Location: Hamilton, Lanarkshire, Scotland.
|
 Posted: Fri May 21, 2021 4:07 pm Post subject: Difference between WIN32 and X64 |
 |
|
The following code demonstrates a difference between WIN32 and X64.
It runs correctly under WIN32 printing out:
When compiled and run using X64 the printout is incorrect:
| Code: |
module data_mod
implicit none
type winreal
real :: val = 1.0
end type winreal
type(winreal) :: r(1)
contains
subroutine init
r(1)%val = 10.0
end subroutine init
end module data_mod
program main
use data_mod
print*, r(1) ! Value printed should be 1
call init
print*, r(1) ! Value printed should be 10 since value changed by subroutine INIT
r(1)%val = 100.0
print*, r(1) ! Value printed should now be 100
end program main |
|
|
| Back to top |
|
 |
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8087
Location: Salford, UK
|
| Posted: Fri May 21, 2021 5:01 pm Post subject: |
|
|
Ken
Thank you for the bug report. The failure relates to the initialisation within the TYPE declaration. Also it appears to be a regression between v8.66 and v8.70.
For the moment a work-around is to avoid initialisation within a TYPE declaration. |
|
| Back to top |
|
|
Kenneth_Smith
Joined: 18 May 2012
Posts: 753
Location: Hamilton, Lanarkshire, Scotland.
|
| Posted: Sat May 22, 2021 9:51 am Post subject: |
|
|
Thanks Paul.
Here is another, possibly related one for you to look at.
The new allocate on assignment feature runs into problems when the allocated array is within a derived type (for both win32 and x64).
In the code below, the size of the allocated array is returned incorrectly and when attempting to print the contents of the array a subscript out of bounds errors occur.
Perhaps this is to be expected and I am pushing the new feature beyond its intended use?
| Code: | program test
implicit none
type point
real x, y
end type point
type polygon
type(point), allocatable :: p(:) ! Replace this line with:
! type(point) p(3)
! and the code runs without error
end type polygon
integer i
type(polygon) triangle
triangle = polygon([point(0.0,0.0),point(3.0,0.0),point(0.0,4.0)])
print*, size(triangle%p)
do i = 1, size(triangle%p), 1
print*, triangle%p(i)%x, triangle%p(i)%y
end do
end program test |
|
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8087
Location: Salford, UK
|
| Posted: Sat May 22, 2021 1:12 pm Post subject: |
|
|
Ken
Thanks. I have made a note of this. |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8087
Location: Salford, UK
|
| Posted: Wed Jun 30, 2021 8:02 am Post subject: |
|
|
| The first issue in this thread has now been fixed for the next release of FTN95. |
|
| Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006
Posts: 2601
Location: Sydney
|
| Posted: Sat Jul 03, 2021 7:12 am Post subject: |
|
|
Paul,
I tried to understand what was the problem with the derived type not being updated.
It appears that
- if the derived type is referenced it is recognised as to be updated following a call, but
- if the derived type is in scope (via a module) it is not recognised as to be updated following a call.
Was this the problem ?
Is this an optimisation effect ?
although I used plato with x64 and CheckMate
I am interested as I am using derived types in modules and in scope via use, but have not noticed this problem.
In scope via contains looks to be a different copy of the derived type ?
I also thought that "print*, r(1)" was not allowed in F95, but "print*, r(1)%val" would be required, although this also fails in a similar way.
The following extension of Ken's code reproduces the problem and shows if the derived type is an argument to a called routine, the problem does not appear.
| Code: | module data_mod
implicit none
type winreal
sequence
integer :: n = 1.0
real :: val = 1.0
end type winreal
type(winreal) :: r(1)
contains
subroutine init (val)
real :: val
r(1)%n = r(1)%n + 1
r(1)%val = val ! 10.0
print*, r(1), ' init to 10'
end subroutine init
subroutine increase_r
r(1)%n = r(1)%n + 1
r(1)%val = r(1)%val * 10.0
print*, r(1),' increase_r by 10'
end subroutine increase_r
subroutine nl
write (*,*) "~"
end subroutine nl
end module data_mod
program main
use data_mod
integer :: i
call nl
print*, r(1) ! Value printed should be 1
do i = 1,3
call increase_r
print*, r(1), 'main DoR' ! Value printed should be 10,100,1000 since value changed by subroutine Increase_R
end do
print*, r(1)%val, 'main end DoR' ! Value printed should be 10,100,1000 since value changed by subroutine Increase_R
call nl
call init (2.0)
print*, r(1), 'main init' ! Value printed should be 10 since value changed by subroutine INIT
do i = 1,3
call increase_a (r)
print*, r(1), 'main DoA' ! Value printed should be 20,200,2000 since value changed by subroutine Increase_A
end do
call nl
call init (10.0)
print*, r(1), 'main init' ! Value printed should be 10 since value changed by subroutine INIT
r(1)%val = 100.0
print*, r(1), 'main 100' ! Value printed should now be 100
end program main
subroutine increase_a (a)
use data_mod
type(winreal) :: a(1)
write (*,*) ' ',a
a(1)%n = a(1)%n + 1
a(1)%val = a(1)%val * 10.0
print*, a(1),' increase_a by 10'
end subroutine increase_a |
I notice that for my example a%n (and r%n) do not increment as I would hope. Is this a related problem or is this non-conforming use of a%n ?
{see run below}
Last edited by JohnCampbell on Sat Jul 03, 2021 7:55 am; edited 1 time in total |
|
| Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006
Posts: 2601
Location: Sydney
|
| Posted: Sat Jul 03, 2021 7:46 am Post subject: |
|
|
| Code: | [FTN95/x64 Ver. 8.74.0 Copyright (c) Silverfrost Ltd 1993-2021]
[Current options] 64;CHECKMATE;ERROR_NUMBERS;IMPLICIT_NONE;INTL;LINK;LOGL;
[SLINK64 v3.02, Copyright (c) Silverfrost Ltd. 2015-2021]
Loading c:\temp\forum\lgotemp@.obj
Creating executable file ftn95_mod.exe
~
1 1.00000
2 10.0000 increase_r by 10
1 1.00000 main DoR
3 100.000 increase_r by 10
1 1.00000 main DoR
4 1000.00 increase_r by 10
1 1.00000 main DoR
1.00000 main end DoR
~
5 2.00000 init to 10 { module copy of r }
1 1.00000 main init
1 1.00000 { this is a local copy from main ? }
2 10.0000 increase_a by 10
2 10.0000 main DoA
2 10.0000
3 100.000 increase_a by 10
3 100.000 main DoA
3 100.000
4 1000.00 increase_a by 10
4 1000.00 main DoA
~
6 10.0000 init to 10 { back to module copy of r }
4 1000.00 main init
4 100.000 main 100
|
|
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8087
Location: Salford, UK
|
| Posted: Sat Jul 03, 2021 7:51 am Post subject: |
|
|
John
The LOC of r(1)%val, when printed from the module was different from the LOC when printed from the main program.
It concerned the way in which the variable is stored when the TYPE has initialised data.
The fix should be included in the latest FTN95 available via the "Sticky post". |
|
| Back to top |
|
|
JohnCampbell
Joined: 16 Feb 2006
Posts: 2601
Location: Sydney
|
| Posted: Sat Jul 03, 2021 9:24 am Post subject: |
|
|
Thanks Paul,
I had proceeded to using LOC.
Removing default initialised type fixes the address error I was seeing.
I rarely use initialised derived types which explains why I have not seen this error. (old habits about avoiding large .exe files)
I should proceed to Ver 8.75 !
Thanks for the further explaination.
John |
|
| Back to top |
|
|
PaulLaidler
Site Admin
Joined: 21 Feb 2005
Posts: 8087
Location: Salford, UK
|
| Posted: Wed Jul 21, 2021 2:34 pm Post subject: |
|
|
| The second issue on this thread [with type(polygon) triangle etc.] has now been fixed for the next version of FTN95 (after 8.80). |
|
| Back to top |
|
|
Kenneth_Smith
Joined: 18 May 2012
Posts: 753
Location: Hamilton, Lanarkshire, Scotland.
|
| Posted: Thu Jul 22, 2021 5:06 pm Post subject: |
|
|
| Thanks, Paul, I look forward to using this new capability. |
|
| 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
