Re: [PATCH 1/2] PR target/107299: Fix build issue when long double is IEEE 128-bit

["Kewen.Lin" <linkw@linux.ibm.com>]

Hi Mike,

on 2023/2/3 13:49, Michael Meissner wrote:
> This patch is a repost of a patch:
> 
> | Date: Thu, 19 Jan 2023 11:37:27 -0500
> | Subject: [PATCH] PR target/107299: Fix build issue when long double is IEEE 128-bit
> | Message-ID: <Y8lxx+Jxfl1IkheJ@toto.the-meissners.org>
> 
> This patch updates the IEEE 128-bit types used in libgcc.
> 
> At the moment, we cannot build GCC when the target uses IEEE 128-bit long
> doubles, such as building the compiler for a native Fedora 36 system.  The
> build dies when it is trying to build the _mulkc3.c and _divkc3 modules.
> 
> This patch changes libgcc to use long double for the IEEE 128-bit base type if
> long double is IEEE 128-bit, and it uses _Float128 otherwise.  The built-in
> functions are adjusted to be the correct version based on the IEEE 128-bit base
> type used.
> 
> While it is desirable to ultimately have __float128 and _Float128 use the same
> internal type and mode within GCC, at present if you use the option
> -mabi=ieeelongdouble, the __float128 type will use the long double type and not
> the _Float128 type.  We get an internal compiler error if we combine the
> signbitf128 built-in with a long double type.
> 
> I've gone through several iterations of trying to fix this within GCC, and
> there are various problems that have come up.  I developed this alternative
> patch that changes libgcc so that it does not tickle the issue.  I hope we can
> fix the compiler at some point, but right now, this is preventing people on
> Fedora 36 systems from building compilers where the default long double is IEEE
> 128-bit.

Thanks for working on this!  If updating libgcc source to workaround this issue
is the best option we can have at this moment, it's fine.  Comparing to one
previous proposal which removes the workaround in build_common_tree_nodes for
rs6000 KFmode, a bit concern on this one is that users can still meet the ICE
with a simple case like:

typedef float TFtype __attribute__((mode (TF)));

TFtype
test (TFtype t)
{
  return __builtin_copysignf128 (1.0q, t);
}

but I guess they would write this kind of code very rarely?

BR,
Kewen