From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3511 invoked by alias); 22 Jan 2009 10:55:40 -0000 Received: (qmail 2051 invoked by uid 48); 22 Jan 2009 10:53:17 -0000 Date: Thu, 22 Jan 2009 10:55:00 -0000 Message-ID: <20090122105317.2050.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/38439] I/O PD edit descriptor inconsistency In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "burnus at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2009-01/txt/msg02369.txt.bz2 ------- Comment #5 from burnus at gcc dot gnu dot org 2009-01-22 10:53 ------- > Thus: '(1pD24.15)' is valid Fully agreed - that version is valid and accepted with gfortran, ifort, NAG f95 etc. > While: '(1pD24.15e4)' is invalid It is, but as written sunf95/openf95/gfortran 4.1 accept it at compile time and gfortran 4.x and g95 accept it at run time and it generates the different size of the exponent ("D+0" for pD24.15e1 and "D+00000" for pD24.15e5). Still, there is the question whether one wants to allow it (at compile time) with some options, reject it at run-time, or keep the status quo. * * * The other question is: Why is the location marker ("1") in the error message (see comment 2) way off? If one tries something else, the location fits much better, e.g. WRITE (*,'(g0.3.4)') 1.0d0 1 Another error question is: '(1pd0.3)' ifort, g95, and NAG f95 claim: "Error: Zero field width invalid for D edit descriptor"; gfortran accepts it but prints "*****" while openf95 accepts it an prints "1.0E+000". I think gfortran should compile-time-diagnose it. (When passing it as string, ifort and g95 print "1.000D+00" and f95 prints ""; I think printing '******' is also ok.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38439