From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 86CD03858000; Wed, 13 Dec 2023 02:40:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 86CD03858000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1702435255; bh=6KJXmjioGrOFy0hO+APPi2qI4zsrJNg48U2wpqF1GmY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=wqxCcp4Wsh8EFWsJ6ngQ50bQNlTNO8u+FK7Msgqhytme+AldPIf4btDeik4PvVghI 7cr9XPJ4HvW7Bm4t+sROlsTiFS9zETi2KaXV2E0FkW/eJJJ/UEIwupe3Vk1Gs3w6rW Mys6mXM605+F7rudWWfIJykbKw0q4+TcdSjO5SHo= From: "cvs-commit at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/112788] [14 regression] ICEs in fold_range, at range-op.cc:206 after r14-5972-gea19de921b01a6 Date: Wed, 13 Dec 2023 02:40:54 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: build, ice-checking, ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: linkw at gcc dot gnu.org X-Bugzilla-Target-Milestone: 14.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 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D112788 --- Comment #6 from GCC Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:fda8e2f8292a90dac9fcaf952bad6fff3aa7fff2 commit r14-6478-gfda8e2f8292a90dac9fcaf952bad6fff3aa7fff2 Author: Kewen Lin Date: Tue Dec 12 20:39:34 2023 -0600 range: Workaround different type precision between _Float128 and long double [PR112788] As PR112788 shows, on rs6000 with -mabi=3Dieeelongdouble type _Float128 has the different type precision (128) from that (127) of type long double, but actually they has the same underlying mode, so they have the same precision as the mode indicates the same real type format ieee_quad_format. It's not sensible to have such two types which have the same mode but different type precisions, some fix attempt was posted at [1]. As the discussion there, there are some historical reasons and practical issues. Considering we passed stage 1 and it also affected the build as reported, this patch is trying to temporarily workaround it. I thought to introduce a hookpod but that seems a bit overkill, assuming scalar float type with the same mode should have the same precision looks sensible. [1] https://inbox.sourceware.org/gcc-patches/718677e7-614d-7977-312d-05a75e1fd5= b4@linux.ibm.com/ PR tree-optimization/112788 gcc/ChangeLog: * value-range.h (range_compatible_p): Workaround same type mode= but different type precision issue for rs6000 scalar float types _Float128 and long double.=