[libc-commits] [libc] [libc][NFC] Remove all trailing spaces from libc (PR #82831)
Joseph Huber via libc-commits
libc-commits at lists.llvm.org
Fri Feb 23 13:02:37 PST 2024
https://github.com/jhuber6 created https://github.com/llvm/llvm-project/pull/82831
Summary:
There are a lot of random training spaces on various lines. This patch
just got rid of all of them with `sed 's/\ \+$//g'.
>From bc8a853a533a03da0ec539da205eb2df40957dad Mon Sep 17 00:00:00 2001
From: Joseph Huber <huberjn at outlook.com>
Date: Fri, 23 Feb 2024 14:59:15 -0600
Subject: [PATCH] [libc][NFC] Remove all trailing spaces from libc
Summary:
There are a lot of random training spaces on various lines. This patch
just got rid of all of them with `sed 's/\ \+$//g'.
---
libc/AOR_v20.02/string/arm/memchr.S | 4 +-
libc/CMakeLists.txt | 2 +-
libc/benchmarks/automemcpy/README.md | 4 +-
.../cmake/modules/CheckCompilerFeatures.cmake | 2 +-
.../modules/LLVMLibCCompileOptionRules.cmake | 2 +-
libc/cmake/modules/LLVMLibCLibraryRules.cmake | 8 +-
libc/cmake/modules/LLVMLibCObjectRules.cmake | 2 +-
libc/cmake/modules/LLVMLibCTestRules.cmake | 14 +-
libc/config/darwin/x86_64/entrypoints.txt | 2 +-
libc/config/linux/x86_64/exclude.txt | 4 +-
libc/config/windows/entrypoints.txt | 2 +-
libc/docs/contributing.rst | 2 +-
libc/docs/date_and_time.rst | 6 +-
libc/docs/dev/clang_tidy_checks.rst | 2 +-
libc/docs/dev/config_options.rst | 2 +-
libc/docs/dev/printf_behavior.rst | 4 +-
libc/docs/full_cross_build.rst | 2 +-
libc/docs/gpu/motivation.rst | 30 +--
libc/docs/gpu/rpc.rst | 204 +++++++++---------
libc/docs/gpu/testing.rst | 4 +-
libc/docs/gpu/using.rst | 18 +-
libc/docs/libc_search.rst | 6 +-
libc/docs/math/index.rst | 6 +-
libc/docs/math/log.rst | 6 +-
libc/docs/porting.rst | 2 +-
libc/docs/stdio.rst | 2 +-
libc/docs/strings.rst | 14 +-
libc/include/fcntl.h.def | 2 +-
libc/include/sched.h.def | 2 +-
libc/include/spawn.h.def | 2 +-
libc/spec/bsd_ext.td | 2 +-
libc/spec/gnu_ext.td | 10 +-
libc/spec/llvm_libc_ext.td | 2 +-
libc/spec/posix.td | 4 +-
libc/src/__support/HashTable/CMakeLists.txt | 2 +-
libc/src/math/generic/CMakeLists.txt | 2 +-
libc/src/search/hsearch/CMakeLists.txt | 2 +-
libc/src/stdio/printf_core/CMakeLists.txt | 2 +-
libc/src/stdio/scanf_core/CMakeLists.txt | 2 +-
libc/src/stdlib/CMakeLists.txt | 6 +-
libc/src/wchar/CMakeLists.txt | 2 +-
libc/startup/linux/CMakeLists.txt | 6 +-
libc/test/integration/scudo/CMakeLists.txt | 2 +-
libc/test/src/__support/CMakeLists.txt | 2 +-
libc/test/src/fenv/CMakeLists.txt | 2 +-
.../math/differential_testing/CMakeLists.txt | 2 +-
libc/test/src/math/smoke/CMakeLists.txt | 2 +-
libc/test/utils/UnitTest/CMakeLists.txt | 4 +-
libc/utils/MPFRWrapper/CMakeLists.txt | 8 +-
libc/utils/gpu/server/CMakeLists.txt | 2 +-
libc/utils/mathtools/GenerateHPDConstants.py | 24 +--
libc/utils/mathtools/ryu_tablegen.py | 2 +-
52 files changed, 227 insertions(+), 227 deletions(-)
diff --git a/libc/AOR_v20.02/string/arm/memchr.S b/libc/AOR_v20.02/string/arm/memchr.S
index a9bba052fb7eee..38aaebd51f7d97 100644
--- a/libc/AOR_v20.02/string/arm/memchr.S
+++ b/libc/AOR_v20.02/string/arm/memchr.S
@@ -49,7 +49,7 @@ __memchr_arm:
and r1,r1,#0xff @ Don't think we can trust the caller to actually pass a char
cmp r2,#16 @ If it's short don't bother with anything clever
- blt 20f
+ blt 20f
tst r0, #7 @ If it's already aligned skip the next bit
beq 10f
@@ -87,7 +87,7 @@ __memchr_arm:
pop {r4,r5,r6,r7}
and r1,r1,#0xff @ Get r1 back to a single character from the expansion above
and r2,r2,#7 @ Leave the count remaining as the number after the double words have been done
-
+
20:
cbz r2, 40f @ 0 length or hit the end already then not found
diff --git a/libc/CMakeLists.txt b/libc/CMakeLists.txt
index 6a57fcec26e473..75fcc91757b807 100644
--- a/libc/CMakeLists.txt
+++ b/libc/CMakeLists.txt
@@ -162,7 +162,7 @@ elseif(LIBC_CMAKE_VERBOSE_LOGGING)
message(STATUS "Path for config files is: ${LIBC_CONFIG_PATH}")
endif()
-# option(LIBC_ENABLE_WIDE_CHARACTERS
+# option(LIBC_ENABLE_WIDE_CHARACTERS
# "Whether to enable wide character functions on supported platforms. This may
# also set flags to enable or disable wide character support within other
# functions (e.g. printf)." ON)
diff --git a/libc/benchmarks/automemcpy/README.md b/libc/benchmarks/automemcpy/README.md
index 88d0b7ece9b9f8..8583368993ef06 100644
--- a/libc/benchmarks/automemcpy/README.md
+++ b/libc/benchmarks/automemcpy/README.md
@@ -17,7 +17,7 @@ git clone https://github.com/Z3Prover/z3.git
python scripts/mk_make.py --prefix=<Z3_INSTALL_DIR>
cd build
make -j
-make install
+make install
```
## Configuration
@@ -68,7 +68,7 @@ Make sure to save the results of the benchmark as a json file.
By default, each function is benchmarked for at least one second, here we lower it to 200ms.
- `--benchmark_filter="BM_Memset|BM_Bzero"`
-
+
By default, all functions are benchmarked, here we restrict them to `memset` and `bzero`.
Other options might be useful, use `--help` for more information.
diff --git a/libc/cmake/modules/CheckCompilerFeatures.cmake b/libc/cmake/modules/CheckCompilerFeatures.cmake
index 9789d72f99dc4c..c3f50df1dda53c 100644
--- a/libc/cmake/modules/CheckCompilerFeatures.cmake
+++ b/libc/cmake/modules/CheckCompilerFeatures.cmake
@@ -57,7 +57,7 @@ foreach(feature IN LISTS ALL_COMPILER_FEATURES)
if(${feature} STREQUAL "float128")
set(LIBC_COMPILER_HAS_FLOAT128 TRUE)
elseif(${feature} STREQUAL "fixed_point")
- set(LIBC_COMPILER_HAS_FIXED_POINT TRUE)
+ set(LIBC_COMPILER_HAS_FIXED_POINT TRUE)
endif()
endif()
endforeach()
diff --git a/libc/cmake/modules/LLVMLibCCompileOptionRules.cmake b/libc/cmake/modules/LLVMLibCCompileOptionRules.cmake
index 408e25b3469c0a..c7ccd392354cb8 100644
--- a/libc/cmake/modules/LLVMLibCCompileOptionRules.cmake
+++ b/libc/cmake/modules/LLVMLibCCompileOptionRules.cmake
@@ -6,7 +6,7 @@ function(_get_compile_options_from_flags output_var)
endif()
check_flag(ADD_SSE4_2_FLAG ${ROUND_OPT_FLAG} ${flags})
check_flag(ADD_EXPLICIT_SIMD_OPT_FLAG ${EXPLICIT_SIMD_OPT_FLAG} ${flags})
-
+
if(LLVM_COMPILER_IS_GCC_COMPATIBLE)
if(ADD_FMA_FLAG)
if(LIBC_TARGET_ARCHITECTURE_IS_X86)
diff --git a/libc/cmake/modules/LLVMLibCLibraryRules.cmake b/libc/cmake/modules/LLVMLibCLibraryRules.cmake
index 9fba51f8ee7f49..c376faafcf2d74 100644
--- a/libc/cmake/modules/LLVMLibCLibraryRules.cmake
+++ b/libc/cmake/modules/LLVMLibCLibraryRules.cmake
@@ -125,7 +125,7 @@ function(add_gpu_entrypoint_library target_name base_target_name)
OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/binary/${name}.gpubin"
COMMAND ${CMAKE_COMMAND} -E make_directory ${CMAKE_CURRENT_BINARY_DIR}/binary
COMMAND ${LIBC_CLANG_OFFLOAD_PACKAGER}
- "${prefix},file=$<JOIN:${object},,file=>" -o
+ "${prefix},file=$<JOIN:${object},,file=>" -o
${CMAKE_CURRENT_BINARY_DIR}/binary/${name}.gpubin
DEPENDS ${dep} ${base_target_name}
COMMENT "Packaging LLVM offloading binary for '${object}'"
@@ -142,7 +142,7 @@ function(add_gpu_entrypoint_library target_name base_target_name)
COMMAND ${CMAKE_COMMAND} -E touch ${CMAKE_CURRENT_BINARY_DIR}/stubs/${name}.cpp
DEPENDS ${dep} ${dep}.__gpubin__ ${base_target_name}
)
- add_custom_target(${dep}.__stub__
+ add_custom_target(${dep}.__stub__
DEPENDS ${dep}.__gpubin__ "${CMAKE_CURRENT_BINARY_DIR}/stubs/${name}.cpp")
add_library(${dep}.__fatbin__
@@ -151,9 +151,9 @@ function(add_gpu_entrypoint_library target_name base_target_name)
)
# This is always compiled for the LLVM host triple instead of the native GPU
- # triple that is used by default in the build.
+ # triple that is used by default in the build.
target_compile_options(${dep}.__fatbin__ BEFORE PRIVATE -nostdlib)
- target_compile_options(${dep}.__fatbin__ PRIVATE
+ target_compile_options(${dep}.__fatbin__ PRIVATE
--target=${LLVM_HOST_TRIPLE}
"SHELL:-Xclang -fembed-offload-object=${CMAKE_CURRENT_BINARY_DIR}/binary/${name}.gpubin")
add_dependencies(${dep}.__fatbin__
diff --git a/libc/cmake/modules/LLVMLibCObjectRules.cmake b/libc/cmake/modules/LLVMLibCObjectRules.cmake
index 78536f4eec55a4..8a84c82206ba6c 100644
--- a/libc/cmake/modules/LLVMLibCObjectRules.cmake
+++ b/libc/cmake/modules/LLVMLibCObjectRules.cmake
@@ -284,7 +284,7 @@ function(create_entrypoint_object fq_target_name)
# The NVPTX target cannot use LTO for the internal targets used for testing.
if(LIBC_TARGET_ARCHITECTURE_IS_NVPTX)
- target_compile_options(${internal_target_name} PRIVATE
+ target_compile_options(${internal_target_name} PRIVATE
-fno-lto -march=${LIBC_GPU_TARGET_ARCHITECTURE})
endif()
diff --git a/libc/cmake/modules/LLVMLibCTestRules.cmake b/libc/cmake/modules/LLVMLibCTestRules.cmake
index 9d1e426a5b7b31..76ce6754bd7339 100644
--- a/libc/cmake/modules/LLVMLibCTestRules.cmake
+++ b/libc/cmake/modules/LLVMLibCTestRules.cmake
@@ -318,8 +318,8 @@ function(add_libc_fuzzer target_name)
target_include_directories(${fq_target_name} SYSTEM PRIVATE ${LIBC_INCLUDE_DIR})
target_include_directories(${fq_target_name} PRIVATE ${LIBC_SOURCE_DIR})
- target_link_libraries(${fq_target_name} PRIVATE
- ${link_object_files}
+ target_link_libraries(${fq_target_name} PRIVATE
+ ${link_object_files}
${LIBC_FUZZER_LINK_LIBRARIES}
)
@@ -352,7 +352,7 @@ endif()
# system libc are linked in to the final executable. The final exe is fully
# statically linked. The libc that the final exe links to consists of only
# the object files of the DEPENDS targets.
-#
+#
# Usage:
# add_integration_test(
# <target name>
@@ -462,7 +462,7 @@ function(add_integration_test test_name)
target_compile_options(${fq_build_target_name} PRIVATE ${compile_options})
if(LIBC_TARGET_ARCHITECTURE_IS_AMDGPU)
- target_link_options(${fq_build_target_name} PRIVATE
+ target_link_options(${fq_build_target_name} PRIVATE
${LIBC_COMPILE_OPTIONS_DEFAULT}
-mcpu=${LIBC_GPU_TARGET_ARCHITECTURE} -flto
"-Wl,-mllvm,-amdgpu-lower-global-ctor-dtor=0" -nostdlib -static
@@ -470,7 +470,7 @@ function(add_integration_test test_name)
elseif(LIBC_TARGET_ARCHITECTURE_IS_NVPTX)
# We need to use the internal object versions for NVPTX.
set(internal_suffix ".__internal__")
- target_link_options(${fq_build_target_name} PRIVATE
+ target_link_options(${fq_build_target_name} PRIVATE
${LIBC_COMPILE_OPTIONS_DEFAULT}
"-Wl,--suppress-stack-size-warning"
-march=${LIBC_GPU_TARGET_ARCHITECTURE} -nostdlib -static
@@ -645,7 +645,7 @@ function(add_libc_hermetic_test test_name)
endforeach()
if(LIBC_TARGET_ARCHITECTURE_IS_AMDGPU)
- target_link_options(${fq_build_target_name} PRIVATE
+ target_link_options(${fq_build_target_name} PRIVATE
${LIBC_COMPILE_OPTIONS_DEFAULT}
-mcpu=${LIBC_GPU_TARGET_ARCHITECTURE} -flto
"-Wl,-mllvm,-amdgpu-lower-global-ctor-dtor=0" -nostdlib -static
@@ -653,7 +653,7 @@ function(add_libc_hermetic_test test_name)
elseif(LIBC_TARGET_ARCHITECTURE_IS_NVPTX)
# We need to use the internal object versions for NVPTX.
set(internal_suffix ".__internal__")
- target_link_options(${fq_build_target_name} PRIVATE
+ target_link_options(${fq_build_target_name} PRIVATE
${LIBC_COMPILE_OPTIONS_DEFAULT}
"-Wl,--suppress-stack-size-warning"
-march=${LIBC_GPU_TARGET_ARCHITECTURE} -nostdlib -static
diff --git a/libc/config/darwin/x86_64/entrypoints.txt b/libc/config/darwin/x86_64/entrypoints.txt
index 91493cb77b1d86..5a1a6a15ef30c0 100644
--- a/libc/config/darwin/x86_64/entrypoints.txt
+++ b/libc/config/darwin/x86_64/entrypoints.txt
@@ -16,7 +16,7 @@ set(TARGET_LIBC_ENTRYPOINTS
libc.src.ctype.toascii
libc.src.ctype.tolower
libc.src.ctype.toupper
-
+
# string.h entrypoints
libc.src.string.bcmp
libc.src.string.bzero
diff --git a/libc/config/linux/x86_64/exclude.txt b/libc/config/linux/x86_64/exclude.txt
index efe3eb9f4671b7..2c218b753b176e 100644
--- a/libc/config/linux/x86_64/exclude.txt
+++ b/libc/config/linux/x86_64/exclude.txt
@@ -9,12 +9,12 @@ try_compile(
)
if(NOT has_sys_random)
- list(APPEND TARGET_LLVMLIBC_REMOVED_ENTRYPOINTS
+ list(APPEND TARGET_LLVMLIBC_REMOVED_ENTRYPOINTS
libc.src.sys.stat.stat
)
# If we're doing a fullbuild we provide the random header ourselves.
if(NOT LLVM_LIBC_FULL_BUILD)
- list(APPEND TARGET_LLVMLIBC_REMOVED_ENTRYPOINTS
+ list(APPEND TARGET_LLVMLIBC_REMOVED_ENTRYPOINTS
libc.src.sys.random.getrandom
)
endif()
diff --git a/libc/config/windows/entrypoints.txt b/libc/config/windows/entrypoints.txt
index 5c3a2e287b9529..1c9ed7bbcfed69 100644
--- a/libc/config/windows/entrypoints.txt
+++ b/libc/config/windows/entrypoints.txt
@@ -116,7 +116,7 @@ set(TARGET_LIBM_ENTRYPOINTS
libc.src.math.acoshf
libc.src.math.asinf
libc.src.math.asinhf
- libc.src.math.atanf
+ libc.src.math.atanf
libc.src.math.atanhf
libc.src.math.copysign
libc.src.math.copysignf
diff --git a/libc/docs/contributing.rst b/libc/docs/contributing.rst
index 50151348f88057..b92575ed4108f5 100644
--- a/libc/docs/contributing.rst
+++ b/libc/docs/contributing.rst
@@ -29,7 +29,7 @@ a list of open projects that one can start with:
#. One is about adding CMake facilities to optionally link the libc's overlay
static archive (see :ref:`overlay_mode`) with other LLVM tools/executables.
#. The other is about putting plumbing in place to release the overlay static
- archive (see :ref:`overlay_mode`) as part of the LLVM binary releases.
+ archive (see :ref:`overlay_mode`) as part of the LLVM binary releases.
#. **Implement Linux syscall wrappers** - A large portion of the POSIX API can
be implemented as syscall wrappers on Linux. A good number have already been
diff --git a/libc/docs/date_and_time.rst b/libc/docs/date_and_time.rst
index 8d25ea6e946135..303dd3fa12df2a 100644
--- a/libc/docs/date_and_time.rst
+++ b/libc/docs/date_and_time.rst
@@ -26,7 +26,7 @@ Implementation Status
* To check date and time functions enabled for Windows:
- - `windows-x86_64 <https://github.com/llvm/llvm-project/tree/main/libc/config/windows/entrypoints.txt>`_
+ - `windows-x86_64 <https://github.com/llvm/llvm-project/tree/main/libc/config/windows/entrypoints.txt>`_
- windows-aarch64 - to be added
@@ -38,11 +38,11 @@ Implementation Status
* To check date and time functions enabled for GPU:
- - `gpu-entrypoints <https://github.com/llvm/llvm-project/tree/main/libc/config/gpu/entrypoints.txt>`_
+ - `gpu-entrypoints <https://github.com/llvm/llvm-project/tree/main/libc/config/gpu/entrypoints.txt>`_
* To check date and time functions enabled for embedded system:
- - `barebone-aarch32 <https://github.com/llvm/llvm-project/tree/main/libc/config/baremetal/arm/entrypoints.txt>`_
+ - `barebone-aarch32 <https://github.com/llvm/llvm-project/tree/main/libc/config/baremetal/arm/entrypoints.txt>`_
- barebone-riscv32 - to be added
diff --git a/libc/docs/dev/clang_tidy_checks.rst b/libc/docs/dev/clang_tidy_checks.rst
index 8ad806993a043c..3feb5375ef113c 100644
--- a/libc/docs/dev/clang_tidy_checks.rst
+++ b/libc/docs/dev/clang_tidy_checks.rst
@@ -75,7 +75,7 @@ a public header with non-namespaced functions like ``string.h`` is included.
This check ensures any function call resolves to a function within the
LIBC_NAMESPACE namespace.
-There are exceptions for the following functions:
+There are exceptions for the following functions:
``__errno_location`` so that ``errno`` can be set;
``malloc``, ``calloc``, ``realloc``, ``aligned_alloc``, and ``free`` since they
are always external and can be intercepted.
diff --git a/libc/docs/dev/config_options.rst b/libc/docs/dev/config_options.rst
index db70342ed74ce9..47f4baef8ebf1a 100644
--- a/libc/docs/dev/config_options.rst
+++ b/libc/docs/dev/config_options.rst
@@ -66,7 +66,7 @@ example, the option-dictionary is:
{
"LIBC_CONF_PRINTF_DISABLE_FLOAT": {
"value": false,
- "doc":
+ "doc":
},
...
}
diff --git a/libc/docs/dev/printf_behavior.rst b/libc/docs/dev/printf_behavior.rst
index bc60aa43ee2b6b..7128c738d19248 100644
--- a/libc/docs/dev/printf_behavior.rst
+++ b/libc/docs/dev/printf_behavior.rst
@@ -2,7 +2,7 @@
Printf Behavior Under All Conditions
====================================
-Introduction:
+Introduction:
=============
On the "defining undefined behavior" page, I said you should write down your
decisions regarding undefined behavior in your functions. This is that document
@@ -102,7 +102,7 @@ behavior.
LIBC_COPT_FLOAT_TO_STR_USE_MEGA_LONG_DOUBLE_TABLE
-------------------------------------------------
When set, the float to string decimal conversion algorithm will use a larger
-table to accelerate long double conversions. This larger table is around 5MB of
+table to accelerate long double conversions. This larger table is around 5MB of
size when compiled.
LIBC_COPT_FLOAT_TO_STR_USE_DYADIC_FLOAT
diff --git a/libc/docs/full_cross_build.rst b/libc/docs/full_cross_build.rst
index cb824730603ad1..f06464534f152d 100644
--- a/libc/docs/full_cross_build.rst
+++ b/libc/docs/full_cross_build.rst
@@ -87,7 +87,7 @@ After configuring the build with the above ``cmake`` command, one can build the
the libc for the target with the following command:
.. code-block:: sh
-
+
$> ninja libc libm
The above ``ninja`` command will build the libc static archives ``libc.a`` and
diff --git a/libc/docs/gpu/motivation.rst b/libc/docs/gpu/motivation.rst
index 171287c3f996f1..7e5336dbbe5de6 100644
--- a/libc/docs/gpu/motivation.rst
+++ b/libc/docs/gpu/motivation.rst
@@ -11,14 +11,14 @@ Motivation and Limitations
Motivation
==========
-This project aims to provide a large subset of the C standard library to users
-of GPU accelerators. We deliberately choose to only implement a subset of the C
-library as some features are not expressly useful or easily implemented on the
-GPU. This will be discussed further in `Limitations <libc_gpu_limitations>`_.
-The main motivation behind this project is to provide the well understood C
+This project aims to provide a large subset of the C standard library to users
+of GPU accelerators. We deliberately choose to only implement a subset of the C
+library as some features are not expressly useful or easily implemented on the
+GPU. This will be discussed further in `Limitations <libc_gpu_limitations>`_.
+The main motivation behind this project is to provide the well understood C
library as a firm base for GPU development.
-The main idea behind this project is that programming GPUs can be as
+The main idea behind this project is that programming GPUs can be as
straightforward as programming on CPUs. This project aims to validate the GPU as
a more general-purpose target. The implementations here will also enable more
complex implementations of other libraries on the GPU, such as ``libc++``.
@@ -31,10 +31,10 @@ toolchain. We also aim to provide these functions in a format compatible with
offloading in ``Clang`` so that we can treat the C library for the GPU as a
standard static library.
-A valuable use for providing C library features on the GPU is for testing. For
-this reason we build `tests on the GPU <libc_gpu_testing>`_ that can run a unit
-test as if it were being run on the CPU. This also helps users port applications
-that traditionally were run on the CPU. With this support, we can expand test
+A valuable use for providing C library features on the GPU is for testing. For
+this reason we build `tests on the GPU <libc_gpu_testing>`_ that can run a unit
+test as if it were being run on the CPU. This also helps users port applications
+that traditionally were run on the CPU. With this support, we can expand test
coverage for the GPU backend to the existing LLVM C library tests.
.. _libc_gpu_limitations:
@@ -43,9 +43,9 @@ Limitations
===========
We only implement a subset of the standard C library. The GPU does not
-currently support thread local variables in all cases, so variables like
-``errno`` are not provided. Furthermore, the GPU under the OpenCL execution
-model cannot safely provide a mutex interface. This means that features like
-file buffering are not implemented on the GPU. We can also not easily provide
-threading features on the GPU due to the execution model so these will be
+currently support thread local variables in all cases, so variables like
+``errno`` are not provided. Furthermore, the GPU under the OpenCL execution
+model cannot safely provide a mutex interface. This means that features like
+file buffering are not implemented on the GPU. We can also not easily provide
+threading features on the GPU due to the execution model so these will be
ignored, as will features like ``locale`` or ``time``.
diff --git a/libc/docs/gpu/rpc.rst b/libc/docs/gpu/rpc.rst
index fb738138568f6e..7b0b35af4da88c 100644
--- a/libc/docs/gpu/rpc.rst
+++ b/libc/docs/gpu/rpc.rst
@@ -11,62 +11,62 @@ Remote Procedure Calls
Remote Procedure Call Implementation
====================================
-Traditionally, the C library abstracts over several functions that interface
-with the platform's operating system through system calls. The GPU however does
+Traditionally, the C library abstracts over several functions that interface
+with the platform's operating system through system calls. The GPU however does
not provide an operating system that can handle target dependent operations.
-Instead, we implemented remote procedure calls to interface with the host's
+Instead, we implemented remote procedure calls to interface with the host's
operating system while executing on a GPU.
-We implemented remote procedure calls using unified virtual memory to create a
-shared communicate channel between the two processes. This memory is often
-pinned memory that can be accessed asynchronously and atomically by multiple
-processes simultaneously. This supports means that we can simply provide mutual
-exclusion on a shared better to swap work back and forth between the host system
-and the GPU. We can then use this to create a simple client-server protocol
+We implemented remote procedure calls using unified virtual memory to create a
+shared communicate channel between the two processes. This memory is often
+pinned memory that can be accessed asynchronously and atomically by multiple
+processes simultaneously. This supports means that we can simply provide mutual
+exclusion on a shared better to swap work back and forth between the host system
+and the GPU. We can then use this to create a simple client-server protocol
using this shared memory.
-This work treats the GPU as a client and the host as a server. The client
-initiates a communication while the server listens for them. In order to
-communicate between the host and the device, we simply maintain a buffer of
-memory and two mailboxes. One mailbox is write-only while the other is
-read-only. This exposes three primitive operations: using the buffer, giving
-away ownership, and waiting for ownership. This is implemented as a half-duplex
-transmission channel between the two sides. We decided to assign ownership of
-the buffer to the client when the inbox and outbox bits are equal and to the
+This work treats the GPU as a client and the host as a server. The client
+initiates a communication while the server listens for them. In order to
+communicate between the host and the device, we simply maintain a buffer of
+memory and two mailboxes. One mailbox is write-only while the other is
+read-only. This exposes three primitive operations: using the buffer, giving
+away ownership, and waiting for ownership. This is implemented as a half-duplex
+transmission channel between the two sides. We decided to assign ownership of
+the buffer to the client when the inbox and outbox bits are equal and to the
server when they are not.
-In order to make this transmission channel thread-safe, we abstract ownership of
-the given mailbox pair and buffer around a port, effectively acting as a lock
-and an index into the allocated buffer slice. The server and device have
-independent locks around the given port. In this scheme, the buffer can be used
-to communicate intent and data generically with the server. We them simply
+In order to make this transmission channel thread-safe, we abstract ownership of
+the given mailbox pair and buffer around a port, effectively acting as a lock
+and an index into the allocated buffer slice. The server and device have
+independent locks around the given port. In this scheme, the buffer can be used
+to communicate intent and data generically with the server. We them simply
provide multiple copies of this protocol and expose them as multiple ports.
-If this were simply a standard CPU system, this would be sufficient. However,
-GPUs have my unique architectural challenges. First, GPU threads execute in
-lock-step with each other in groups typically called warps or wavefronts. We
-need to target the smallest unit of independent parallelism, so the RPC
-interface needs to handle an entire group of threads at once. This is done by
-increasing the size of the buffer and adding a thread mask argument so the
-server knows which threads are active when it handles the communication. Second,
-GPUs generally have no forward progress guarantees. In order to guarantee we do
-not encounter deadlocks while executing it is required that the number of ports
-matches the maximum amount of hardware parallelism on the device. It is also
-very important that the thread mask remains consistent while interfacing with
+If this were simply a standard CPU system, this would be sufficient. However,
+GPUs have my unique architectural challenges. First, GPU threads execute in
+lock-step with each other in groups typically called warps or wavefronts. We
+need to target the smallest unit of independent parallelism, so the RPC
+interface needs to handle an entire group of threads at once. This is done by
+increasing the size of the buffer and adding a thread mask argument so the
+server knows which threads are active when it handles the communication. Second,
+GPUs generally have no forward progress guarantees. In order to guarantee we do
+not encounter deadlocks while executing it is required that the number of ports
+matches the maximum amount of hardware parallelism on the device. It is also
+very important that the thread mask remains consistent while interfacing with
the port.
.. image:: ./rpc-diagram.svg
:width: 75%
:align: center
-The above diagram outlines the architecture of the RPC interface. For clarity
-the following list will explain the operations done by the client and server
+The above diagram outlines the architecture of the RPC interface. For clarity
+the following list will explain the operations done by the client and server
respectively when initiating a communication.
First, a communication from the perspective of the client:
* The client searches for an available port and claims the lock.
-* The client checks that the port is still available to the current device and
+* The client checks that the port is still available to the current device and
continues if so.
* The client writes its data to the fixed-size packet and toggles its outbox.
* The client waits until its inbox matches its outbox.
@@ -75,51 +75,51 @@ First, a communication from the perspective of the client:
Now, the same communication from the perspective of the server:
-* The server searches for an available port with pending work and claims the
+* The server searches for an available port with pending work and claims the
lock.
* The server checks that the port is still available to the current device.
-* The server reads the opcode to perform the expected operation, in this
+* The server reads the opcode to perform the expected operation, in this
case a receive and then send.
* The server reads the data from the fixed-size packet.
* The server writes its data to the fixed-size packet and toggles its outbox.
-* The server closes the port and continues searching for ports that need to be
+* The server closes the port and continues searching for ports that need to be
serviced
-This architecture currently requires that the host periodically checks the RPC
-server's buffer for ports with pending work. Note that a port can be closed
-without waiting for its submitted work to be completed. This allows us to model
-asynchronous operations that do not need to wait until the server has completed
-them. If an operation requires more data than the fixed size buffer, we simply
+This architecture currently requires that the host periodically checks the RPC
+server's buffer for ports with pending work. Note that a port can be closed
+without waiting for its submitted work to be completed. This allows us to model
+asynchronous operations that do not need to wait until the server has completed
+them. If an operation requires more data than the fixed size buffer, we simply
send multiple packets back and forth in a streaming fashion.
Server Library
--------------
-The RPC server's basic functionality is provided by the LLVM C library. A static
-library called ``libllvmlibc_rpc_server.a`` includes handling for the basic
-operations, such as printing or exiting. This has a small API that handles
+The RPC server's basic functionality is provided by the LLVM C library. A static
+library called ``libllvmlibc_rpc_server.a`` includes handling for the basic
+operations, such as printing or exiting. This has a small API that handles
setting up the unified buffer and an interface to check the opcodes.
-Some operations are too divergent to provide generic implementations for, such
-as allocating device accessible memory. For these cases, we provide a callback
-registration scheme to add a custom handler for any given opcode through the
-port API. More information can be found in the installed header
+Some operations are too divergent to provide generic implementations for, such
+as allocating device accessible memory. For these cases, we provide a callback
+registration scheme to add a custom handler for any given opcode through the
+port API. More information can be found in the installed header
``<install>/include/llvmlibc_rpc_server.h``.
Client Example
--------------
-The Client API is not currently exported by the LLVM C library. This is
-primarily due to being written in C++ and relying on internal data structures.
-It uses a simple send and receive interface with a fixed-size packet. The
-following example uses the RPC interface to call a function pointer on the
+The Client API is not currently exported by the LLVM C library. This is
+primarily due to being written in C++ and relying on internal data structures.
+It uses a simple send and receive interface with a fixed-size packet. The
+following example uses the RPC interface to call a function pointer on the
server.
-This code first opens a port with the given opcode to facilitate the
-communication. It then copies over the argument struct to the server using the
-``send_n`` interface to stream arbitrary bytes. The next send operation provides
-the server with the function pointer that will be executed. The final receive
-operation is a no-op and simply forces the client to wait until the server is
+This code first opens a port with the given opcode to facilitate the
+communication. It then copies over the argument struct to the server using the
+``send_n`` interface to stream arbitrary bytes. The next send operation provides
+the server with the function pointer that will be executed. The final receive
+operation is a no-op and simply forces the client to wait until the server is
done. It can be omitted if asynchronous execution is desired.
.. code-block:: c++
@@ -137,23 +137,23 @@ done. It can be omitted if asynchronous execution is desired.
Server Example
--------------
-This example shows the server-side handling of the previous client example. When
-the server is checked, if there are any ports with pending work it will check
-the opcode and perform the appropriate action. In this case, the action is to
+This example shows the server-side handling of the previous client example. When
+the server is checked, if there are any ports with pending work it will check
+the opcode and perform the appropriate action. In this case, the action is to
call a function pointer provided by the client.
-In this example, the server simply runs forever in a separate thread for
-brevity's sake. Because the client is a GPU potentially handling several threads
-at once, the server needs to loop over all the active threads on the GPU. We
-abstract this into the ``lane_size`` variable, which is simply the device's warp
-or wavefront size. The identifier is simply the threads index into the current
-warp or wavefront. We allocate memory to copy the struct data into, and then
-call the given function pointer with that copied data. The final send simply
-signals completion and uses the implicit thread mask to delete the temporary
+In this example, the server simply runs forever in a separate thread for
+brevity's sake. Because the client is a GPU potentially handling several threads
+at once, the server needs to loop over all the active threads on the GPU. We
+abstract this into the ``lane_size`` variable, which is simply the device's warp
+or wavefront size. The identifier is simply the threads index into the current
+warp or wavefront. We allocate memory to copy the struct data into, and then
+call the given function pointer with that copied data. The final send simply
+signals completion and uses the implicit thread mask to delete the temporary
data.
.. code-block:: c++
-
+
for(;;) {
auto port = server.try_open(index);
if (!port)
@@ -181,11 +181,11 @@ data.
CUDA Server Example
-------------------
-The following code shows an example of using the exported RPC interface along
-with the C library to manually configure a working server using the CUDA
-language. Other runtimes can use the presence of the ``__llvm_libc_rpc_client``
-in the GPU executable as an indicator for whether or not the server can be
-checked. These details should ideally be handled by the GPU language runtime,
+The following code shows an example of using the exported RPC interface along
+with the C library to manually configure a working server using the CUDA
+language. Other runtimes can use the presence of the ``__llvm_libc_rpc_client``
+in the GPU executable as an indicator for whether or not the server can be
+checked. These details should ideally be handled by the GPU language runtime,
but the following example shows how it can be used by a standard user.
.. code-block:: cuda
@@ -193,30 +193,30 @@ but the following example shows how it can be used by a standard user.
#include <cstdio>
#include <cstdlib>
#include <cuda_runtime.h>
-
+
#include <llvmlibc_rpc_server.h>
-
+
[[noreturn]] void handle_error(cudaError_t err) {
fprintf(stderr, "CUDA error: %s\n", cudaGetErrorString(err));
exit(EXIT_FAILURE);
}
-
+
[[noreturn]] void handle_error(rpc_status_t err) {
fprintf(stderr, "RPC error: %d\n", err);
exit(EXIT_FAILURE);
}
-
+
// The handle to the RPC client provided by the C library.
extern "C" __device__ void *__llvm_libc_rpc_client;
-
+
__global__ void get_client_ptr(void **ptr) { *ptr = __llvm_libc_rpc_client; }
-
+
// Obtain the RPC client's handle from the device. The CUDA language cannot look
// up the symbol directly like the driver API, so we launch a kernel to read it.
void *get_rpc_client() {
void *rpc_client = nullptr;
void **rpc_client_d = nullptr;
-
+
if (cudaError_t err = cudaMalloc(&rpc_client_d, sizeof(void *)))
handle_error(err);
get_client_ptr<<<1, 1>>>(rpc_client_d);
@@ -227,7 +227,7 @@ but the following example shows how it can be used by a standard user.
handle_error(err);
return rpc_client;
}
-
+
// Routines to allocate mapped memory that both the host and the device can
// access asychonrously to communicate with eachother.
void *alloc_host(size_t size, void *) {
@@ -236,64 +236,64 @@ but the following example shows how it can be used by a standard user.
handle_error(err);
return sharable_ptr;
};
-
+
void free_host(void *ptr, void *) {
if (cudaError_t err = cudaFreeHost(ptr))
handle_error(err);
}
-
+
// The device-side overload of the standard C function to call.
extern "C" __device__ int puts(const char *);
-
+
// Calls the C library function from the GPU C library.
__global__ void hello() { puts("Hello world!"); }
-
+
int main() {
int device = 0;
// Initialize the RPC server to run on a single device.
if (rpc_status_t err = rpc_init(/*num_device=*/1))
handle_error(err);
-
+
// Initialize the RPC server to run on the given device.
if (rpc_status_t err =
rpc_server_init(device, RPC_MAXIMUM_PORT_COUNT,
/*warp_size=*/32, alloc_host, /*data=*/nullptr))
handle_error(err);
-
+
// Initialize the RPC client by copying the buffer to the device's handle.
void *rpc_client = get_rpc_client();
if (cudaError_t err =
cudaMemcpy(rpc_client, rpc_get_client_buffer(device),
rpc_get_client_size(), cudaMemcpyHostToDevice))
handle_error(err);
-
+
cudaStream_t stream;
if (cudaError_t err = cudaStreamCreate(&stream))
handle_error(err);
-
+
// Execute the kernel.
hello<<<1, 1, 0, stream>>>();
-
+
// While the kernel is executing, check the RPC server for work to do.
while (cudaStreamQuery(stream) == cudaErrorNotReady)
if (rpc_status_t err = rpc_handle_server(device))
handle_error(err);
-
+
// Shut down the server running on the given device.
if (rpc_status_t err =
rpc_server_shutdown(device, free_host, /*data=*/nullptr))
handle_error(err);
-
+
// Shut down the entire RPC server interface.
if (rpc_status_t err = rpc_shutdown())
handle_error(err);
-
+
return EXIT_SUCCESS;
}
-The above code must be compiled in CUDA's relocatable device code mode and with
-the advanced offloading driver to link in the library. Currently this can be
-done with the following invocation. Using LTO avoids the overhead normally
+The above code must be compiled in CUDA's relocatable device code mode and with
+the advanced offloading driver to link in the library. Currently this can be
+done with the following invocation. Using LTO avoids the overhead normally
associated with relocatable device code linking.
.. code-block:: sh
@@ -307,6 +307,6 @@ associated with relocatable device code linking.
Extensions
----------
-We describe which operation the RPC server should take with a 16-bit opcode. We
-consider the first 32768 numbers to be reserved while the others are free to
+We describe which operation the RPC server should take with a 16-bit opcode. We
+consider the first 32768 numbers to be reserved while the others are free to
use.
diff --git a/libc/docs/gpu/testing.rst b/libc/docs/gpu/testing.rst
index f793e938e9806f..9842a675283619 100644
--- a/libc/docs/gpu/testing.rst
+++ b/libc/docs/gpu/testing.rst
@@ -18,8 +18,8 @@ Testing Infrastructure
======================
The testing support in LLVM's libc implementation for GPUs is designed to mimic
-the standard unit tests as much as possible. We use the :ref:`libc_gpu_rpc`
-support to provide the necessary utilities like printing from the GPU. Execution
+the standard unit tests as much as possible. We use the :ref:`libc_gpu_rpc`
+support to provide the necessary utilities like printing from the GPU. Execution
is performed by emitting a ``_start`` kernel from the GPU
that is then called by an external loader utility. This is an example of how
this can be done manually:
diff --git a/libc/docs/gpu/using.rst b/libc/docs/gpu/using.rst
index 79b9116c38ed26..1a48c8a3bcba31 100644
--- a/libc/docs/gpu/using.rst
+++ b/libc/docs/gpu/using.rst
@@ -14,11 +14,11 @@ Building the GPU library
LLVM's libc GPU support *must* be built with an up-to-date ``clang`` compiler
due to heavy reliance on ``clang``'s GPU support. This can be done automatically
-using the LLVM runtimes support. The GPU build is done using cross-compilation
-to the GPU architecture. This project currently supports AMD and NVIDIA GPUs
-which can be targeted using the appropriate target name. The following
-invocation will enable a cross-compiling build for the GPU architecture and
-enable the ``libc`` project only for them.
+using the LLVM runtimes support. The GPU build is done using cross-compilation
+to the GPU architecture. This project currently supports AMD and NVIDIA GPUs
+which can be targeted using the appropriate target name. The following
+invocation will enable a cross-compiling build for the GPU architecture and
+enable the ``libc`` project only for them.
.. code-block:: sh
@@ -29,8 +29,8 @@ enable the ``libc`` project only for them.
-DLLVM_ENABLE_PROJECTS="clang;lld;compiler-rt" \
-DLLVM_ENABLE_RUNTIMES="openmp" \
-DCMAKE_BUILD_TYPE=<Debug|Release> \ # Select build type
- -DCMAKE_INSTALL_PREFIX=<PATH> \ # Where 'libcgpu.a' will live
- -DRUNTIMES_nvptx64-nvidia-cuda_LLVM_ENABLE_RUNTIMES=libc \
+ -DCMAKE_INSTALL_PREFIX=<PATH> \ # Where 'libcgpu.a' will live
+ -DRUNTIMES_nvptx64-nvidia-cuda_LLVM_ENABLE_RUNTIMES=libc \
-DRUNTIMES_amdgcn-amd-amdhsa_LLVM_ENABLE_RUNTIMES=libc \
-DLLVM_RUNTIME_TARGETS=default;amdgcn-amd-amdhsa;nvptx64-nvidia-cuda
$> ninja install
@@ -40,8 +40,8 @@ toolchain, we list them in ``LLVM_ENABLE_PROJECTS``. To ensure ``libc`` is built
using a compatible compiler and to support ``openmp`` offloading, we list them
in ``LLVM_ENABLE_RUNTIMES`` to build them after the enabled projects using the
newly built compiler. ``CMAKE_INSTALL_PREFIX`` specifies the installation
-directory in which to install the ``libcgpu-nvptx.a`` and ``libcgpu-amdgpu.a``
-libraries and headers along with LLVM. The generated headers will be placed in
+directory in which to install the ``libcgpu-nvptx.a`` and ``libcgpu-amdgpu.a``
+libraries and headers along with LLVM. The generated headers will be placed in
``include/<gpu-triple>``.
Usage
diff --git a/libc/docs/libc_search.rst b/libc/docs/libc_search.rst
index 605efa8a8e8ea5..4a7ee288dd43e8 100644
--- a/libc/docs/libc_search.rst
+++ b/libc/docs/libc_search.rst
@@ -29,7 +29,7 @@ Type Name Available
============================ =========
ACTION |check|
ENTRY |check|
-VISIT
+VISIT
============================ =========
POSIX Standard Functions
@@ -42,8 +42,8 @@ hcreate |check|
hdestroy |check|
hsearch |check|
insque |check|
-lfind
-lsearch
+lfind
+lsearch
remque |check|
tdelete
tfind
diff --git a/libc/docs/math/index.rst b/libc/docs/math/index.rst
index c586fe6664e27f..8d584338c10f3b 100644
--- a/libc/docs/math/index.rst
+++ b/libc/docs/math/index.rst
@@ -81,7 +81,7 @@ Implementation Status
* To check math functions enabled for Windows:
- - `windows-x86_64 <https://github.com/llvm/llvm-project/tree/main/libc/config/windows/entrypoints.txt>`_
+ - `windows-x86_64 <https://github.com/llvm/llvm-project/tree/main/libc/config/windows/entrypoints.txt>`_
- windows-aarch64 - to be added
@@ -93,11 +93,11 @@ Implementation Status
* To check math functions enabled for GPU:
- - `gpu-entrypoints <https://github.com/llvm/llvm-project/tree/main/libc/config/gpu/entrypoints.txt>`_
+ - `gpu-entrypoints <https://github.com/llvm/llvm-project/tree/main/libc/config/gpu/entrypoints.txt>`_
* To check math functions enabled for embedded system:
- - `baremetal-aarch32 <https://github.com/llvm/llvm-project/tree/main/libc/config/baremetal/arm/entrypoints.txt>`_
+ - `baremetal-aarch32 <https://github.com/llvm/llvm-project/tree/main/libc/config/baremetal/arm/entrypoints.txt>`_
- baremetal-riscv32 - to be added
diff --git a/libc/docs/math/log.rst b/libc/docs/math/log.rst
index 5be880c24f8472..82d2e2be6fb591 100644
--- a/libc/docs/math/log.rst
+++ b/libc/docs/math/log.rst
@@ -121,7 +121,7 @@ Hence we have the following bound on `s`:
In order for `s` to exist, we need that:
.. math::
- \frac{C - (k + 1) 2^{-M}}{1 + (k + 1) 2^{-M}} >
+ \frac{C - (k + 1) 2^{-M}}{1 + (k + 1) 2^{-M}} >
\frac{-C - k 2^{-M}}{1 + k 2^{-M}}
which is equivalent to:
@@ -135,7 +135,7 @@ side of `\text{(C1)}` is bounded by:
.. math::
2^{-M - 1} > \frac{2^{-M - 1}}{1 + (2k + 1) 2^{-M - 1}} \geq
- \frac{2^{-M - 1}}{1 + (2^{M + 1} - 1) 2^{-M - 1}} > 2^{-M - 2}.
+ \frac{2^{-M - 1}}{1 + (2^{M + 1} - 1) 2^{-M - 1}} > 2^{-M - 2}.
Hence, from `\text{(C1)}`, being an exact power of 2, `C = 2^{-N}` is bounded below
by:
@@ -427,7 +427,7 @@ to look-up for the reduction constant `s_{i, k}`. In other word, `k` is given
by the formula:
.. math::
- k = \left\lfloor 2^{N_i + M_i} u_i \right\rfloor
+ k = \left\lfloor 2^{N_i + M_i} u_i \right\rfloor
Notice that our reduction constant `s_{i, k}` must work for all `u_i` in the
interval `I = \{ v: k 2^{-N_i - M_i} \leq v < (k + 1) 2^{-N_i - M_i} \}`,
diff --git a/libc/docs/porting.rst b/libc/docs/porting.rst
index a3b318d3613921..ef7a2ff5cc8758 100644
--- a/libc/docs/porting.rst
+++ b/libc/docs/porting.rst
@@ -30,7 +30,7 @@ If you are starting to bring up LLVM's libc on a new operating system, the first
step is to add a directory for that OS in the ``libc/config`` directory. Both
`Linux <https://github.com/llvm/llvm-project/tree/main/libc/config/linux>`_ and
`Windows <https://github.com/llvm/llvm-project/tree/main/libc/config/windows>`_,
-the two operating systems on which LLVM's libc is being actively developed,
+the two operating systems on which LLVM's libc is being actively developed,
have their own config directory.
.. note:: Windows development is not as active as the development on Linux.
diff --git a/libc/docs/stdio.rst b/libc/docs/stdio.rst
index 1063aa2432af93..4fd6b71a09171b 100644
--- a/libc/docs/stdio.rst
+++ b/libc/docs/stdio.rst
@@ -61,7 +61,7 @@ funlockfile |check|
Operations on system files
==========================
-These functions operate on files on the host's system, without using the
+These functions operate on files on the host's system, without using the
``FILE`` object type. They only take the name of the file being operated on.
============= =========
diff --git a/libc/docs/strings.rst b/libc/docs/strings.rst
index d7e415d371cfb3..427644c407ae83 100644
--- a/libc/docs/strings.rst
+++ b/libc/docs/strings.rst
@@ -36,7 +36,7 @@ Function Name Available
============= =========
bzero |check|
bcmp |check|
-bcopy |check|
+bcopy |check|
memcpy |check|
memset |check|
memcmp |check|
@@ -99,14 +99,14 @@ These functions are not in strings.h, but are still primarily string
functions, and are therefore tracked along with the rest of the string
functions.
-The String to float functions were implemented using the Eisel-Lemire algorithm
+The String to float functions were implemented using the Eisel-Lemire algorithm
(read more about the algorithm here: `The Eisel-Lemire ParseNumberF64 Algorithm
<https://nigeltao.github.io/blog/2020/eisel-lemire.html>`_). This improved
the performance of string to float and double, and allowed it to complete this
comprehensive test 15% faster than glibc: `Parse Number FXX Test Data
-<https://github.com/nigeltao/parse-number-fxx-test-data>`_. The test was done
+<https://github.com/nigeltao/parse-number-fxx-test-data>`_. The test was done
with LLVM-libc built on 2022-04-14 and Debian GLibc version 2.33-6. The targets
-``libc_str_to_float_comparison_test`` and
+``libc_str_to_float_comparison_test`` and
``libc_system_str_to_float_comparison_test`` were built and run on the test data
10 times each, skipping the first run since it was an outlier.
@@ -142,7 +142,7 @@ strerror_r |check|
Localized String Functions
==========================
-These functions require locale.h, and will be finished when locale support is
+These functions require locale.h, and will be finished when locale support is
implemented in LLVM-libc.
============= =========
@@ -160,7 +160,7 @@ Many String functions have an equivalent _s version, which is intended to be
more secure and safe than the previous standard. These functions add runtime
error detection and overflow protection. While they can be seen as an
improvement, adoption remains relatively low among users. In addition, they are
-being considered for removal, see
+being considered for removal, see
`Field Experience With Annex K — Bounds Checking Interfaces
-<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm>`_. For these reasons,
+<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1967.htm>`_. For these reasons,
there is no ongoing work to implement them.
diff --git a/libc/include/fcntl.h.def b/libc/include/fcntl.h.def
index 83d4477d006430..b11645d18c5bde 100644
--- a/libc/include/fcntl.h.def
+++ b/libc/include/fcntl.h.def
@@ -14,4 +14,4 @@
%%public_api()
-#endif // LLVM_LIBC_FCNTL_H
+#endif // LLVM_LIBC_FCNTL_H
diff --git a/libc/include/sched.h.def b/libc/include/sched.h.def
index eb5832690da14d..3b2d5e3308593f 100644
--- a/libc/include/sched.h.def
+++ b/libc/include/sched.h.def
@@ -14,4 +14,4 @@
%%public_api()
-#endif // LLVM_LIBC_SCHED_H
+#endif // LLVM_LIBC_SCHED_H
diff --git a/libc/include/spawn.h.def b/libc/include/spawn.h.def
index 95c24bba0df36b..368ebff17ca12d 100644
--- a/libc/include/spawn.h.def
+++ b/libc/include/spawn.h.def
@@ -13,4 +13,4 @@
%%public_api()
-#endif // LLVM_LIBC_SPAWN_H
+#endif // LLVM_LIBC_SPAWN_H
diff --git a/libc/spec/bsd_ext.td b/libc/spec/bsd_ext.td
index c52d5bf10c80a8..50ca8b919ff2c5 100644
--- a/libc/spec/bsd_ext.td
+++ b/libc/spec/bsd_ext.td
@@ -4,7 +4,7 @@ def BsdExtensions : StandardSpec<"BSDExtensions"> {
[], // Macros
[], // Types
[], // Enumerations
- [
+ [
FunctionSpec<
"strlcat",
RetValSpec<SizeTType>,
diff --git a/libc/spec/gnu_ext.td b/libc/spec/gnu_ext.td
index 1b1b35b4d028be..add07d75050df4 100644
--- a/libc/spec/gnu_ext.td
+++ b/libc/spec/gnu_ext.td
@@ -101,8 +101,8 @@ def GnuExtensions : StandardSpec<"GNUExtensions"> {
FunctionSpec<
"hcreate_r",
RetValSpec<IntType>,
- [
- ArgSpec<SizeTType>,
+ [
+ ArgSpec<SizeTType>,
ArgSpec<StructHsearchDataPtr>
]
>,
@@ -117,7 +117,7 @@ def GnuExtensions : StandardSpec<"GNUExtensions"> {
"hsearch_r",
RetValSpec<IntType>,
[
- ArgSpec<EntryType>,
+ ArgSpec<EntryType>,
ArgSpec<ActionType>,
ArgSpec<EntryTypePtrPtr>,
ArgSpec<StructHsearchDataPtr>
@@ -207,8 +207,8 @@ def GnuExtensions : StandardSpec<"GNUExtensions"> {
[], // Enumerations
[
FunctionSpec<
- "qsort_r",
- RetValSpec<VoidType>,
+ "qsort_r",
+ RetValSpec<VoidType>,
[ArgSpec<VoidPtr>, ArgSpec<SizeTType>, ArgSpec<SizeTType>, ArgSpec<QSortRCompareT>, ArgSpec<VoidPtr>]
>,
]
diff --git a/libc/spec/llvm_libc_ext.td b/libc/spec/llvm_libc_ext.td
index 5e1ae2cfd060d5..2fd0c5f78fb8a7 100644
--- a/libc/spec/llvm_libc_ext.td
+++ b/libc/spec/llvm_libc_ext.td
@@ -36,7 +36,7 @@ def LLVMLibcExt : StandardSpec<"llvm_libc_ext"> {
>,
]
>;
-
+
HeaderSpec Sched = HeaderSpec<
"sched.h",
[], // Macros
diff --git a/libc/spec/posix.td b/libc/spec/posix.td
index 92d0f8edb29946..70be692e208a88 100644
--- a/libc/spec/posix.td
+++ b/libc/spec/posix.td
@@ -1319,7 +1319,7 @@ def POSIX : StandardSpec<"POSIX"> {
"hsearch",
RetValSpec<EntryTypePtr>,
[
- ArgSpec<EntryType>,
+ ArgSpec<EntryType>,
ArgSpec<ActionType>
]
>,
@@ -1339,7 +1339,7 @@ def POSIX : StandardSpec<"POSIX"> {
]
>,
]
- >;
+ >;
HeaderSpec Termios = HeaderSpec<
"termios.h",
diff --git a/libc/src/__support/HashTable/CMakeLists.txt b/libc/src/__support/HashTable/CMakeLists.txt
index 6fa90c780c90d3..c79ee9ab9f414b 100644
--- a/libc/src/__support/HashTable/CMakeLists.txt
+++ b/libc/src/__support/HashTable/CMakeLists.txt
@@ -14,7 +14,7 @@ list(FIND TARGET_ENTRYPOINT_NAME_LIST getrandom getrandom_index)
if (NOT ${getrandom_index} EQUAL -1)
message(STATUS "Using getrandom for hashtable randomness")
set(randomness_compile_flags -DLIBC_HASHTABLE_USE_GETRANDOM)
- set(randomness_extra_depends
+ set(randomness_extra_depends
libc.src.sys.random.getrandom libc.src.errno.errno)
endif()
diff --git a/libc/src/math/generic/CMakeLists.txt b/libc/src/math/generic/CMakeLists.txt
index 07885ae6a3e242..2ef13168bce8f0 100644
--- a/libc/src/math/generic/CMakeLists.txt
+++ b/libc/src/math/generic/CMakeLists.txt
@@ -1437,7 +1437,7 @@ add_entrypoint_object(
../sqrtf128.h
DEPENDS
libc.src.__support.macros.properties.float
- libc.src.__support.FPUtil.sqrt
+ libc.src.__support.FPUtil.sqrt
COMPILE_OPTIONS
-O3
)
diff --git a/libc/src/search/hsearch/CMakeLists.txt b/libc/src/search/hsearch/CMakeLists.txt
index 17289f03d0628f..60a562d748e2ad 100644
--- a/libc/src/search/hsearch/CMakeLists.txt
+++ b/libc/src/search/hsearch/CMakeLists.txt
@@ -1,7 +1,7 @@
add_object_library(
global
SRCS
- global.cpp
+ global.cpp
HDRS
global.h
)
diff --git a/libc/src/stdio/printf_core/CMakeLists.txt b/libc/src/stdio/printf_core/CMakeLists.txt
index 8da274395526df..9b81a7abb6cfd0 100644
--- a/libc/src/stdio/printf_core/CMakeLists.txt
+++ b/libc/src/stdio/printf_core/CMakeLists.txt
@@ -110,7 +110,7 @@ add_object_library(
)
if(NOT (TARGET libc.src.__support.File.file) AND LLVM_LIBC_FULL_BUILD)
- # Not all platforms have a file implementation. If file is unvailable, and a
+ # Not all platforms have a file implementation. If file is unvailable, and a
# full build is requested, then we must skip all file based printf sections.
return()
endif()
diff --git a/libc/src/stdio/scanf_core/CMakeLists.txt b/libc/src/stdio/scanf_core/CMakeLists.txt
index 060dc2d239eee6..b3445300059fa9 100644
--- a/libc/src/stdio/scanf_core/CMakeLists.txt
+++ b/libc/src/stdio/scanf_core/CMakeLists.txt
@@ -75,7 +75,7 @@ add_object_library(
)
if(NOT (TARGET libc.src.__support.File.file) AND LLVM_LIBC_FULL_BUILD)
- # Not all platforms have a file implementation. If file is unvailable, and a
+ # Not all platforms have a file implementation. If file is unvailable, and a
# full build is requested, then we must skip all file based printf sections.
return()
endif()
diff --git a/libc/src/stdlib/CMakeLists.txt b/libc/src/stdlib/CMakeLists.txt
index ce08635df3145f..bd0bcffe0045d1 100644
--- a/libc/src/stdlib/CMakeLists.txt
+++ b/libc/src/stdlib/CMakeLists.txt
@@ -268,7 +268,7 @@ if(LLVM_LIBC_INCLUDE_SCUDO)
set(SCUDO_DEPS "")
include(${LIBC_SOURCE_DIR}/../compiler-rt/cmake/Modules/AllSupportedArchDefs.cmake)
-
+
# scudo distinguishes riscv32 and riscv64, so we need to translate the architecture
set(LIBC_TARGET_ARCHITECTURE_FOR_SCUDO ${LIBC_TARGET_ARCHITECTURE})
if(LIBC_TARGET_ARCHITECTURE_IS_RISCV64)
@@ -278,7 +278,7 @@ if(LLVM_LIBC_INCLUDE_SCUDO)
endif()
if(NOT (LIBC_TARGET_ARCHITECTURE_FOR_SCUDO IN_LIST ALL_SCUDO_STANDALONE_SUPPORTED_ARCH))
- message(FATAL_ERROR "Architecture ${LIBC_TARGET_ARCHITECTURE_FOR_SCUDO} is not supported by SCUDO.
+ message(FATAL_ERROR "Architecture ${LIBC_TARGET_ARCHITECTURE_FOR_SCUDO} is not supported by SCUDO.
Either disable LLVM_LIBC_INCLUDE_SCUDO or change your target architecture.")
endif()
@@ -290,7 +290,7 @@ if(LLVM_LIBC_INCLUDE_SCUDO)
RTGwpAsanBacktraceLibc.${LIBC_TARGET_ARCHITECTURE_FOR_SCUDO}
RTGwpAsanSegvHandler.${LIBC_TARGET_ARCHITECTURE_FOR_SCUDO}
)
-
+
add_entrypoint_external(
malloc
DEPENDS
diff --git a/libc/src/wchar/CMakeLists.txt b/libc/src/wchar/CMakeLists.txt
index 7af881dac79e8c..1d62399c1fe9d7 100644
--- a/libc/src/wchar/CMakeLists.txt
+++ b/libc/src/wchar/CMakeLists.txt
@@ -5,7 +5,7 @@ add_entrypoint_object(
wctob.cpp
HDRS
wctob.h
- DEPENDS
+ DEPENDS
libc.include.stdio
libc.include.wchar
libc.src.__support.wctype_utils
diff --git a/libc/startup/linux/CMakeLists.txt b/libc/startup/linux/CMakeLists.txt
index a287bc4d633d45..68f68ff45aa9ea 100644
--- a/libc/startup/linux/CMakeLists.txt
+++ b/libc/startup/linux/CMakeLists.txt
@@ -37,13 +37,13 @@ function(merge_relocatable_object name)
add_dependencies(${fq_name} ${relocatable_target})
target_link_libraries(${fq_name} INTERFACE ${fq_link_libraries})
set_target_properties(
- ${fq_name}
+ ${fq_name}
PROPERTIES
LINKER_LANGUAGE CXX
IMPORTED_OBJECTS ${CMAKE_CURRENT_BINARY_DIR}/${name}.o
TARGET_TYPE ${OBJECT_LIBRARY_TARGET_TYPE}
DEPS "${fq_link_libraries}"
- )
+ )
endfunction()
function(add_startup_object name)
@@ -56,7 +56,7 @@ function(add_startup_object name)
)
get_fq_target_name(${name} fq_target_name)
-
+
add_object_library(
${name}
SRCS ${ADD_STARTUP_OBJECT_SRC}
diff --git a/libc/test/integration/scudo/CMakeLists.txt b/libc/test/integration/scudo/CMakeLists.txt
index 4fb8b656f89c95..8a085b618044b2 100644
--- a/libc/test/integration/scudo/CMakeLists.txt
+++ b/libc/test/integration/scudo/CMakeLists.txt
@@ -54,5 +54,5 @@ target_link_libraries(libc-gwp-asan-uaf-should-crash
add_custom_command(TARGET libc-scudo-integration-test
POST_BUILD
COMMAND $<TARGET_FILE:libc-scudo-integration-test>
- COMMENT "Run the test after it is built."
+ COMMENT "Run the test after it is built."
VERBATIM)
diff --git a/libc/test/src/__support/CMakeLists.txt b/libc/test/src/__support/CMakeLists.txt
index 53fa1323d18b70..c5634866f839b3 100644
--- a/libc/test/src/__support/CMakeLists.txt
+++ b/libc/test/src/__support/CMakeLists.txt
@@ -182,7 +182,7 @@ if(NOT LIBC_TARGET_OS_IS_GPU)
POST_BUILD
COMMAND $<TARGET_FILE:libc_str_to_float_comparison_test> ${float_test_file}
DEPENDS ${float_test_file}
- COMMENT "Test the strtof and strtod implementations against precomputed results."
+ COMMENT "Test the strtof and strtod implementations against precomputed results."
VERBATIM)
endif()
diff --git a/libc/test/src/fenv/CMakeLists.txt b/libc/test/src/fenv/CMakeLists.txt
index d7b9104cf8304a..ba338bb6c73189 100644
--- a/libc/test/src/fenv/CMakeLists.txt
+++ b/libc/test/src/fenv/CMakeLists.txt
@@ -87,7 +87,7 @@ add_libc_unittest(
if (NOT (LLVM_USE_SANITIZER OR (${LIBC_TARGET_OS} STREQUAL "windows")
OR (${LIBC_TARGET_OS} STREQUAL "darwin")))
- # Sanitizers don't like SIGFPE. So, we will run the
+ # Sanitizers don't like SIGFPE. So, we will run the
# tests which raise SIGFPE only in non-sanitizer builds.
# The tests are also disabled for Windows and MacOS as they fail currently.
# TODO: Investigate and fix the windows failures and enable them for Windows
diff --git a/libc/test/src/math/differential_testing/CMakeLists.txt b/libc/test/src/math/differential_testing/CMakeLists.txt
index 72bc2f8fb16aaa..878f81f1d573c8 100644
--- a/libc/test/src/math/differential_testing/CMakeLists.txt
+++ b/libc/test/src/math/differential_testing/CMakeLists.txt
@@ -61,7 +61,7 @@ function(add_diff_binary target_name)
set_target_properties(${fq_target_name}
PROPERTIES RUNTIME_OUTPUT_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR})
-
+
if(DIFF_CXX_STANDARD)
set_target_properties(
${fq_target_name}
diff --git a/libc/test/src/math/smoke/CMakeLists.txt b/libc/test/src/math/smoke/CMakeLists.txt
index 2d24b5a76b0132..0d6b33bd7d66e1 100644
--- a/libc/test/src/math/smoke/CMakeLists.txt
+++ b/libc/test/src/math/smoke/CMakeLists.txt
@@ -1164,7 +1164,7 @@ if(NOT LIBC_TARGET_OS_IS_GPU)
libc.src.math.fmaxl
libc.src.__support.FPUtil.fp_bits
)
-
+
add_fp_unittest(
fmaxf128_test
SUITE
diff --git a/libc/test/utils/UnitTest/CMakeLists.txt b/libc/test/utils/UnitTest/CMakeLists.txt
index 3b917e06cde21f..d3af8245515b9c 100644
--- a/libc/test/utils/UnitTest/CMakeLists.txt
+++ b/libc/test/utils/UnitTest/CMakeLists.txt
@@ -11,7 +11,7 @@ add_libc_unittest(
SRCS
testfilter_test.cpp
DEPENDS
- # TODO(michaelrj): Remove this dependancy. It's only here because all unit
+ # TODO(michaelrj): Remove this dependancy. It's only here because all unit
# tests must have at least one dependancy.
- libc.src.__support.CPP.bit
+ libc.src.__support.CPP.bit
)
diff --git a/libc/utils/MPFRWrapper/CMakeLists.txt b/libc/utils/MPFRWrapper/CMakeLists.txt
index 6f44ca0d786c85..2f2b0ac09df9a8 100644
--- a/libc/utils/MPFRWrapper/CMakeLists.txt
+++ b/libc/utils/MPFRWrapper/CMakeLists.txt
@@ -7,14 +7,14 @@ if(LIBC_TESTS_CAN_USE_MPFR)
target_compile_options(libcMPFRWrapper PRIVATE -O3)
if (LLVM_LIBC_FULL_BUILD)
# It is not easy to make libcMPFRWrapper a standalone library because gmp.h may unconditionally
- # pull in some STL headers. As a result, targets using this library will need to link against
+ # pull in some STL headers. As a result, targets using this library will need to link against
# C++ and unwind libraries. Since we are using MPFR anyway, we directly specifies the GNU toolchain.
target_link_libraries(libcMPFRWrapper PUBLIC -lstdc++ -lgcc_s)
endif()
add_dependencies(
- libcMPFRWrapper
- libc.src.__support.CPP.string_view
- libc.src.__support.CPP.type_traits
+ libcMPFRWrapper
+ libc.src.__support.CPP.string_view
+ libc.src.__support.CPP.type_traits
libc.src.__support.FPUtil.fp_bits
libc.src.__support.FPUtil.fpbits_str
LibcTest.unit
diff --git a/libc/utils/gpu/server/CMakeLists.txt b/libc/utils/gpu/server/CMakeLists.txt
index 745a248d9b63d2..8712f24de84f7b 100644
--- a/libc/utils/gpu/server/CMakeLists.txt
+++ b/libc/utils/gpu/server/CMakeLists.txt
@@ -14,7 +14,7 @@ target_compile_definitions(llvmlibc_rpc_server PUBLIC
# This utility needs to be compiled for the host system when cross compiling.
if(LLVM_RUNTIMES_TARGET OR LIBC_TARGET_TRIPLE)
- target_compile_options(llvmlibc_rpc_server PUBLIC
+ target_compile_options(llvmlibc_rpc_server PUBLIC
--target=${LLVM_HOST_TRIPLE})
target_link_libraries(llvmlibc_rpc_server PUBLIC
"--target=${LLVM_HOST_TRIPLE}")
diff --git a/libc/utils/mathtools/GenerateHPDConstants.py b/libc/utils/mathtools/GenerateHPDConstants.py
index c37b35e000c53c..642c379f001d5f 100644
--- a/libc/utils/mathtools/GenerateHPDConstants.py
+++ b/libc/utils/mathtools/GenerateHPDConstants.py
@@ -1,17 +1,17 @@
from math import *
"""
-This script is used to generate a table used by
+This script is used to generate a table used by
libc/src/__support/high_precision_decimal.h.
For the ith entry in the table there are two values (indexed starting at 0).
The first value is the number of digits longer the second value would be if
multiplied by 2^i.
-The second value is the smallest number that would create that number of
-additional digits (which in base ten is always 5^i). Anything less creates one
+The second value is the smallest number that would create that number of
+additional digits (which in base ten is always 5^i). Anything less creates one
fewer digit.
-As an example, the 3rd entry in the table is {1, "125"}. This means that if
+As an example, the 3rd entry in the table is {1, "125"}. This means that if
125 is multiplied by 2^3 = 8, it will have exactly one more digit.
Multiplying it out we get 125 * 8 = 1000. 125 is the smallest number that gives
that extra digit, for example 124 * 8 = 992, and all larger 3 digit numbers
@@ -19,17 +19,17 @@
This makes sense because 5^3 * 2^3 = 10^3, the smallest 4 digit number.
For numbers with more digits we can ignore the digits past what's in the second
-value, since the most significant digits determine how many extra digits there
-will be. Looking at the previous example, if we have 1000, and we look at just
-the first 3 digits (since 125 has 3 digits), we see that 100 < 125, so we get
-one fewer than 1 extra digits, which is 0.
-Multiplying it out we get 1000 * 8 = 8000, which fits the expectation.
-Another few quick examples:
+value, since the most significant digits determine how many extra digits there
+will be. Looking at the previous example, if we have 1000, and we look at just
+the first 3 digits (since 125 has 3 digits), we see that 100 < 125, so we get
+one fewer than 1 extra digits, which is 0.
+Multiplying it out we get 1000 * 8 = 8000, which fits the expectation.
+Another few quick examples:
For 1255, 125 !< 125, so 1 digit more: 1255 * 8 = 10040
For 9999, 999 !< 125, so 1 digit more: 9999 * 8 = 79992
-Now let's try an example with the 10th entry: {4, "9765625"}. This one means
-that 9765625 * 2^10 will have 4 extra digits.
+Now let's try an example with the 10th entry: {4, "9765625"}. This one means
+that 9765625 * 2^10 will have 4 extra digits.
Let's skip straight to the examples:
For 1, 1 < 9765625, so 4-1=3 extra digits: 1 * 2^10 = 1024, 1 digit to 4 digits is a difference of 3.
For 9765624, 9765624 < 9765625 so 3 extra digits: 9765624 * 1024 = 9999998976, 7 digits to 10 digits is a difference of 3.
diff --git a/libc/utils/mathtools/ryu_tablegen.py b/libc/utils/mathtools/ryu_tablegen.py
index 91e2029e417710..02806434b7e965 100644
--- a/libc/utils/mathtools/ryu_tablegen.py
+++ b/libc/utils/mathtools/ryu_tablegen.py
@@ -8,7 +8,7 @@
//===----------------------------------------------------------------------===//
-This file is used to generate the tables of values in
+This file is used to generate the tables of values in
src/__support/ryu_constants.h and ryu_long_double constants.h. To use it, set
the constants at the top of the file to the values you want to use for the Ryu
algorithm, then run this file. It will output the appropriate tables to stdout,
More information about the libc-commits
mailing list