From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 2AF213857C63; Sun, 7 Mar 2021 13:19:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2AF213857C63 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: Sun, 07 Mar 2021 13:19:47 +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: REOPENED X-Bugzilla-Resolution: 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: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Mar 2021 13:19:47 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D57871 --- Comment #12 from Dominique d'Humieres --- > As this issue is about documentation, if I read the later comments correc= tly: > Can you check whether the documentation is now sufficient or whether more= is needed? > If so, what is needed? =E2=80=94 If not, can this bug now be = closed? I don't like the sentence Note that for @code{REAL(KIND=3DKIND(1.0))} the literal may get promoted and then the result may get promoted again. There is only one promotion for -freal-4-real-X, and it does not matter if 1.0 is promoted first KIND(1.0) is then X, or after KIND(1.0) is 4 then=20 REAL(KIND=3D4) is promoted to REAL(KIND=3DX). The situation for SELECTED_REAL_KIND(1) is quite different: if the promotio= n of -freal-4-real-X is done first, then the smallest kind available is 8, if it is done after then SELECTED_REAL_KIND(1) will be 4, then promoted to = X. What about a sentence such as: Note that while @code{REAL(KIND=3DKIND(1.0))} is always promoted to X by -freal-4-real-X, @code{SELECTED_REAL_KIND(1)} returns always 4 which is then promoted to X. ? It may be also useful to add a sentence saying that the promotion options a= re provided as such and that the observed behavior is not a bug but a feature. As said in comment 8, I did not find any other circonstance, by SELECTED_REAL_KIND for which such ambiguity exists.=