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?
