From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25797 invoked by alias); 11 Jun 2011 15:56:42 -0000 Received: (qmail 25779 invoked by uid 22791); 11 Jun 2011 15:56:41 -0000 X-SWARE-Spam-Status: No, hits=-0.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from sv13.net-housting.de (HELO sv13.net-housting.de) (178.248.244.23) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 11 Jun 2011 15:56:26 +0000 Received: from localhost (mailscan.hofmeirmedia.net [172.30.129.51]) by sv13.net-housting.de (Postfix) with ESMTP id 868812812B2A0; Sat, 11 Jun 2011 17:56:24 +0200 (CEST) Received: from sv13.net-housting.de ([172.30.129.23]) by localhost (mailscan.hofmeirmedia.net [172.30.129.51]) (amavisd-new, port 10024) with ESMTP id 2FKAPvLrD0ue; Sat, 11 Jun 2011 17:56:22 +0200 (CEST) Received: from mail-vw0-f47.google.com (mail-vw0-f47.google.com [209.85.212.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by sv13.net-housting.de (Postfix) with ESMTPSA id DCB4C281132A4; Sat, 11 Jun 2011 17:56:21 +0200 (CEST) Received: by vws2 with SMTP id 2so3263961vws.20 for ; Sat, 11 Jun 2011 08:56:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.102.17 with SMTP id e17mr1163833vco.258.1307807771513; Sat, 11 Jun 2011 08:56:11 -0700 (PDT) Received: by 10.220.72.135 with HTTP; Sat, 11 Jun 2011 08:56:11 -0700 (PDT) In-Reply-To: <4DF3626B.6070404@charter.net> References: <4DE8D8D6.5030506@charter.net> <4DF25409.1080509@charter.net> <4DF3626B.6070404@charter.net> Date: Sat, 11 Jun 2011 16:05:00 -0000 Message-ID: Subject: Re: [patch, libgfortran] PR48906 Wrong rounding results with -m32 From: Thomas Henlich To: jerry DeLisle Cc: Janne Blomqvist , gfortran , gcc patches Content-Type: text/plain; charset=ISO-8859-1 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-06/txt/msg00916.txt.bz2 On Sat, Jun 11, 2011 at 14:41, jerry DeLisle wrote: > This was established as solution to PR48488 where we had two choices for > selecting the significant digits. Nine significant digits was established as > a requirement to guarantee round trip in all cases. The char4_iunit_1.f03 > test case was revised because after we corrected the formatting in PR48906, > it started to fail and I observed the test case was looking for the wrong > number of significant digits. > > Based on this, I would suggest we leave it as I have it, which is correct. I'm afraid it's not. 1.23450002E-06 has nine significant digits. That's how it should be. We don't want 1PG16.9E2 editing for list-directed and G0, but G16.9E2 for the F editing range and 1PE16.8E2 editing for the E range. This is to make sure the result always has nine significant digits, whether in the F or E range.