[llvm-bugs] [Bug 47729] New: long double return miscompiled on Solaris/sparcv9

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=47729

            Bug ID: 47729
           Summary: long double return miscompiled on Solaris/sparcv9
           Product: libraries
           Version: trunk
          Hardware: Sun
                OS: Solaris
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: Sparc
          Assignee: unassignedbugs at nondot.org
          Reporter: ro at gcc.gnu.org
                CC: efriedma at quicinc.com, jrtc27 at jrtc27.com,
                    jyknight at google.com, llvm-bugs at lists.llvm.org,
                    llvm-bugzilla at jfbastien.com, venkatra at cs.wisc.edu

Several tests FAIL on Solaris/sparcv9 where long double is 128 bits:

  Builtins-sparcv9-sunos :: addtf3_test.c
  Builtins-sparcv9-sunos :: divtf3_test.c
  Builtins-sparcv9-sunos :: extenddftf2_test.c
  Builtins-sparcv9-sunos :: extendsftf2_test.c
  Builtins-sparcv9-sunos :: floatditf_test.c
  Builtins-sparcv9-sunos :: floatsitf_test.c
  Builtins-sparcv9-sunos :: floattitf_test.c
  Builtins-sparcv9-sunos :: floatunditf_test.c
  Builtins-sparcv9-sunos :: floatunsitf_test.c
  Builtins-sparcv9-sunos :: floatuntitf_test.c
  Builtins-sparcv9-sunos :: multf3_test.c
  Builtins-sparcv9-sunos :: subtf3_test.c

E.g. addtf3_test.c FAILs with

error in test__addtf3(36.40888825164657541977, 0.96444431369742592240) =
37.37333256534401470898, expected 37.37333256534400134216

The error doesn't happen in a 1-stage build with gcc or in a Debug build.

Via side-by-side debugging with addtf3.c.o compiled with clang -O vs. gcc -O
(everything else from a regular 2-stage clang build), it turned out that both
compilers produce the same result until the very end of __addtf3.  The only
difference is in the final fromRep call, which can be seen with this testcase:

$ cat fr.c
typedef long double fp_t;
typedef __uint128_t rep_t;

fp_t fromRep(rep_t x) {
  const union {
    fp_t f;
    rep_t i;
  } rep = {.i = x};
  return rep.f;
}

gcc -m64 -O produces

fromRep:
        add     %sp, -144, %sp
        stx     %o0, [%sp+2175]
        stx     %o1, [%sp+2183]
        ldd     [%sp+2175], %f0
        ldd     [%sp+2183], %f2
        jmp     %o7+8
         add    %sp, 144, %sp

while clang yields

fromRep:                                ! @fromRep
! %bb.0:                                ! %entry
        save %sp, -144, %sp
        add %fp, 2031, %i2
        or %i2, 8, %i2
        stx %i0, [%fp+2031]
        ldd [%fp+2031], %f0
        ldd [%i2], %f2
        stx %i1, [%i2]
        ret
        restore

The long double return value is supposed to be in %f0 and %f2.  gcc handles
this just fine, and clang gets it right for %f0, too.  However, it stores the
contents of an uninitialized stack slot in %f2 and only then stores the second
half (%i1) of the arg there.

I don't have the slightest idea how to fix this codegen bug, but I have a
workaround patch (to be posted for reference shortly) that wraps the affected
functions in #pragma clang optimize off/on (nothing more than a hack to show
that this fixes all the failures above).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20201005/679ab4ec/attachment.html>