fetestexcept reordered with floating point operation

[llvmbot]

Bugzilla Link	35233
Version	4.0
OS	Linux
Attachments	C++11 file exhibiting the bug
Reporter	LLVM Bugzilla Contributor
CC	@andykaylor,@hfinkel,@rotateright

Extended Description

A static_cast of a uint64_t to a double on Clang 4.0 and AArch64 is reordered with a fettestexcept, resulting in the wrong floating point state being tested.

Example output from GCC 6.0: https://godbolt.org/g/pbAW4J

Here's Clang's output:

oot@mcsema-aarch64:/remill# ../remill-build/libraries/llvm/bin/clang++ -std=c++11 -O3 -c /tmp/convert.cc -S -o /tmp/convert.S
root@mcsema-aarch64:/remill# cat /tmp/convert.S
.text
.file "/tmp/convert.cc"
.globl _Z9to_doubleR5flagsm
.p2align 2
.type _Z9to_doubleR5flagsm,@function
_Z9to_doubleR5flagsm: // @​_Z9to_doubleR5flagsm
// BB#0:
stp x20, x19, [sp, #-32]! // 8-byte Folded Spill
mov x19, x0
orr w0, wzr, #​0x1f
stp x29, x30, [sp, #​16] // 8-byte Folded Spill
add x29, sp, #​16 // =16
mov x20, x1
bl feclearexcept
orr w0, wzr, #​0x1f
bl fetestexcept
tbz w0, #​4, .LBB0_2
// BB#1:
orr w8, wzr, #​0x1
str w8, [x19]
.LBB0_2:
tbz w0, #​2, .LBB0_4
// BB#3:
orr w8, wzr, #​0x1
str w8, [x19, #​4]
.LBB0_4:
tbz w0, #​3, .LBB0_6
// BB#5:
orr w8, wzr, #​0x1
str w8, [x19, #​8]
.LBB0_6:
ucvtf d0, x20
tbz w0, #​0, .LBB0_8
// BB#7:
orr w8, wzr, #​0x1
str w8, [x19, #​12]
.LBB0_8:
ldp x29, x30, [sp, #​16] // 8-byte Folded Reload
ldp x20, x19, [sp], #​32 // 8-byte Folded Reload
ret
.Lfunc_end0:
.size _Z9to_doubleR5flagsm, .Lfunc_end0-_Z9to_doubleR5flagsm

[llvmbot]

clang version 4.0.1 (https://github.com/llvm-mirror/clang.git 3c8961bedc65c9a15cbe67a2ef385a0938f7cfef) (https://github.com/llvm-mirror/llvm.git c8fccc53ed66d505898f8850bcc690c977a7c9a7)

[hfinkel]

FWIW, Clang/LLVM currently don't support floating-point environment access. In C, you'd need to use #pragma STDC FENV_ACCESS ON, which we don't support.

There is active work in this area (e.g., to add a mode in which the optimizer respects fp-environment access).

[arsenm]

This requires FENV_ACCESS enabled