https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91752
--- Comment #5 from Steve Kargl <sgk at troutmask dot apl.washington.edu> --- On Fri, Sep 13, 2019 at 07:34:11AM +0000, juergen.reuter at desy dot de wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91752 > > --- Comment #4 from Jürgen Reuter <juergen.reuter at desy dot de> --- > (In reply to kargl from comment #3) > > See the documentation. -fallow-invalid-boz reduces the error to a warning. > > The warning can only be silenced by -w. This was done with intent. > > Actually not all of them, this one is still flagged as an error: > implicit none > integer :: h > h = B"11" > select case (h) > case (B"11") > print *, "Found" > end select > end > That is the intended behavior. I did not try to allow every previous invalid use of BOZ. When I made BOZ work 15 years ago, I implemented the requirement of F95 that a BOZ is converted to the integer with the widest decimal range (ie, either INTEGER(8) or INTEGER(16)). A BOZ was parsed and immediately converted, so a BOZ could appear in any place that an INTEGER could appear. That was a mistake, and undocumented behavior. I have corrected that mistake. This used to compile with gfortran where INTEGER(8) is the integer with widest kind: module m interface prn module procedure prn4 module procedure prn8 end interface prn contains subroutine prn4(i) integer(4), intent(in) :: i print *, i end subroutine prn4 subroutine prn8(i) integer(8), intent(in) :: i print *, i end subroutine prn8 end module m program foo use m call prn(B'11') end program foo It now issues an error and -fallow-invalid-boz will not downgrade the error in this case. Because a BOZ is a typeless and kindless entity, there is no way to resolve the interface. Sure, you can argue that if gfortran use to compile some garbage code, it should always compile that garbage code. My stance is gfortran should reject the garbage.
