Message ID | Y9yfDC9bMaaB86ZP@toto.the-meissners.org |
---|---|
Headers |
Return-Path: <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp660741wrn; Thu, 2 Feb 2023 21:44:29 -0800 (PST) X-Google-Smtp-Source: AK7set9ml2ihufQOhRszoje8ryYSzCp9/FUq48x2igj4o5wtAXDT6ajuLw2Cf1zSke9gO39fwnTK X-Received: by 2002:a17:906:fa89:b0:880:5ab7:cb76 with SMTP id lt9-20020a170906fa8900b008805ab7cb76mr8156652ejb.33.1675403069788; Thu, 02 Feb 2023 21:44:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1675403069; cv=none; d=google.com; s=arc-20160816; b=oH4KvD001HUXVtKfKT83EZSB0UBcyq64QiW+0y1JsretK72vwEa4NX1hn+Cn0DHVLx zB9NmTmDT011VANZAQ0UZl2FYsThlRKW2S+Ublf5yKfnOA4gq2RWC0feeJNI75Ko0Gyy HYJFFIeu+z+yZU/39cAXRCEBvnrDP6r3Um9c9LOfzfmBesgAbhXkXr29G5QbP1wBMRRF WUh8tFf/fPMLm9kSX6oGE/N8J8AB2COuvf5VpV3OR21iQoT8ZaCdcjbVzoE5g0EjwU5G Oi9aflrgKQJCX/GPyWZTQ9PXkliItDL3pueUfOaZEyHVBt3/tD2siMrp9zdEbj5uncb4 7mqw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:reply-to:from:list-subscribe:list-help:list-post :list-archive:list-unsubscribe:list-id:precedence :content-disposition:mime-version:mail-followup-to:message-id :subject:to:date:dmarc-filter:delivered-to:dkim-signature :dkim-filter; bh=Sxxjsg3CLPRJsTMlW2Yofn59AUrTZbGxr9QAdr6VymI=; b=CSu+3FlLNxfsnnATWGNowqyti3Ado2zAal+O0Gb64YHwcW1I4Q60r0Tf9PCw5m79bx lE3bATq9YJPpxJG6oOgulZ2MEa9VXVfF34lqpJo49dm6E1UkBQErPyvVUhUCWLLAbar0 uVdlGG0EmY/76fKfgZmSCMW272SVXVD195nz0b1dLvTWnxu2MvCdg/ZZQ0Sjsz5rwltS SSWY/n52MnDSHJRqAwr0kxnhghIhOVqBEKLXOEdIaxLuFSsFtRaijuNcxQAzBIU9YiLR bXXpJPT4xNsAPVntIsBPNrwptmsTjwN3MTi6lrViEYTyKS1pO37SZS7T5ajXFKOARZAW IJqA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=wHWzBBlP; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from sourceware.org (ip-8-43-85-97.sourceware.org. [8.43.85.97]) by mx.google.com with ESMTPS id z23-20020a170906435700b0088dd72fa97dsi1750970ejm.975.2023.02.02.21.44.29 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 02 Feb 2023 21:44:29 -0800 (PST) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) client-ip=8.43.85.97; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=wHWzBBlP; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id C07B738582BE for <ouuuleilei@gmail.com>; Fri, 3 Feb 2023 05:44:28 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C07B738582BE DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1675403068; bh=Sxxjsg3CLPRJsTMlW2Yofn59AUrTZbGxr9QAdr6VymI=; h=Date:To:Subject:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=wHWzBBlPdTwl5/Eaezb8b4fzUb3RI/SziNgqfUxBjKXfnIgWTVZCpT9k0QnN1KuVW SjCcGUIoAOaMCmpJzT90p7IihBuBB+APYyMCwmcCa7/dm+w1E83xgDFpD+Oud59mYn luoMiaVQtgHS6+7lX+Z/BHmkPazOUZJonxm8KFII= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id CD2633858C5E for <gcc-patches@gcc.gnu.org>; Fri, 3 Feb 2023 05:43:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org CD2633858C5E Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 3135Dh4H018028; Fri, 3 Feb 2023 05:43:45 GMT Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3nguxcrh48-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 03 Feb 2023 05:43:45 +0000 Received: from m0098420.ppops.net (m0098420.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 3135h8bS031158; Fri, 3 Feb 2023 05:43:44 GMT Received: from ppma03wdc.us.ibm.com (ba.79.3fa9.ip4.static.sl-reverse.com [169.63.121.186]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3nguxcrh42-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 03 Feb 2023 05:43:44 +0000 Received: from pps.filterd (ppma03wdc.us.ibm.com [127.0.0.1]) by ppma03wdc.us.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 3132ND75008305; Fri, 3 Feb 2023 05:43:44 GMT Received: from smtprelay02.wdc07v.mail.ibm.com ([9.208.129.120]) by ppma03wdc.us.ibm.com (PPS) with ESMTPS id 3ncvtf7753-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 03 Feb 2023 05:43:43 +0000 Received: from smtpav06.dal12v.mail.ibm.com (smtpav06.dal12v.mail.ibm.com [10.241.53.105]) by smtprelay02.wdc07v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 3135hgAx62194000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 3 Feb 2023 05:43:42 GMT Received: from smtpav06.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 24C815805E; Fri, 3 Feb 2023 05:43:42 +0000 (GMT) Received: from smtpav06.dal12v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 96A6D58043; Fri, 3 Feb 2023 05:43:41 +0000 (GMT) Received: from toto.the-meissners.org (unknown [9.65.233.34]) by smtpav06.dal12v.mail.ibm.com (Postfix) with ESMTPS; Fri, 3 Feb 2023 05:43:41 +0000 (GMT) Date: Fri, 3 Feb 2023 00:43:40 -0500 To: gcc-patches@gcc.gnu.org, Michael Meissner <meissner@linux.ibm.com>, Segher Boessenkool <segher@kernel.crashing.org>, "Kewen.Lin" <linkw@linux.ibm.com>, David Edelsohn <dje.gcc@gmail.com>, Peter Bergner <bergner@linux.ibm.com>, Will Schmidt <will_schmidt@vnet.ibm.com> Subject: [PATCH 0/2] Repost of patches for solving the build on Fedora 36 problem Message-ID: <Y9yfDC9bMaaB86ZP@toto.the-meissners.org> Mail-Followup-To: Michael Meissner <meissner@linux.ibm.com>, gcc-patches@gcc.gnu.org, Segher Boessenkool <segher@kernel.crashing.org>, "Kewen.Lin" <linkw@linux.ibm.com>, David Edelsohn <dje.gcc@gmail.com>, Peter Bergner <bergner@linux.ibm.com>, Will Schmidt <will_schmidt@vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: BGmZGGh8lAf7FVvzHPQaEg89O3Ew_rEt X-Proofpoint-GUID: tpKWXuTz5WwMqaEG3OAOFbfQbQw7K0nK X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.930,Hydra:6.0.562,FMLib:17.11.122.1 definitions=2023-02-03_02,2023-02-02_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxlogscore=807 mlxscore=0 lowpriorityscore=0 impostorscore=0 clxscore=1015 bulkscore=0 spamscore=0 phishscore=0 adultscore=0 malwarescore=0 priorityscore=1501 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2212070000 definitions=main-2302030050 X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, KAM_MANYTO, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Michael Meissner via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Michael Meissner <meissner@linux.ibm.com> Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1756787449181155140?= X-GMAIL-MSGID: =?utf-8?q?1756787449181155140?= |
Series |
Repost of patches for solving the build on Fedora 36 problem
|
|
Message
Michael Meissner
Feb. 3, 2023, 5:43 a.m. UTC
I'm reposting these two patches that allow GCC to build on Fedora 36 just to be clear which patches I'm talking about. The issue is that if GCC is configured with long double using the IEEE 128-bit representation, it currently cannot build _mulkc3 and _divkc3 in libgcc. Note, these patches do not solve the underlying problem of mixing _Float128 and long double types and using built-in functions (i.e. calling a _Float128 built-in function with long double arguments when long double is IEEE 128-bit, or vice versa calling a long double built-in function with _Float128 arguments). But they do allow the compiler to build. Note, it is the morning of February 3rd, and I will be off on vacation from February 7th through February 14th. The first patch changes libgcc so that it uses either _Float128 or long double as the base IEEE 128-bit type, depending on whether long double uses the IBM double-double representation, or the IEEE 128-bit representation. And for the complex type it uses _Complex _Float128 or _Complex long double. The _mulkc3 and _divkc3 functions are adjusted to use the f128 built-in functions or the long double built-in functions, based on the long double type. The second patch improves how the compiler generates the call to _mulkc3 and _divkc3. I've discovered as I have tried to fix underlying problem with the IEEE 128-bit floating point types, it breaks the calls for IEEE 128-bit complex multiply and divide. This patch uses a cleaner approach to generate these calls, and it will work with the current setup, and with the various fixes that I've attempted to do to fix the underlying problem.
Comments
On Fri, Feb 3, 2023 at 6:44 AM Michael Meissner via Gcc-patches <gcc-patches@gcc.gnu.org> wrote: > > I'm reposting these two patches that allow GCC to build on Fedora 36 just to be > clear which patches I'm talking about. The issue is that if GCC is configured > with long double using the IEEE 128-bit representation, it currently cannot > build _mulkc3 and _divkc3 in libgcc. It's interesting that we do not see this with openSUSE where I configure with --with-cpu=power8 --with-tune=power9 --with-long-double-format=ieee --with-long-double-128 note this is ppc64le, we leave ppc64 and ppc with their default. > Note, these patches do not solve the underlying problem of mixing _Float128 and > long double types and using built-in functions (i.e. calling a _Float128 > built-in function with long double arguments when long double is IEEE 128-bit, > or vice versa calling a long double built-in function with _Float128 > arguments). But they do allow the compiler to build. > > Note, it is the morning of February 3rd, and I will be off on vacation from > February 7th through February 14th. > > The first patch changes libgcc so that it uses either _Float128 or long double > as the base IEEE 128-bit type, depending on whether long double uses the IBM > double-double representation, or the IEEE 128-bit representation. And for the > complex type it uses _Complex _Float128 or _Complex long double. The _mulkc3 > and _divkc3 functions are adjusted to use the f128 built-in functions or the > long double built-in functions, based on the long double type. > > The second patch improves how the compiler generates the call to _mulkc3 and > _divkc3. I've discovered as I have tried to fix underlying problem with the > IEEE 128-bit floating point types, it breaks the calls for IEEE 128-bit complex > multiply and divide. This patch uses a cleaner approach to generate these > calls, and it will work with the current setup, and with the various fixes that > I've attempted to do to fix the underlying problem. > > -- > Michael Meissner, IBM > PO Box 98, Ayer, Massachusetts, USA, 01432 > email: meissner@linux.ibm.com
On 2/3/23 1:42 AM, Richard Biener wrote: > On Fri, Feb 3, 2023 at 6:44 AM Michael Meissner via Gcc-patches > <gcc-patches@gcc.gnu.org> wrote: >> >> I'm reposting these two patches that allow GCC to build on Fedora 36 just to be >> clear which patches I'm talking about. The issue is that if GCC is configured >> with long double using the IEEE 128-bit representation, it currently cannot >> build _mulkc3 and _divkc3 in libgcc. > > It's interesting that we do not see this with openSUSE where I configure with > > --with-cpu=power8 --with-tune=power9 --with-long-double-format=ieee > --with-long-double-128 > > note this is ppc64le, we leave ppc64 and ppc with their default. That's strange, Bill just retested on our ppc64le openSUSE Tumbleweed system using basically the same configure options and sees the ICE: /home/seurer/gcc/git/gcc-trunk/libgcc/config/rs6000/_mulkc3.c: In function '__mulkc3_sw': /home/seurer/gcc/git/gcc-trunk/libgcc/config/rs6000/_mulkc3.c:97:1: internal compiler error: in fold_stmt, at gimple-range-fold.cc:522 He did not specify --with=cpu= or --with-tune=, which means he got power8 defaults for both of those. It's hard for me to believe that --with-tune=power9 could hide the issue, but we'll try that configuration too. Do you have any other configure options that might affect things? Peter
On Mon, Feb 6, 2023 at 7:28 PM Peter Bergner <bergner@linux.ibm.com> wrote: > > On 2/3/23 1:42 AM, Richard Biener wrote: > > On Fri, Feb 3, 2023 at 6:44 AM Michael Meissner via Gcc-patches > > <gcc-patches@gcc.gnu.org> wrote: > >> > >> I'm reposting these two patches that allow GCC to build on Fedora 36 just to be > >> clear which patches I'm talking about. The issue is that if GCC is configured > >> with long double using the IEEE 128-bit representation, it currently cannot > >> build _mulkc3 and _divkc3 in libgcc. > > > > It's interesting that we do not see this with openSUSE where I configure with > > > > --with-cpu=power8 --with-tune=power9 --with-long-double-format=ieee > > --with-long-double-128 > > > > note this is ppc64le, we leave ppc64 and ppc with their default. > > That's strange, Bill just retested on our ppc64le openSUSE Tumbleweed system > using basically the same configure options and sees the ICE: > > /home/seurer/gcc/git/gcc-trunk/libgcc/config/rs6000/_mulkc3.c: In function '__mulkc3_sw': > /home/seurer/gcc/git/gcc-trunk/libgcc/config/rs6000/_mulkc3.c:97:1: internal compiler error: in fold_stmt, at gimple-range-fold.cc:522 > > He did not specify --with=cpu= or --with-tune=, which means he got > power8 defaults for both of those. It's hard for me to believe that > --with-tune=power9 could hide the issue, but we'll try that configuration > too. Do you have any other configure options that might affect things? The full configure is ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,ada,go,jit,m2 --enable-host-shared --enable-checking=release --disable-werror --with-gxx-include-dir=/usr/include/c++/13 --with-libstdcxx-zoneinfo=/usr/share/zoneinfo --enable-ssp --disable-libssp --disable-libvtv --enable-cet=auto --disable-libcc1 --enable-plugin --with-bugurl=https://bugs.opensuse.org/ '--with-pkgversion=SUSE Linux' --with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --with-gcc-major-version-only --enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function --program-suffix=-13 --without-system-libunwind --with-cpu=power8 --with-tune=power9 --with-long-double-format=ieee --enable-secureplt --with-long-double-128 --enable-targets=powerpcle-linux --disable-multilib --with-build-config=bootstrap-lto-lean --enable-link-mutex --build=powerpc64le-suse-linux --host=powerpc64le-suse-linux and _mulkc3.c is built like /home/abuild/rpmbuild/BUILD/gcc-13.0.1+git5679/obj-powerpc64le-suse-linux/./gcc/xgcc -B/home/abuild/rpmbuild/BUILD/gcc-13.0.1+git5679/obj-powerpc64le-suse-linux/./gcc/ -B/usr/powerpc64le-suse-linux/bin/ -B/usr/powerpc64le-suse-linux/lib/ -isystem /usr/powerpc64le-suse-linux/include -isystem /usr/powerpc64le-suse-linux/sys-include -fno-checking -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g -U_FORTIFY_SOURCE -O2 -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g -U_FORTIFY_SOURCE -DIN_GCC -fPIC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -mlong-double-128 -mno-minimal-toc -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -mlong-double-128 -mno-minimal-toc -I. -I. -I../.././gcc -I../../../libgcc -I../../../libgcc/. -I../../../libgcc/../gcc -I../../../libgcc/../include -I../../../libgcc/../libdecnumber/dpd -I../../../libgcc/../libdecnumber -DHAVE_CC_TLS -Wno-type-limits -mvsx -mfloat128 -mno-float128-hardware -mno-gnu-attribute -I../../../libgcc/soft-fp -I../../../libgcc/config/rs6000 -DFLOAT128_HW_INSNS -DFLOAT128_HW_INSNS_ISA3_1 -o _mulkc3.o -MT _mulkc3.o -MD -MP -MF _mulkc3.dep -c ../../../libgcc/config/rs6000/_mulkc3.c -fvisibility=hidden -DHIDE_EXPORTS > > Peter > >
On Tue, Feb 07, 2023 at 03:22:41PM +0100, Richard Biener via Gcc-patches wrote: > > He did not specify --with=cpu= or --with-tune=, which means he got > > power8 defaults for both of those. It's hard for me to believe that > > --with-tune=power9 could hide the issue, but we'll try that configuration > > too. Do you have any other configure options that might affect things? > > The full configure is > > ../configure --prefix=/usr --infodir=/usr/share/info > --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 > --enable-languages=c,c++,objc,fortran,obj-c++,ada,go,jit,m2 > --enable-host-shared --enable-checking=release --disable-werror > --with-gxx-include-dir=/usr/include/c++/13 > --with-libstdcxx-zoneinfo=/usr/share/zoneinfo --enable-ssp > --disable-libssp --disable-libvtv --enable-cet=auto --disable-libcc1 > --enable-plugin --with-bugurl=https://bugs.opensuse.org/ > '--with-pkgversion=SUSE Linux' --with-slibdir=/lib64 > --with-system-zlib --enable-libstdcxx-allocator=new > --disable-libstdcxx-pch --enable-version-specific-runtime-libs > --with-gcc-major-version-only --enable-linker-build-id > --enable-linux-futex --enable-gnu-indirect-function > --program-suffix=-13 --without-system-libunwind --with-cpu=power8 > --with-tune=power9 --with-long-double-format=ieee --enable-secureplt > --with-long-double-128 --enable-targets=powerpcle-linux > --disable-multilib --with-build-config=bootstrap-lto-lean > --enable-link-mutex --build=powerpc64le-suse-linux > --host=powerpc64le-suse-linux > > and _mulkc3.c is built like We do not get the ICE in Fedora builds either. The important thing is --enable-checking=release With release checking there is no ICE, with checking there is one. Jakub