This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [FORTRAN] New -fboz-kind option to aid compilation of legacy code


Steve Kargl wrote:
Index: gfortran.texi
===================================================================
--- gfortran.texi (revision 118777)
+++ gfortran.texi (working copy)
@@ -908,10 +908,12 @@ in any initialization expression as well
Attempts to use a BOZ literal constant to do a bitwise initialization of a
variable can lead to confusion. A BOZ literal constant is converted to an
-@code{INTEGER} value with the kind type with the largest decimal representation,
-and this value is then converted numerically to the type and kind of the
-variable in question. Thus, one should not expect a bitwise copy of the BOZ
-literal constant to be assigned to a @code{REAL} variable.
+@code{INTEGER} value with the kind type with the largest decimal exponent
+range, and this value is then converted numerically to the type and kind
+of the variable in question. Thus, one should not expect a bitwise copy
+of the BOZ literal constant to be assigned to a @code{REAL} variable.
+The kind type parameter of the conversion can be controlled by the
+@option{-fboz-kind=@var{n}} option.

Though I agree that the "largest decimal representation" wording should be improved, I don't quite like the idea of an integer type with an "exponent range". Perhaps just "largest range"?


Also, there isn't a check to confirm that a valid kind type is supplied, and so I'll bet you ICE on an invalid kind. Unfortunately, this can't be checked in options.c (despite the fact that -qkind tried to do it that way), since the kind types haven't been processed when that's run. I'd suggest that the right place to put the validity check is at the end of gfc_init_kinds, in trans-types.c. To simply cut-and-pasting the check from the old -qkind code, here's what it had:

 if (gfc_validate_kind (BT_REAL, value, true) < 0)
   gfc_fatal_error ("Argument to -fqkind isn't a valid real kind");

(I would have been tempted to suggest that once you add the check to trans-types.c, it would be simpler to expand that check to set gfc_option.flag_boz_kind to gfc_max_integer_kind if 0 is given, rather than switching between the two in primary.c. But I see that you're also using the flag to disable range checking, so that isn't quite so simple.)


- Brooks


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]