Author: Balázs Benics
Date: 2026-02-20T10:58:35Z
New Revision: 2802626af62c4e1b1d0c4e1dea0e99a00779fac4

URL: 
https://github.com/llvm/llvm-project/commit/2802626af62c4e1b1d0c4e1dea0e99a00779fac4
DIFF: 
https://github.com/llvm/llvm-project/commit/2802626af62c4e1b1d0c4e1dea0e99a00779fac4.diff

LOG: [analyzer][docs] Further improve the optin.core.FixedAddressDereference 
docs (#182037)

This addresses the raised points in:

https://github.com/llvm/llvm-project/pull/181858#pullrequestreview-3820145678

Added: 
    

Modified: 
    clang/docs/analyzer/checkers.rst
    clang/include/clang/Basic/AttrDocs.td

Removed: 
    


################################################################################
diff  --git a/clang/docs/analyzer/checkers.rst 
b/clang/docs/analyzer/checkers.rst
index e51015655de65..0afb094ecf0d2 100644
--- a/clang/docs/analyzer/checkers.rst
+++ b/clang/docs/analyzer/checkers.rst
@@ -877,26 +877,31 @@ numerical value.
    int x = (*p_function)('x', 'y'); // NO warning yet at functon pointer calls
  }
 
+Access of fixed numerical addresses can be legitimate in low-level projects 
(e.g. firmware) and hardware interop.
+These values are often marked as ``volatile`` (to prevent unwanted compiler 
optimizations),
+so this checker doesn't report situations where the pointee of the fixed 
address is ``volatile``.
+If this suppression is not sufficient on a low-level project, then consider 
disabling this ``optin`` checker.
+Note that null pointers will still be reported by :ref:`core.NullDereference 
<core-NullDereference>`
+regardless if the pointee is ``volatile`` or not.
+
+.. code-block:: c
+
  void volatile_pointee() {
-   *(volatile int *)0x404 = 1; // no warning: constant non-null "volatile" 
pointee, you must know what you are doing
+   *(volatile int *)0x404 = 1; // no warning: fixed non-null "volatile" 
pointee, you must know what you are doing
  }
 
  void deref_volatile_nullptr() {
    *(volatile int *)0 = 1; // core.NullDereference still warns about this
  }
 
-If your project is low-level (e.g., firmware), or deals with hardware interop 
with a lot of genuine constant addresses, then consider disabling this checker.
-The checker automatically suppresses issues if the type of the pointee of the 
address is ``volatile``.
-You probably already need this to be ``volatile`` for legitimate access, so 
the checker suppresses such issues to avoid false-positives.
-Note that null pointers will still be reported by :ref:`core.NullDereference 
<core-NullDereference>`
-regardless if the pointee is ``volatile`` or not.
-
 If the analyzer option ``suppress-dereferences-from-any-address-space`` is set
 to true (the default value), then this checker never reports dereference of
 pointers with a specified address space. If the option is set to false, then
 reports from the specific x86 address spaces 256, 257 and 258 are still
 suppressed, but fixed address dereferences from other address spaces are
 reported.
+Do not use the :ref:`address_space <langext-address_space_documentation>`
+attribute to suppress the reports - it just happens so that the checker also 
doesn't raise issues if the attribute is present.
 
 .. _optin-cplusplus-UninitializedObject:
 

diff  --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index 43bfa15d2646f..68fdc3b976d66 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -196,6 +196,7 @@ TLS models are mutually exclusive.
 def AddressSpaceDocs : Documentation {
   let Category = DocCatType;
   let Heading = "address_space";
+  let Label = "langext-address_space_documentation";
   let Content = [{
 .. Note:: This attribute is mainly intended to be used by target headers
   provided by the toolchain. End users should prefer the documented, named


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

Reply via email to