<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - long double return miscompiled on Solaris/sparcv9"
href="https://bugs.llvm.org/show_bug.cgi?id=47729">47729</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>long double return miscompiled on Solaris/sparcv9
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Sun
</td>
</tr>
<tr>
<th>OS</th>
<td>Solaris
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>Backend: Sparc
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>ro@gcc.gnu.org
</td>
</tr>
<tr>
<th>CC</th>
<td>efriedma@quicinc.com, jrtc27@jrtc27.com, jyknight@google.com, llvm-bugs@lists.llvm.org, llvm-bugzilla@jfbastien.com, venkatra@cs.wisc.edu
</td>
</tr></table>
<p>
<div>
<pre>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).</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>