* [Bug fortran/111218] Conflict in BIND(C) INTERFACEs in two Modules leads to ICE.
2023-08-28 19:28 [Bug fortran/111218] New: Conflict in BIND(C) INTERFACEs in two Modules leads to ICE toon at moene dot org
@ 2023-08-28 23:14 ` kargl at gcc dot gnu.org
2023-08-29 16:47 ` anlauf at gcc dot gnu.org
` (5 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: kargl at gcc dot gnu.org @ 2023-08-28 23:14 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111218
kargl at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kargl at gcc dot gnu.org
--- Comment #1 from kargl at gcc dot gnu.org ---
> (tested with gcc version 14.0.0 20230828 (experimental) [master
> r14-3528-gc3669bb677b] (GCC)
No ICE with a 14.0.0 20230824 gfortran
^ permalink raw reply [flat|nested] 8+ messages in thread* [Bug fortran/111218] Conflict in BIND(C) INTERFACEs in two Modules leads to ICE.
2023-08-28 19:28 [Bug fortran/111218] New: Conflict in BIND(C) INTERFACEs in two Modules leads to ICE toon at moene dot org
2023-08-28 23:14 ` [Bug fortran/111218] " kargl at gcc dot gnu.org
@ 2023-08-29 16:47 ` anlauf at gcc dot gnu.org
2023-08-29 16:51 ` anlauf at gcc dot gnu.org
` (4 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: anlauf at gcc dot gnu.org @ 2023-08-29 16:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111218
anlauf at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords|ice-on-invalid-code |ice-on-valid-code
Status|UNCONFIRMED |NEW
Last reconfirmed| |2023-08-29
Ever confirmed|0 |1
--- Comment #2 from anlauf at gcc dot gnu.org ---
I get an ICE for all gcc >= 11 here, and I think the code is actually valid.
(Other compilers, like NAG, Intel, NVidia accept it).
Might be a regression, as my installs of 7 <= gcc <= 10 all pass.
^ permalink raw reply [flat|nested] 8+ messages in thread* [Bug fortran/111218] Conflict in BIND(C) INTERFACEs in two Modules leads to ICE.
2023-08-28 19:28 [Bug fortran/111218] New: Conflict in BIND(C) INTERFACEs in two Modules leads to ICE toon at moene dot org
2023-08-28 23:14 ` [Bug fortran/111218] " kargl at gcc dot gnu.org
2023-08-29 16:47 ` anlauf at gcc dot gnu.org
@ 2023-08-29 16:51 ` anlauf at gcc dot gnu.org
2023-08-31 10:41 ` rimvydas.jas at gmail dot com
` (3 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: anlauf at gcc dot gnu.org @ 2023-08-29 16:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111218
--- Comment #3 from anlauf at gcc dot gnu.org ---
A workaround is to add a 'private' statement to any of the first two modules.
^ permalink raw reply [flat|nested] 8+ messages in thread* [Bug fortran/111218] Conflict in BIND(C) INTERFACEs in two Modules leads to ICE.
2023-08-28 19:28 [Bug fortran/111218] New: Conflict in BIND(C) INTERFACEs in two Modules leads to ICE toon at moene dot org
` (2 preceding siblings ...)
2023-08-29 16:51 ` anlauf at gcc dot gnu.org
@ 2023-08-31 10:41 ` rimvydas.jas at gmail dot com
2023-10-14 2:00 ` kargl at gcc dot gnu.org
` (2 subsequent siblings)
6 siblings, 0 replies; 8+ messages in thread
From: rimvydas.jas at gmail dot com @ 2023-08-31 10:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111218
Rimvydas (RJ) <rimvydas.jas at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rimvydas.jas at gmail dot com
--- Comment #4 from Rimvydas (RJ) <rimvydas.jas at gmail dot com> ---
Another testcase resulting in identical ICE.
$ cat test.f90
module foo1
interface !bail ! generic works ok
subroutine bail() bind(c,name="bail_")
end subroutine
end interface
end
module foo2
interface !bail
subroutine sfx_bail(k)
integer :: k
end subroutine
end interface
end
module foo
use foo1
use foo2 , bail => sfx_bail
end
subroutine unice_dummy ! avoid ice
end
$ ./gcc/f951 test.f90
test.f90:21:22:
21 | subroutine unice_dummy
| 1
Error: Name 'bail' at (1) is an ambiguous reference to 'bail' from module
'foo1'
Using extra dummy unit at the end of file helps to avoid the ICE (avoids ICE on
original case too), but notice the wrong locus. Issue here happens because
ambiguous_symbol() is called after parsing was already done, resulting in
nullification of gfc_current_locus global in gfc_advance_line () at
gcc/fortran/scanner.cc:651
651 gfc_current_locus.nextc = NULL;
So the "%C" cannot be used in gcc/fortran/symbol.cc:3167
gfc_error ("Name %qs at %C is an ambiguous reference to %qs "
Note: there is an assertion in gcc/fortran/error.cc:1078
gcc_assert (loc->nextc - loc->lb->line >= 0);
Question is weather bind(c) rename attribute should somehow affect interface
generic status in any way?
Testcase does pass with bind(c) commented out or with explicitly marked
interface as generic in foo1.
^ permalink raw reply [flat|nested] 8+ messages in thread* [Bug fortran/111218] Conflict in BIND(C) INTERFACEs in two Modules leads to ICE.
2023-08-28 19:28 [Bug fortran/111218] New: Conflict in BIND(C) INTERFACEs in two Modules leads to ICE toon at moene dot org
` (3 preceding siblings ...)
2023-08-31 10:41 ` rimvydas.jas at gmail dot com
@ 2023-10-14 2:00 ` kargl at gcc dot gnu.org
2023-10-14 2:08 ` kargl at gcc dot gnu.org
2023-10-14 2:30 ` kargl at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: kargl at gcc dot gnu.org @ 2023-10-14 2:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111218
--- Comment #5 from kargl at gcc dot gnu.org ---
Interesting bug. If one puts a break point ...
0x75917d gfc_format_decoder
/home/toon/compilers/gcc/gcc/fortran/error.cc:1078
0x2153e1f pp_format(pretty_printer*, text_info*)
/home/toon/compilers/gcc/gcc/pretty-print.cc:1475
0x21315be diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
/home/toon/compilers/gcc/gcc/diagnostic.cc:1606
0x9b628e gfc_report_diagnostic
/home/toon/compilers/gcc/gcc/fortran/error.cc:890
0x9b628e gfc_error_opt
/home/toon/compilers/gcc/gcc/fortran/error.cc:1460
0x9b7470 gfc_error(char const*, ...)
/home/toon/compilers/gcc/gcc/fortran/error.cc:1489
0xa6205b ambiguous_symbol
/home/toon/compilers/gcc/gcc/fortran/symbol.cc:3167
here, one ends up at
gfc_error ("Name %qs at %C is an ambiguous reference to %qs from"
"module %qs", name, st->n.sym->name, st->n.sym->module);
%C means one should use gfc_current_locus to print the offending line.
If one looks are gfc_current_locus, one sees gfc_current_locus.lb = 0x0,
an infamous NULL pointer dereference then occurs. Ouch. This patch
fixes the issue:
diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
index a6078bc608a..5b726f8b715 100644
--- a/gcc/fortran/symbol.cc
+++ b/gcc/fortran/symbol.cc
@@ -3164,8 +3164,16 @@ ambiguous_symbol (const char *name, gfc_symtree *st)
return;
if (st->n.sym->module)
- gfc_error ("Name %qs at %C is an ambiguous reference to %qs "
- "from module %qs", name, st->n.sym->name, st->n.sym->module);
+ {
+ if (gfc_current_locus.lb)
+ gfc_error ("Name %qs at %C is an ambiguous reference to %qs from"
+ "module %qs", name, st->n.sym->name, st->n.sym->module);
+ else
+ gfc_error ("Name %qs is an ambiguous reference to %qs, which is "
+ "available through USE association from module %qs at %L",
+ name, st->n.sym->name, st->n.sym->module,
+ &st->n.sym->declared_at);
+ }
else
gfc_error ("Name %qs at %C is an ambiguous reference to %qs "
"from current program unit", name, st->n.sym->name);
^ permalink raw reply [flat|nested] 8+ messages in thread* [Bug fortran/111218] Conflict in BIND(C) INTERFACEs in two Modules leads to ICE.
2023-08-28 19:28 [Bug fortran/111218] New: Conflict in BIND(C) INTERFACEs in two Modules leads to ICE toon at moene dot org
` (4 preceding siblings ...)
2023-10-14 2:00 ` kargl at gcc dot gnu.org
@ 2023-10-14 2:08 ` kargl at gcc dot gnu.org
2023-10-14 2:30 ` kargl at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: kargl at gcc dot gnu.org @ 2023-10-14 2:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111218
kargl at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P4
--- Comment #6 from kargl at gcc dot gnu.org ---
> if (st->n.sym->module)
> - gfc_error ("Name %qs at %C is an ambiguous reference to %qs "
> - "from module %qs", name, st->n.sym->name, st->n.sym->module);
> + {
> + if (gfc_current_locus.lb)
> + gfc_error ("Name %qs at %C is an ambiguous reference to %qs from"
A space is missing after "... from". Should be "... from "
> + "module %qs", name, st->n.sym->name, st->n.sym->module);
> + else
> + gfc_error ("Name %qs is an ambiguous reference to %qs, which is "
> + "available through USE association from module %qs at %L",
> + name, st->n.sym->name, st->n.sym->module,
> + &st->n.sym->declared_at);
> + }
> else
> gfc_error ("Name %qs at %C is an ambiguous reference to %qs "
> "from current program unit", name, st->n.sym->name);
The original code is too painful to read (aka uppercase and no formatting).
The claim is that the code is valid. Maybe it is as the conflicting
names in the modules are not referenced in the program unit. If OP
references SET_ABOR1_EXCEPTION_HANDLER, good luck.
^ permalink raw reply [flat|nested] 8+ messages in thread* [Bug fortran/111218] Conflict in BIND(C) INTERFACEs in two Modules leads to ICE.
2023-08-28 19:28 [Bug fortran/111218] New: Conflict in BIND(C) INTERFACEs in two Modules leads to ICE toon at moene dot org
` (5 preceding siblings ...)
2023-10-14 2:08 ` kargl at gcc dot gnu.org
@ 2023-10-14 2:30 ` kargl at gcc dot gnu.org
6 siblings, 0 replies; 8+ messages in thread
From: kargl at gcc dot gnu.org @ 2023-10-14 2:30 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111218
--- Comment #7 from kargl at gcc dot gnu.org ---
An alternative patch that allows the original code to compile is
diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
index a6078bc608a..34eb3a65e8f 100644
--- a/gcc/fortran/symbol.cc
+++ b/gcc/fortran/symbol.cc
@@ -3160,7 +3160,7 @@ static void
ambiguous_symbol (const char *name, gfc_symtree *st)
{
- if (st->n.sym->error)
+ if (st->n.sym->error || (st->n.sym->module && !gfc_current_locus.lb))
return;
if (st->n.sym->module)
This one simply returns. If one actually tries to reference the
conflicting entity an error message is generated.
^ permalink raw reply [flat|nested] 8+ messages in thread