https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93682
--- Comment #3 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- On Tue, 11 Feb 2020, bugdal at aerifal dot cx wrote: > I think the underlying issue here is just that -mpc64 (along with -mpc32) is > just hopelessly broken and should be documented as such. It could probably be > made to work, but there are all sorts of issues like float.h being wrong, math > library code breaking, etc. Correct. It's a link-only option that breaks fundamental compile-time assumptions about how the processor behaves. > On a more fundamental level (but seemingly unrelated to the mechanism of > breakage here), the underlying x87 precision control modes are also hopelessly > broken. They're not actually single/double precision modes, but single/double > mantissa with ld80 exponent. So I don't think it's possible to make the > optimizer aware of them without making it aware of two new floating point > formats that it doesn't presently know about. If you just pretended they were Actually GCC does know about one of those formats (see ieee_extended_intel_96_round_53_format in real.c - apparently this is used by 32-bit FreeBSD).
