From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) by sourceware.org (Postfix) with ESMTPS id 4381B3858291 for ; Fri, 3 Feb 2023 07:42:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4381B3858291 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lj1-x230.google.com with SMTP id g14so4397006ljh.10 for ; Thu, 02 Feb 2023 23:42:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=CxUMpadTOHRExRE6Rh07JRlJAMhC+VePxHgOJ25RgaY=; b=qS3dlwQbwjRUz75rRS5BQMEyYnk17biKZU8K1GnoX+3fwPrgO8P17cZIx5Ng0Q3k6K rAabXz4Kk01T9LI5jQiq6tivz9vvn6PGdnu8dKPjlcodncwuyvngou/pq5jrrmZl+w7X yDLUgsv2s5EkBfLag38edbzLJSA4CUTKr3apCQ2ZWHwl6tn+GfOp+p6Pfpv4lsxnELDK vmL/HIOYXirqEx+v1uN5/r1ryzENtRPXAHKB5rWm/GxqcxNGRbeDcKmiIxHAejDGXGLW Q+T+vT+GKla+2NikhLA+9Ge/bpIGJyXoc5fMQpF9far8KCY5qKk0yGkbJGO0F/IuHsH1 ut+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=CxUMpadTOHRExRE6Rh07JRlJAMhC+VePxHgOJ25RgaY=; b=jOVLlKmB7TFZ5zSWuGuBK4pn/+q7elMaeDt6i1zRrfLsopc1DT/Tcoy8FDAxwvwSN2 FDw8KtVWPTqZXg1UDH6oZijZTQrKsMXCKI23MZ+RvCQelJnaEtevgSrnCOld9hOCQbfv +tPlEOU7a9VO9h+P4ofzhsVE7cVeJFrVj8MWN3sJhaHhN6eNFbzn3QYWwCYMhLpmz7r3 bckhSoppGEB0uYQiv3FRSyRMf2BXStjhpDavatA/VzHQm48CAE5j3B7yyjGbsIh9/HaW gJ7wDp+rv5Kn0qcrTqoKy77Rx4V+ilWcAT+K8OvOAVmfPWYaEpBEJ/t5CBl1IFaOrfYz c+xA== X-Gm-Message-State: AO0yUKWziIFJKfuGc4pW4oa9Kg6X9Ev6YcoScZsrujyn0akxopzneKQ3 1thETKRh9FS4Nv4M1lRNlcOw0agNWkarGJj/q/A= X-Google-Smtp-Source: AK7set9E44wuBAoqvUbtrt2myWd+W3LF+5BxqvpdWWh1Aypq4CQ5K8XkNhUY81ykpYEPYTukW3AnWK9umEnBt9Sri4w= X-Received: by 2002:a2e:2c0e:0:b0:28b:77fd:d92b with SMTP id s14-20020a2e2c0e000000b0028b77fdd92bmr1376279ljs.86.1675410173633; Thu, 02 Feb 2023 23:42:53 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Fri, 3 Feb 2023 08:42:41 +0100 Message-ID: Subject: Re: [PATCH 0/2] Repost of patches for solving the build on Fedora 36 problem To: Michael Meissner , gcc-patches@gcc.gnu.org, Segher Boessenkool , "Kewen.Lin" , David Edelsohn , Peter Bergner , Will Schmidt Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_MANYTO,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, Feb 3, 2023 at 6:44 AM Michael Meissner via Gcc-patches 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