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

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

[bugdal at aerifal dot cx]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95921

            Bug ID: 95921
           Summary: [m68k] invalid codegen for __builtin_sqrt
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bugdal at aerifal dot cx
  Target Milestone: ---

On ISA levels below 68040, __builtin_sqrt expands to code that performs an
extended-precision sqrt operation rather than a double-precision one. Not only
does this give the wrong result; it enables further cascadingly-wrong
optimization ala #93806 and related bugs, because the compiler thinks the value
in the output register is a double, but it's not.

I think the right fix is making the rtl in m68k.md only allow long double
operands unless ISA level is at least 68040, in which case the
correctly-rounding instruction can be used. Then the standard function will be
used instead of a builtin definition, and it can patch up the result
accordingly.

[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 <bugdal at aerifal dot cx> ---
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.

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

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95921

--- Comment #2 from Andreas Schwab <schwab@linux-m68k.org> ---
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 #3 from Rich Felker <bugdal at aerifal dot cx> ---
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

[bugdal at aerifal dot cx]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95921

--- Comment #4 from Rich Felker <bugdal at aerifal dot cx> ---
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.