Bug 18833 - ICE 'missing spec' on integer/char equivalence
Summary: ICE 'missing spec' on integer/char equivalence
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: 4.0.2
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code
: 20828 (view as bug list)
Depends on:
Blocks: 19292 20405 20850
  Show dependency treegraph
 
Reported: 2004-12-04 20:30 UTC by Thomas Koenig
Modified: 2005-08-06 13:35 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2005-06-06 00:17:44


Attachments
bug.f (325 bytes, application/octet-stream)
2005-07-22 14:20 UTC, Federico Carminati
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Koenig 2004-12-04 20:30:17 UTC
I haven't seen this one before...

$ cat integer-char.f90
program main
  character(len=8) :: c
  integer, dimension(2) :: i
  equivalence(c(1:1), i(1))
end program main
$ gfortran integer-char.f90
 In file integer-char.f90:5

end program main
               1
 Internal Error at (1):
 find_array_spec(): Missing spec
$ gfortran -v
Reading specs from /home/ig25/lib/gcc/i686-pc-linux-gnu/4.0.0/specs
Configured with: ../gcc/configure --prefix=/home/ig25
--enable-languages=c,c++,f95 --disable-shared
Thread model: posix
gcc version 4.0.0 20041204 (experimental)
Comment 1 Andrew Pinski 2004-12-05 15:34:52 UTC
Confirmed.
Comment 2 Tobias Schlüter 2004-12-05 20:59:39 UTC
The problem is that the substring reference is parsed as array reference. the
responsible code is this fragment from match_varspec in primary.c, after which
we unconditionally parse an array reference:
  if (primary->symtree->n.sym->attr.dimension
      || (equiv_flag
	  && gfc_peek_char () == '('))
 
Comment 3 Andrew Pinski 2005-04-08 12:20:42 UTC
*** Bug 20828 has been marked as a duplicate of this bug. ***
Comment 4 Andrew Pinski 2005-04-08 12:22:56 UTC
Even though the code listed in comment #0 is F90/F95, you can generate a f77 code which causes the 
same problem like so (from PR 20828):
      PROGRAM BUG
      CHARACTER  CQALLC*1, CQLETT(1)*1
      EQUIVALENCE (CQLETT(1),CQALLC(1:1))

      END
Comment 5 Jakub Jelinek 2005-07-22 12:37:26 UTC
I have partly written patch, but would like to understand whether ordering
matters or not.
Is the following all valid f77/f90/f95?
      subroutine foo
      character*8 c
      character*1 d, f
      dimension d(2), f(2)
      character*4 e
      equivalence (c(1:1), d(1)), (c(3:5), e(2:4)), (c(6:6), f(2))
      c='abcdefgh'
      if (c.ne.'abcdefgh'.or.d(1).ne.'a'.or.d(2).ne.'b') call abort
      if (e.ne.'bcde'.or.f(1).ne.'e'.or.f(2).ne.'f') call abort
      end subroutine foo
      subroutine bar
      equivalence (c(1:1), d(1)), (c(3:5), e(2:4)), (c(6:6), f(2))
      character*8 c
      character*1 d, f
      dimension d(2), f(2)
      character*4 e
      c='abcdefgh'
      if (c.ne.'abcdefgh'.or.d(1).ne.'a'.or.d(2).ne.'b') call abort
      if (e.ne.'bcde'.or.f(1).ne.'e'.or.f(2).ne.'f') call abort
      end subroutine bar
      subroutine baz
      character*8 c
      character*1 d, f
      character*4 e
      equivalence (c(1:1), d(1)), (c(3:5), e(2:4)), (c(6:6), f(2))
      dimension d(2), f(2)
      c='abcdefgh'
      if (c.ne.'abcdefgh'.or.d(1).ne.'a'.or.d(2).ne.'b') call abort
      if (e.ne.'bcde'.or.f(1).ne.'e'.or.f(2).ne.'f') call abort
      end subroutine baz
      subroutine another
      dimension d(2), f(2)
      equivalence (c(1:1), d(1)), (c(3:5), e(2:4)), (c(6:6), f(2))
      character*8 c
      character*1 d, f
      character*4 e
      c='abcdefgh'
      if (c.ne.'abcdefgh'.or.d(1).ne.'a'.or.d(2).ne.'b') call abort
      if (e.ne.'bcde'.or.f(1).ne.'e'.or.f(2).ne.'f') call abort
      end subroutine another
      program main
      call foo
      call bar
      call baz
      call another
      end program main

Can equivalence contain sym%name or is that forbidden?
Comment 6 Federico Carminati 2005-07-22 13:42:43 UTC
Subject: Re:  ICE 'missing spec' on integer/char equivalence

Hello,
   this is valid f90/95 code. Equivalence cannot  contain sym%val as  
far as I understand, but they can cointain derived types as long as
they are sequenced. Best regards, Fed
On 22 Jul 2005, at 14:37, jakub at redhat dot com wrote:

>
> ------- Additional Comments From jakub at redhat dot com   
> 2005-07-22 12:37 -------
> I have partly written patch, but would like to understand whether  
> ordering
> matters or not.
> Is the following all valid f77/f90/f95?
>       subroutine foo
>       character*8 c
>       character*1 d, f
>       dimension d(2), f(2)
>       character*4 e
>       equivalence (c(1:1), d(1)), (c(3:5), e(2:4)), (c(6:6), f(2))
>       c='abcdefgh'
>       if (c.ne.'abcdefgh'.or.d(1).ne.'a'.or.d(2).ne.'b') call abort
>       if (e.ne.'bcde'.or.f(1).ne.'e'.or.f(2).ne.'f') call abort
>       end subroutine foo
>       subroutine bar
>       equivalence (c(1:1), d(1)), (c(3:5), e(2:4)), (c(6:6), f(2))
>       character*8 c
>       character*1 d, f
>       dimension d(2), f(2)
>       character*4 e
>       c='abcdefgh'
>       if (c.ne.'abcdefgh'.or.d(1).ne.'a'.or.d(2).ne.'b') call abort
>       if (e.ne.'bcde'.or.f(1).ne.'e'.or.f(2).ne.'f') call abort
>       end subroutine bar
>       subroutine baz
>       character*8 c
>       character*1 d, f
>       character*4 e
>       equivalence (c(1:1), d(1)), (c(3:5), e(2:4)), (c(6:6), f(2))
>       dimension d(2), f(2)
>       c='abcdefgh'
>       if (c.ne.'abcdefgh'.or.d(1).ne.'a'.or.d(2).ne.'b') call abort
>       if (e.ne.'bcde'.or.f(1).ne.'e'.or.f(2).ne.'f') call abort
>       end subroutine baz
>       subroutine another
>       dimension d(2), f(2)
>       equivalence (c(1:1), d(1)), (c(3:5), e(2:4)), (c(6:6), f(2))
>       character*8 c
>       character*1 d, f
>       character*4 e
>       c='abcdefgh'
>       if (c.ne.'abcdefgh'.or.d(1).ne.'a'.or.d(2).ne.'b') call abort
>       if (e.ne.'bcde'.or.f(1).ne.'e'.or.f(2).ne.'f') call abort
>       end subroutine another
>       program main
>       call foo
>       call bar
>       call baz
>       call another
>       end program main
>
> Can equivalence contain sym%name or is that forbidden?
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18833
>
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
>

Comment 7 Tobias Schlüter 2005-07-22 14:01:06 UTC
Subject: Re:  ICE 'missing spec' on integer/char equivalence

federico dot carminati at cern dot ch wrote:
>    this is valid f90/95 code. Equivalence cannot  contain sym%val as  
> far as I understand, but they can cointain derived types as long as
> they are sequenced.

I'm not sure if oyu meant to say the right thing, so let me clarify: sym%name
and sym are allowed if sym is of a type with the sequence attribute.

I haven't yet looked over the posted program.
Comment 8 Federico Carminati 2005-07-22 14:20:46 UTC
Subject: Re:  ICE 'missing spec' on integer/char equivalence

Errr... I was a bit cryptic. You cannot put in an equivalence  
anything like sym%var, but you can put a whole
derived data type, as long as it is sequenced. See the attached  
example. Regards, Fed


On 22 Jul 2005, at 16:01, Tobias dot Schlueter at physik dot uni- 
muenchen dot de wrote:

>
> ------- Additional Comments From Tobias dot Schlueter at physik dot  
> uni-muenchen dot de  2005-07-22 14:01 -------
> Subject: Re:  ICE 'missing spec' on integer/char equivalence
>
> federico dot carminati at cern dot ch wrote:
>
>>    this is valid f90/95 code. Equivalence cannot  contain sym%val as
>> far as I understand, but they can cointain derived types as long as
>> they are sequenced.
>>
>
> I'm not sure if oyu meant to say the right thing, so let me  
> clarify: sym%name
> and sym are allowed if sym is of a type with the sequence attribute.
>
> I haven't yet looked over the posted program.
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18833
>
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
>

Comment 9 Federico Carminati 2005-07-22 14:20:48 UTC
Created attachment 9329 [details]
bug.f
Comment 10 Federico Carminati 2005-07-22 14:22:54 UTC
Subject: Re:  ICE 'missing spec' on integer/char equivalence

Sorry, file now inline. Fed

       subroutine foo
       character*8 c
       character*1 d, f
       dimension d(2), f(2)
       character*4 e
       equivalence (c(1:1), d(1)), (c(3:5), e(2:4)), (c(6:6), f(2))
       c='abcdefgh'
       if (c.ne.'abcdefgh'.or.d(1).ne.'a'.or.d(2).ne.'b') call abort
       if (e.ne.'bcde'.or.f(1).ne.'e'.or.f(2).ne.'f') call abort
       end subroutine foo
       subroutine bar
       equivalence (c(1:1), d(1)), (c(3:5), e(2:4)), (c(6:6), f(2))
       character*8 c
       character*1 d, f
       dimension d(2), f(2)
       character*4 e
       c='abcdefgh'
       if (c.ne.'abcdefgh'.or.d(1).ne.'a'.or.d(2).ne.'b') call abort
       if (e.ne.'bcde'.or.f(1).ne.'e'.or.f(2).ne.'f') call abort
       end subroutine bar
       subroutine baz
       character*8 c
       character*1 d, f
       character*4 e
       equivalence (c(1:1), d(1)), (c(3:5), e(2:4)), (c(6:6), f(2))
       dimension d(2), f(2)
       c='abcdefgh'
       if (c.ne.'abcdefgh'.or.d(1).ne.'a'.or.d(2).ne.'b') call abort
       if (e.ne.'bcde'.or.f(1).ne.'e'.or.f(2).ne.'f') call abort
       end subroutine baz
       subroutine another
       dimension d(2), f(2)
       equivalence (c(1:1), d(1)), (c(3:5), e(2:4)), (c(6:6), f(2))
       character*8 c
       character*1 d, f
       character*4 e
       c='abcdefgh'
       if (c.ne.'abcdefgh'.or.d(1).ne.'a'.or.d(2).ne.'b') call abort
       if (e.ne.'bcde'.or.f(1).ne.'e'.or.f(2).ne.'f') call abort
       end subroutine another
       program main
       call foo
       call bar
       call baz
       call another
       end program main


On 22 Jul 2005, at 16:20, federico dot carminati at cern dot ch wrote:

>
> ------- Additional Comments From federico dot carminati at cern dot  
> ch  2005-07-22 14:20 -------
> Subject: Re:  ICE 'missing spec' on integer/char equivalence
>
> Errr... I was a bit cryptic. You cannot put in an equivalence
> anything like sym%var, but you can put a whole
> derived data type, as long as it is sequenced. See the attached
> example. Regards, Fed
>
>
> On 22 Jul 2005, at 16:01, Tobias dot Schlueter at physik dot uni-
> muenchen dot de wrote:
>
>
>>
>> ------- Additional Comments From Tobias dot Schlueter at physik dot
>> uni-muenchen dot de  2005-07-22 14:01 -------
>> Subject: Re:  ICE 'missing spec' on integer/char equivalence
>>
>> federico dot carminati at cern dot ch wrote:
>>
>>
>>>    this is valid f90/95 code. Equivalence cannot  contain sym%val as
>>> far as I understand, but they can cointain derived types as long as
>>> they are sequenced.
>>>
>>>
>>
>> I'm not sure if oyu meant to say the right thing, so let me
>> clarify: sym%name
>> and sym are allowed if sym is of a type with the sequence attribute.
>>
>> I haven't yet looked over the posted program.
>>
>>
>> -- 
>>
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18833
>>
>> ------- You are receiving this mail because: -------
>> You are on the CC list for the bug, or are watching someone who is.
>>
>>
>
>
> ------- Additional Comments From federico dot carminati at cern dot  
> ch  2005-07-22 14:20 -------
> Created an attachment (id=9329)
>  --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9329&action=view)
>
>
> -- 
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18833
>
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
>

Comment 11 Tobias Schlüter 2005-07-22 14:49:18 UTC
Subject: Re:  ICE 'missing spec' on integer/char equivalence

federico dot carminati at cern dot ch wrote:
> ------- Additional Comments From federico dot carminati at cern dot ch  2005-07-22 14:20 -------
> Subject: Re:  ICE 'missing spec' on integer/char equivalence
> 
> Errr... I was a bit cryptic. You cannot put in an equivalence  
> anything like sym%var, but you can put a whole
> derived data type, as long as it is sequenced. See the attached  
> example. Regards, Fed

Ugh, yes, I agree with you (if you add "variable" after "derived data type"),
I misread the standard.
Comment 12 CVS Commits 2005-08-06 10:01:15 UTC
Subject: Bug 18833

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	jakub@gcc.gnu.org	2005-08-06 10:00:54

Modified files:
	gcc/fortran    : ChangeLog primary.c resolve.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/gfortran.dg: equiv_1.f90 equiv_2.f90 
	gcc/testsuite/gfortran.fortran-torture/execute: equiv_2.f90 
	                                                equiv_3.f90 
	                                                equiv_4.f90 

Log message:
	PR fortran/18833
	PR fortran/20850
	* primary.c (match_varspec): If equiv_flag, don't look at sym's
	attributes, call gfc_match_array_ref up to twice and don't do any
	substring or component processing.
	* resolve.c (resolve_equivalence): Transform REF_ARRAY into
	REF_SUBSTRING or nothing if needed.  Check that substrings
	don't have zero length.
	
	* gfortran.dg/equiv_1.f90: New test.
	* gfortran.dg/equiv_2.f90: New test.
	* gfortran.fortran-torture/execute/equiv_2.f90: New test.
	* gfortran.fortran-torture/execute/equiv_3.f90: New test.
	* gfortran.fortran-torture/execute/equiv_4.f90: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&r1=1.512&r2=1.513
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/primary.c.diff?cvsroot=gcc&r1=1.32&r2=1.33
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/resolve.c.diff?cvsroot=gcc&r1=1.47&r2=1.48
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.5884&r2=1.5885
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_1.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_2.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/equiv_2.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/equiv_3.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/equiv_4.f90.diff?cvsroot=gcc&r1=NONE&r2=1.1

Comment 13 CVS Commits 2005-08-06 10:12:57 UTC
Subject: Bug 18833

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-4_0-branch
Changes by:	jakub@gcc.gnu.org	2005-08-06 10:12:42

Modified files:
	gcc/fortran    : ChangeLog primary.c resolve.c 
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/gfortran.dg: equiv_1.f90 equiv_2.f90 
	gcc/testsuite/gfortran.fortran-torture/execute: equiv_2.f90 
	                                                equiv_3.f90 
	                                                equiv_4.f90 

Log message:
	PR fortran/18833
	PR fortran/20850
	* primary.c (match_varspec): If equiv_flag, don't look at sym's
	attributes, call gfc_match_array_ref up to twice and don't do any
	substring or component processing.
	* resolve.c (resolve_equivalence): Transform REF_ARRAY into
	REF_SUBSTRING or nothing if needed.  Check that substrings
	don't have zero length.
	
	* gfortran.dg/equiv_1.f90: New test.
	* gfortran.dg/equiv_2.f90: New test.
	* gfortran.fortran-torture/execute/equiv_2.f90: New test.
	* gfortran.fortran-torture/execute/equiv_3.f90: New test.
	* gfortran.fortran-torture/execute/equiv_4.f90: New test.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.335.2.99&r2=1.335.2.100
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/primary.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.22.2.8&r2=1.22.2.9
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/fortran/resolve.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.34.2.12&r2=1.34.2.13
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.318&r2=1.5084.2.319
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_1.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.dg/equiv_2.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/equiv_2.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/equiv_3.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gfortran.fortran-torture/execute/equiv_4.f90.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1

Comment 14 Andrew Pinski 2005-08-06 13:35:40 UTC
Fixed.