From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27805 invoked by alias); 11 Jul 2013 22:51:45 -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 Received: (qmail 27757 invoked by uid 55); 11 Jul 2013 22:51:36 -0000 From: "sgk at troutmask dot apl.washington.edu" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/57871] gfortran -freal-4-real-16 gives wrong result for selected_real_kind(1) Date: Thu, 11 Jul 2013 22:51:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Version: 4.8.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: sgk at troutmask dot apl.washington.edu X-Bugzilla-Status: REOPENED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-07/txt/msg00659.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57871 --- Comment #6 from Steve Kargl --- On Thu, Jul 11, 2013 at 10:30:04PM +0000, harper at msor dot vuw.ac.nz wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57871 > > --- Comment #5 from harper at msor dot vuw.ac.nz --- > I have now found two more oddities of type promotion but I don't claim > that these are gfortran bugs, only that the mmanual might need amending. > > Oddity 1. Although -freal-4-real-8 does what the manual implies with > the program below (making the real kinds 8,10,16 on an x86_64 system), > -fdefault-real-8 keeps the available kinds at 4,8,10,16 but merely > changes the defaults. I suggest that the following sentence > be added to the manual sewction on -fdefault-real-8 at the end: > > If "REAL(KIND=4)" is a real type available with no -f options, then it > remains available with -fdefault-real-8 though not with -freal-4-real-8. > > Oddity 2. If one uses -fdefault-double-8 in a system where default real > was 4 bytes wide then one must also use -fdefault-real-8. The manual > entries for -fdefault-double-8 and -fdefault-real-8 are both silent > on what happens if -fdefault-double-8 is given but -fdefault-real-8 is > not. I won't suggest an amendment here because I don't know what happens > in a system whose default real with no -f options was 8 bytes wide. I am not at all surprised by your findings. I would personally like to deprecate the -fdefault-* options. These options do not necessarily do what a user may expect. The options require care with EQUIVALENCE, COMMON, and may even require one to rebuild the runtime library (if one is doing double precision IO). Most users don't understand the limitations, and simply use these options as a quick-n-dirty way to port single precision code to double precision. Unfortunately, the -fdefault-* options are too ingrained into peoples brains. The -freal-* options were a later attempt to try to fix the deficiencies with the -fdefault-* options. These family of option should not be mixed. I suppose this should be documented.