https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95921
--- Comment #4 from Rich Felker ---
The related issue I meant to link to is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93681 which is for x87, but the
equivalent happens on m68k due to FLT_EVAL_METHOD being 2 here as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95921
--- Comment #3 from Rich Felker ---
Yes,I'm aware m68k has FLT_EVAL_METHOD=2. That's not license for *functions* to
return excess precision. The language specification is very clear about where
excess precision is and isn't kept, and here it must
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95921
--- Comment #2 from Andreas Schwab ---
The m68k backend generally does all floating point arithmethic in extended
precision for !TARGET_68040, setting FLT_EVAL_METHOD to 2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95921
--- Comment #1 from Rich Felker ---
I wonder if the fact that GCC thinks the output of the insn is already double
suggests other similar bugs in the m68k backend, though... If extended
precision were working correctly, I'd think it would at least
