Hi Mike, on 2022/12/7 14:44, Michael Meissner wrote: > On Tue, Dec 06, 2022 at 05:36:54PM +0800, Kewen.Lin wrote: >> Hi Mike, >> >> Thanks for fixing this! >> >> Could you help to elaborate why we need to disable it during libgcc building? > > When you are building libgcc, you are building the __mulkc3, __divkc3 > functions. The mapping in the compiler interferes with those functions, > because at the moment, libgcc uses an alternate IEEE 128-bit type. >
But I'm still confused. For __mulkc3 (__divkc3 is similar), 1) with -mabi=ieeelongdouble (TARGET_IEEEQUAD true, define __LONG_DOUBLE_IEEE128__), the used types are: typedef float TFtype __attribute__ ((mode (TF))); typedef __complex float TCtype __attribute__ ((mode (TC))); 2) with -mabi=ibmlongdouble (TARGET_IEEEQUAD false, not __LONG_DOUBLE_IEEE128__ defined), the used types are: typedef float TFtype __attribute__ ((mode (KF))); typedef __complex float TCtype __attribute__ ((mode (KC))); The proposed mapping in the current patch is: + + if (id == complex_multiply_builtin_code (KCmode)) + newname = "__mulkc3"; + + else if (id == complex_multiply_builtin_code (ICmode)) + newname = "__multc3"; + + else if (id == complex_multiply_builtin_code (TCmode)) + newname = (TARGET_IEEEQUAD) ? "__mulkc3" : "__multc3"; for 1), TCmode && TARGET_IEEEQUAD => "__mulkc3" for 2), KCmode => "__mulkc3" Both should be still with name "__mulkc3", do I miss anything? BR, Kewen > I have a patch for making libgcc use the 'right' type that I haven't submitted > yet. This is because the more general fix that these 3 patches do impacts > other > functions (due to __float128 and _Float128 being different in the current > compiler when -mabi=ieeelongdouble). >
