On Thu, 29 Apr 2021, Michael Meissner via Gcc-patches wrote: > On Thu, Apr 29, 2021 at 04:31:50PM +0000, Joseph Myers wrote: > > On Thu, 29 Apr 2021, Michael Meissner via Gcc-patches wrote: > > > > > Fix PR bootstrap/100327 (_divkf3.c) on PowerPC. > > > > > > This patch fixes the PowerPC _divkf3.c module to use the appropriate > > > FLT128 constants if long double is not IEEE 128-bit. > > > > > > I have tested this patch by doing a bootstrap on a little endian power9 > > > system running Linux. Can I check this into the trunk? > > > > Why aren't the __LIBGCC_KF_* macros defined? If there's a bug in the > > logic to define macros for all floating-point modes supported by libgcc, > > it should be fixed there. If there's some reason that can't work, the > > commit message needs to explain in more detail. > > As Richard points out, the default libgcc_floating_mode_supported_p returns > false for these types. If you add a target hook to return true for these > types, the c-cppbuiltin.c then aborts because there is no suffix for these > types. There is no target hook to define strings to add new suffixes (or > prefixes).
Presumably the code works with the __FLT128_* macros as used in your patch. Those should expand to constants using the f128 suffix. So there *is* an available suffix here (f128). Why doesn't the code there, which checks all the available _FloatN and _FloatNx types for any with the right machine mode, find that suffix? (The target hook indeed can't return true for modes that don't have any corresponding suffix, e.g. IFmode. The modes for which it returns true may need to depend on the options passed to the compiler.) -- Joseph S. Myers jos...@codesourcery.com
