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

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

[Steve Kargl]

Historically, gfortran has accepted real-literal-constants
of the form 1.23Q45 as single precision values.  Many commercial
compilers (dating back years) have used the 'Q' exponent-letter
to mean quadruple precision.  With the addition of software
support for REAL(16) on i386 and x86_64 targets, I anticipate
an increase in use of the 'Q' form.  The attached patch does
the following:

1) If REAL(16) is available, a real-literal-constant with a 'Q'
   exponent-letter is accepted as a REAL(16) entity.

2) If REAL(16) is not available but REAL(10) is, then the constant
   is accepted as a REAL(10).

3) If neither REAL(16) nor REAL(10) is available, an error is 
   issued.

4) An error is issued if one uses -std=f95, f2003, or f2008; otherwise
   a warning will be issued.  The only way to disable the warning is
   to either fix the code to conform to the Fortran standard or use
   -w to disable warnings.

5) If the constant has the form 1.23Q45_16 (ie., a integer kind
   suffix is appended to the value), then an error is issued.  This
   is similar to the requirement that 1.23D45_xyz violated the 
   Fortran Standard.

The attached patch has been built and regression
tested on x86_64-*-freebsd.  There were no regression
with the patch.  OK for trunk (and 4.6 branch after
testing)?

2011-04-25  Steven G. Kargl  <kargl@gcc.gnu.org.>

	PR fortran/48720
	* gfortran.texi: Document the 'Q' exponent-letter extension.
	* primary.c (match_real_constant):  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.

-- 
Steve

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

[Steve Kargl]

[-- Attachment #1: Type: text/plain, Size: 445 bytes --]

On Mon, Apr 25, 2011 at 11:42:07AM -0700, Steve Kargl wrote:
> 
> 2011-04-25  Steven G. Kargl  <kargl@gcc.gnu.org.>
> 
> 	PR fortran/48720
> 	* gfortran.texi: Document the 'Q' exponent-letter extension.
> 	* primary.c (match_real_constant):  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.

Of course, it would be helpful to include the patch.

-- 
Steve

[-- Attachment #2: qformat.diff --]
[-- Type: text/x-diff, Size: 2961 bytes --]

Index: gfortran.texi
===================================================================
--- gfortran.texi	(revision 172773)
+++ gfortran.texi	(working copy)
@@ -1237,6 +1237,7 @@ without warning.
 * Missing period in FORMAT specifications::
 * I/O item lists::
 * BOZ literal constants::
+* @code{Q} exponent-letter::
 * Real array indices::
 * Unary operators::
 * Implicitly convert LOGICAL and INTEGER values::
@@ -1427,6 +1428,23 @@ To support legacy codes, GNU Fortran all
 of the @code{READ} statement, and the output item lists of the
 @code{WRITE} and @code{PRINT} statements, to start with a comma.
 
+@node @code{Q} exponent-letter
+@subsection @code{Q} exponent-letter
+@cindex @code{Q} exponent-letter
+
+GNU Fortran accepts real literal constants with an exponent-letter
+of @code{Q}, for example, @code{1.23Q45}.  Prior to version 4.6.1,
+GNU Fortran silently accepted @code{Q} as an alias for the single
+precision exponent-letter @code{E}.  With the introduction of software
+support for @code{REAL(16)} (i.e., quadruple precision) on i386 and
+x86_64 targets, the interpretation of @code{Q} has been updated to
+mean a @code{REAL(16)} real-literal-constant.  This aligns GNU Fortran
+with many commercially available compilers.  If the target does not
+support @code{REAL(16)} but has a @code{REAL(10)} type, then the
+real-literal-constant will be interpreted as a @code{REAL(10)} entity.
+In the absence of @code{REAL(16)} and @code{REAL(10)}, an error will
+occur.
+
 @node BOZ literal constants
 @subsection BOZ literal constants
 @cindex BOZ literal constants
Index: primary.c
===================================================================
--- primary.c	(revision 172773)
+++ 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
+	gfc_warning("Extension: exponent-letter 'q' in real-literal-constant "
+		    "at %C");
+    }
+
   /* Scan exponent.  */
   c = gfc_next_ascii_char ();
   count++;
@@ -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;
+	    }
+	}
+      break;
+
     default:
       if (kind == -2)
 	kind = gfc_default_real_kind;

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

[Janne Blomqvist]

On Mon, Apr 25, 2011 at 21:42, Steve Kargl
<sgk@troutmask.apl.washington.edu> wrote:
> Historically, gfortran has accepted real-literal-constants
> of the form 1.23Q45 as single precision values.  Many commercial
> compilers (dating back years) have used the 'Q' exponent-letter
> to mean quadruple precision.  With the addition of software
> support for REAL(16) on i386 and x86_64 targets, I anticipate
> an increase in use of the 'Q' form.  The attached patch does
> the following:
>
> 1) If REAL(16) is available, a real-literal-constant with a 'Q'
>   exponent-letter is accepted as a REAL(16) entity.
>
> 2) If REAL(16) is not available but REAL(10) is, then the constant
>   is accepted as a REAL(10).
>
> 3) If neither REAL(16) nor REAL(10) is available, an error is
>   issued.
>
> 4) An error is issued if one uses -std=f95, f2003, or f2008; otherwise
>   a warning will be issued.  The only way to disable the warning is
>   to either fix the code to conform to the Fortran standard or use
>   -w to disable warnings.

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.

> 5) If the constant has the form 1.23Q45_16 (ie., a integer kind
>   suffix is appended to the value), then an error is issued.  This
>   is similar to the requirement that 1.23D45_xyz violated the
>   Fortran Standard.
>
> The attached patch has been built and regression
> tested on x86_64-*-freebsd.  There were no regression
> with the patch.  OK for trunk (and 4.6 branch after
> testing)?
>
> 2011-04-25  Steven G. Kargl  <kargl@gcc.gnu.org.>
>
>        PR fortran/48720
>        * gfortran.texi: Document the 'Q' exponent-letter extension.

IMHO you can leave out the sentences " Prior to version 4.6.1,
+GNU Fortran silently accepted @code{Q} as an alias for the single
+precision exponent-letter @code{E}.  With the introduction of software
+support for @code{REAL(16)} (i.e., quadruple precision) on i386 and
+x86_64 targets, the interpretation of @code{Q} has been updated to
+mean a @code{REAL(16)} real-literal-constant.  This aligns GNU Fortran
+with many commercially available compilers. ". In general we don't
document in which particular version a certain bug/regression/feature
was fixed/implemented as that would eventually just clutter up the
manual with

>        * primary.c (match_real_constant):  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.


Otherwise Ok. Thanks for the patch.



-- 
Janne Blomqvist

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

[Steve Kargl]

On Mon, Apr 25, 2011 at 10:26:20PM +0300, Janne Blomqvist wrote:
> On Mon, Apr 25, 2011 at 21:42, Steve Kargl
> <sgk@troutmask.apl.washington.edu> wrote:
> > Historically, gfortran has accepted real-literal-constants
> > of the form 1.23Q45 as single precision values. ??Many commercial
> > compilers (dating back years) have used the 'Q' exponent-letter
> > to mean quadruple precision. ??With the addition of software
> > support for REAL(16) on i386 and x86_64 targets, I anticipate
> > an increase in use of the 'Q' form. ??The attached patch does
> > the following:
> >
> > 1) If REAL(16) is available, a real-literal-constant with a 'Q'
> > ?? exponent-letter is accepted as a REAL(16) entity.
> >
> > 2) If REAL(16) is not available but REAL(10) is, then the constant
> > ?? is accepted as a REAL(10).
> >
> > 3) If neither REAL(16) nor REAL(10) is available, an error is
> > ?? issued.
> >
> > 4) An error is issued if one uses -std=f95, f2003, or f2008; otherwise
> > ?? a warning will be issued. ??The only way to disable the warning is
> > ?? to either fix the code to conform to the Fortran standard or use
> > ?? -w to disable warnings.
> 
> 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.  I can add that
if you think it is necessary.  Personally, I would rather encourage
individuals to fix their code.

> IMHO you can leave out the sentences " Prior to version 4.6.1,
> +GNU Fortran silently accepted @code{Q} as an alias for the single
> +precision exponent-letter @code{E}.  With the introduction of software
> +support for @code{REAL(16)} (i.e., quadruple precision) on i386 and
> +x86_64 targets, the interpretation of @code{Q} has been updated to
> +mean a @code{REAL(16)} real-literal-constant.  This aligns GNU Fortran
> +with many commercially available compilers. ". In general we don't
> document in which particular version a certain bug/regression/feature
> was fixed/implemented as that would eventually just clutter up the
> manual with

OK.  I'll update the docs.  I was trying to avoid POLA issues 
where the old behavior gave a single precision constant and
the new behavior is quad precision.  Consider,

program foo
   real(16) q
   q = 1.1q0
   print *, q
end program foo

% gfc46 -o z ui.f90 && ./z
 1.1000000238418579101562500000000000      

% gfc4x -o z ui.f90 && ./z
 1.1000000000000000000000000000000001      

This is a substantial ULP change.

-- 
Steve

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

[Janne Blomqvist]

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:
>> On Mon, Apr 25, 2011 at 21:42, Steve Kargl
>> <sgk@troutmask.apl.washington.edu> wrote:
>> > Historically, gfortran has accepted real-literal-constants
>> > of the form 1.23Q45 as single precision values. ??Many commercial
>> > compilers (dating back years) have used the 'Q' exponent-letter
>> > to mean quadruple precision. ??With the addition of software
>> > support for REAL(16) on i386 and x86_64 targets, I anticipate
>> > an increase in use of the 'Q' form. ??The attached patch does
>> > the following:
>> >
>> > 1) If REAL(16) is available, a real-literal-constant with a 'Q'
>> > ?? exponent-letter is accepted as a REAL(16) entity.
>> >
>> > 2) If REAL(16) is not available but REAL(10) is, then the constant
>> > ?? is accepted as a REAL(10).
>> >
>> > 3) If neither REAL(16) nor REAL(10) is available, an error is
>> > ?? issued.
>> >
>> > 4) An error is issued if one uses -std=f95, f2003, or f2008; otherwise
>> > ?? a warning will be issued. ??The only way to disable the warning is
>> > ?? to either fix the code to conform to the Fortran standard or use
>> > ?? -w to disable warnings.
>>
>> 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?

>  I can add that
> if you think it is necessary.  Personally, I would rather encourage
> individuals to fix their code.

I was thinking of not generating a warning by default as the feature
is (now) something with well defined (within gfortran, if not
portably) semantics.

>> IMHO you can leave out the sentences " Prior to version 4.6.1,
>> +GNU Fortran silently accepted @code{Q} as an alias for the single
>> +precision exponent-letter @code{E}.  With the introduction of software
>> +support for @code{REAL(16)} (i.e., quadruple precision) on i386 and
>> +x86_64 targets, the interpretation of @code{Q} has been updated to
>> +mean a @code{REAL(16)} real-literal-constant.  This aligns GNU Fortran
>> +with many commercially available compilers. ". In general we don't
>> document in which particular version a certain bug/regression/feature
>> was fixed/implemented as that would eventually just clutter up the
>> manual with
>
> OK.  I'll update the docs.  I was trying to avoid POLA issues
> where the old behavior gave a single precision constant and
> the new behavior is quad precision.  Consider,
>
> program foo
>   real(16) q
>   q = 1.1q0
>   print *, q
> end program foo
>
> % gfc46 -o z ui.f90 && ./z
>  1.1000000238418579101562500000000000
>
> % gfc4x -o z ui.f90 && ./z
>  1.1000000000000000000000000000000001
>
> This is a substantial ULP change.

Yes, I'm aware of that. I still think putting in info about when
something was fixed in the docs is not the right place. Perhaps the
release notes would be the proper place?


-- 
Janne Blomqvist

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

[Steve Kargl]

[-- Attachment #1: Type: text/plain, Size: 1123 bytes --]

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?

-- 
Steve

[-- Attachment #2: qformat_1.diff --]
[-- Type: text/x-diff, Size: 6590 bytes --]

Index: gfortran.texi
===================================================================
--- gfortran.texi	(revision 172974)
+++ gfortran.texi	(working copy)
@@ -1237,6 +1237,7 @@ without warning.
 * Missing period in FORMAT specifications::
 * I/O item lists::
 * BOZ literal constants::
+* @code{Q} exponent-letter::
 * Real array indices::
 * Unary operators::
 * Implicitly convert LOGICAL and INTEGER values::
@@ -1427,6 +1428,18 @@ To support legacy codes, GNU Fortran all
 of the @code{READ} statement, and the output item lists of the
 @code{WRITE} and @code{PRINT} statements, to start with a comma.
 
+@node @code{Q} exponent-letter
+@subsection @code{Q} exponent-letter
+@cindex @code{Q} exponent-letter
+
+GNU Fortran accepts real literal constants with an exponent-letter
+of @code{Q}, for example, @code{1.23Q45}.  The constant is interpreted
+as a @code{REAL(16)} entity on targets that suppports this type.  If
+the target does not support @code{REAL(16)} but has a @code{REAL(10)}
+type, then the real-literal-constant will be interpreted as a
+@code{REAL(10)} entity.  In the absence of @code{REAL(16)} and
+@code{REAL(10)}, an error will occur.
+
 @node BOZ literal constants
 @subsection BOZ literal constants
 @cindex BOZ literal constants
Index: gfortran.h
===================================================================
--- gfortran.h	(revision 172974)
+++ gfortran.h	(working copy)
@@ -2189,6 +2189,7 @@ typedef struct
   int warn_character_truncation;
   int warn_array_temp;
   int warn_align_commons;
+  int warn_real_q_constant;
   int warn_unused_dummy_argument;
   int max_errors;
 
Index: lang.opt
===================================================================
--- lang.opt	(revision 172974)
+++ lang.opt	(working copy)
@@ -242,6 +242,10 @@ Wintrinsics-std
 Fortran Warning
 Warn on intrinsics not part of the selected standard
 
+Wreal-q-constant
+Fortran Warning
+Warn about real-literal-constants with 'q' exponent-letter
+
 Wreturn-type
 Fortran Warning
 ; Documented in C
Index: invoke.texi
===================================================================
--- invoke.texi	(revision 172974)
+++ invoke.texi	(working copy)
@@ -134,12 +134,13 @@ by type.  Explanations are in the follow
 @item Error and Warning Options
 @xref{Error and Warning Options,,Options to request or suppress errors
 and warnings}.
-@gccoptlist{-fmax-errors=@var{n} @gol
--fsyntax-only  -pedantic  -pedantic-errors @gol
--Wall  -Waliasing  -Wampersand  -Warray-bounds -Wcharacter-truncation @gol
--Wconversion -Wimplicit-interface  -Wimplicit-procedure  -Wline-truncation @gol
--Wintrinsics-std  -Wsurprising  -Wno-tabs  -Wunderflow  -Wunused-parameter @gol
--Wintrinsic-shadow  -Wno-align-commons -Wfunction-elimination}
+@gccoptlist{-fmax-errors=@var{n}
+-fsyntax-only -pedantic -pedantic-errors -Wall @gol
+-Waliasing -Wampersand -Warray-bounds -Wcharacter-truncation @gol
+-Wconversion -Wimplicit-interface -Wimplicit-procedure -Wline-truncation @gol
+-Wintrinsics-std -Wreal-q-format -Wsurprising -Wno-tabs -Wunderflow @gol
+-Wunused-parameter -Wintrinsic-shadow -Wno-align-commons @gol
+-Wfunction-elimination}
 
 @item Debugging Options
 @xref{Debugging Options,,Options for debugging your program or GNU Fortran}.
@@ -694,7 +695,7 @@ we recommend avoiding and that we believ
 This currently includes @option{-Waliasing}, @option{-Wampersand}, 
 @option{-Wconversion}, @option{-Wsurprising}, @option{-Wintrinsics-std},
 @option{-Wno-tabs}, @option{-Wintrinsic-shadow}, @option{-Wline-truncation},
-and @option{-Wunused}.
+@option{-Wreal-q-format} and @option{-Wunused}.
 
 @item -Waliasing
 @opindex @code{Waliasing}
@@ -782,6 +783,12 @@ it as @code{EXTERNAL} procedure because 
 be used to never trigger this behavior and always link to the intrinsic
 regardless of the selected standard.
 
+@item -Wreal-q-constant
+@opindex @code{Wreal-q-constant}
+@cindex warnings, @code{q} exponent-letter
+Produce a warning if a real-literal-constant contains a @code{q}
+exponent-letter.
+
 @item -Wsurprising
 @opindex @code{Wsurprising}
 @cindex warnings, suspicious code
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");
+    }
+
   /* Scan exponent.  */
   c = gfc_next_ascii_char ();
   count++;
@@ -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;
+	    }
+	}
+      break;
+
     default:
       if (kind == -2)
 	kind = gfc_default_real_kind;
Index: options.c
===================================================================
--- options.c	(revision 172974)
+++ options.c	(working copy)
@@ -108,6 +108,7 @@ gfc_init_options (unsigned int decoded_o
   gfc_option.warn_intrinsic_shadow = 0;
   gfc_option.warn_intrinsics_std = 0;
   gfc_option.warn_align_commons = 1;
+  gfc_option.warn_real_q_constant = 0;
   gfc_option.warn_unused_dummy_argument = 0;
   gfc_option.max_errors = 25;
 
@@ -455,6 +456,7 @@ set_Wall (int setting)
   gfc_option.warn_intrinsic_shadow = setting;
   gfc_option.warn_intrinsics_std = setting;
   gfc_option.warn_character_truncation = setting;
+  gfc_option.warn_real_q_constant = setting;
   gfc_option.warn_unused_dummy_argument = setting;
 
   warn_unused = setting;
@@ -659,6 +661,10 @@ gfc_handle_option (size_t scode, const c
       gfc_option.warn_align_commons = value;
       break;
 
+    case OPT_Wreal_q_constant:
+      gfc_option.warn_real_q_constant = value;
+      break;
+
     case OPT_Wunused_dummy_argument:
       gfc_option.warn_unused_dummy_argument = value;
       break;

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

[Janne Blomqvist]

On Tue, Apr 26, 2011 at 19:52, Steve Kargl
<sgk@troutmask.apl.washington.edu> wrote:
> 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.

--- primary.c	(revision 172974)
+++ primary.c	(working copy)
@@ -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.  */

s/given/give/

> OK?

Ok. Thanks for fixing this!

-- 
Janne Blomqvist

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

[Mikael Morin]

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.


> 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). 
By the way testcases are missing :-p.

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

I only glanced at the rest, but Jane OK'ed it anyway :-).

Mikael

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

[Steve Kargl]

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

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

[Mikael Morin]

On Wednesday 27 April 2011 01:06:26 Steve Kargl wrote:
> > > 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.
My concern is that gfc_notify_std seems to return SUCCESS on warnings (I can't 
test right now as make has decided to rebuild the whole middle-end :-(). Then, 
I expect double warnings with -pedantic -Wreal-q-constant as -pedantic is a 
(the only one ?) case outputing warnings for GNU extensions.

Mikael

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

[Steve Kargl]

On Wed, Apr 27, 2011 at 10:54:37PM +0200, Mikael Morin wrote:
> On Wednesday 27 April 2011 01:06:26 Steve Kargl wrote:
> > 
> > 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.
> My concern is that gfc_notify_std seems to return SUCCESS on warnings (I can't 
> test right now as make has decided to rebuild the whole middle-end :-(). Then, 
> I expect double warnings with -pedantic -Wreal-q-constant as -pedantic is a 
> (the only one ?) case outputing warnings for GNU extensions.
> 
> Mikael

laptop:kargl[220] gfc4x -pedantic -Wreal-q-constant -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[221] 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[222] gfc4x -Wreal-q-constant -o z ui.f90
ui.f90:3.12:

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

PS: People should not use -pedantic, anyway.  It doesn't do what
people think it does.

-- 
Steve

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

[Mikael Morin]

On Wednesday 27 April 2011 23:10:14 Steve Kargl wrote:
> On Wed, Apr 27, 2011 at 10:54:37PM +0200, Mikael Morin wrote:
> > On Wednesday 27 April 2011 01:06:26 Steve Kargl wrote:
> > > 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.
> > 
> > My concern is that gfc_notify_std seems to return SUCCESS on warnings (I
> > can't test right now as make has decided to rebuild the whole middle-end
> > :-(). Then, I expect double warnings with -pedantic -Wreal-q-constant as
> > -pedantic is a (the only one ?) case outputing warnings for GNU
> > extensions.
> > 
> > Mikael
> 
> laptop:kargl[220] gfc4x -pedantic -Wreal-q-constant -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[221] 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[222] gfc4x -Wreal-q-constant -o z ui.f90
> ui.f90:3.12:
> 
>    q = 1.23q45
>             1
> Warning: Extension: exponent-letter 'q' in real-literal-constant at (1)
Well, that's something odd that I don't want to investigate further. 
As it is clean from a user point of view, let's move on.

Mikael