================
@@ -248,12 +248,26 @@ compilers, so we suggest to use it together with
 The same attribute used on a global variable prevents AddressSanitizer
 from adding redzones around it and detecting out of bounds accesses.
 
-
 AddressSanitizer also supports
 ``__attribute__((disable_sanitizer_instrumentation))``. This attribute
 works similarly to ``__attribute__((no_sanitize("address")))``, but it also
 prevents instrumentation performed by other sanitizers.
 
+Interaction of Inlining with Disabling Sanitizer Instrumentation
+-----------------------------------------------------------------
+
+* `no_sanitize` functions will not be inlined heuristically by the compiler.
+* Forcibly combining `no_sanitize` and ``__attribute__((always_inline))`` is 
not supported, and will often lead to unexpected results. To avoid mixing these 
attributes, use:
+
+.. code-block:: c
+
+    // Note, __has_feature test for sanitizers is deprecated, and Clang will 
support __SANITIZE_<sanitizer>__ similar to GCC.
+    #if __has_feature(address_sanitizer) || defined(__SANITIZE_ADDRESS__) || 
... <other sanitizers>
----------------
melver wrote:

The old compilers that don't have __has_feature also have broken no_sanitize 
AFAIK, so not sure if worth it.
__has_feature is pretty standard now, and in fact we're deprecating the 
__has_feature(*sanitizer) checks (although the doc isn't updated for that yet). 

https://github.com/llvm/llvm-project/pull/177672
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to