[Bug fortran/54788] New: ICE on pointer-array element assignment

[Bug fortran/54788] New: ICE on pointer-array element assignment

[slayoo at staszic dot waw.pl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54788

             Bug #: 54788
           Summary: ICE on pointer-array element assignment
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: slayoo@staszic.waw.pl


Hello,

I'm sending below a short code causing an ICE of gfortran.

HTH,
Sylwester

P.S. BTW, could you help me in understanding the following error message:
$ cat question.f90
program question
  type :: arr_t
    real, pointer :: arr(:,:)
  end type
  class(arr_t), pointer :: vec(:)
  allocate(vec(2))
  allocate(vec(0)%arr(4,4))
  vec(1) => vec(0)
end

$ gfortran question.f90 
question.f90:8.2:

  vec(1) => vec(0)
  1
Error: Expected bounds specification for 'vec' at (1)

In principle, I'm trying to define a vector of pointers to arrays, and make two
elements of this vector point to the same array. 

----------------------------------------------------------------------
$ cat bug.f90 
program bug
  integer, pointer :: a(:)
  integer :: b
  allocate(a(0:0))
  a(0:0) => b
end

$ /usr/lib/gcc-snapshot/bin/gfortran bug.f90 
f951: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-snapshot/README.Bugs> for instructions.

$ /usr/lib/gcc-snapshot/bin/gfortran --version
GNU Fortran (Debian 20120930-1) 4.8.0 20120930 (experimental) [trunk revision
191865]
Copyright (C) 2012 Free Software Foundation, Inc.

GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING

[Bug fortran/54788] ICE on pointer-array element assignment

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54788

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |janus at gcc dot gnu.org

--- Comment #1 from janus at gcc dot gnu.org 2012-10-03 00:01:59 UTC ---
I think both programs are invalid and should be rejected.

The error message for the first one is misleading, to say the least. I don't
quite understand it either.

Note: "integer, pointer :: a(:)" defines a pointer to an array, and not an
array of pointers. Therefore "a(0:0)" is an element (or rather an array
section) of the array which is pointed to by "a". It is not a pointer itself
and can not be used in a pointer assignment context.

[Bug fortran/54788] ICE on pointer-array element assignment

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54788

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-invalid-code
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-10-03 07:32:43 UTC ---
(In reply to comment #1)
> I think both programs are invalid and should be rejected.

I concur.

(In reply to comment #0)
>   vec(1) => vec(0)
>   1
> Error: Expected bounds specification for 'vec' at (1)

  R733 pointer-assignment-stmt
        is   data-pointer-object [ (bounds-spec-list) ] => data-target
        or   data-pointer-object (bounds-remapping-list ) => data-target
        or   proc-pointer-object => proc-target

with

  bounds-spec        is  lower-bound-expr :
  bounds-remapping   is  lower-bound-expr : upper-bound-expr

  C716 (R733)   If bounds-spec-list is specified, the number of bounds-specs
                shall equal the rank of data-pointer-object.
  C717 (R733)   If bounds-remapping-list is specified, the number of bounds-
                remappings shall equal the rank of data-pointer-object.

Thus, if you want to do bounds remapping, you have to specify a range, e.g.

  vec(1:1) => vec(0:0)


>   integer, pointer :: a(:)
>   integer :: b
>   a(0:0) => b

That violates C717 as the LHS is rank 1 and the RHS is scalar. But it shouldn't
give an ICE.

[Bug fortran/54788] ICE on pointer-array element assignment

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54788

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-10-03 09:14:26 UTC ---
(In reply to comment #0)
>   allocate(vec(2))
>   allocate(vec(0)%arr(4,4))

I assume you have a C background. In Fortran, by default the lower array bound
is one. Thus, with "allocate(vec(2))" you allocated an array of size 2, which
can be accessed via vec(1) and vec(2). Thus, you access invalid memory for
"vec(0)".

However, you can also allocate via
   allocate(vec(0:2))
then you have a size-3 array, where vec(0), vec(1) and vec(2) are valid.
(you could also have negative bounds, e.g. "allocate(vec(-2:0))".)


The other point is, as Janus already mentioned: Fortran only has pointers to
arrays but not an array of pointers. Thus "vec(1)" and "vec(2)" point to the
same array, one to the first element and one to the second element.

In terms of the standard,
  allocate(vec(2))
allocates an anonymous target (a rank-1, size-2 array) and then pointer assigns
that target to the (scalar) pointer "vec". Thus "vec" is a pointer to a size-2
array with the lower bound "1" and upper bound "2".


(In reply to comment #2)
> Thus, if you want to do bounds remapping, you have to specify a range, e.g.
>   vec(1:1) => vec(0:0)

Remark to my example: While it is syntactically correct, accessing "vec(0:0)"
isn't (out of bounds). It were okay for "allocate(vec(0:2))" - but still, it
wouldn't do what you expect:
"vec(1)" would then point to the first element of the array, "vec(2)" would be
in principle the second element (and in practice accessible), but but one may
not use it: In "vec(1:1) =>" one has explicitly told the compiler that one only
wants to point to a size-1 array.

[Bug fortran/54788] ICE on pointer-array element assignment

[slayoo at staszic dot waw.pl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54788

--- Comment #4 from Sylwester Arabas <slayoo at staszic dot waw.pl> 2012-10-03 10:45:10 UTC ---
Thanks for your replies!

I've managed to get a vector of array pointers employing one more intermediate
derived type. The arrvec_t defined below has also some limited support for
negative indexing as in Python:



module arrvec_m
  implicit none

  type :: arr_t
    real, pointer :: a(:,:)
  end type

  type :: arrptr_t
    class(arr_t), pointer :: p
  end type

  type :: arrvec_t
    class(arrptr_t), pointer :: at(:)
    logical, pointer :: inited(:)
    contains
    procedure :: ctor => arrvec_ctor
    procedure :: init => arrvec_init
    procedure :: dtor => arrvec_dtor ! waiting for FINAL
  end type

  contains

  subroutine arrvec_ctor(this, n)
    class(arrvec_t) :: this
    integer, intent(in) :: n

    allocate(this%at(-n:n-1))
    allocate(this%inited(0:n-1))
    this%inited = .false.
  end subroutine

  subroutine arrvec_init(this, n, i_min, i_max, j_min, j_max)
    class(arrvec_t) :: this
    integer, intent(in) :: n, i_min, i_max, j_min, j_max

    allocate(this%at(n)%p)
    allocate(this%at(n)%p%a(i_min : i_max, j_min : j_max))
    this%inited(n) = .true.
    this%at(n - size(this%inited))%p => this%at(n)%p
  end subroutine

  subroutine arrvec_dtor(this)
    class(arrvec_t) :: this
    integer :: i

    do i = 0, size(this%inited) - 1
      if (this%inited(i)) then
        deallocate(this%at(i)%p%a)
        deallocate(this%at(i)%p)
      end if
    end do
    deallocate(this%at)
  end subroutine
end module



program test_arrvec
  use arrvec_m
  class(arrvec_t), pointer :: psi

  allocate(psi)
  call psi%ctor(2)
  call psi%init(0, 0, 3, 0, 4)

  print*, psi%at(0)%p%a
  print*, psi%at(0)%p%a(1,1)
  psi%at(0)%p%a(1,1) = 10
  print*, psi%at(0)%p%a(1,1)
  print*, psi%at(-2)%p%a(1,1)

  call psi%dtor
  deallocate(psi)
end

[Bug fortran/54788] ICE on pointer-array element assignment

[slayoo at staszic dot waw.pl]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54788

--- Comment #5 from Sylwester Arabas <slayoo at staszic dot waw.pl> 2012-10-09 18:57:42 UTC ---
Created attachment 28404
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28404
testcase

The bug report got cluttered with non-relevant discussion and code (thanks
again for you answers to my question!), so I'm submitting the testcase in a
separate file as attachment.
S.

[Bug fortran/54788] ICE on pointer-array element assignment

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54788

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-06-27
     Ever confirmed|0                           |1

--- Comment #6 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
I still get an ICE for the second test in comment #1 at revision 200429. The
backtrace is

Program received signal SIGSEGV, Segmentation fault.
gfc_array_size (array=0x141b148d0, result=0x7fff5fbfd300) at
../../work/gcc/fortran/array.c:2087
2087      if (as->type == AS_ASSUMED_RANK)
(gdb) bt 
#0  gfc_array_size (array=0x141b148d0, result=0x7fff5fbfd300) at
../../work/gcc/fortran/array.c:2087
#1  0x000000010003f1a0 in gfc_check_pointer_assign (lvalue=0x141b143f0,
rvalue=0x141b148d0) at ../../work/gcc/fortran/expr.c:3648
#2  0x00000001000a060e in resolve_code (code=<value optimized out>, ns=<value
optimized out>) at ../../work/gcc/fortran/resolve.c:9815
#3  0x00000001000a18c4 in resolve_codes (ns=<value optimized out>) at
../../work/gcc/fortran/resolve.c:14474
#4  0x0000000100091f1d in gfc_resolve (ns=<value optimized out>) at
../../work/gcc/fortran/resolve.c:14502
#5  0x0000000100085f2b in gfc_parse_file () at
../../work/gcc/fortran/parse.c:4442
#6  0x00000001000c6316 in gfc_be_parse_file () at
../../work/gcc/fortran/f95-lang.c:189
#7  0x0000000100793294 in compile_file () at ../../work/gcc/toplev.c:544
#8  0x0000000100795389 in toplev_main (argc=2, argv=0x7fff5fbfd7a8) at
../../work/gcc/toplev.c:1872
#9  0x0000000100009ca4 in start (pc=<value optimized out>, bases=0x0) at
../../../work/libgcc/config/unwind-dw2-fde-darwin.c:272

With the following (untested) patch

--- ../_clean/gcc/fortran/array.c    2013-06-08 11:35:26.000000000 +0200
+++ gcc/fortran/array.c    2013-06-27 11:06:24.000000000 +0200
@@ -2084,7 +2084,7 @@ spec_size (gfc_array_spec *as, mpz_t *re
   mpz_t size;
   int d;

-  if (as->type == AS_ASSUMED_RANK)
+  if (!as || as->type == AS_ASSUMED_RANK)
     return false;

   mpz_init_set_ui (*result, 1);

one gets the error

  a(0:0) => b
            1
Error: Rank remapping target must be rank 1 or simply contiguous at (1)

[Bug fortran/54788] ICE on pointer-array element assignment

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54788

--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Author: burnus
Date: Mon Jul  1 07:53:55 2013
New Revision: 200575

URL: http://gcc.gnu.org/viewcvs?rev=200575&root=gcc&view=rev
Log:
2013-07-01  Dominique d'Humieres  <dominiq@lps.ens.fr>

        PR fortran/54788
        * array.c (spec_size): handle the case as==NULL.

2013-07-01  Dominique d'Humieres  <dominiq@lps.ens.fr>

        PR fortran/54788
        * gfortran.dg/pointer_remapping_8.f90: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/pointer_remapping_8.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/array.c
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/54788] ICE on pointer-array element assignment

[burnus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54788

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #8 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Closed as FIXED.

Thanks for the bug report!