<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 - Wrong code with optimization on i386 FreeBSD"
href="https://bugs.llvm.org/show_bug.cgi?id=41224">41224</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Wrong code with optimization on i386 FreeBSD
</td>
</tr>
<tr>
<th>Product</th>
<td>new-bugs
</td>
</tr>
<tr>
<th>Version</th>
<td>7.0
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>FreeBSD
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>new bugs
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>sgk@troutmask.apl.washington.edu
</td>
</tr>
<tr>
<th>CC</th>
<td>htmldeveloper@gmail.com, llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=21664" name="attach_21664" title="Program that demonstrates the issue">attachment 21664</a> <a href="attachment.cgi?id=21664&action=edit" title="Program that demonstrates the issue">[details]</a></span>
Program that demonstrates the issue
The attached testcase, a.c, demonstrates a code generation issue on FreeBSD
running on an i686 class hardware (i.e., 32-bit i386/387). FreeBSD sets the
i387 FPU to a 53-bit precision when the FPU is first accessed. clang or llvm
seems to have no knowledge of this setting and unconditionally assumes a 64-bit
precision. This leads to wrong for floating point codes that use the 32-bit
float type when optimization is used. Consider,
gcc8 (FreeBSD Ports Collection) 8.3.0
gcc8 -fno-builtin -O0 -o z a.c -lm && ./z
gcc8 -fno-builtin -O1 -o z a.c -lm && ./z
gcc8 -fno-builtin -O2 -o z a.c -lm && ./z
gcc8 -fno-builtin -O3 -o z a.c -lm && ./z
The above command lines yield
Maximum ULP: 2.297073
# of ULP > 21: 0
This is the expected result.
gcc8 -fno-builtin -O0 -DKLUDGE -o z a.c -lm && ./z
gcc8 -fno-builtin -O1 -DKLUDGE -o z a.c -lm && ./z
gcc8 -fno-builtin -O2 -DKLUDGE -o z a.c -lm && ./z
gcc8 -fno-builtin -O3 -DKLUDGE -o z a.c -lm && ./z
The above command lines yield
Maximum ULP: 2.297073
# of ULP > 21: 0
This is the expected result.
Now, consider
FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250)
(based on LLVM 7.0.1)
Target: i386-unknown-freebsd13.0
Thread model: posix
/usr/bin/clang -fno-builtin -O0 -o z a.c -lm && ./z
The above command line yields
Maximum ULP: 2.297073
# of ULP > 21: 0
This is the expected result.
/usr/bin/clang -fno-builtin -O1 -o z a.c -lm && ./z
/usr/bin/clang -fno-builtin -O2 -o z a.c -lm && ./z
/usr/bin/clang -fno-builtin -O3 -o z a.c -lm && ./z
The above command lines yield
Maximum ULP: 23.061242
# of ULP > 21: 39
This is not the expected result. In fact, in my numerical testsuite I have
observed 6 digit Max ULP estimates (i.e., only a single digit is correct).
/usr/bin/clang -fno-builtin -O0 -DKLUDGE -o z a.c -lm && ./z
/usr/bin/clang -fno-builtin -O1 -DKLUDGE -o z a.c -lm && ./z
/usr/bin/clang -fno-builtin -O2 -DKLUDGE -o z a.c -lm && ./z
/usr/bin/clang -fno-builtin -O3 -DKLUDGE -o z a.c -lm && ./z
The above command lines yield
Maximum ULP: 2.297073
# of ULP > 21: 0
which is again the expected results. The -DKLUDGE option causes
the source to use 'volatile float x, y' instead of just 'float x, y'.
AFAICT, from the generated asm (see attachments), the use of volatile
forces clang to spill/reload x, y (thus, using the correct precision
for the type).</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>