[PATCH,Fortran] Handle 'q' exponent-letter in real-literal-constant

Steve Kargl sgk@troutmask.apl.washington.edu
Tue Apr 26 23:44:00 GMT 2011


On Wed, Apr 27, 2011 at 12:23:03AM +0200, Mikael Morin wrote:
> On Tuesday 26 April 2011 18:52:58 Steve Kargl wrote:
> > On Mon, Apr 25, 2011 at 11:15:35PM +0300, Janne Blomqvist wrote:
> > > On Mon, Apr 25, 2011 at 22:45, Steve Kargl
> > > 
> > > <sgk@troutmask.apl.washington.edu> wrote:
> > > > On Mon, Apr 25, 2011 at 10:26:20PM +0300, Janne Blomqvist wrote:
> > > >> Hmm, I'd prefer if the warning was issued only with -Wsomething which
> > > >> would be included in -Wall. But I suppose this can be done as a
> > > >> follow-up patch.
> > > > 
> > > > I thought about adding a -freal-q-constant option.
> > > 
> > > -Wreal-q-constant, presumably?
> > 
> > Yes.  I've implemented in the revised patch, and I've
> > updated the docs.
> > 
> > 2011-04-26  Steven G. Kargl  <kargl@gcc.gnu.org>
> > 
> > 	PR fortran/48720
> > 	* gfortran.texi: Document the 'Q' exponent-letter extension.
> > 	* invoke.texi: Document -Wreal-q-constant.
> > 	* lang.opt: Add -Wreal-q-constant option.
> > 	* gfortran.h: Add warn_real_q_constant to option struct.
> > 	* primary.c (match_real_constant):  Use it.  Accept 'Q' as
> > 	exponent-letter for REAL(16) real-literal-constant with a
> > 	fallback to REAL(10) or error if REAL(10) is not available.
> > 	* options.c (gfc_init_options, set_Wall) Set it.
> > 	(gfc_handle_option): Handle new option.
> > 
> > OK?
> Sorry to jump late on this.
> 

No problem.  I would rather get it right than rush something
into the tree.

> > Index: primary.c
> > ===================================================================
> > --- primary.c   (revision 172974)
> > +++ primary.c   (working copy)
> > @@ -541,6 +541,17 @@ match_real_constant (gfc_expr **result, 
> >      goto done;
> >    exp_char = c;
> >  
> > +
> > +  if (c == 'q')
> > +    {
> > +      if (gfc_notify_std (GFC_STD_GNU, "Extension: exponent-letter 'q' in "
> > +                        "real-literal-constant at %C") == FAILURE)
> > +       return MATCH_ERROR;
> > +      else if (gfc_option.warn_real_q_constant)
> > +       gfc_warning("Extension: exponent-letter 'q' in real-literal-constant 
> "
> > +                   "at %C");
> > +    }
> I think the above could generate double warnings. With -pedantic for example 
> (but I didn't check). 

It's an 'if -- else if' construct.  If gfc_notify_std == FAILURE, then
the error message is issues and the function returns.   If it is TRUE,
then there should be no messages and else if() is tested.

laptop:kargl[204] gfc4x -pedantic -o z ui.f90
ui.f90:3.12:

   q = 1.23q45
            1
Warning: Extension: exponent-letter 'q' in real-literal-constant at (1)
laptop:kargl[205] gfc4x -pedantic -o z -std=f95 ui.f90
ui.f90:3.12:

   q = 1.23q45
            1
Error: Extension: exponent-letter 'q' in real-literal-constant at (1)

> By the way testcases are missing :-p.

I haven't figure out how to write the testcases (yet).  :-)

> > @@ -616,6 +627,29 @@ done:
> >        kind = gfc_default_double_kind;
> >        break;
> >  
> > +    case 'q':
> > +      if (kind != -2)
> > +       {
> > +         gfc_error ("Real number at %C has a 'q' exponent and an explicit "
> > +                    "kind");
> > +         goto cleanup;
> > +       }
> > +
> > +      /* The maximum possible real kind type parameter is 16.  First, try
> > +        that for the kind, then fallback to trying kind=10 (Intel 80 bit)
> > +        extended precision.  If neither value works, just given up.  */
> > +      kind = 16;
> > +      if (gfc_validate_kind (BT_REAL, kind, true) < 0)
> > +       {
> > +         kind = 10;
> > +          if (gfc_validate_kind (BT_REAL, kind, true) < 0)
> > +           {
> > +             gfc_error ("Invalid real kind %d at %C", kind);
> > +             goto cleanup;
> > +           }
> Here kind is guaranteed to be 10 in the error. As the user didn't specify 
> kind=10 explicitely, I suggest a more informative message like (for example):
> Use of 'q' exponent requires REAL(16) or REAL(10) support at %C

Good catch!  I'll update the error message based on your suggestion.

-- 
Steve



More information about the Gcc-patches mailing list