Prior to this change, we wouldn't build headers that aren't referenced
by other parts of the libc which would result in a build error during
installation. To address this, we make the header target a dependency of
the libc archive. Additionally, we also redo the install targets, moving
the install targets closer to build targets and simplifying the
hierarchy and generally matching what we do for other runtimes.
Summary:
We use `add_libc_test' now because it works for both hermetic and unit
tests. If the test needs to be unit test only you use `UNIT_TEST_ONLY`
as an argument.
GCC complains about "type qualifiers ignored on cast result type".
Upon investigation the correct fix was to remove all `volatile` and use the `-frounding-math` option.
This header first appeared in 4.4BSD and is provided by a number of C
libraries including Newlib. Several of our embedded projects use this
header and so to make LLVM libc a drop-in replacement, we need to
provide it as well.
For the initial commit, we only implement singly linked variants (SLIST
and STAILQ). The doubly linked variants (LIST, TAILQ and CIRCLEQ) can be
implemented in the future as needed.
Summary:
A recent patch in https://github.com/llvm/llvm-project/pull/72280
provided `clang` the ability to easily use scoped atomics. These are a
special modifier on atomics that some backends support. They are
intended for providing more fine-grained control over the affected
memory of an atomic action. The default is a "system" scope, e.g.
coherence with the GPU and CPU memory on a heterogeneous system. If we
use "device" scope, that implies that the memory is only ordered with
respect to the current GPU.
These builtins are direct replacements for the GCC atomic builitins in
cases where the backend doesn't do anything with the information, so
these should be a drop-in. This introduces some noise, but hopefully it
isn't too contentious.
In particular, we have internal customers that would like to use nanf
and
scalbnf.
The differences between various entrypoint files can be checked via:
$ comm -3 <(grep libc\.src path/to/entrypoints.txt | sort) \
<(grep libc\.src path/to/other/entrypoints.txt | sort)
These were fixed properly by f1f1875c18.
- Revert "[libc] temporarily set -Wno-shorten-64-to-32 (#77396)"
- Revert "[libc] make off_t 32b for 32b arm (#77350)"
While trying to enable -Werror (#74506), the 32b ARM build bot reported
an
error stemming from -Wshorten-64-to-32 related to usages of `off_t`.
I failed to fix these properly in #77350 (the 32b ARM build is not a
fullbuild)
and #77396.
It turns out, the preprocessor defines `-D_LARGEFILE_SOURCE` and
`-D_FILE_OFFSET_BITS=64` were being set for llvmlibc when using the
cmake build
system. In particular, these preprocessor defines are feature test
macros used
by glibc, and which have effects no the corresponding ABI for types like
`off_t` (for instance, should `off_t` be 32b or 64b on 32b targets).
But who was setting these? Turns out that the use of
add_compile_definitions
in llvm/cmake/modules/HandleLLVMOptions.cmake was setting these (and
more),
which is then inherited by every subdirectory. While some of these
defines
maybe make sense for host builds, they do not make sense for libraries
for the
target. The full list of defines being set prior to this commit:
- `-D_GNU_SOURCE`
- `-D_FILE_OFFSET_BITS=64`
- `-D_DEBUG`
- `-D_GLIBCXX_ASSERTIONS`
- `-D_LARGEFILE_SOURCE`
- `-D_FILE_OFFSET_BITS=64`
- `-D__STDC_CONSTANT_MACROS`
- `-D__STDC_FORMAT_MACROS`
- `-D__STDC_LIMIT_MACROS`
If we desire any of the above, we should manually reset them.
Fix this by resetting COMPILE_DEFINITIONS for the libc/ subdirectory.
Side note: to debug 'directory properties' in cmake, you first need to
use
`get_directory_property` to fetch the corresponding value into a
variable
first, then that variable can be printed via `message`.
Link:
https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html#index-_005fFILE_005fOFFSET_005fBITS
Link:
https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html#index-_005fFILE_005fOFFSET_005fBITSFixes: #77395
This patch removes the `FPBits` specialization for x86 Extended Precision by moving it up to `FPRep`.
It also introduces enums (`Exponent`, `BiasedExponent` and `Significand`) to represent the exponent and significant parts of the floating point numbers. These enums are used to construct and observe floating point representations.
Additionally, we remove `LongDoubleBits.h` that is now unnecessary.
The support introduced in 675702f356b0c3a540fa2e8af4192f7d658b2988 is
not working correctly in all scenarios. Instead of setup_host_tool
function, we can use the existing targets introduced by add_tablegen
macro.
When crosscompiling tools for a different architecture, we need to build
native libc-hdrgen which can be achieved using the existing CMake
support for crosscompiling tablegen tools.
The death test infrastructure seems to depend on operator new, which
isn't currently supported in our hermetic tests. This patch just
disables the death tests in hermetic mode since they only overlap in the
nan tests.
Similar to #77345, the buildbots are observing similar warnings for the
sse2
implementation.
llvm-project/libc/src/__support/HashTable/sse2/bitmask_impl.inc:36:13:
error: suggest braces around initialization of subobject
[-Werror,-Wmissing-braces]
return {bitmask};
^~~~~~~
{ }
llvm-project/libc/src/__support/HashTable/sse2/bitmask_impl.inc:45:13:
error: suggest braces around initialization of subobject
[-Werror,-Wmissing-braces]
return {static_cast<uint16_t>(~mask_available().word)};
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{ }
Link:
https://lab.llvm.org/buildbot/#/builders/163/builds/49350/steps/8/logs/stdio
Link: https://github.com/llvm/llvm-project/pull/74506
Fixes the following diagnostic:
llvm-project/libc/src/sys/mman/linux/mmap.cpp:44:59: error: implicit
conversion loses integer precision: 'off_t' (aka 'long long') to 'long'
[-Werror,-Wshorten-64-to-32]
size, prot, flags, fd, offset);
^~~~~~
It looks like off_t is a curious types on different platforms. FWICT,
it's 32b
on arm (at least for arm-linux-gnueabi) but 64b elsewhere (including 32b
riscv32-linux-gnu).
Fixes the following errors observed on the aarch64 fullbuild:
/home/libc-buildbot/libc-aarch64-ubuntu/libc-aarch64-ubuntu-fullbuild-dbg/llvm-project/libc/src/__support/HashTable/generic/bitmask_impl.inc:116:13:
error: suggest braces around initialization of subobject
[-Werror,-Wmissing-braces]
return {static_cast<bitmask_t>(mask_available().word ^
repeat_byte(0x80))};
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
{ }
In file included from
/home/libc-buildbot/libc-aarch64-ubuntu/libc-aarch64-ubuntu-fullbuild-dbg/llvm-project/libc/src/search/hdestroy.cpp:10:
/home/libc-buildbot/libc-aarch64-ubuntu/libc-aarch64-ubuntu-fullbuild-dbg/llvm-project/libc/src/__support/HashTable/table.h:336:41:
error: suggest braces around initialization of subobject
[-Werror,-Wmissing-braces]
iterator end() const { return {0, 0, {0}, *this}; }
^
{}
Link:
https://lab.llvm.org/buildbot/#/builders/223/builds/33868/steps/6/logs/stdio
Link: https://github.com/llvm/llvm-project/pull/74506
The aarch64 code is using __builtin_return_address with a non-zero
parameter,
which generates the following warning:
llvm-project/libc/src/__support/threads/linux/thread.cpp:171:38: error:
calling '__builtin_frame_address' with a nonzero argument is unsafe
[-Werror,-Wframe-address]
171 | return reinterpret_cast<uintptr_t>(__builtin_frame_address(1));
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
Disable this diagnostic just for this file so that we can enable
-Werror.
Fixes: #77007
Summary:
A previous patch added a dependency on the stack protectors, this was
not built on the GPU targets so every test was disabled. It turns out
that disabled tests still get targets so we need to specifically check
if the it is in the target's set of entrypoints before we can use it.
Another patch, because the build-bot was down, snuck in that prevented
the new math tests from being run. The problem is that the `signal.h`
header requires target specific definitions but was being used
unconditionally. I have made changes that disable building this header
if the file is not defined in the config. This required disbaling the
signal_to_string utility, so that will simply be missing from targets
that don't define it.
This allows individual object files to override the common compile
commands in
their local CMakeLists' add_object_library call.
For example, the common compile commands contain -Wall and -Wextra.
Before
this patch, the per object COMPILE_OPTIONS were prepended to these, so
that
builds of individual object files could not individually disable
specific
diagnostics from those groups explicitly.
After this patch, the per-object file compile objects are appended to
the list
of compiler flags, enabling this use case.
ARGN is a bit of cmake magic; let's be explicit in the APPEND that we're
appending the compile options.
Link: #77007
GCC reports an instance of -Warray-bounds in block_offset. Reimplement
block_offset in terms of memcpy_inline which was created to avoid this
diagnostic. See the linked issue for the full trace of diagnostic.
Fixes: https://github.com/llvm/llvm-project/issues/76877
* separate initialization routines into _start and do_start for all
architectures.
* lift do_start as a separate object library to avoid code duplication.
* (addtionally) address the problem of building hermetic libc with
-fstack-pointer-*
The `crt1.o` is now a merged result of three components:
```
___
|___ x86_64
| |_______ start.cpp.o <- _start (loads process initial stack and aligns stack pointer)
| |_______ tls.cpp.o <- init_tls, cleanup_tls, set_thread_pointer (TLS related routines)
|___ do_start.cpp.o <- do_start (sets up global variables and invokes the main function)
```
This patch reduces the scope of `FPBits` exported variables and
functions.
It also moves storage up into `FPRep` and tries to make the default and
specialized versions of `FPBits` more uniform.
The next step is to move the specialization from `FPBits` to `FPRep` so
we can manipulate floating point representations through `FPType`
alone - that is - independently from the host architecture.
