[Bug fortran/94737] BIND(C) names are not always treated as case sensitive.

["sgk at troutmask dot apl.washington.edu" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94737

--- Comment #5 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Sun, Apr 26, 2020 at 02:39:37AM +0000, busby1 at llnl dot gov wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94737
> 
> --- Comment #4 from Lee Busby <busby1 at llnl dot gov> ---
> (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".  But it's the wrong one.  Oh,
> well, above my pay grade.  Thank you for your investigation, and ongoing work
> on gfortran.
> 

I suppose I don't quite follow you.  gfortran flagged an
error in your code.  Thomas took the time to locate the
passage in the Fortran standard that confirms you have
an error in your code.  You would rather ask the diminishing
number of volunteers to add an extension to gfortran to
to compile your nonconforming code than fix the code.
Seems reasonable.