https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556
--- Comment #24 from Steve Kargl <sgk at troutmask dot apl.washington.edu> --- On Mon, Sep 02, 2019 at 06:51:23PM +0000, anlauf at gcc dot gnu.org wrote: > 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. This is exactly why TYPE(*) was added to the Fortran standard. I would need to good spelunking on the J3 website, but I vaguely recal that Craig Rassmussen from the OpenMP standard committee championed it. From the Fortran 2018 standard An entity that is declared using the TYPE(*) type specifier is assumed-type and is an unlimited polymorphic entity. It is not declared to have a type, and is not considered to have the same declared type as any other entity, including another unlimited polymorphic entity. Its dynamic type and type parameters are assumed from its effective argument. Adding the INTERFACE in the code from comment #14 allows gfortran to use the effective type in the function calls. > > 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? Of course. Thomas quoted a part of the standard that indicate the code is invalid Fortran. I quoted a different line from the standard that indicates the code is invalid Fortran. gfortran is informing the user the code is broken. > Otherwise, can procedures without explicit interfaces be marked that they > are not eligible to this kind of optimization? It seems that you missed an important aspect of Thomas's patch. It allows one to find suspect subprogram references when the subprograms are implicitly defined. Go read the first 6 comments in the PR. Jurgen had a bug in his code. Thomas's patch generated an error pointing to the problem. With Jurgen's code, there is a big difference in passing a double precision value as opposed to the desired quad precision value. I'm having a hard time understanding why you think gfortran should continue to silently compile invalid, and possibly broken, code instead of actually alerting a user of an issue. I'm having an even harder time understanding why you want to have the ability to completely disable the
