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

[Steve Kargl <sgk at troutmask dot apl dot washington dot edu>]

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