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

[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.

[Bug fortran/85448] the compiler selects the wrong subroutine because of bind(c,name=...)

[francois.jacq at irsn dot fr]

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

--- Comment #5 from francois.jacq at irsn dot fr ---
On Thursday 19 April 2018 16:30:09 you wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85448
> 
> --- Comment #4 from Steve Kargl 
> ---
> 
> On Thu, Apr 19, 2018 at 09:07:15AM +0000, francois.jacq at irsn dot fr 
wrote:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85448
> > 
> > --- Comment #3 from francois.jacq at irsn dot fr ---
> > Notice that this is a regression : The version 4.8.5 returns the result I
> > expected...
> 
> Or it was a bug in 4.8.5 and is now fixed.
> 
> Now, the version where you rename odopen from m1
> to odopen_m1 is probably a bug.

No : both are bugs (and probably identical). The bind clause cannot change how 
the procedure name "odopen" has to be considered from the Fortran side !

Intel, Oracle and Nag compilers agree with me.

[Bug fortran/85448] the compiler selects the wrong subroutine because of bind(c,name=...)

[francois.jacq at irsn dot fr]

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

--- Comment #3 from francois.jacq at irsn dot fr ---
Notice that this is a regression : The version 4.8.5 returns the result I
expected...

[Bug fortran/85448] the compiler selects the wrong subroutine because of bind(c,name=...)

[francois.jacq at irsn dot fr]

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

--- Comment #2 from francois.jacq at irsn dot fr ---
(In reply to kargl from comment #1)
> (In reply to francois.jacq from comment #0)
> > In the following example, the subroutine c_open of the module m2, which
> > should call the subroutine odopen of the module m1, calls itself instead...
> 
> The behavior you see is correct.  There is no 'c_odopen'
> in the m2.o file.  You gave it the binding name 'odopen'.
> You have created a recursive call.

No the behavior is not correct : at least, the compiler should issue an error
message precising that there is a name conflict because odopen is also
accessible via the instruction use.

Another variant which clearly shows that the compiler behavior is wrong :

module m2
   use iso_c_binding
   use m1, only : odopen_m1 => odopen
   implicit none
   contains
   subroutine c_odopen(unit) bind(c,name="odopen")
  integer(c_int),intent(out) :: unit
  write(*,*) 'c_odopen'
  call odopen_m1(unit)
   end subroutine
end module

With this variant, I get again the same behavior : c_odopen is called
recursively

[Bug fortran/85448] New: the compiler selects the wrong subroutine because of bind(c,name=...)

[francois.jacq at irsn dot fr]

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

Bug ID: 85448
   Summary: the compiler selects the wrong subroutine because of
bind(c,name=...)
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: francois.jacq at irsn dot fr
  Target Milestone: ---

In the following example, the subroutine c_open of the module m2, which should
call the subroutine odopen of the module m1, calls itself instead...

Tested with gcc 4.9.2 , 5.3.0, 6.3.0

result :

dev005{bug} 114 : gfortran -c m1.f90 m2.f90
dev005{bug} 114 : gcc main.c *.o -lgfortran
dev005{bug} 114 : ./a.out
c_odopen
c_odopen
c_odopen
...

module m1
   implicit none
   contains
   subroutine odopen(unit)
  integer,intent(out) :: unit
  write(*,*) 'odopen'
  unit=8
   end subroutine
end module

module m2
   use iso_c_binding
   use m1
   implicit none
   contains
   subroutine c_odopen(unit) bind(c,name="odopen")
  integer(c_int),intent(out) :: unit
  write(*,*) 'c_odopen'
  call odopen(unit)
   end subroutine
end module

#include 
void odopen(int*);
int main(){
   int unit;
   odopen();
   printf("unit=%d \n",unit);
   return 0;
}

[Bug fortran/34640] ICE when assigning item of a derived-component to a pointer

[francois.jacq at irsn dot fr]

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

--- Comment #40 from francois.jacq at irsn dot fr ---
Happy to learn that this old bug is solved now. 9 years : just enough to get
good wine !

[Bug fortran/77525] wrong requirement of an upper bound for an array argument

[francois.jacq at irsn dot fr]

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

--- Comment #2 from francois.jacq at irsn dot fr ---
(In reply to Dominique d'Humieres from comment #1)
> Confirmed from 4.5 up to trunk (7.0). Fortran 2003: Procedure components at
> (1) are not yet implemented in gfortran-4.4.
> 
> > This is a regression because gfortran 4.9.2 is OK
> 
> Are you sure of that? I don't have 4.9.2, but I see the error with various
> 4.9.0 and 4.9.4.

No you are right ! It does not work even with gfortran-4.9.2

Sorry for that wrong remark...

[Bug fortran/77525] New: wrong requirement of an upper bound for an array argument

[francois.jacq at irsn dot fr]

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

Bug ID: 77525
   Summary: wrong requirement of an upper bound for an array
argument
   Product: gcc
   Version: 5.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: francois.jacq at irsn dot fr
  Target Milestone: ---

The following source file does not compile correctly with gfortran 5.3.0 and
5.3.1 
This is a regression because gfortran 4.9.2 is OK

coul@b10p5001:~/test$ gfortran -c mdb_proc.f90
mdb_proc.f90:41:19:

 call my_proc%f(tx,r)

Error: The upper bound in the last dimension must appear in the reference to
the assumed size array 'tx' at (1)

Source file :

module mdb_proc

   ! module managing external procedures to compute specific models

   implicit none
   private   
   save
   public :: listproc,mdb_proc_t

   abstract interface ! all possible signatures of user procedures
  subroutine p(tx,r)
 real,intent(in)  :: tx(*)
 real,intent(out) :: r
  end subroutine
   end interface

   type mdb_proc_t
  character(32):: cname
  integer  :: mode=0
  procedure(p) ,pointer,nopass :: f
   end type

   integer,parameter:: nprocmax=2048
   type(mdb_proc_t),target  :: listproc(0:nprocmax-1)

end module

subroutine test(tx,r)
use mdb_proc
implicit none
real,intent(in) :: tx(*)
real,intent(out) :: r
type(mdb_proc_t),pointer :: my_proc
my_proc => listproc(5)
call my_proc%f(tx,r)
end subroutine