https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94737
--- Comment #6 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
(In reply to Lee Busby from comment #4)
> (In reply to kargl from comment #3)
> > (In reply to Thomas Koenig from comment #2)
> > > Correction, this is not a regression.
> > >
> > > F2018 has, in 19.2, paragraph 2
> > >
> > > # The global identifier of an entity shall not be the same as the global
> > > # identifier of any other entity. Furthermore, a binding label shall not
> > > # be the same as the global identifier of any other global entity,
> > > # ignoring differences in case.
> > >
> > > So, the error message is correct, and you need to change your
> > > program accordingly.
> >
> > Good catch, Thomas!
> >
> > In hindsight, the restriction makes prefect sense given
> > Fortran is a case insensitive language.
>
> I don't have any particular problem using 19.2 to make this a feature, not a
> bug. Clarity is always better. I wonder how does 19.2 square with 8.5.5,
> lines 13-14:
>
> # If the value of the [NAME=scalar-character-constant] is [...] nonzero,
> # it shall be valid as an identifier on the companion processor.
>
> If you ignore the case of an identifier in the C language (the "companion
> processor"?), I suppose it is still "valid".
That's not what is happening.
According to the Fortran standard, we ignore the case when determining
if there is a duplicate global symbol, which we then reject.
You can use a C symbol with whatever case mix you want. Take, for
example
module foo
interface
function func1(ii) result (k) bind(c, name="C_fUnC")
integer :: ii
integer :: k
end function func1
end interface
contains
function func2(ii) result (k)
integer :: ii
integer :: k
k = func1(ii)
end function func2
end module foo
$ gfortran -c a.f90
$ nm a.o
U C_fUnC
0000000000000000 T __foo_MOD_func2
where you see an identifier "C_fUnC" (your external C function)
as an undefined symbol, so you can link it against an object
file containing that function, and all will be fine.
Regarding extensions: We have quite a few (maybe too many...)
for old features, for code that was written before modern
Fortran arrived. People need them, so we usually accept
patches for this kind of thing.
If there is a prohibition against the user doing something
in the standard, like in this case (marked by "shall" or
"shall not"), we usually try to identify the error to help
the user correct his code.
Hmm... I just checked, and found that, while we get this right,
there is no test case to make sure we don't regress. I will
add that shortly.
