[Bug fortran/94737] New: BIND(C) names are not always treated as case sensitive. Versions < 8 are ok.

[Bug fortran/94737] New: BIND(C) names are not always treated as case sensitive. Versions < 8 are ok.

[busby1 at llnl dot gov]

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

            Bug ID: 94737
           Summary: BIND(C) names are not always treated as case
                    sensitive.  Versions < 8 are ok.
           Product: gcc
           Version: 8.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: busby1 at llnl dot gov
  Target Milestone: ---

Created attachment 48365
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48365&action=edit
A fortran module.  Compilation instructions (Linux) and output are in it

I will attach a small reproducer for the problem.  There is an obvious
workaround in this case, to use a C name that is unique even if case
sensitivity is disregarded.  I do not have easy access to gfortran version 9 or
10, sorry I cannot report on those.

Thank you,
Lee Busby

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

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4
                 CC|                            |kargl at gcc dot gnu.org
   Last reconfirmed|                            |2020-04-23
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
      Known to fail|                            |10.0, 8.1.0

--- Comment #1 from kargl at gcc dot gnu.org ---
This also fails with trunk as svn revision 280157.  The following trivial patch
allows your code to compile.

Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c       (revision 280157)
+++ gcc/fortran/resolve.c       (working copy)
@@ -2517,8 +2517,14 @@ resolve_global_procedure (gfc_symbol *sym, locus *wher
   gsym = gfc_get_gsymbol (sym->binding_label ? sym->binding_label : sym->name,
                          sym->binding_label != NULL);

-  if ((gsym->type != GSYM_UNKNOWN && gsym->type != type))
-    gfc_global_used (gsym, where);
+  if (gsym->type != GSYM_UNKNOWN && gsym->type != type)
+    {
+      if (sym->binding_label && gsym->binding_label
+         && strcmp (sym->binding_label, gsym->binding_label) != 0)
+       ;
+      else
+       gfc_global_used (gsym, where);
+    }

   if ((sym->attr.if_source == IFSRC_UNKNOWN
        || sym->attr.if_source == IFSRC_IFBODY)




Passing the created *.mod file through gunzip shows

3 'func1' 'foo' 'c_func' 1 ((PROCEDURE UNKNOWN-INTENT EXTERNAL-PROC BODY
UNKNOWN 0 0 EXTERNAL FUNCTION IS_BIND_C IS_C_INTEROP
ARRAY_OUTER_DEPENDENCY) () (INTEGER 4 0 1 0 INTEGER ()) 4 0 (5) () 6 ()
() () 0 0)

11 'sub1' 'foo' 'c_Func' 1 ((PROCEDURE UNKNOWN-INTENT MODULE-PROC BODY
UNKNOWN 0 0 EXTERNAL SUBROUTINE IS_BIND_C IS_C_INTEROP
ARRAY_OUTER_DEPENDENCY) () (UNKNOWN 0 0 1 0 UNKNOWN ()) 12 0 (13 14) ()

so I suspect it works.  Probably, need to expand the test to skip the
error path to do comparisons involving sym->name and gsym->name.  Just
details for someone else to consider.

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

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|BIND(C) names are not       |[8/9/10 Regression] BIND(C)
                   |always treated as case      |names are not always
                   |sensitive.  Versions < 8    |treated as case sensitive.
                   |are ok.                     |
           Keywords|                            |rejects-valid
                 CC|                            |tkoenig at gcc dot gnu.org
   Target Milestone|---                         |8.5

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

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
            Summary|[8/9/10 Regression] BIND(C) |BIND(C) names are not
                   |names are not always        |always treated as case
                   |treated as case sensitive.  |sensitive.
         Resolution|---                         |INVALID

--- Comment #2 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
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.

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

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|rejects-valid               |

--- Comment #3 from kargl at gcc dot gnu.org ---
(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.

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

[busby1 at llnl dot gov]

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.

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

[sgk at troutmask dot apl.washington.edu]

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.

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

[tkoenig at gcc dot gnu.org]

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.

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Thomas Kथà¤nig <tkoenig@gcc.gnu.org>:

https://gcc.gnu.org/g:870923cd48e1e715120ff68425437e5b346283a1

commit r10-7972-g870923cd48e1e715120ff68425437e5b346283a1
Author: Thomas Koenig <tkoenig@gcc.gnu.org>
Date:   Sun Apr 26 14:57:16 2020 +0200

    Added test case from PR 94737.

    2020-04-26  Thomas Koenig  <tkoenig@gcc.gnu.org>

            PR fortran/94737
            * gfortran.dg/binding_label_tests_34.f90: New test case.

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

[tkoenig at gcc dot gnu.org]

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

--- Comment #8 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
So, test case committed.

Thanks for the bug report!  Even though it turned out to be invalid,
it still ended up making the compiler better.