diff mbox

RFC [Patch, Fortran] PR - support "q" for exponents when READing floating-point numbers

Message ID 4F9129E5.30002@net-b.de
State New
Headers show

Commit Message

Tobias Burnus April 20, 2012, 9:18 a.m. UTC
Dear all,

some compilers support using "q" to indicate quad precision, e.g. 
"4.0q0". Since GCC 4.7, gfortran supports this vendor extension in the 
source code. However, READing the floating-point number "4.0q0" was not 
supported.

The attached patch adds this support, which some users expect (cf. PR 
and comp.lang.fortran).

Testing other compilers, the result is:
- 'q' not supported: g95, NAG f95, PGI, PathScale, Crayftn
- 'q' supported: g77, ifort, sunf95
(I don't know which of those compilers support quad precision.)

Hence, I am not sure whether one should add support for it. What do you 
think?

Attached is a lightly tested patch and a test case.
OK for the trunk after regtesting it?

Tobias

Comments

Tobias Burnus April 20, 2012, 9:34 a.m. UTC | #1
Small follow up.

On 04/20/2012 11:18 AM, Tobias Burnus wrote:
> Testing other compilers, the result is:
> - 'q' not supported: g95, NAG f95, PGI, PathScale, Crayftn
> - 'q' supported: g77, ifort, sunf95

It seems to be also supported by IBM's xlf - at least it supports such 
literals in the source code. (Cf. [1].)

Before Fortran 90, using "q" was to only way to write quad precision 
literals in the source code. For I/O, it does not matter. However, some 
compilers wrote "d" for double precision - newer compilers prefer "e" 
and accept both "e" and "d" as input, in line with the standard. It is 
unclear whether some compilers also wrote "q" for the output or whether 
just users did/do so - either because they are used to it, or under the 
(always or only nowadays?) wrong perception that it matters.

Tobias

[1] 
http://publib.boulder.ibm.com/infocenter/lnxpcomp/v9v111/index.jsp?topic=/com.ibm.xlf111.linux.doc/xlflr/realdatatype.htm
Janne Blomqvist April 22, 2012, 4:28 p.m. UTC | #2
On Fri, Apr 20, 2012 at 12:18, Tobias Burnus <burnus@net-b.de> wrote:
> Dear all,
>
> some compilers support using "q" to indicate quad precision, e.g. "4.0q0".
> Since GCC 4.7, gfortran supports this vendor extension in the source code.
> However, READing the floating-point number "4.0q0" was not supported.
>
> The attached patch adds this support, which some users expect (cf. PR and
> comp.lang.fortran).
>
> Testing other compilers, the result is:
> - 'q' not supported: g95, NAG f95, PGI, PathScale, Crayftn
> - 'q' supported: g77, ifort, sunf95
> (I don't know which of those compilers support quad precision.)
>
> Hence, I am not sure whether one should add support for it. What do you
> think?

I don't particularly like adding extensions, but this seems fairly
widespread (thanks for testing!) and the patch is small, so I don't
think it'll hurt.

> Attached is a lightly tested patch and a test case.
> OK for the trunk after regtesting it?

Ok.
diff mbox

Patch

diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index 2024fcd..4d2ce79 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -1136,6 +1136,8 @@  parse_real (st_parameter_dt *dtp, void *buffer, int length)
 	case 'E':
 	case 'd':
 	case 'D':
+	case 'q':
+	case 'Q':
 	  push_char (dtp, 'e');
 	  goto exp1;
 
@@ -1449,6 +1451,8 @@  read_real (st_parameter_dt *dtp, void * dest, int length)
 	case 'e':
 	case 'D':
 	case 'd':
+	case 'Q':
+	case 'q':
 	  goto exp1;
 
 	case '+':
@@ -1546,6 +1550,8 @@  read_real (st_parameter_dt *dtp, void * dest, int length)
 	case 'e':
 	case 'D':
 	case 'd':
+	case 'Q':
+	case 'q':
 	  goto exp1;
 
 	case '+':
diff --git a/libgfortran/io/read.c b/libgfortran/io/read.c
index aa41bc7..32c8b32 100644
--- a/libgfortran/io/read.c
+++ b/libgfortran/io/read.c
@@ -1026,6 +1026,8 @@  found_digit:
 	case 'E':
 	case 'd':
 	case 'D':
+	case 'q':
+	case 'Q':
 	  ++p;
 	  --w;
 	  goto exponent;