2

Please look at the following code:

program test
implicit none

  integer, allocatable :: v1(:, :)
  integer, allocatable :: v2(:, :)

  allocate(v1(2, 4))
  allocate(v2(2, 3))
  v1(:, :) = reshape([11, 12, 13, 14, 15, 16, 17, 18], [2, 4])
  v2(:, :) = reshape([21, 22, 23, 24, 25, 26], [2, 3])

  print *, v1
  print *, 'shape(v1): ', shape(v1)
  print *
  print *, v2
  print *, 'shape(v2): ', shape(v2)
  print *

  v2 = v1

  print *, v1
  print *, 'shape(v1): ', shape(v1)
  print *
  print *, v2
  print *, 'shape(v2): ', shape(v2)
  print *

  deallocate(v1)
  deallocate(v2)
end program test

When I compile it with gfortran, I get the following output:

11         12         13         14         15         16         17         18
shape(v1):            2           4

21         22         23         24         25         26
shape(v2):            2           3

11         12         13         14         15         16         17         18
shape(v1):            2           4

11         12         13         14         15         16         17         18
shape(v2):            2           4

When I compile it with ifort, I get the following output:

11         12         13         14         15         16         17         18
shape(v1):            2           4

21         22         23         24         25         26
shape(v2):            2           3

11         12         13         14         15         16         17         18
shape(v1):            2           4

11         12         13         14         15         16
shape(v2):            2           3

which one is reliable? is there a bug in ifort or in gfortran?

gfortran version 4.8.1
ifort version 14.0.0

hamid attar
  • 388
  • 1
  • 8
  • 3
    Did you [compile with `-assume realloc-lhs`](https://stackoverflow.com/q/22313883)? – francescalus Jun 23 '15 at 14:49
  • No I did not. I used the 'check' options of the compiler, but no error was reported in either case. – hamid attar Jun 23 '15 at 14:52
  • 1
    If you do use that option (with ifort) do you get the results you expect? – francescalus Jun 23 '15 at 15:00
  • Yes I do :) thanks for the very exact answer. – hamid attar Jun 23 '15 at 15:21
  • The program should fail and be terminated without the option in ifort. Do I miss something? – Vladimir F Героям слава Jun 23 '15 at 18:34
  • 1
    @VladimirF Without that option ifort seemingly doesn't check the shape of the arrays either (the question is consistent with my previous observations). Ignoring this runtime check and the Fortran standard seems to be the most awkward for the end user. [Prompting a search for the `-assume correct-addition` option required so that `0+0` evaluates as `0`.] – francescalus Jun 23 '15 at 20:09
  • I'm also confused about this difference. So I always put colon(s) explicitly in the lhs, such that v2(:,:) = v1, when I want to make a simple copy of array elements (with no new allocation). – roygvib Jun 23 '15 at 22:19
  • @roygvib I prefer to use explicit colons too when possible. But there are cases for example when the allocatable is a member of a derived data type A. Then by assigning the objects of A one must be sure what happens to the internal allocatables. – hamid attar Jun 25 '15 at 05:24

1 Answers1

4

By default, ifort before version 17 does not use Fortran 2003 semantics for reallocating an allocatable type on the left side of an assignment. The ifort 15 manual has this to say (for the default norealloc-lhs assumption):

The compiler uses Standard Fortran rules when interpreting assignment statements. The left-hand side is assumed to be allocated with the correct shape to hold the right-hand side. If it is not, incorrect behavior will occur.

To allow the left side of the assignment to be reallocated to the proper shape, compile with the option -assume realloc-lhs. Alternatively you can compile with -standard-semantics to make all assumptions default to compliance with the Fortran 2003 standard, with some Fortran 2008 features.

casey
  • 6,855
  • 1
  • 24
  • 37