[Bug fortran/58182] [4.9 Regression] ICE with global binding name used as a FUNCTION
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=206429root=gccview=rev Log: 2014-01-08 Janus Weil ja...@gcc.gnu.org PR fortran/58182 * resolve.c (gfc_verify_binding_labels): Modify order of checks. 2014-01-08 Janus Weil ja...@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
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.
[Bug fortran/58182] [4.9 Regression] ICE with global binding name used as a FUNCTION
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
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
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
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
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
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
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
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
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
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
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
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
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.
