Created attachment 27159 [details]
Fortran source file with minimal example to reproduce the descibed behaviour

ICE Confirmed with 4.6, 4.7 and trunk.

I think the test case is invalid in F03, but should be valid in F08: It makes use of pointer functions as lvalue, which is PR40054.

However, it does not just use a 'plain' pointer function, but even a pointer-valued (and dimensionful) type-bound procedure. Phew. Thanks for the nice test case :)

> pointer-valued (and dimensionful) type-bound procedure. Phew. 
> Thanks for the nice test case :)

That's what I've got trying to reimplement quite verbosely a piece of C++ code in Fortran :)
Sylwester

Just out of curiosity: Are you aware of any compiler which swallows this?


Here is a slightly reduced test case, which gives the same ICE:

module adv
  implicit none

  type adv_t
  contains
    procedure, nopass :: left_halo
  end type 

contains

  function left_halo (arr)
    real, intent(in), dimension(:), pointer :: arr
    real, dimension(:), pointer :: left_halo
    left_halo => arr(-1:-1)
  end function

end module

program test
  use adv
  implicit none

  real, dimension(:), pointer :: arr
  class(adv_t), allocatable :: a

  allocate(adv_t::a)
  allocate(arr(-1:5))

  arr(-1) = 666
  print*, a%left_halo(arr)

  a%left_halo(arr) = -666  ! ICE

end program

(In reply to comment #3)
> That's what I've got trying to reimplement quite verbosely a piece of C++ code
> in Fortran :)

That seems like a rare intention. There are certainly more people doing it the other way around ;)

(In reply to comment #4)
> Here is a slightly reduced test case, which gives the same ICE:

Note #1: When commenting out the 'ICE' line, compilation goes through and running the program yields the output:

   666.000000

I.e. it prints only one number, where it actually should print three.

(In reply to comment #4)
> Here is a slightly reduced test case, which gives the same ICE:

Note #2: When changing "class(adv_t)" into "type(adv_t)", one gets:

  a%left_halo(arr) = -666
  1
Error: 'left_halo' at (1) is not a VALUE

> Just out of curiosity: Are you aware of any compiler which swallows this?

No. I've just tried it with PGI (pgf95) but it chokes on "contains" "within a
derived type definition".

>> That's what I've got trying to reimplement quite verbosely a piece of C++ code
>> in Fortran :)
>
> That seems like a rare intention. There are certainly more people doing 
> it the other way around ;)

Indeed, but there're also lots of people (around me) dead sure of Fortran being
faster than anything :)

> I.e. it prints only one number, where it actually should print three.

Isn't arr(-1:-1) meaning a[-1], i.e. just one element? 

Sylwester

(In reply to comment #8)
> > Just out of curiosity: Are you aware of any compiler which swallows this?
> 
> No. I've just tried it with PGI (pgf95) but it chokes on "contains" "within a
> derived type definition".

That was probably an older version. I'm pretty sure the more recent versions of PGI at least support type-bound procedures.



> > I.e. it prints only one number, where it actually should print three.
> 
> Isn't arr(-1:-1) meaning a[-1], i.e. just one element? 

Ah, yes. I somehow misread it as arr(-1:1). Sorry for the false alarm.

(In reply to comment #9)
> (In reply to comment #8)
> > > Just out of curiosity: Are you aware of any compiler which swallows this?
> > 
> > No. I've just tried it with PGI (pgf95) but it chokes on "contains" "within a
> > derived type definition".
> 
> That was probably an older version. I'm pretty sure the more recent versions of
> PGI at least support type-bound procedures.

I just tried ifort 12.1.1.256 and PGI 11.9 on comment #4, and both reject it:


ifort pr52994.f90 
pr52994.f90(32): error #6515: This function, which is specified as the left side of an assignment statement, is invalid.   [LEFT_HALO]
  a%left_halo(arr) = -666  ! ICE
----^


pgf95 pr52994.f90 
PGF90-S-0072-Assignment operation illegal to external procedure left_halo9 (pr52994.f90: 32)
  0 inform,   0 warnings,   1 severes, 0 fatal for test

Note that at gfortran correctly rejects the test case with -std=f2003:

  a%left_halo(arr) = -666  ! ICE
  1
Error: Fortran 2008: Pointer functions in variable definition context (assignment) at (1)

FYI : On my environment it's not possible to produce an ICE with gcc-9
and several tested combinations of options / all tested configurations.


$ gfortran-9-20181021 -c pr52994.f90
pr52994.f90:43:29:

   43 |   a%left_halo(psi%arr) = -666
      |                             1
Error: Different types in pointer assignment at (1); attempted assignment of REAL(4) to INTEGER(4)

> FYI : On my environment it's not possible to produce an ICE with gcc-9
> and several tested combinations of options / all tested configurations.
>
> $ gfortran-9-20181021 -c pr52994.f90
> pr52994.f90:43:29:
>
>    43 |   a%left_halo(psi%arr) = -666
>       |                             1
> Error: Different types in pointer assignment at (1); attempted assignment
> of REAL(4) to INTEGER(4)

The change occurred between revisions r227742 (2015-09-14, ICE) and r228457 (2015-10-04, error), likely r228222 (pr40054, pr63921).

Note that I am surprised by the order of REAL(4) and INTEGER(4): AFAICT a%left_halo(psi%arr) is real and -666 an integer, isn't it?

(In reply to Dominique d'Humieres from comment #13)
> > FYI : On my environment it's not possible to produce an ICE with gcc-9
> > and several tested combinations of options / all tested configurations.

Confirmed, the ICE is gone since gfortran 6.


> > $ gfortran-9-20181021 -c pr52994.f90
> > pr52994.f90:43:29:
> >
> >    43 |   a%left_halo(psi%arr) = -666
> >       |                             1
> > Error: Different types in pointer assignment at (1); attempted assignment
> > of REAL(4) to INTEGER(4)
> 
> Note that I am surprised by the order of REAL(4) and INTEGER(4): AFAICT
> a%left_halo(psi%arr) is real and -666 an integer, isn't it?

The bigger problem is that the mentioned statement is not actually a pointer assignment. left_halo returns a pointer, but the assignment concerns the target of that pointer, not the pointer itself.

When changing to a real value, I get:

   32 |   a%left_halo(arr) = -666.
      |                          1
Error: Different ranks in pointer assignment at (1)


Also this error is bogus. The assignment is valid AFAICS.

From as far back as GNU Fortran (GCC) 11.2.1 20210728, the pointer function assignment gives the correct result arr(-1) = -666.0

Marking it as fixed.

Paul