llvmorg-github-actions[bot] wrote:
<!--LLVM PR SUMMARY COMMENT--> @llvm/pr-subscribers-backend-amdgpu Author: Reid Kleckner (rnk) <details> <summary>Changes</summary> Tracking issue: https://github.com/llvm/llvm-project/issues/201242 Migration guide docs: https://llvm.org/docs/SphinxQuickstartTemplate.html#markdown-migration-guidelines RFC: https://discourse.llvm.org/t/rfc-make-myst-markdown-the-llvm-docs-format-rip-rest/90840 This was prepared with rst2myst plus LLM-assisted cleanup. I paged through all the generated HTML looking for migration artifacts, and all of the differences I could find appear to be formatting error corrections. Please spot check my work and approve if it looks good. You can use the HTML links below to confirm it renders properly. ---- Before/after validation links: | Source file | Before HTML | After HTML | | --- | --- | --- | | `clang/docs/AllocToken.md` | [before](https://clang.llvm.org/docs/AllocToken.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/AllocToken.html) | | `clang/docs/BoundsSafety.md` | [before](https://clang.llvm.org/docs/BoundsSafety.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/BoundsSafety.html) | | `clang/docs/BoundsSafetyAdoptionGuide.md` | [before](https://clang.llvm.org/docs/BoundsSafetyAdoptionGuide.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/BoundsSafetyAdoptionGuide.html) | | `clang/docs/BoundsSafetyImplPlans.md` | [before](https://clang.llvm.org/docs/BoundsSafetyImplPlans.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/BoundsSafetyImplPlans.html) | | `clang/docs/ControlFlowIntegrity.md` | [before](https://clang.llvm.org/docs/ControlFlowIntegrity.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/ControlFlowIntegrity.html) | | `clang/docs/APINotes.md` | [before](https://clang.llvm.org/docs/APINotes.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/APINotes.html) | | `clang/docs/DebuggingCoroutines.md` | [before](https://clang.llvm.org/docs/DebuggingCoroutines.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/DebuggingCoroutines.html) | | `clang/docs/AMDGPUSupport.md` | [before](https://clang.llvm.org/docs/AMDGPUSupport.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/AMDGPUSupport.html) | | `clang/docs/RISCVSupport.md` | [before](https://clang.llvm.org/docs/RISCVSupport.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/RISCVSupport.html) | | `clang/docs/CXXTypeAwareAllocators.md` | [before](https://clang.llvm.org/docs/CXXTypeAwareAllocators.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/CXXTypeAwareAllocators.html) | | `clang/docs/CIR/index.md` | [before](https://clang.llvm.org/docs/CIR/index.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/CIR/index.html) | | `clang/docs/CommandGuide/index.md` | [before](https://clang.llvm.org/docs/CommandGuide/index.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/CommandGuide/index.html) | | `clang/docs/FAQ.md` | [before](https://clang.llvm.org/docs/FAQ.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/FAQ.html) | | `clang/docs/Tooling.md` | [before](https://clang.llvm.org/docs/Tooling.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/Tooling.html) | | `clang/docs/ExternalClangExamples.md` | [before](https://clang.llvm.org/docs/ExternalClangExamples.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/ExternalClangExamples.html) | | `clang/docs/IntroductionToTheClangAST.md` | [before](https://clang.llvm.org/docs/IntroductionToTheClangAST.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/IntroductionToTheClangAST.html) | | `clang/docs/LibTooling.md` | [before](https://clang.llvm.org/docs/LibTooling.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/LibTooling.html) | | `clang/docs/LibClang.md` | [before](https://clang.llvm.org/docs/LibClang.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/LibClang.html) | | `clang/docs/LibFormat.md` | [before](https://clang.llvm.org/docs/LibFormat.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/LibFormat.html) | | `clang/docs/ClangPlugins.md` | [before](https://clang.llvm.org/docs/ClangPlugins.html) | [after](https://llvmdocs.staging.reidkleckner.dev/clang/docs/ClangPlugins.html) | --- Patch is 336.58 KiB, truncated to 20.00 KiB below, full version: https://github.com/llvm/llvm-project/pull/209283.diff 20 Files Affected: - (modified) clang/docs/AMDGPUSupport.md (+23-57) - (modified) clang/docs/APINotes.md (+14-22) - (modified) clang/docs/AllocToken.md (+126-140) - (modified) clang/docs/BoundsSafety.md (+567-602) - (modified) clang/docs/BoundsSafetyAdoptionGuide.md (+48-56) - (modified) clang/docs/BoundsSafetyImplPlans.md (+97-116) - (modified) clang/docs/CIR/index.md (+15-15) - (modified) clang/docs/CXXTypeAwareAllocators.md (+64-71) - (modified) clang/docs/ClangPlugins.md (+125-146) - (modified) clang/docs/CommandGuide/index.md (+10-10) - (modified) clang/docs/ControlFlowIntegrity.md (+151-174) - (modified) clang/docs/DebuggingCoroutines.md (+906-931) - (modified) clang/docs/ExternalClangExamples.md (+96-83) - (modified) clang/docs/FAQ.md (+38-43) - (modified) clang/docs/IntroductionToTheClangAST.md (+67-72) - (modified) clang/docs/LibClang.md (+321-338) - (modified) clang/docs/LibFormat.md (+41-47) - (modified) clang/docs/LibTooling.md (+138-151) - (modified) clang/docs/RISCVSupport.md (+20-21) - (modified) clang/docs/Tooling.md (+41-46) ``````````diff diff --git a/clang/docs/AMDGPUSupport.md b/clang/docs/AMDGPUSupport.md index 8ca537fa5d729..8731af371b23f 100644 --- a/clang/docs/AMDGPUSupport.md +++ b/clang/docs/AMDGPUSupport.md @@ -1,66 +1,32 @@ -.. raw:: html +```{contents} +:local: true +``` - <style type="text/css"> - .none { background-color: #FFCCCC } - .part { background-color: #FFFF99 } - .good { background-color: #CCFF99 } - </style> - -.. role:: none -.. role:: part -.. role:: good - -.. contents:: - :local: - -============== -AMDGPU Support -============== +# AMDGPU Support Clang supports OpenCL, HIP and OpenMP on AMD GPU targets. - -Predefined Macros -================= - - -.. list-table:: - :header-rows: 1 - - * - Macro - - Description - * - ``__AMDGPU__`` - - Indicates that the code is being compiled for an AMD GPU. - * - ``__AMDGCN__`` - - Defined if the GPU target is AMDGCN. - * - ``__R600__`` - - Defined if the GPU target is R600. - * - ``__<ArchName>__`` - - Defined with the name of the architecture (e.g., ``__gfx906__`` for the gfx906 architecture). - * - ``__<GFXN>__`` - - Defines the GFX family (e.g., for gfx906, this macro would be ``__GFX9__``). - * - ``__amdgcn_processor__`` - - Defined with the processor name as a string (e.g., ``"gfx906"``). - * - ``__amdgcn_target_id__`` - - Defined with the target ID as a string. - * - ``__amdgcn_feature_<feature-name>__`` - - Defined for each supported target feature. The value is 1 if the feature is enabled and 0 if it is disabled. Allowed feature names are sramecc and xnack. - * - ``__AMDGCN_CUMODE__`` - - Defined as 1 if the CU mode is enabled and 0 if the WGP mode is enabled. - * - ``__AMDGCN_UNSAFE_FP_ATOMICS__`` - - Defined if unsafe floating-point atomics are allowed. - * - ``__HAS_FMAF__`` - - Defined if FMAF instruction is available (deprecated). - * - ``__HAS_LDEXPF__`` - - Defined if LDEXPF instruction is available (deprecated). - * - ``__HAS_FP64__`` - - Defined if FP64 instruction is available (deprecated). +## Predefined Macros + +| Macro | Description | +| --- | --- | +| `__AMDGPU__` | Indicates that the code is being compiled for an AMD GPU. | +| `__AMDGCN__` | Defined if the GPU target is AMDGCN. | +| `__R600__` | Defined if the GPU target is R600. | +| `__<ArchName>__` | Defined with the name of the architecture (e.g., `__gfx906__` for the gfx906 architecture). | +| `__<GFXN>__` | Defines the GFX family (e.g., for gfx906, this macro would be `__GFX9__`). | +| `__amdgcn_processor__` | Defined with the processor name as a string (e.g., `"gfx906"`). | +| `__amdgcn_target_id__` | Defined with the target ID as a string. | +| `__amdgcn_feature_<feature-name>__` | Defined for each supported target feature. The value is 1 if the feature is enabled and 0 if it is disabled. Allowed feature names are sramecc and xnack. | +| `__AMDGCN_CUMODE__` | Defined as 1 if the CU mode is enabled and 0 if the WGP mode is enabled. | +| `__AMDGCN_UNSAFE_FP_ATOMICS__` | Defined if unsafe floating-point atomics are allowed. | +| `__HAS_FMAF__` | Defined if FMAF instruction is available (deprecated). | +| `__HAS_LDEXPF__` | Defined if LDEXPF instruction is available (deprecated). | +| `__HAS_FP64__` | Defined if FP64 instruction is available (deprecated). | Please note that the specific architecture and feature names will vary depending on the GPU. Also, some macros are deprecated and may be removed in future releases. - -Target-Specific Builtins -======================== +## Target-Specific Builtins Clang exposes AMDGPU hardware intrinsics as target-specific builtins with the -``__builtin_amdgcn_`` prefix. These are documented in :doc:`AMDGPUBuiltinReference`. +`__builtin_amdgcn_` prefix. These are documented in {doc}`AMDGPUBuiltinReference`. diff --git a/clang/docs/APINotes.md b/clang/docs/APINotes.md index 8a1018011d023..4d8646ec36c27 100644 --- a/clang/docs/APINotes.md +++ b/clang/docs/APINotes.md @@ -1,6 +1,4 @@ -================================================ -API Notes: Annotations Without Modifying Headers -================================================ +# API Notes: Annotations Without Modifying Headers **The Problem:** You have headers you want to use, but you also want to add extra information to the API. You don't want to put that information in the @@ -11,9 +9,9 @@ want to modify them at all. **Incomplete solution:** Redeclare all the interesting parts of the API in your own header and add the attributes you want. Unfortunately, this: -* doesn't work with attributes that must be present on a definition -* doesn't allow changing the definition in other ways -* requires your header to be included in any client code to take effect +- doesn't work with attributes that must be present on a definition +- doesn't allow changing the definition in other ways +- requires your header to be included in any client code to take effect **Better solution:** Provide a "sidecar" file with the information you want to add, and have that automatically get picked up by the module-building logic in @@ -22,14 +20,11 @@ the compiler. That's API notes. API notes use a YAML-based file format. YAML is a format best explained by -example, so here is a `small example -<https://github.com/llvm/llvm-project/blob/main/clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKit.apinotes>`_ +example, so here is a [small example](https://github.com/llvm/llvm-project/blob/main/clang/test/APINotes/Inputs/Frameworks/SomeKit.framework/Headers/SomeKit.apinotes) from the compiler test suite of API notes for a hypothetical "SomeKit" framework. - -Usage -===== +## Usage API notes files are found relative to the module map that defines a module, under the name "SomeKit.apinotes" for a module named "SomeKit". Additionally, a @@ -42,34 +37,30 @@ PrivateHeaders directory as well, though it does not need an additional "_private" suffix on its name. Clang will search for API notes files next to module maps only when passed the -``-fapinotes-modules`` option. - +`-fapinotes-modules` option. -Limitations -=========== +## Limitations - Since they're identified by module name, API notes cannot be used to modify arbitrary textual headers. - -"Versioned" API Notes -===================== +## "Versioned" API Notes Many API notes affect how a C API is imported into Swift. In order to change that behavior while still remaining backwards-compatible, API notes can be selectively applied based on the Swift compatibility version provided to the -compiler (e.g. ``-fapi-notes-swift-version=5``). The rule is that an +compiler (e.g. `-fapi-notes-swift-version=5`). The rule is that an explicitly-versioned API note applies to that version *and all earlier versions,* and any applicable explicitly-versioned API note takes precedence over an unversioned API note. - -Reference -========= +## Reference An API notes file contains a YAML dictionary with the following top-level entries: +```{eval-rst} + :Name: The name of the module (the framework name, for frameworks). Note that this @@ -513,3 +504,4 @@ declaration kind), all of which are optional: - Selector: "initWithFrame:" MethodKind: Instance DesignatedInit: true +``` diff --git a/clang/docs/AllocToken.md b/clang/docs/AllocToken.md index a7d8043734ee6..7083d7d655641 100644 --- a/clang/docs/AllocToken.md +++ b/clang/docs/AllocToken.md @@ -1,12 +1,10 @@ -================= -Allocation Tokens -================= +# Allocation Tokens -.. contents:: - :local: +```{contents} +:local: true +``` -Introduction -============ +## Introduction Clang provides support for allocation tokens to enable allocator-level heap organization strategies. Clang assigns mode-dependent token IDs to allocation @@ -15,55 +13,49 @@ compatible memory allocator. Possible allocator strategies include: -* **Security Hardening**: Placing allocations into separate, isolated heap +- **Security Hardening**: Placing allocations into separate, isolated heap partitions. For example, separating pointer-containing types from raw data can mitigate exploits that rely on overflowing a primitive buffer to corrupt object metadata. - -* **Memory Layout Optimization**: Grouping related allocations to improve data +- **Memory Layout Optimization**: Grouping related allocations to improve data locality and cache utilization. - -* **Custom Allocation Policies**: Applying different management strategies to +- **Custom Allocation Policies**: Applying different management strategies to different partitions. -Token Assignment Mode -===================== +## Token Assignment Mode The default mode to calculate tokens is: -* ``typehashpointersplit``: This mode assigns a token ID based on the hash of +- `typehashpointersplit`: This mode assigns a token ID based on the hash of the allocated type's name, where the top half ID-space is reserved for types that contain pointers and the bottom half for types that do not contain pointers. Other token ID assignment modes are supported, but they may be subject to -change or removal. These may (experimentally) be selected with ``-Xclang --falloc-token-mode=<mode>``: +change or removal. These may (experimentally) be selected with `-Xclang +-falloc-token-mode=<mode>`: -* ``typehash``: This mode assigns a token ID based on the hash of the allocated +- `typehash`: This mode assigns a token ID based on the hash of the allocated type's name. - -* ``random``: This mode assigns a statically-determined random token ID to each +- `random`: This mode assigns a statically-determined random token ID to each allocation site. - -* ``increment``: This mode assigns a simple, incrementally increasing token ID +- `increment`: This mode assigns a simple, incrementally increasing token ID to each allocation site. The following command-line options affect generated token IDs: -* ``-falloc-token-max=<N>`` - Configures the maximum number of token IDs. By default the number of tokens - is bounded by ``SIZE_MAX``. +- `-falloc-token-max=<N>` + : Configures the maximum number of token IDs. By default the number of tokens + is bounded by `SIZE_MAX`. -Querying Token IDs with ``__builtin_infer_alloc_token`` -======================================================= +## Querying Token IDs with `__builtin_infer_alloc_token` For use cases where the token ID must be known at compile time, Clang provides a builtin function: -.. code-block:: c - - size_t __builtin_infer_alloc_token(<args>, ...); +```c +size_t __builtin_infer_alloc_token(<args>, ...); +``` This builtin returns the token ID inferred from its argument expressions, which mirror arguments normally passed to any allocation function. The argument @@ -72,168 +64,162 @@ have side effects without any runtime impact. For example, it can be used as follows: -.. code-block:: c +```c +struct MyType { ... }; +void *__partition_alloc(size_t size, size_t partition); +#define partition_alloc(...) __partition_alloc(__VA_ARGS__, __builtin_infer_alloc_token(__VA_ARGS__)) - struct MyType { ... }; - void *__partition_alloc(size_t size, size_t partition); - #define partition_alloc(...) __partition_alloc(__VA_ARGS__, __builtin_infer_alloc_token(__VA_ARGS__)) +void foo(void) { + MyType *x = partition_alloc(sizeof(*x)); +} +``` - void foo(void) { - MyType *x = partition_alloc(sizeof(*x)); - } - -Allocation Token Instrumentation -================================ +## Allocation Token Instrumentation To enable instrumentation of allocation functions, code can be compiled with -the ``-fsanitize=alloc-token`` flag: - -.. code-block:: console +the `-fsanitize=alloc-token` flag: - % clang++ -fsanitize=alloc-token example.cc +```console +% clang++ -fsanitize=alloc-token example.cc +``` The instrumentation transforms allocation calls to include a token ID. For example: -.. code-block:: c - - // Original: - ptr = malloc(size); +```c +// Original: +ptr = malloc(size); - // Instrumented: - ptr = __alloc_token_malloc(size, <token id>); +// Instrumented: +ptr = __alloc_token_malloc(size, <token id>); +``` -Runtime Interface ------------------ +### Runtime Interface A compatible runtime must be provided that implements the token-enabled allocation functions. The instrumentation generates calls to functions that -take a final ``size_t token_id`` argument. - -.. code-block:: c - - // C standard library functions - void *__alloc_token_malloc(size_t size, size_t token_id); - void *__alloc_token_calloc(size_t count, size_t size, size_t token_id); - void *__alloc_token_realloc(void *ptr, size_t size, size_t token_id); - // ... - - // C++ operators (mangled names) - // operator new(size_t, size_t) - void *__alloc_token__Znwm(size_t size, size_t token_id); - // operator new[](size_t, size_t) - void *__alloc_token__Znam(size_t size, size_t token_id); - // ... other variants like nothrow, etc., are also instrumented. - -Fast ABI --------- - -An alternative ABI can be enabled with ``-fsanitize-alloc-token-fast-abi``, +take a final `size_t token_id` argument. + +```c +// C standard library functions +void *__alloc_token_malloc(size_t size, size_t token_id); +void *__alloc_token_calloc(size_t count, size_t size, size_t token_id); +void *__alloc_token_realloc(void *ptr, size_t size, size_t token_id); +// ... + +// C++ operators (mangled names) +// operator new(size_t, size_t) +void *__alloc_token__Znwm(size_t size, size_t token_id); +// operator new[](size_t, size_t) +void *__alloc_token__Znam(size_t size, size_t token_id); +// ... other variants like nothrow, etc., are also instrumented. +``` + +### Fast ABI + +An alternative ABI can be enabled with `-fsanitize-alloc-token-fast-abi`, which encodes the token ID in the allocation function name. -.. code-block:: c - - void *__alloc_token_0_malloc(size_t size); - void *__alloc_token_1_malloc(size_t size); - void *__alloc_token_2_malloc(size_t size); - ... - void *__alloc_token_0_Znwm(size_t size); - void *__alloc_token_1_Znwm(size_t size); - void *__alloc_token_2_Znwm(size_t size); - ... +```c +void *__alloc_token_0_malloc(size_t size); +void *__alloc_token_1_malloc(size_t size); +void *__alloc_token_2_malloc(size_t size); +... +void *__alloc_token_0_Znwm(size_t size); +void *__alloc_token_1_Znwm(size_t size); +void *__alloc_token_2_Znwm(size_t size); +... +``` This ABI provides a more efficient alternative where -``-falloc-token-max`` is small. +`-falloc-token-max` is small. -Instrumenting Non-Standard Allocation Functions ------------------------------------------------ +### Instrumenting Non-Standard Allocation Functions By default, AllocToken only instruments standard library allocation functions. This simplifies adoption, as a compatible allocator only needs to provide token-enabled variants for a well-defined set of standard functions. To extend instrumentation to custom allocation functions, enable broader -coverage with ``-fsanitize-alloc-token-extended``. Such functions require being -marked with the `malloc -<https://clang.llvm.org/docs/AttributeReference.html#malloc>`_ or `alloc_size -<https://clang.llvm.org/docs/AttributeReference.html#alloc-size>`_ attributes +coverage with `-fsanitize-alloc-token-extended`. Such functions require being +marked with the [malloc][malloc-attribute] or +[alloc_size][alloc-size-attribute] attributes (or a combination). For example: -.. code-block:: c - - void *custom_malloc(size_t size) __attribute__((malloc)); - void *my_malloc(size_t size) __attribute__((alloc_size(1))); +```c +void *custom_malloc(size_t size) __attribute__((malloc)); +void *my_malloc(size_t size) __attribute__((alloc_size(1))); - // Original: - ptr1 = custom_malloc(size); - ptr2 = my_malloc(size); +// Original: +ptr1 = custom_malloc(size); +ptr2 = my_malloc(size); - // Instrumented: - ptr1 = __alloc_token_custom_malloc(size, token_id); - ptr2 = __alloc_token_my_malloc(size, token_id); +// Instrumented: +ptr1 = __alloc_token_custom_malloc(size, token_id); +ptr2 = __alloc_token_my_malloc(size, token_id); +``` -Note: Even in the default mode (without ``-fsanitize-alloc-token-extended``), -an *inline* allocation wrapper marked with the `malloc -<https://clang.llvm.org/docs/AttributeReference.html#malloc>`_ or `alloc_size -<https://clang.llvm.org/docs/AttributeReference.html#alloc-size>`_ attribute is +Note: Even in the default mode (without `-fsanitize-alloc-token-extended`), +an *inline* allocation wrapper marked with the [malloc][malloc-attribute] or +[alloc_size][alloc-size-attribute] attribute is supported if it is inlined into its caller: the inferred token is propagated to the allocation call the wrapper returns, which is then instrumented normally. Wrappers that are not inlined still require -``-fsanitize-alloc-token-extended``. +`-fsanitize-alloc-token-extended`. -Disabling Instrumentation -------------------------- +[malloc-attribute]: https://clang.llvm.org/docs/AttributeReference.html#malloc +[alloc-size-attribute]: https://clang.llvm.org/docs/AttributeReference.html#alloc-size -To exclude specific functions from instrumentation, you can use the -``no_sanitize("alloc-token")`` attribute: +### Disabling Instrumentation -.. code-block:: c +To exclude specific functions from instrumentation, you can use the +`no_sanitize("alloc-token")` attribute: - __attribute__((no_sanitize("alloc-token"))) - void* custom_allocator(size_t size) { - return malloc(size); // Uses original malloc - } +```c +__attribute__((no_sanitize("alloc-token"))) +void* custom_allocator(size_t size) { + return malloc(size); // Uses original malloc +} +``` Note: Independent of any given allocator support, the instrumentation aims to -remain performance neutral. As such, ``no_sanitize("alloc-token")`` +remain performance neutral. As such, `no_sanitize("alloc-token")` functions may be inlined into instrumented functions and vice-versa. If correctness is affected, such functions should explicitly be marked -``noinline``. +`noinline`. -The ``__attribute__((disable_sanitizer_instrumentation))`` is also supported to +The `__attribute__((disable_sanitizer_instrumentation))` is also supported to disable this and other sanitizer instrumentations. -Suppressions File (Ignorelist) ------------------------------- +### Suppressions File (Ignorelist) -AllocToken respects the ``src`` and ``fun`` entity types in the -:doc:`SanitizerSpecialCaseList`, which can be used to omit specified source +AllocToken respects the `src` and `fun` entity types in the +{doc}`SanitizerSpecialCaseList`, which can be used to omit specified source files or functions from instrumentation. -.. code-block:: bash - - [alloc-token] - # Exclude specific source files - src:third_party/allocator.c - # Exclude function name patterns - fun:*custom_malloc* - fun:LowLevel::* +```bash +[alloc-token] +# Exclude specific source files +src:third_party/allocator.c +# Exclude function name patterns +fun:*custom_malloc* +fun:LowLevel::* +``` -.. code-block:: console +```console +% clang++ -fsanitize=alloc-token -fsanitize-ignorelist=my_ignorelist.txt example.cc +``` - % clang++ -fsanitize=alloc-token -fsanitize-ignorelist=my_ignorelist.txt example.cc - -Conditional Compilation with ``__SANITIZE_ALLOC_TOKEN__`` ------------------------------------------------------------ +### Conditional Compilation with `__SANITIZE_ALLOC_TOKEN__` In some cases, one may need to execute different code depending on whether -AllocToken instrumentation is enabled. The ``__SANITIZE_ALLOC_TOKEN__`` macro +AllocToken instrumentation is enabled. The `__SANITIZE_ALLOC_TOKEN__` macro can be used for this purpose. -.. code-block:: c - - #ifdef __SANITIZE_ALLOC_TOKEN__ - // Code specific to -fsanitize=alloc-token builds - #endif +```c +#ifdef __SANITIZE_ALLOC_TOKEN__ +// Code specific to -fsanitize=alloc-token builds +#endif +``` diff --git a/clang/docs/BoundsSafety.md b/clang/docs/BoundsSafety.md index b82e68eb7555a..e9ef248a4f7c1 100644 --- a/clang/docs/BoundsSafety.md +++ b/clang/docs/BoundsSafety.md @@ -1,29 +1,27 @@ -================================================== -``-fbounds-safety``: Enforcing bounds safety for C -===============... [truncated] `````````` </details> https://github.com/llvm/llvm-project/pull/209283 _______________________________________________ llvm-branch-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
