[Bug fortran/49624] New: ICE with pointer-bound remapping

[Bug fortran/49624] New: ICE with pointer-bound remapping

[burnus at gcc dot gnu.org]

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

           Summary: ICE with pointer-bound remapping
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Keywords: ice-on-invalid-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: burnus@gcc.gnu.org


Assume:
  integer, target :: A(100)
  integer,pointer :: P(:,:)
  p(10,1:) => A
  end

Compiling the program with gfortran results in:

test.f90:4:0: internal compiler error: in gfc_trans_pointer_assignment, at
fortran/trans-expr.c:5081


While the following variant gives:
  p(1:10,1:) => A
  1
Error: Either all or none of the upper bounds must be specified at (1)

Also the valid "p(1:10,1:10) => A" works.


I think the compiler is right about rejecting the code, one finds:

R733 pointer-assignment-stmt
         is  data-pointer-object [ (bounds-spec-list) ] => data-target
         or  data-pointer-object (bounds-remapping-list ) => data-target
       [...]
R735 bounds-spec is lower-bound-expr :
R736 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.
C718 (R733) If bounds-remapping-list is not specified, the ranks of
            data-pointer-object and data-target shall be the same.


Thus, for bounds remapping both lower and upper bounds are required.

[Bug fortran/49624] ICE with pointer-bound remapping

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-07-15 15:31:05 UTC ---
(In reply to comment #0)
>   p(10,1:) => A

The problem is that "10" is parsed as DIMEN_ELEMENT such that ar.start is set
and ar.end is not. Thus, for the resolver, it is regarded as (10:,1:).


Patch:

--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -3286,7 +3286,7 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_expr
*rvalue)
             upper bounds are present, we may do rank remapping.  */
          for (dim = 0; dim < ref->u.ar.dimen; ++dim)
            {
-             if (!ref->u.ar.start[dim])
+             if (!ref->u.ar.start[dim]
                  || ref->u.ar.dimen_type[dim] != DIMEN_RANGE)
                {
                  gfc_error ("Lower bound has to be present at %L",
                             &lvalue->where);

[Bug fortran/49624] ICE with pointer-bound remapping

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-07-17 14:52:50 UTC ---
Author: burnus
Date: Sun Jul 17 14:52:46 2011
New Revision: 176370

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=176370
Log:
2011-07-17  Tobias Burnus  <burnus@net-b.de>

        PR fortran/49624
        * expr.c (gfc_check_pointer_assign): Fix checking for invalid
        pointer bounds.

2011-07-17  Tobias Burnus  <burnus@net-b.de>

        PR fortran/49624
        * gfortran.dg/pointer_remapping_7.f90: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/pointer_remapping_7.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/expr.c
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/49624] ICE with pointer-bound remapping

[burnus at gcc dot gnu.org]

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

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

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

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-07-17 14:57:47 UTC ---
FIXED on the 4.7 trunk.