https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119246
--- Comment #1 from Tomasz Kamiński <tkaminsk at gcc dot gnu.org> --- As described in PR108053, this problem is caused by normalization of this floating point types to standard floating point type, where they have same representation. We lost the information about the source type in such cases. To resolve the issue, we want to store the 16, 32, 64 in their respective types directly in the basic_format_arg union. We can do that as we have already reserved enum values for such types (_Arg_f16, ...). In the case of the 128 bit floating point type, most platforms already define multiple 128bits integer types: * __float128 and _Float128 for x86_64 * __iee128, __ibm128 and _Float128 for PowerPC As for IBM we need to store both __iee128 and __ibm128 in handle, as either of them can be long double, we need additional enum value for such type. For x86_64 we should use it to store __float128. This will consistently store _Float128 into the handle on all platforms. The impact on additional indirection should not be that visible when formatting 128bit integer.
