Module array defined using transpose/reshape

If you compile and run the following program with FTN95:

module t
implicit none
integer :: rgb1(2,3)= transpose(reshape([ &
       1,  2,  3, &
       4,  5,  6 ], shape=[3,2]))
end module t

program p
use t
implicit none
integer :: i, j

  do i = 1, 2
    print*, (rgb1(i,j), j=1,3)
  end do
  
end program p

you will find that the results returned are:

            0           0           0
            0           0           0

The output should be:

           1           2           3
           4           5           6

When rgb1 is not a global/module variable the modified program below returns the expected result:

program p
implicit none
integer :: rgb1(2,3)= transpose(reshape([ &
       1,  2,  3, &
       4,  5,  6 ], shape=[3,2]))
integer :: i, j

  do i = 1, 2
    print*, (rgb1(i,j), j=1,3)
  end do
  
end program p

Ken

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

Paul,

The example above was created by pruning back the following code. This code (which is a stand alone module) fails at compile time when initialising the two arrays.

module test
implicit none
integer :: viridis_rgb(20,3) = transpose(reshape([ &
       68,  1,  84, &
       64,  38,108, &
       60,  66,135, &
       55,  91,160, &
       50, 114,176, &
       47, 136,183, &
       43, 156,182, &
       38, 175,172, &
       44, 190,155, &
       68, 201,138, &
       93, 211,122, &
      122, 218,109, &
      152, 224, 98, &
      182, 227, 89, &
      213, 230, 81, &
      236, 233, 74, &
      248, 232, 64, &
      251, 221, 55, &
      253, 206, 45, &
      253, 231, 37  &
      ], shape=[3,20]))
integer :: inferno_rgb(20,3) = transpose(reshape([ &
       0,   0,   4, &
      31,  12,  72, &
      63,  26, 112, &
      88,  44, 137, &
     114,  67, 161, &
     141,  91, 180, &
     168, 118, 198, &
     193, 145, 212, &
     217, 174, 223, &
     237, 201, 232, &
     249, 225, 238, &
     252, 239, 244, &
     253, 248, 249, &
     254, 254, 251, &
     252, 254, 245, &
     249, 251, 236, &
     244, 247, 224, &
     238, 240, 210, &
     231, 232, 194, &
     231, 231, 176  &
     ], shape=[3,20]))
end module test


Access violation:
The instruction at address 004f44bf attempted to read from location 0029295d
004f43a1 do_all_initialisations(void)#46 [+011e]

004f4657 ProcessVariables(int,int,<ref>int) [+0d82]

004155d7 handle_token(<ptr>char,int,int,int,int,<ref>int) [+0f33]

0040627a ProcessEntireLine(void) [+06c8]

004071fa compile(<ptr>char) [+016f]

0040181d main [+058e]

eax=00000000   ebx=00acc344   ecx=0029295d
edx=00030000   esi=0411be9f   edi=03d77230
ebp=03d7734c   esp=03d77220   IOPL=0
ds=002b   es=002b   fs=0053
gs=002b   cs=0023   ss=002b
flgs=00210212 [NC OP NZ SN DN NV]
0372/7020 TSTK=6 [ ]
004f44bf  mov      eax,[ecx]

004f44c1  mov      [ebp-0x10],eax

Compilation completed with no errors.

If the definition of inferno_rgb is commented out this does not occur. If the definition of viridis_rgb is commented, retaining inferno_rgb it does occur.

Ken

Thanks for the additional information.

At the moment FTN95 can't handle the compile time call to TRANSPOSE...

module t
integer,parameter::rgb1(2,3) = transpose(reshape([1,2,3,4,5,6],shape=[3,2]))
end module t

when rgb1 is a module parameter.

For the moment alternative coding must be used such as not using a module definition or manually reordering the linear array.

This issue has now been fixed for the next release of FTN95.