[Bug fortran/55735] New: ICE with deferred-length strings in COMMON

[Bug fortran/55735] New: ICE with deferred-length strings in COMMON

[burnus at gcc dot gnu.org]

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

             Bug #: 55735
           Summary: ICE with deferred-length strings in COMMON
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: burnus@gcc.gnu.org


I think the following test case it valid. In any case, an ICE is a bug. Vaguely
related is PR 55733.

block data
  character(len=:), pointer :: str(:)
  common /foo/ str
end block data

subroutine bar()
  character(len=:), pointer :: str
  common /foo/ str
!  print *, len(str), '"'//str//'"' !ICE in gfc_conv_intrinsic_len
  print '(3a)', '"',str(1:6),'"' ! ICE in gfc_conv_variable
end

character(len=:), pointer :: str(:)
common /foo/ str
allocate (character(len=6) :: str(1))
str = "ABCDEF"
call bar()
end

[Bug fortran/55735] ICE with deferred-length strings in COMMON

[burnus at gcc dot gnu.org]

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

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

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

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-12-18 16:06:14 UTC ---
Postscript: The example in comment 0 mixes a scalar and an array pointers.
While the ICE occurs with either, the declaration should be consistent.

[Bug fortran/55735] ICE with deferred-length strings in COMMON

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

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

--- Comment #2 from kargl at gcc dot gnu.org 2012-12-18 16:47:10 UTC ---
(In reply to comment #1)
> Postscript: The example in comment 0 mixes a scalar and an array pointers.
> While the ICE occurs with either, the declaration should be consistent.

I could be wrong, but I believe that the program in comment 0
is invalid.

F2008: p. 116
A data pointer shall be storage associated only with data pointers of the
same type and rank.  Data pointers that are storage associated shall have
deferred the same type parameters; corresponding nondeferred type parameters
shall have the same value.

I doubt that it is possible to catch the rank mismatch (except 
maybe under -fwhole-program with everything in one file).

[Bug fortran/55735] ICE with deferred-length strings in COMMON

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-12-18 20:04:12 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > Postscript: The example in comment 0 mixes a scalar and an array pointers.
> > While the ICE occurs with either, the declaration should be consistent.
>
> I could be wrong, but I believe that the program in comment 0
> is invalid.

Mixing scalars and arrays is invalid. But as written, the same ICE occurs if
one has only arrays or only scalars (which I intended but didn't post). And do
I believe the program(s) is (are) valid in that case.


> I doubt that it is possible to catch the rank mismatch

Well, the compiler does warn that the named common blocks have a different
size.

[Bug fortran/55735] ICE with deferred-length strings in COMMON

[dominiq at lps dot ens.fr]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-09-03
     Ever confirmed|0                           |1