Silverfrost Forums

Welcome to our forums

Difference between WIN32 and X64

21 May 2021 3:07 #27830

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

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
21 May 2021 4:01 #27832

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.

22 May 2021 8:51 #27834

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?

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
22 May 2021 12:12 #27835

Ken

Thanks. I have made a note of this.

30 Jun 2021 7:02 #28024

The first issue in this thread has now been fixed for the next release of FTN95.

3 Jul 2021 6:12 (Edited: 3 Jul 2021 6:55) #28043

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.

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 ?

3 Jul 2021 6:46 #28045
[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
3 Jul 2021 6:51 #28046

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'.

3 Jul 2021 8:24 #28047

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

21 Jul 2021 1:34 #28108

The second issue on this thread [with type(polygon) triangle etc.] has now been fixed for the next version of FTN95 (after 8.80).

22 Jul 2021 4:06 #28111

Thanks, Paul, I look forward to using this new capability.

Please login to reply.