This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: [RFC] handling of real literal constants of the form 1.q0
- From: Mikael Morin <mikael dot morin at sfr dot fr>
- To: fortran at gcc dot gnu dot org
- Cc: Steve Kargl <sgk at troutmask dot apl dot washington dot edu>
- Date: Fri, 22 Apr 2011 23:00:09 +0200
- Subject: Re: [RFC] handling of real literal constants of the form 1.q0
- References: <20110422160602.GA41471@troutmask.apl.washington.edu>
On Friday 22 April 2011 18:06:02 Steve Kargl wrote:
> gfortran currently accepts real literal constants of the
> form 1.1q0, but it simply replaces the 'q' with an 'e'.
> This means all literal constants with a 'q' are taken
> to be default real kind. We have two options, drop
> the acceptance of 'q' or fix its handling. The attach
> patch 'fixes' the handling by starting with the largest
> possible real kind type parameter of 16, then dropping
> back to 10. If neither 16 or 10 is found on the
> target, then an error is issued.
>
> Also, note that the Fortran standard disallows the form
> 1.1d0_knd for double precision. I have included a similar
> fix for 1.1q0_knd.
>
> Also**2, note that gfortan silently accepts 'q' with
> -std=f95, -std=f2003, and -std=f2008. I have not
> addressed this, yet.
>
> So, the questions are:
>
> 1) Do we drop support for 'q'?
We have had support for 'q' since the dawn of gfortran times it seems.
Dropping support could be seen as a regression, and the bug report shows that
there are some people using 'q'.
On the other hand, 'q' is not part of the standard, and I haven't seen it the
manual either, so I'm more inclined to drop support.
> 2) If we keep 'q', do we interpret it as a real with
> the largest possible kind type parameter?
One could expect 'd' to mean 'double' (<=> kind=8), and then 'q' to mean
'quad' (<=> kind=16 only).
However, the current code seems to handle it as default real. If we need to
change the semantics, better drop support ;-).
> 3) If neither kind=10 or kind=16 is present, do we
> fall back to double precision or error out?
Error, of course.
> 4) Do we insert gfc_notify_std((GFC_STD_GNU, ...) to
> flag the use of 'q'?
Yes!
In short, my opinion is:
- in all cases, errors!
- possibly drop support (more questionable)
Mikael