http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61069
--- Comment #2 from Tristan Moody <tristanmoody at gmail dot com> --- Of course the code is invalid. That's the point. The compiler is inconsistent about whether it will catch that fact. This invalid code could easily show up, say, when refactoring a large code base, converting a subroutine to a function, wherein a subroutine call gets missed. Since this is a case of the compiler treating invalid code as valid and not the reverse, a fix is low priority, if not unnecessary. I just think it should, at the very least, be noted in the documentation. For what it's worth, neither the Intel nor the Portland compilers detected that the code was invalid, even when everything was in a single source file. On May 5, 2014 5:33 PM, "dominiq at lps dot ens.fr" < gcc-bugzi...@gcc.gnu.org> wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61069 > > --- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> --- > Your code is invalid and the compiler can do anything. Note that if you > type > bar as you should, gfortran complains: > > ! { dg-do compile } > program foo > implicit none > integer :: i, bar > external bar, baz > > i = 0 > call bar(i) > ! print *, bar(i) > call baz(i) > end program > > gives > > pr61069_3.f90:4.19: > > integer :: i, bar > 1 > Error: FUNCTION attribute conflicts with SUBROUTINE attribute in 'bar' at > (1) > pr61069_3.f90:4.19: > > integer :: i, bar > 1 > pr61069_3.f90:8.13: > > call bar(i) > 2 > Error: 'bar' at (1) has a type, which is not consistent with the CALL at > (2) > > -- > You are receiving this mail because: > You reported the bug. >
