https://bugs.llvm.org/show_bug.cgi?id=41224
Bug ID: 41224
Summary: Wrong code with optimization on i386 FreeBSD
Product: new-bugs
Version: 7.0
Hardware: PC
OS: FreeBSD
Status: NEW
Severity: enhancement
Priority: P
Component: new bugs
Assignee: unassignedbugs at nondot.org
Reporter: sgk at troutmask.apl.washington.edu
CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org
Created attachment 21664
--> https://bugs.llvm.org/attachment.cgi?id=21664&action=edit
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).
--
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/20190325/eaf3d8f3/attachment.html>