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.
