[Bug target/95921] [m68k] invalid codegen for __builtin_sqrt

[bugdal at aerifal dot cx]

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.

[Bug target/95921] [m68k] invalid codegen for __builtin_sqrt

[bugdal at aerifal dot cx]

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 not be. All results are
deterministic even with excess precision. Moreover if there's excess precision
where gcc's middle end didn't expect it, it will turn into cascadingly wrong
optimization, possibly even making pure integer results wrong.

[Bug target/95921] [m68k] invalid codegen for __builtin_sqrt

[sch...@linux-m68k.org]

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.

[Bug target/95921] [m68k] invalid codegen for __builtin_sqrt

[bugdal at aerifal dot cx]

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 expect the result
to have extended precision and be trying to drop the excess precision
separately. But it's not; it's just returning. Here's my test case:

double my_sqrt(double x)
{
return __builtin_sqrt(x);
}

with -O2 -std=c11 -fno-math-errno -fomit-frame-pointer

The last 2 options are non-critical (GCC still uses the inline insn even with
-fmath-errno and branches only for the exceptional case) but clean up the
output so it's more clear what's going on.