Hi Steve,
On 10/25/19 4:17 PM, Steve Kargl wrote:
My BOZ patch brought gfortran closer to an actual comforming Fortran
compiler while providing an option that would allow quite a few
documented and undocumented extensions. If the patch broke some of
your code, and -fallow-invalid-boz did not allow the code to compile
Actually, it does allow it to compile – but I missed the option;
-std=legacy used to be sufficient.
For the code at hand, it was actually better to nag the author to change
the code to valid Fortran than to fiddle around with some options.
But I think that point to a problem: Some compiler flags do exist, but
it is are hard to find them (especially, if one does not know that they
do exist). … I am not claiming that it should be done in this case, but
sometimes something like:
"Error: BOZ literal constant at (1) is neither a DATA statement value
nor an actual argument of INT/REAL/DBLE/CMPLX intrinsic subprogram; _for
legacy code, -fallow-invalid-boz might be an option"_
would have surely helped.**
Side note: to me, "the … intrinsic function" is clearer than "…
intrinsic subprogram".
and you were forced to use INT(, kind=) to get it to compile
Well, using INT() was the way in order to get the code standard
conforming :-)
As you you quoted:
C410 (R411) A boz-literal-constant shall appear only as a
data-stmt-constant in a DATA statement, as the actual
argument associated with the dummy argument A of the
numeric intrinsic functions DBLE, REAL or INT, or as
the actual argument associated with the X or Y dummy
argument of the intrinsic function CMPLX.
Cheers,
Tobias
**This does not mean that users will always read this. (I get this
error, what shall I do?) Nor that fixing the code would be usually be
the better option. (As in my case.)
