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 

Difference between WIN32 and X64

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



Joined: 18 May 2012
Posts: 697
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Fri May 21, 2021 4:07 pm    Post subject: Difference between WIN32 and X64 Reply with quote

The following code demonstrates a difference between WIN32 and X64.

It runs correctly under WIN32 printing out:
    1.0000
    10.000
    100.00

When compiled and run using X64 the printout is incorrect:
    1.0000
    1.0000
    100.00


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
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


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

PostPosted: Fri May 21, 2021 5:01 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
Kenneth_Smith



Joined: 18 May 2012
Posts: 697
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Sat May 22, 2021 9:51 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
PaulLaidler
Site Admin


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

PostPosted: Sat May 22, 2021 1:12 pm    Post subject: Reply with quote

Ken

Thanks. I have made a note of this.
Back to top
View user's profile Send private message AIM Address
PaulLaidler
Site Admin


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

PostPosted: Wed Jun 30, 2021 8:02 am    Post subject: Reply with quote

The first issue in this thread has now been fixed for the next release of FTN95.
Back to top
View user's profile Send private message AIM Address
JohnCampbell



Joined: 16 Feb 2006
Posts: 2551
Location: Sydney

PostPosted: Sat Jul 03, 2021 7:12 am    Post subject: Reply with quote

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
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2551
Location: Sydney

PostPosted: Sat Jul 03, 2021 7:46 am    Post subject: Reply with quote

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


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

PostPosted: Sat Jul 03, 2021 7:51 am    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
JohnCampbell



Joined: 16 Feb 2006
Posts: 2551
Location: Sydney

PostPosted: Sat Jul 03, 2021 9:24 am    Post subject: Reply with quote

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


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

PostPosted: Wed Jul 21, 2021 2:34 pm    Post subject: Reply with quote

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
View user's profile Send private message AIM Address
Kenneth_Smith



Joined: 18 May 2012
Posts: 697
Location: Hamilton, Lanarkshire, Scotland.

PostPosted: Thu Jul 22, 2021 5:06 pm    Post subject: Reply with quote

Thanks, Paul, I look forward to using this new capability.
Back to top
View user's profile Send private message Visit poster's website
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