https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118932
--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #2)
> I think the relevant sentence from 19.2, paragraph 2, is
>
> "Furthermore, a binding label shall not be the same as the global identifier
> of any other global entity, ignoring differences in case."
[...]
> I think this is an unfortunate choice, but it is the way the
> standard is written.
Hmmm, too bad. I wonder if the committee was aware of the consequence
that this limits the usefulness of binding labels, given that there is
quite some text explaining their utility.
E.g. 18.10.2 has the following text in the Note:
"[...]
ISO/IEC 9899:2018 permits functions to have names that are not permitted as
Fortran names; it also distinguishes between names that would be considered
as the same name in Fortran. For example, a C name can begin with an
underscore, and C names that differ in case are distinct names.
The specification of a binding label allows a program to use a Fortran name to
refer to a procedure defined by a companion processor."
and similar text for variables and common blocks, stressing linkage
association.
Which is why I think that for entities with explicit C binding one must have
had the C side in mind more than the Fortran side.
And as it could happen that there is an external C procedure "aaa" and an
external integer variable "AAA", one could only use these via something like
module m
use iso_c_binding, only: c_int
implicit none
integer(c_int), bind(c,name="AAA") :: external_var ! ICE
! integer(c_int), bind(c,name="AAA_") :: external_var ! OK
interface
subroutine external_sub () bind(c,name="aaa")
end subroutine external_sub
end interface
contains
subroutine sub ()
external_var = 42
call external_sub ()
end subroutine sub
end
Compiling this with ifx or nagfor, one finds the expected symbols:
% nm pr118932.o | head -2
U aaa
0000000000000004 C AAA
Assuming the standard text strictly, it would be possible to access either
one or the other, but not both. I find it hard to understand that one
would really want to prohibit this.
BTW: the above example ICEs here (since gcc-8:
pr118932.f90:17:24:
17 | call external_sub ()
| 1
internal compiler error: in conv_function_val, at fortran/trans-expr.cc:4696
0x35a3b64 internal_error(char const*, ...)
../../gcc-trunk/gcc/diagnostic-global-context.cc:517
0xdb9b3c fancy_abort(char const*, int, char const*)
../../gcc-trunk/gcc/diagnostic.cc:1722
0xd63dea conv_function_val
../../gcc-trunk/gcc/fortran/trans-expr.cc:4696
0xf2190b gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec<tree_node*, va_gc, vl_embed>*)
../../gcc-trunk/gcc/fortran/trans-expr.cc:8615
0xf80702 gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool)
../../gcc-trunk/gcc/fortran/trans-stmt.cc:425
0xedadbc trans_code
../../gcc-trunk/gcc/fortran/trans.cc:2406
0xf1380b gfc_generate_function_code(gfc_namespace*)
../../gcc-trunk/gcc/fortran/trans-decl.cc:8065
0xee01f1 gfc_generate_module_code(gfc_namespace*)
../../gcc-trunk/gcc/fortran/trans.cc:2765
0xe7e9ae translate_all_program_units
../../gcc-trunk/gcc/fortran/parse.cc:7435
0xe7e9ae gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.cc:7768
0xed773f gfc_be_parse_file
../../gcc-trunk/gcc/fortran/f95-lang.cc:241
So there is at least one real issue here, and the question is:
ice-on-valid or ice-on-invalid? ;-)
