On Thu, Aug 08, 2019 at 09:23:11AM -0700, Steve Kargl wrote: > On Thu, Aug 08, 2019 at 10:11:39AM +0100, Mark Eggleston wrote: > > > > >> Comparisons with BOZ constants was allowed using 9.1 with > > >> -Wconversion-extra: > > >> > > >> 5 | if (i4 .eq. z'1000') then > > >> | 1 > > >> Warning: Conversion from INTEGER(4) to INTEGER(16) at (1) > > >> [-Wconversion-extra] > > > This is the old behavior were a BOZ upon parsing is > > > immediately converted to an INTEGER with the widest decimal > > > range. It is a holdover from when I made BOZ work in > > > accordance with the Fortran 95 standard, where a BOZ is > > > only allowed as a data-stmt-constant. On your target, that > > > is INTEGER(16). Because of that conversion, a BOZ could > > > be used anywhere an INTEGER can be used. > > > > Other invalid BOZ usage is enable with -fallow-invalid-box, why not this? > > > > This is from a test suite for a customer to check that gfortran supports > > various legacy features. This feature is supported by all the compilers > > they use including gfortran up to 9.1. This change will break legacy > > code. > > Because, I choose not to support invalid code. One would need > to add a bunch of code to expr.c(simplify_intrinsic_op) to > detect the BOZ usage and report an error or warning and then > do some conversion. What does one do with
Ugh. expr.c(simplify_intrinsic_op) would need updates if we do some sort of constant-folding of BOZs. For resolution of 'if (i .eq. z"123")' one gets to resolve.c(resolve_operator). The same questions still apply. -- Steve
