This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Committed] PR fortran/54072 -- More fun with BOZ
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