From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24440 invoked by alias); 5 Apr 2011 02:12:51 -0000 Received: (qmail 24430 invoked by uid 22791); 5 Apr 2011 02:12:50 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 05 Apr 2011 02:12:45 +0000 From: "inform at tiker dot net" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/48426] [patch] Quad precision promotion X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: inform at tiker dot net X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Date: Tue, 05 Apr 2011 02:12:00 -0000 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: 2011-04/txt/msg00364.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48426 --- Comment #6 from Andreas Kloeckner 2011-04-05 02:12:33 UTC --- (In reply to comment #4) > On Sun, Apr 03, 2011 at 07:49:53PM +0000, inform at tiker dot net wrote: > This is the number one reason why these options (including the > current 3 [1]) should not be available in any compiler. Few people > use these types of options for debugging. Most have a single > precision algorithm, but want a double (or higher) precision > routine. Instead of actually trying to understand and implement > a proper double (or higher) precision version, people simply use > these types of options without checking the robustness of the > algorithm. First, some use of type promotion is--at least to some extent--legitimate. If you would like to use a certain piece of code in single and double precision and maintain compatibility with pure F77, then having the compiler able to rewrite your code is a useful thing to have available. Second, as I explained, there are uses of this in debugging. Obviously, maintaining multiple versions of the source code is not really an option in this case especially. To reiterate, the practical use of these flags should not be underestimated. Further, trying to convince users by not implementing this feature will simply drive them away from free tools. The need exists. > In glancing at the patch, there are at least two problems. First, > this chunk > > + else if (saw_i8 && gfc_option.flag_integer4_kind == 8 ) > + { > + gfc_default_integer_kind = 8; > + > + /* Even if the user specified that the default integer kind be 8, > + the numeric storage size isn't 64. In this case, a warning will > + be issued when NUMERIC_STORAGE_SIZE is used. */ > + gfc_numeric_storage_size = 4 * 8; > + } > > is simply a bad idea. This just imitates the behavior of -fdefault-integer-8, whose treatment is right directly above this snippet. So if our code is broken, so is the code for the existing flag. > Second, this chunk > > + if (ts->type == BT_REAL || ts->type == BT_COMPLEX) > + { > + if( ts->kind == 4 && gfc_option.flag_real4_kind == 8) ts->kind = 8; > + if( ts->kind == 4 && gfc_option.flag_real4_kind == 10) ts->kind = 10; > + if( ts->kind == 4 && gfc_option.flag_real4_kind == 16) ts->kind = 16; > + if( ts->kind == 8 && gfc_option.flag_real8_kind == 4) ts->kind = 4; > + if( ts->kind == 8 && gfc_option.flag_real8_kind == 10) ts->kind = 10; > + if( ts->kind == 8 && gfc_option.flag_real8_kind == 16) ts->kind = 16; > > appears to assume that ts->kind=10 and ts->kind=16 are available. > This may or may not be true depending on the target and the options > used during execution of configure. One needs to check if 10 and 16 > are available. Fixed in an updated version of the patch.