We don't need 128-bit integers here, instead rewrite the fp_test.h helpers
to avoid the need for __int128. Also change the high argument for
compareResultF80() and F80FromRep80() to be uint16_t since values greater
than this do not make any sense. This should allow the compiler to detect
accidentally swapping the arguments.
Reviewed By: biabbas, alexander-shaposhnikov
Pull Request: https://github.com/llvm/llvm-project/pull/117818
Issue: #105181
extendhfxf2 calls extendhfXfy to convert _Float16 to double, then type
casts this converted value to long double.
__uint128_t may not be available on all architectures. Thus I din't use
extendhfXfy to widen precision to 128 bits.
Adjust __divsc3 to ensure consistent behavior across x86_64 and AArch64 when the divisor should be treated as infinity if one of its components is a NaN (including signaling NaNs).
Test plan: ninja check-all
This patch deletes two shell scripts in compiler-rt/builtiins/Unit that
seemed to have been used to run the tests at some point, but not
anymore.
They were originally copied over in
8c1441f86037d62f8e164cc458dff8b91d015998,
but have only been updated once since in what seemed like a simple grep.
These files also got lit testing support about seven years ago in
9b7bbeca48b10a0eb81708650777703ce41e67d7 that I believe makes these
scripts completely redundant.
Most of GCC's Linux targets have a link spec
`%{!static|static-pie:--eh-frame-hdr}` that doesn't pass --eh-frame-hdr
for `-static` links. `-static` links are supposed to utilize
`__register_frame_info` (called by `crtbeginT.o`, not by crtbegin.o or
crtbeginS.o) as a replacement.
compiler-rt crtbegin (not used with GCC) has some ehframe code, which is
not utilized because Clang driver unconditionally passes --eh-frame-hdr
for Linux targets, even for -static. In addition, LLVM libunwind
implements `__register_frame_info` as an empty stub.
Furthermore, in a non-static link, the `__register_frame_info`
references can cause an undesired weak dynamic symbol.
For now, just disable the config by default.
As detailed in Issue #72398, the recent builtins rework and
77d75dc9be5c4bb1d9986a475e1c661718067c6a caused `Builtins-sparc-sunos::
divtc3_test.c` to `XPASS` on 32-bit Solaris/SPARC. Since there are
several underlying issues, un-`XFAIL` the test for now until those are
resolved, to turn the Solaris/sparcv9 buildbot green again after 5 days.
Tested on `sparcv9-sun-solaris2.11` and `x86_64-pc-linux-gnu`.
MinGW mode can also use the MSVC/UCRT math functions. On ARM/ARM64,
mingw-w64 has always used the UCRT scalbn function. On x86, mingw-w64
recently changed to prefer the UCRT version for a large number of math
functions.
This is a follow-up to 910a4bf5b.
1. __builtin_clz takes unsigned int, thus for uint16_t
src_rep_t_clz can't use it directly but should subtract 16
(leading 16 bits of the promoted argument are zero).
2. Fix (and simplify) clz_in_sig_frac.
Test plan: ninja check-compiler-rt
(extendhfsf2_test.c and extenddftf2_test.c)
GCC provides these functions (e.g. __addtf3, etc.) in libgcc on x86_64.
Since Clang supports float128, we can also enable the existing code by
using float128 for fp_t if either __FLOAT128__ or __SIZEOF_FLOAT128__ is
defined instead of only supporting these builtins for platforms with
128-bit IEEE long doubles.
This commit defines a new tf_float typedef that matches a float with
attribute((mode(TF)) on each given architecture.
There are more tests that could be enabled for x86, but to keep the diff
smaller, I restricted test changes to ones that started failing as part
of this refactoring.
This change has been tested on x86 (natively) and
aarch64,powerpc64,riscv64 and sparc64 via qemu-user.
This supersedes https://reviews.llvm.org/D98261 and should also cover
the changes from https://github.com/llvm/llvm-project/pull/68041.
This patch implements __extendxftf2 (long double -> f128) and
__trunctfxf2 (f128 -> long double) on x86_64.
This is a preparation to unblock https://reviews.llvm.org/D53608,
We intentionally do not modify compiler-rt/lib/builtins/fp_lib.h in this
PR
(in particular, to limit the scope and avoid exposing other functions on
X86_64 in this PR).
Instead, TODOs were added to use fp_lib.h once it is available.
Test plan:
1. ninja check-compiler-rt (verified on X86_64 and on Aarch64)
In particular, new tests (extendxftf2_test.c and trunctfxf2_test.c) were
added.
2. compared the results of conversions with what other compilers (gcc)
produce.
When compiling the builtins with the undefined behavior sanitizer and running
testcases you end up with the following warning:
UBSan: fp_fixint_impl.inc:39:42: left shift of 8388608 by 40 places cannot be represented in type 'fixint_t' (aka 'long long')
UBSan: fp_fixint_impl.inc:39:17: signed integer overflow: -1 * -9223372036854775808 cannot be represented in type 'fixint_t' (aka 'long long')
This can be avoided by doing the shift and the multiplication in a matching
unsigned variant of the type.
The added test only trigger the intended signed overflow case when the builtins
are built with -D__SOFTFP__.
This was found in an out of tree target.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D159069
This flag does nothing for clang and is apparently not supported by GCC:
aarch64-linux-gnu-gcc: error: unrecognized command-line option '-fnested-functions'; did you mean '-Wunused-function'?
It looks like it was maybe supported by Apple GCC, but that is no longer
a supported compiler.
Differential Revision: https://reviews.llvm.org/D153819
We are trying to build the compiler-rt as big-endian. And found that the tests compiler-rt/test/builtins/Unit/arm/aeabi_cdcmpeq_test.c and compiler-rt/test/builtins/Unit/arm/aeabi_cfcmpeq_test.c do not work on big endian at the moment. This patch makes these tests work on big endian as well.
Reviewed By: peter.smith, simon_tatham
Differential Revision: https://reviews.llvm.org/D155208
Unlike COMPILER_RT_HAS_CRT this handles the case where CRT is available
but has been disabled by setting COMPILER_RT_BUILD_CRT. This addresses
an issue reported on D153989.
Differential Revision: https://reviews.llvm.org/D155126
On Linux crt is typically use in combination with builtins. In the Clang
driver the use of builtins and crt is controlled by the --rtlib option.
Both builtins and crt also have similar build requirements where they
need to be built before any other runtimes and must avoid dependencies.
We also want builtins and crt these to be buildable separately from the
rest of compiler-rt for bootstrapping purposes. Given how simple crt is,
rather than maintaining a separate directory with its own separate build
setup, it's more efficient to just move crt into builtins. We still use
separate CMake option to control whether to built crt same as before.
This is an alternative to D89492 and D136664.
Differential Revision: https://reviews.llvm.org/D153989
On Linux crt is typically use in combination with builtins. In the Clang
driver the use of builtins and crt is controlled by the --rtlib option.
Both builtins and crt also have similar build requirements where they
need to be built before any other runtimes and must avoid dependencies.
We also want builtins and crt these to be buildable separately from the
rest of compiler-rt for bootstrapping purposes. Given how simple crt is,
rather than maintaining a separate directory with its own separate build
setup, it's more efficient to just move crt into builtins. We still use
separate CMake option to control whether to built crt same as before.
This is an alternative to D89492 and D136664.
Differential Revision: https://reviews.llvm.org/D153989
The q floating point suffix is not supported by all compilers
configurations (e.g. GCC only supports it for some targets), so use a
macro (much like UINT64_C) instead. As this touches almost all lines in
the two tests also run them through clang-format.
These conversion functions were using LDBL_MANT_DIG (which is the 80-bit
extended float on x86) instead of the appropriate macro for the 128-bit
floating point type expected by the *tf* softfloat library calls.
This was discovered while testing D98261 (which allows building the *tf*
functions on x86).
This also changes the constants used in the two tests to use 128-bit
floating-point literals instead of long double ones to ensure that the
comparison succeeds on platforms with smaller long double (e.g. x86_64)
Reviewed By: scanon
Differential Revision: https://reviews.llvm.org/D131787
The picolib/newlib implementation of scalbn gives slightly different
results compared to glibc and compiler-rt's inlined
__compiler_rt_scalbn in certain rounding modes. Since these tests
are already disabled for msvc which doesn't respect the mode change,
this patch skips them for newlib as well.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D150280
This is an ongoing series of commits that are reformatting our
Python code. This catches the last of the python files to
reformat. Since they where so few I bunched them together.
Reformatting is done with `black`.
If you end up having problems merging this commit because you
have made changes to a python file, the best way to handle that
is to run git checkout --ours <yourfile> and then reformat it
with black.
If you run into any problems, post to discourse about it and
we will try to help.
RFC Thread below:
https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style
Reviewed By: jhenderson, #libc, Mordante, sivachandra
Differential Revision: https://reviews.llvm.org/D150784
The clang-cl/MSVC case is handled above, thus consider win32 && !is_msvc
to be mingw.
This matches the list of libraries passed by e.g. the libcxx build, when
using -nodefaultlibs.
Differential Revision: https://reviews.llvm.org/D147647
This test succeeds on aarch64 windows now (tested both in mingw
mode and with clang-cl), most probably since commit
ccd96b3e03e18653e909852bfef105fc10782acb / D146667 ([builtins][test] Fix
divmodti4_test.c on Windows).
Differential Revision: https://reviews.llvm.org/D148000
Don't hardcode the vendor field in the triples to "pc"; for mingw
environments the triple is often "<arch>-w64-windows-gnu".
Differential Revision: https://reviews.llvm.org/D147862
The amount to shift should be specified by the int type not a 32-bit integer
type.
This patch change the functions for 128-bit shifts in compiler-rt the same way
as was done for 64-bit shifts in D78662.
The README.txt is updated with the shift builtins signatures from this patch and D78662.
Reviewed By: efriedma
Differential Revision: https://reviews.llvm.org/D146960
By making the 64 bit integer literals unsigned. Otherwise some of them
are unexpectedly sign extended (and the compiler rightly diagnosed this
with warnings)
Initially added in D80506.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D146667
This patch remove xfail decorator from
builtins/Unit/trampoline_setup_test.c as it is passing on Windows/AArch64
nowz. It is being skipped in code with __clang__ not defined.
https://lab.llvm.org/buildbot/#/builders/120/builds/3873
Following tests are marked XFAIl because they are dependent on native
C complex numbers but they are not a native type for Microsoft ABI [1].
Builtins-aarch64-windows :: divmodti4_test.c
Builtins-aarch64-windows :: fixunstfdi_test.c
Builtins-aarch64-windows :: multc3_test.c
Also trampoline_setup_test.c as it runs with only non-clang compiler while
WoA LLVM buildbots use clang.
[1] https://learn.microsoft.com/en-us/cpp/c-runtime-library/complex-math-support?view=msvc-170
