From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 7773A38618BD; Fri, 11 Sep 2020 18:56:31 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 7773A38618BD DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1599850591; bh=klLaYvm+uKW2q0D3mBW0j4aFI5wdepWGbh68KqnGqx0=; h=From:To:Subject:Date:In-Reply-To:References:From; b=IYPkPSB+YmEV/t2WqPQiRPKnAOJREYtaHI3mOY49Nseei0Ncrqc+3d0L6tprsb471 Okk5l34JoaOsdbTt7Zd9t/KgLInCt1v5hmndzreHLNkpbLV6nbW6WJh9lEPZU93A6k eALSkcHGoWX+b3cydPBy04tqLvpRQVxqe9wMfvSo= From: "anlauf at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042 Date: Fri, 11 Sep 2020 18:56:31 +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: 11.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: anlauf at gcc dot gnu.org X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.0 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: Fri, 11 Sep 2020 18:56:31 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D96983 --- Comment #19 from anlauf at gcc dot gnu.org --- (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #14) > > --- Comment #13 from anlauf at gcc dot gnu.org --- > > This may lead to a total mess, and I am unable to test it, but can you = try: >=20 > I just ran bootstraps on both sparc-sun-solaris2.11 and > i386-pc-solaris2.11. x86 results are unchanged, but sparc is completely > miserable: OK, thanks. Scrap the patch from comment#13. Let's try using long double when TYPE_PRECISION (long_double_type_node) is big enough for the conversio= n: diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c index 32fe9886c57..c508a4faedb 100644 --- a/gcc/fortran/trans-intrinsic.c +++ b/gcc/fortran/trans-intrinsic.c @@ -395,6 +395,13 @@ build_round_expr (tree arg, tree restype) fn =3D builtin_decl_for_precision (BUILT_IN_LROUND, argprec); else if (resprec <=3D LONG_LONG_TYPE_SIZE) fn =3D builtin_decl_for_precision (BUILT_IN_LLROUND, argprec); + else if (resprec =3D=3D TYPE_PRECISION (long_double_type_node) + && resprec >=3D argprec) + { + int kind =3D TYPE_PRECISION (long_double_type_node) / 8; + arg =3D fold_convert (long_double_type_node, arg); + fn =3D gfc_builtin_decl_for_float_kind (BUILT_IN_ROUND, kind); + } else if (resprec >=3D argprec && resprec =3D=3D 128) { /* Search for a real kind suitable as temporary for conversion. */ This should have no effect on x86. I may work on SPARC; could you please test for me? It will not work on POWER given comment#15 by Peter. However, the prints by Peter suggest that IBM's long double could be a usable type. So if this works on SPARC, one could adapt it to POWER, but we'd need also a slightly adapted testcase that runs only on POWER, while the original one is for IEEE128 platforms only.=