[Bug fortran/85448] Report binding label clash with a global identifyer

2019-04-14 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85448

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Thomas Koenig  ---
Test case committed, closing.

[Bug fortran/85448] Report binding label clash with a global identifyer

2019-04-14 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85448

--- Comment #10 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Apr 14 20:15:48 2019
New Revision: 270354

URL: https://gcc.gnu.org/viewcvs?rev=270354=gcc=rev
Log:
2019-04-14  Thomas Koenig  

PR fortran/85448
* gfortran.dg/bind_c_usage_33.f90: New test and...
* gfortran.dg/bind_c_usage_33_c.c: Additional source.


Added:
trunk/gcc/testsuite/gfortran.dg/bind_c_usage_33.f90
trunk/gcc/testsuite/gfortran.dg/bind_c_usage_33_c.c
Modified:
trunk/gcc/testsuite/ChangeLog

[Bug fortran/85448] Report binding label clash with a global identifyer

2019-04-14 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85448

--- Comment #9 from Thomas Koenig  ---
With current trunk, I get

$ gfortran od.c odopen.f90 
$ ./a.out
 c_odopen
 odopen
unit=8 
$ gfortran od.c odopen.f90 
$ ./a.out
 c_odopen
 odopen
unit=8
$ 

which looks correct.

So, I'm going to commit a test case (better safe than sorry) and
close as fixed.

[Bug fortran/85448] Report binding label clash with a global identifyer

2018-04-20 Thread francois.jacq at irsn dot fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85448

--- Comment #8 from francois.jacq at irsn dot fr ---
(In reply to Thomas Koenig from comment #7)
> As quoted by Steve Lionel on c.l.f (F2008, 16.2, para 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 code is invalid. Since this is not a constraint, the compiler
> can do anything it pleases.
> 
> It would be nice to have an error message, though; should be straightforward
> to implement.

Unfortunately, if you look into the comment #2, you will understand that the
situation is a little bit more subtile.