On Thu, 12 Aug 2021, Patrick McGehearty via Gcc-patches wrote: > > This file includes quad-float128.h, which does some remapping from TF to > > KF depending on __LONG_DOUBLE_IEEE128__. > > > > I think you probably need to have a similar __LONG_DOUBLE_IEEE128__ > > conditional here. If __LONG_DOUBLE_IEEE128__ is not defined, use > > __LIBGCC_KF_* macros instead of __LIBGCC_TF_*; if __LONG_DOUBLE_IEEE128__ > > is defined, use __LIBGCC_TF_* as above. (Unless the powerpc maintainers > > say otherwise.) > --------- > The KF version fails when in IBM128 mode while the DF version works > for that mode.
KFmode should always be IEEE binary128. IFmode should always be IBM long double. TFmode may be one or the other depending on command-line options. "in IBM128 mode" should mean that the compiler defaults to long double being IBM long double and TFmode being IBM long double. But in that mode, KFmode should still be IEEE binary128 and it should still be correct to use the KF constants in this file. > My understanding of ibm FP mode build procedure is minimal, > but it seems that the _divkc3.c routine is built for both IEEE128 > and IBM128 modes. If built for IBM128 mode (i.e., compiler defaults to TFmode = IBM long double), it should still build a function __divkc3 which takes IEEE binary128 arguments and uses IEEE binary128 (KFmode) constants. If you were changing the L_divtc3 case in libgcc2.c to use different constants in the case where TFmode is IBM long double, that would make sense to me. It's changing an IEEE-only file for an IBM long double issue that doesn't make sense. If this change causes some test using IBM long double to pass where it failed before, that indicates a build system problem somewhere. -- Joseph S. Myers jos...@codesourcery.com
