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)
Confirmed.
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 () == '('))
*** Bug 20828 has been marked as a duplicate of this bug. ***
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
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?
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. >
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.
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. >
Created attachment 9329 [details] bug.f
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. >
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.
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
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
Fixed.