This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFC] handling of real literal constants of the form 1.q0


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]