Fix typos in documentation
This commit is contained in:
parent
fb250b8295
commit
a82f2b2db3
@ -44,7 +44,7 @@ Command Line Options
|
||||
|
||||
This option specifies a comma-separated list of globs describing the list of
|
||||
callbacks that should be traced. Globs are processed in order of appearance.
|
||||
Positive globs add matched callbacks to the set, netative globs (those with
|
||||
Positive globs add matched callbacks to the set, negative globs (those with
|
||||
the '-' prefix) remove callacks from the set.
|
||||
|
||||
* FileChanged
|
||||
|
@ -3558,7 +3558,7 @@ The third argument is one of the memory ordering specifiers ``__ATOMIC_RELAXED``
|
||||
``__ATOMIC_CONSUME``, ``__ATOMIC_ACQUIRE``, ``__ATOMIC_RELEASE``,
|
||||
``__ATOMIC_ACQ_REL``, or ``__ATOMIC_SEQ_CST`` following C++11 memory model semantics.
|
||||
|
||||
In terms or aquire-release ordering barriers these two operations are always
|
||||
In terms of acquire-release ordering barriers these two operations are always
|
||||
considered as operations with *load-store* semantics, even when the original value
|
||||
is not actually modified after comparison.
|
||||
|
||||
|
@ -207,7 +207,7 @@ Non-comprehensive list of changes in this release
|
||||
``memcmp(&lhs, &rhs, sizeof(T)) == 0``.
|
||||
- Clang now ignores null directives outside of the include guard when deciding
|
||||
whether a file can be enabled for the multiple-include optimization.
|
||||
- Clang now support ``__builtin_FUNCSIG()`` which retruns the same information
|
||||
- Clang now support ``__builtin_FUNCSIG()`` which returns the same information
|
||||
as the ``__FUNCSIG__`` macro (available only with ``-fms-extensions`` flag).
|
||||
This fixes (`#58951 <https://github.com/llvm/llvm-project/issues/58951>`_).
|
||||
|
||||
|
@ -10,7 +10,7 @@ Building Compiler-RT
|
||||
.. _build instructions:
|
||||
|
||||
The instructions on this page are aimed at vendors who ship Compiler-RT as part of an
|
||||
operating system distribution, a toolchain or similar shipping vehicules. If you
|
||||
operating system distribution, a toolchain or similar shipping vehicles. If you
|
||||
are a user merely trying to use Compiler-RT in your program, you most likely want to
|
||||
refer to your vendor's documentation, or to the general documentation for using
|
||||
LLVM, Clang, the various santizers, etc.
|
||||
|
@ -10,7 +10,7 @@ If your ``-Wl,--gc-sections`` build fail with a linker error like this:
|
||||
it is likely your C identifier name sections are not properly annotated to
|
||||
suffice under ``--gc-sections``.
|
||||
|
||||
``__start_meta`` and ``__stop_meta`` are sometimed called encapsulation
|
||||
``__start_meta`` and ``__stop_meta`` are sometimes called encapsulation
|
||||
symbols. In October 2015, GNU ld switched behavior and made a ``__start_meta``
|
||||
reference from a live section retain all ``meta`` input sections. This
|
||||
conservative behavior works for existing code which does not take GC into fair
|
||||
|
@ -117,7 +117,7 @@ outlined in `PEP-8 <https://peps.python.org/pep-0008/>`_.
|
||||
|
||||
For consistency and to limit churn, code should be automatically formatted with the
|
||||
`black <https://github.com/psf/black>`_ utility. Black allows changing the formatting
|
||||
rules based on major version. In order to avoid unecessary churn in the formatting rules
|
||||
rules based on major version. In order to avoid unnecessary churn in the formatting rules
|
||||
we currently use black version 23.x in LLVM.
|
||||
|
||||
Mechanical Source Issues
|
||||
|
@ -725,7 +725,7 @@ LIBOMPTARGET_DEBUG
|
||||
""""""""""""""""""
|
||||
|
||||
``LIBOMPTARGET_DEBUG`` controls whether or not debugging information will be
|
||||
displayed. This feature is only availible if ``libomptarget`` was built with
|
||||
displayed. This feature is only available if ``libomptarget`` was built with
|
||||
``-DOMPTARGET_DEBUG``. The debugging output provided is intended for use by
|
||||
``libomptarget`` developers. More user-friendly output is presented when using
|
||||
``LIBOMPTARGET_INFO``.
|
||||
@ -975,7 +975,7 @@ going wrong.
|
||||
Libomptarget error: Consult https://openmp.llvm.org/design/Runtimes.html for debugging options.
|
||||
sum.cpp:5:1: Libomptarget error 1: failure of target construct while offloading is mandatory
|
||||
|
||||
This shows that there is an illegal memory access occuring inside the OpenMP
|
||||
This shows that there is an illegal memory access occurring inside the OpenMP
|
||||
target region once execution has moved to the CUDA device, suggesting a
|
||||
segmentation fault. This then causes a chain reaction of failures in
|
||||
``libomptarget``. Another message suggests using the ``LIBOMPTARGET_INFO``
|
||||
@ -1061,7 +1061,7 @@ of LLVM did not.
|
||||
LIBOMPTARGET_JIT_OPT_LEVEL
|
||||
""""""""""""""""""""""""""
|
||||
|
||||
This environment variable can be used to change the optimization pipeleine used
|
||||
This environment variable can be used to change the optimization pipeline used
|
||||
to optimize the embedded device code as part of the device JIT. The value is
|
||||
corresponds to the ``-O{0,1,2,3}`` command line argument passed to ``clang``.
|
||||
|
||||
@ -1225,9 +1225,9 @@ LIBOMPTARGET_AMDGPU_MAX_ASYNC_COPY_BYTES
|
||||
|
||||
This environment variable specifies the maximum size in bytes where the memory
|
||||
copies are asynchronous operations in the AMDGPU plugin. Up to this transfer
|
||||
size, the memory copies are asychronous operations pushed to the corresponding
|
||||
size, the memory copies are asynchronous operations pushed to the corresponding
|
||||
stream. For larger transfers, they are synchronous transfers. Memory copies
|
||||
involving already locked/pinned host buffers are always asychronous. The default
|
||||
involving already locked/pinned host buffers are always asynchronous. The default
|
||||
value is ``1*1024*1024`` bytes (1 MB).
|
||||
|
||||
LIBOMPTARGET_AMDGPU_NUM_INITIAL_HSA_SIGNALS
|
||||
@ -1288,7 +1288,7 @@ LIBOMPTARGET_RPC_ADDRESS
|
||||
The address and port at which the server is running. This needs to be set for
|
||||
the server and the application, the default is ``0.0.0.0:50051``. A single
|
||||
OpenMP executable can offload onto multiple remote hosts by setting this to
|
||||
comma-seperated values of the addresses.
|
||||
comma-separated values of the addresses.
|
||||
|
||||
LIBOMPTARGET_RPC_ALLOCATOR_MAX
|
||||
""""""""""""""""""""""""""""""
|
||||
|
Loading…
x
Reference in New Issue
Block a user