[Bug fortran/91556] Problems with better interface checking

[anlauf at gcc dot gnu.org]

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

--- Comment #23 from anlauf at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #22)
> A problem with such code is that type violations like that are likely to
> cause
> actual wrong code issues because much of the aliasing analysis is type
> based...
> 
> What I could do is to
> 
> a) restrict the number of warnings for each routine to one (put a flag
>    Into the gsym)
> 
> b) try to figure something out to make this harmless to the middle end...
> like
>    passing a void* instead of a reference.

I do see that there was a motivation for the change.  However, I think that
the resolution happens at the wrong time and comes to wrong conclusions.

The example in comment#14 compiles if I add e.g.

  interface
     subroutine my_mpi_bcast_wrapper (buffer, len)
       type(*), dimension(..) :: buffer
       integer, intent(in)    :: len
     end subroutine my_mpi_bcast_wrapper
  end interface

which I think is the appropriate explicit interface *if* it needs to be
explicitly given.  Then the code compiles without any warnings.

> If we just continue to ignore this error, is is going to bite people sooner
> or
> later. And wehn somevody finds that a complex  MPI code no longer works, I
> want
> to have that warning in the build log.

A warning by default would be fine with me, especially when it can be turned
off.  I am not happy to make this an error.
(I may have a different opinion for a varying number of arguments to a
procedure.)

> Also, this sort of code is a major obstacle for LTO, If we do not fix this,
> then
> I might as well give up on making gfortran LTO clean.

Is the current treatment only necessary for LTO?

How does LTO handle TYPE(*) etc.?  It has to be able to deal with it!

Otherwise, can procedures without explicit interfaces be marked that they
are not eligible to this kind of optimization?