[Bug fortran/113254] New: Option -fallow-invalid-boz does not help with sample code

[Bug fortran/113254] New: Option -fallow-invalid-boz does not help with sample code

[xecej4 at outlook dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113254

            Bug ID: 113254
           Summary: Option -fallow-invalid-boz does not help with sample
                    code
           Product: gcc
           Version: 11.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: xecej4 at outlook dot com
  Target Milestone: ---

Created attachment 56999
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56999&action=edit
Fortran program to illustrate no benefit from -fallow-invalid-boz

The -fallow-invalid-boz option is described to have this purpose: "... allows a
BOZ literal constant to appear where the Fortran standard would otherwise
prohibit its use". 

The option appears to have no effect on the attached test program, and the
error message is the same with or without -fallow-invalid-boz. (I am also using
-fmax-errors=1.)

[Bug fortran/113254] Option -fallow-invalid-boz does not help with sample code

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113254

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org
           Priority|P3                          |P4

--- Comment #1 from kargl at gcc dot gnu.org ---
-fallow-invalid-boz is not a panacea for invalid Fortran.

F2018 has

   F2018:C7110 (R770) If type-spec is omitted, each ac-value expression
   in the array-constructor shall have the same declared type and kind
   type parameters.

   F2018:C7111 (R770) If type-spec specifies an intrinsic type, each ac-value
   expression in the array-constructor shall be of an intrinsic type that
   is in type conformance with a variable of type type-spec as specified in
   Table 10.8.

As a BOZ is typeless, it therefore cannot be in an array constructor.
Even if you had added a type-spec such as '[integer :: ...]'.

F2023 does allow a BOZ in an array constructor, with the following constraints:

   F2023:C7126 If an ac-value is a boz-literal-constant, type-spec shall
   appear and shall specify type integer or real.

   F2023:C7127 If an ac-value is a boz-literal-constant and type-spec
   specifies type real, the boz-literal-constant shall be a valid internal
   representation for the specified kind of real.

Your code lacks a type-spec, so C7126 kicks in.  Even with a type-spec,
as this is a new F2023 feature, gfortran does not currently support a BOZ
in an array-constructor.

Adding this capability would be a good introduction to contributing to
gfortran development.

[Bug fortran/113254] Option -fallow-invalid-boz does not help with sample code

[xecej4 at outlook dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113254

--- Comment #2 from mecej4 <xecej4 at outlook dot com> ---
Created attachment 57001
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57001&action=edit
Program source that is handled correctly when -fallow-invalid-boz is specified

[Bug fortran/113254] Option -fallow-invalid-boz does not help with sample code

[kargl at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113254

--- Comment #3 from kargl at gcc dot gnu.org ---
(In reply to mecej4 from comment #2)
> Created attachment 57001 [details]
> Program source that is handled correctly when -fallow-invalid-boz is
> specified

Correctly?  It is not the same as the initial case.

For [B'01111111',B'10111111', ...], each of the BOZ is an ac-value.
See the Fortran standards for the constraints that I already cited.
A BOZ cannot be an ac-value.  It is typeless.  Should gfortran convert
B'01111111' to 127 or 1.77964905E-43?  Remember a BOZ is typeless,
and prior to F2023, the RHS is evaluated without regard to the type and
kind of the LHS.

For the new case of [char(B'01111111'),char(B'10111111'), ...], the
BOZ are actual arguments to some intrinsic subprogram.  These BOZ are
not ac-values.  The error message(s) actually tells you that this is invalid.
Gfortran accepts these actual-argument BOZ with the -fallow-invalid-boz,
because older versions of gfortran would convert a BOZ to an integer upon
reading the BOZ from the source code.  The actual argument of char() happens
to be of type integer, so you got lucky!

Consider the equally egregious example:

   program bozz
      implicit none
      real, parameter :: x = sin(B'01111111')
      print *, x
   end program

% gfcx -o z a.f90
a.f90:4:28:

    4 |    real, parameter :: x=sin(B'01111111')
      |                            1
Error: A BOZ literal constant at (1) cannot appear as an actual argument in a
function reference

% gfcx -o z a.f90 -fallow-invalid-boz
a.f90:4:28:

    4 |    real, parameter :: x=sin(B'01111111')
      |                            1
Error: A BOZ literal constant at (1) cannot appear as an actual argument in a
function reference

[integer ::  B'01111111',B'10111111', ...] is F2023 standard conforming.
gfortran does not currently support this new feature of F2023.  It should
not be too hard to support F2023, but that would require someone to either
provide a patch or provide funding for someone else to provide the patch.