From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22957 invoked by alias); 10 Jul 2013 13:07:44 -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 22931 invoked by uid 48); 10 Jul 2013 13:07:41 -0000 From: "dominiq at lps dot ens.fr" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/57871] gfortran -freal-4-real-16 gives wrong result for selected_real_kind(1) Date: Wed, 10 Jul 2013 13:07: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: dominiq at lps dot ens.fr X-Bugzilla-Status: RESOLVED 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: bug_status resolution 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/msg00604.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57871 Dominique d'Humieres changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Dominique d'Humieres --- > gfortran 4.8.1 -freal-4-real-16 gives real(16) kind with > selected_real_kind(1) but it ought to give real(8) because that is > the smallest decimal precision available with that compiler option. > Same problem with -freal-4-real-10 giving real(10) instead of real(8). ... Why are you expecting that? The manual says: -freal-4-real-8 -freal-4-real-10 -freal-8-real-4 -freal-8-real-10 -freal-8-real-16 Promote all REAL(KIND=M) entities to REAL(KIND=N) entities. If REAL(KIND=N) is unavailable, then an error will be issued. All other real kind types are unaffected by this option. These options should be used with care and may not be suitable for your codes. Areas of possible concern include calls to external procedures, alignment in EQUIVALENCE and/or COMMON, generic interfaces, BOZ literal constant conversion, and I/O. Inspection of the intermediate representation of the translated Fortran code, produced by -fdump-tree-original, is suggested. and your example does exactly that: Closing as INVALID.