https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90536
--- Comment #14 from Steve Kargl <sgk at troutmask dot apl.washington.edu> --- On Wed, May 22, 2019 at 11:21:52PM +0000, j.ravens.nz at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90536 > > --- Comment #13 from Jonathan Ravens <j.ravens.nz at gmail dot com> --- > Thanks everyone for your input on this issue. I hadn't realised thati > it could cause such dissent. There is no dissent. > As a software developer, my major driver is to manage the users' > expectations. > In that respect, declaring a byte and being able to set it to a valid value > should not raise a warning, especially when an option called no-range-check is > in use which, intuitively, would suppress range-checking errors instead of > causing them. I suggest it might only be technically correct from a > developer's perspective, but not from the user's. You appear to be conflating 2 issues. Range checking has nothing to do with type conversion. In your original code, you have a BOZ of '89'X (which to be standard conforming should be written as Z'89'). This BOZ is either an INTEGER(8) or INTEGER(16) (depends on the target) because gfortran follows how Fortran 95 handles a BOZ in a DATA statement (the only place a BOZ can appear in valid Fortran 95 code). It has a value of 137. So, you now have 2 problems when you are trying to assign it to a BYTE (aka INTEGER(1)) entity: 1) It is out-of-range. 2) It has a type of INTEGER(8) or INTEGER(16). -fno-range-check takes care of 1). -Wno-conversion takes care or 2). Now, when you have '09'X (or correctly Z'09'), this BOZ has a value of 9, but it is still a INTEGER(8) or INTEGER(16) entity. When gfortran performs the ranging checking for assigning 9 to a BYTE (aka INTEGER(1)) entity, it inibits the conversion warning because 9 is in range of a BYTE (aka INTEGER(1)). A warning isn't needed because gfortran knows there is no problem. When you specify -Wall -fno-range-check, the only thing that gfortran knows is that you're assigning an INTEGER(8) or INTEGER(16) entity to a BYTE (aka INTEGER(1)). So, gfortran brings the potential problem to your attention. You specifically requested this behavior via the options! > If commonly-used constructs such as BYTE are to be removed from gfortran, I'd > expect that to require a lot of re-coding for people in general, given the > amount of legacy Fortran code in use. In our case, I think the best option > would be to phase out usage of gfortran. No decisions have been made. I'll raise an RFC about deprecation of a number of mistakes in gfortran (when time permits as I am not paid to contribute to gfortran). The plan would be to issue a deprecation notice in the 10.x releases of gfortran with removal of the mistakes in 11.1. A deprection notice cannot be suppressed by an option, so user will see the notice everytime the user compiles his/her code. So, removal won't happen for 2 or more years. If removal of a mistake such as BYTE causes you to stop using gfortran, oh well.
