On Mon, Apr 25, 2011 at 22:45, Steve Kargl
<s...@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
>> <s...@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
