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


On Mon, Nov 13, 2006 at 06:36:13PM -0800, Brooks Moses wrote:
> 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"?

Check the Standard.  That wording comes directly from F2003.

> 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. 

gfc_convert_integer issues an error of the form

Error: Can't convert INTEGER(42) to INTEGER(4) at (1).

If you prefer I can add a call to gfc_validate_kind right before
the BOZ conversion.

> (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.)

Yes, it disables checking because of BOZ constants of the form
z'ffffffff', which gfortran treats as an unsigned int during
the conversion.  Upon assignment to a INTEGER(4) variable, we
get the -1 (of twos compliment arithmetic).

-- 
Steve


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