[Bug fortran/58182] [4.9 Regression] ICE with global binding name used as a FUNCTION

[Bug fortran/58182] [4.9 Regression] ICE with global binding name used as a FUNCTION

[dominiq at lps dot ens.fr]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-08-17
            Summary|ICE with global binding     |[4.9 Regression] ICE with
                   |name used as a FUNCTION     |global binding name used as
                   |                            |a FUNCTION
     Ever confirmed|0                           |1

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Confirmed. There is no ICE nor error with revision 198750 (2013-05-09).
Revision 199418 (2013-05-29) gives the ICE.

[Bug fortran/58182] [4.9 Regression] ICE with global binding name used as a FUNCTION

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ice-on-invalid-code
                 CC|                            |janus at gcc dot gnu.org

--- Comment #2 from janus at gcc dot gnu.org ---
There may be other ways to fix this, but a particularly simple one is just
flipping the checks in the if statement which produces the ICE:


Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c    (revision 201834)
+++ gcc/fortran/resolve.c    (working copy)
@@ -10114,11 +10114,11 @@ gfc_verify_binding_labels (gfc_symbol *sym)
        && ((gsym->type != GSYM_SUBROUTINE && gsym->type != GSYM_FUNCTION)
            || (gsym->defined && sym->attr.if_source != IFSRC_IFBODY))
        && sym != gsym->ns->proc_name
-       && (strcmp (gsym->sym_name, sym->name) != 0
-           || module != gsym->mod_name
+       && (module != gsym->mod_name
+           || strcmp (gsym->sym_name, sym->name) != 0
            || (module && strcmp (module, gsym->mod_name) != 0)))
     {
-      /* Print an error if the procdure is defined multiple times; we have to
+      /* Print an error if the procedure is defined multiple times; we have to
      exclude references to the same procedure via module association or
      multiple checks for the same procedure.  */
       gfc_error ("Procedure %s with binding label %s at %L uses the same "


With this I get the following:

mod2.f90:2.6:

  use fg
      1
mod2.f90:1.8:

module f
        2
Error: Procedure f with binding label f at (1) uses the same global identifier
as entity at (2)


This is slightly different from the error message in comment 0, but it still
sounds reasonable to me.


Btw, does it make sense to have a dummy procedure with 'BIND(C)' at all? I have
the feeling that this might be something which should be forbidden in general
... (?)

[Bug fortran/58182] [4.9 Regression] ICE with global binding name used as a FUNCTION

[janus at gcc dot gnu.org]

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

--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to janus from comment #2)
> There may be other ways to fix this, but a particularly simple one is just
> flipping the checks in the if statement which produces the ICE:

Note: The patch in comment 2 regtests cleanly.

[Bug fortran/58182] [4.9 Regression] ICE with global binding name used as a FUNCTION

[abensonca at gmail dot com]

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

--- Comment #4 from Andrew Benson <abensonca at gmail dot com> ---
"Btw, does it make sense to have a dummy procedure with 'BIND(C)' at all? I
have the feeling that this might be something which should be forbidden in
general ... (?)"

Possibly not....... This was reduced from the FGSL library source, so not my
own code. I could check in the original if the BIND(C) is actually needed.

[Bug fortran/58182] [4.9 Regression] ICE with global binding name used as a FUNCTION

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to Andrew Benson from comment #4)
> "Btw, does it make sense to have a dummy procedure with 'BIND(C)' at all? I
> have the feeling that this might be something which should be forbidden in
> general ... (?)"

Trying to answer that myself: It seems like at least BIND(C,NAME=...) is
forbidden for a dummy procedure (and is indeed rejected by gfortran). Quote
from F08:

C1254 (R1229) A proc-language-binding-spec with a NAME= specifier shall not be
specified in the function-stmt or subroutine-stmt of an internal procedure, or
of an interface body for an abstract interface or a dummy procedure.

However, BIND(C) without NAME=... seems to be allowed.

[Bug fortran/58182] [4.9 Regression] ICE with global binding name used as a FUNCTION

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.9.0

[Bug fortran/58182] [4.9 Regression] ICE with global binding name used as a FUNCTION

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4

[Bug fortran/58182] [4.9 Regression] ICE with global binding name used as a FUNCTION

[janus at gcc dot gnu.org]

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

--- Comment #6 from janus at gcc dot gnu.org ---
The ICE seems to be gone at r206252. Can we close this PR?

[Bug fortran/58182] [4.9 Regression] ICE with global binding name used as a FUNCTION

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> The ICE seems to be gone at r206252. Can we close this PR?

I still get an ICE with r206348 when compiling the test in two files, but not
when merged in a single file.

[Bug fortran/58182] [4.9 Regression] ICE with global binding name used as a FUNCTION

[janus at gcc dot gnu.org]

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

--- Comment #8 from janus at gcc dot gnu.org ---
Right. Like PR 59023, this regression is probably due to r199120. Unfortunately
it is not fixed by r206355, but I think the patch in comment 2 does make sense
after all.

[Bug fortran/58182] [4.9 Regression] ICE with global binding name used as a FUNCTION

[janus at gcc dot gnu.org]

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

--- Comment #9 from janus at gcc dot gnu.org ---
(In reply to janus from comment #2)
> This is slightly different from the error message in comment 0, but it still
> sounds reasonable to me.

The error message depends on whether the code is in one or two files and does
not change with the patch in comment 2.

The wording is reasonable in both cases, but one gets a better locus for the
single-file version.

[Bug fortran/58182] [4.9 Regression] ICE with global binding name used as a FUNCTION

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |janus at gcc dot gnu.org

[Bug fortran/58182] [4.9 Regression] ICE with global binding name used as a FUNCTION

[janus at gcc dot gnu.org]

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

--- Comment #10 from janus at gcc dot gnu.org ---
I think the patch in comment 2 is simple enough to be committed as obvious,
which I will do shortly.

[Bug fortran/58182] [4.9 Regression] ICE with global binding name used as a FUNCTION

[janus at gcc dot gnu.org]

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

--- Comment #11 from janus at gcc dot gnu.org ---
Author: janus
Date: Wed Jan  8 15:25:22 2014
New Revision: 206429

URL: http://gcc.gnu.org/viewcvs?rev=206429&root=gcc&view=rev
Log:
2014-01-08  Janus Weil  <janus@gcc.gnu.org>

    PR fortran/58182
    * resolve.c (gfc_verify_binding_labels): Modify order of checks.


2014-01-08  Janus Weil  <janus@gcc.gnu.org>

    PR fortran/58182
    * gfortran.dg/binding_label_tests_26a.f90: New.
    * gfortran.dg/binding_label_tests_26b.f90: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/binding_label_tests_26a.f90
    trunk/gcc/testsuite/gfortran.dg/binding_label_tests_26b.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/58182] [4.9 Regression] ICE with global binding name used as a FUNCTION

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

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

--- Comment #12 from janus at gcc dot gnu.org ---
Fixed with r206429. Closing.