[Bug fortran/65469] New: ICE on bad code

[Bug fortran/65469] New: ICE on bad code

[daniel.price at monash dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65469

            Bug ID: 65469
           Summary: ICE on bad code
           Product: gcc
           Version: 4.9.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: daniel.price at monash dot edu

Created attachment 35062
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35062&action=edit
code that produces the internal compiler error

Dear gfortran folks,

 Attached is a short test case of (wrong) code I happened to produce that
triggers an "internal compiler error" and a seg fault.

 I've got it down to just 9 lines of code. The code should obviously fail to
compile, but I thought you might like to fix the ICE and the seg fault... 

Daniel

Output as follows:

$ gfortran-mp-4.9 -o ice.o -c ice.f90
ice.f90:7.17:

 type(block_type) :: my_block
                 1
Error: Derived type 'block_type' at (1) is being used before it is defined
f951: internal compiler error: Segmentation fault: 11

f951: internal compiler error: Abort trap: 6
gfortran-mp-4.9: internal compiler error: Abort trap: 6 (program f951)
Abort trap: 6

-----
Version info (also fails with gfortran v4.8):
-----
$ gfortran-mp-4.9 -v
Using built-in specs.
COLLECT_GCC=gfortran-mp-4.9
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin14/4.9.2/lto-wrapper
Target: x86_64-apple-darwin14
Configured with:
/opt/local/var/macports/build/_opt_mports_dports_lang_gcc49/gcc49/work/gcc-4.9.2/configure
--prefix=/opt/local --build=x86_64-apple-darwin14
--enable-languages=c,c++,objc,obj-c++,lto,fortran,java
--libdir=/opt/local/lib/gcc49 --includedir=/opt/local/include/gcc49
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-4.9 --with-local-prefix=/opt/local
--with-system-zlib --disable-nls --program-suffix=-mp-4.9
--with-gxx-include-dir=/opt/local/include/gcc49/c++/ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local
--disable-isl-version-check --with-cloog=/opt/local
--disable-cloog-version-check --enable-stage1-checking --disable-multilib
--enable-lto --enable-libstdcxx-time --with-as=/opt/local/bin/as
--with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar
--with-bugurl=https://trac.macports.org/newticket --with-pkgversion='MacPorts
gcc49 4.9.2_1'
Thread model: posix
gcc version 4.9.2 (MacPorts gcc49 4.9.2_1)

[Bug fortran/65469] [4.8/4.9/5 Regression] ICE on bad code

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65469

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-invalid-code
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-03-20
                 CC|                            |janus at gcc dot gnu.org
   Target Milestone|---                         |5.0
            Summary|ICE on bad code             |[4.8/4.9/5 Regression] ICE
                   |                            |on bad code
     Ever confirmed|0                           |1

--- Comment #1 from janus at gcc dot gnu.org ---
I can confirm the ICE with gfortran 4.7. With 4.4 and 4.6 I only see the
expected error message:

 type(my_type) :: crap
              1
Error: Derived type 'my_type' at (1) is being used before it is defined


With 4.9 and trunk, I don't actually get an ICE, but see some junk in the error
message:

c0.f90:6.14:

 type(my_type) :: crap
              1
Error: Derived type 'my_type' at (1) is being used before it is defined
c0.f90:9:

end module
1
Error: Procedure 'ȴ' in generic interface 'my_type' at (1) is neither
function nor subroutine
>From gcc-bugs-return-480917-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Mar 20 08:58:35 2015
Return-Path: <gcc-bugs-return-480917-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 45766 invoked by alias); 20 Mar 2015 08:58:35 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 45732 invoked by uid 48); 20 Mar 2015 08:58:31 -0000
From: "janus at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/65454] Extending both forms of relational operators
Date: Fri, 20 Mar 2015 09:28:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: janus at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-65454-4-aqzyCP9yos@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65454-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65454-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-03/txt/msg02061.txt.bz2
Content-length: 734

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide454

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 ---
(In reply to Paul Martin from comment #0)
> Can this behavior be considered as a bug?

I'm not completely sure, but probably yes.

A workaround is to apply the USE directive without the ONLY. Also, the latter
possibly makes your program invalid, since you import only the ".LE." but not
the "<=" operator. Or should it import both forms? (I haven't read up on the
details in the standard.)

[Bug fortran/65469] [4.8/4.9/5 Regression] ICE on bad code

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65469

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |error-recovery
           Priority|P3                          |P4
                 CC|                            |jakub at gcc dot gnu.org

[Bug fortran/65469] [4.8/4.9/5 Regression] ICE on bad code

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65469

--- Comment #2 from janus at gcc dot gnu.org ---
This should be enough to fix it:

Index: gcc/fortran/interface.c
===================================================================
--- gcc/fortran/interface.c    (Revision 221530)
+++ gcc/fortran/interface.c    (Arbeitskopie)
@@ -1569,7 +1569,7 @@ check_interface0 (gfc_interface *p, const char *in
      functions or subroutines.  */
       if (((!p->sym->attr.function && !p->sym->attr.subroutine)
        || !p->sym->attr.if_source)
-      && p->sym->attr.flavor != FL_DERIVED)
+      && p->sym->attr.flavor != FL_DERIVED && *p->sym->name)
     {
       if (p->sym->attr.external)
         gfc_error ("Procedure %qs in %s at %L has no explicit interface",

[Bug fortran/65469] [4.8/4.9/5 Regression] ICE on bad code

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65469

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

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

--- Comment #3 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Dup.

*** This bug has been marked as a duplicate of bug 59016 ***

[Bug fortran/65469] [4.8/4.9/5 Regression] ICE on bad code

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65469

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

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

--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Well, I have been too fast. This PR is indeed related to pr59016. However the
patch in comment 2 fixes it, but not pr59016 (AFAICT).

[Bug fortran/65469] [4.8/4.9/5 Regression] ICE on bad code

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65469

--- Comment #5 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Comment 4 was based on

[Book15] f90/bug% gfc pr65469.f90 
pr65469.f90:6:14:

  type(my_type) :: crap
              1
Error: Derived type 'my_type' at (1) is being used before it is defined
[Book15] f90/bug%

However running the same compilation later gave

[Book15] f90/bug% gfc pr65469.f90
pr65469.f90:6:14:

  type(my_type) :: crap
              1
Error: Derived type 'my_type' at (1) is being used before it is defined
f951: internal compiler error: Segmentation fault: 11
...

So if this PR is not a duplicate of pr59016, both bugs seem related to
p->sym->name being in an unpredictable state.

[Bug fortran/65469] [4.8/4.9/5 Regression] ICE on bad code

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65469

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

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

--- Comment #6 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> So if this PR is not a duplicate of pr59016, both bugs seem related to
> p->sym->name being in an unpredictable state.

Both PRs are fixed by the same patch and this PR is almost identical to the one
in pr59016 comment 1.

*** This bug has been marked as a duplicate of bug 59016 ***