llvm-project

History

Michal Gorny 7b97bf233f [test] [builtins] Remove obsolete/UB tests in __fixuns?fdi based Remove the failing tests for __fixunssfdi() and __fixunsdfdi() that relied on undefined (and most likely obsolete in terms of compiler-rt implementation behavior). Both tests presumed that 0x1.p+64 would be converted to 0xFFFFFFFFFFFFFFFFLL, that is the largest value in uint64 range. However, the C/C++ standards do not specify the behavior for converting a floating-point value to an integer of smaller range, and in this case both libgcc and compiler-rt implementations return 0 instead. Since the current behavior is correct with regards to standards and there is no good way of expressing 0xFFFFFFFFFFFFFFFFLL in single- or double-precision float, I've removed the failing test altogether. Differential Revision: https://reviews.llvm.org/D28146 llvm-svn: 292257	2017-01-17 21:08:25 +00:00
..
Unit	[test] [builtins] Remove obsolete/UB tests in __fixuns?fdi based	2017-01-17 21:08:25 +00:00
timing	…

Michal Gorny 7b97bf233f [test] [builtins] Remove obsolete/UB tests in __fixuns?fdi based

Remove the failing tests for __fixunssfdi() and __fixunsdfdi() that
relied on undefined (and most likely obsolete in terms of compiler-rt
implementation behavior).

Both tests presumed that 0x1.p+64 would be converted to
0xFFFFFFFFFFFFFFFFLL, that is the largest value in uint64 range.
However, the C/C++ standards do not specify the behavior for converting
a floating-point value to an integer of smaller range, and in this case
both libgcc and compiler-rt implementations return 0 instead.

Since the current behavior is correct with regards to standards
and there is no good way of expressing 0xFFFFFFFFFFFFFFFFLL in single-
or double-precision float, I've removed the failing test altogether.

Differential Revision: https://reviews.llvm.org/D28146

llvm-svn: 292257

2017-01-17 21:08:25 +00:00

Unit

[test] [builtins] Remove obsolete/UB tests in __fixuns?fdi based

2017-01-17 21:08:25 +00:00

timing

…