Skip to content

Commit dbe6e52

Browse files
committed
!fixup reword as suggested, thanks!
1 parent 0479563 commit dbe6e52

File tree

1 file changed

+71
-20
lines changed

1 file changed

+71
-20
lines changed

clang/docs/UsersManual.rst

Lines changed: 71 additions & 20 deletions
Original file line numberDiff line numberDiff line change
@@ -2492,26 +2492,77 @@ are listed below.
24922492
Strict Aliasing
24932493
---------------
24942494

2495-
Clang by default applies C/C++'s strict aliasing rules during optimizations. In
2496-
cases C and C++ rules diverge, the more conservative rules are used. Clang does
2497-
not make use of strict aliasing rules in all cases yet, including unions and
2498-
variable-sized arrays. That may change in the future.
2499-
2500-
Internally Clang encodes the strict aliasing rules in LLVM IR using type-based
2501-
alias analysis (TBAA) metadata.
2502-
2503-
Note that clang-cl disables strict aliasing by default, see
2504-
:ref:`Strict aliasing in clang-cl. <clang_cl_strict_aliasing>`
2505-
2506-
As of Clang 20, strict aliasing rules are also applied to nested pointers. The
2507-
new behavior can be disabled using ``-fno-pointer-tbaa``. Note that Clang does
2508-
not apply strict aliasing rules to `void*` pointers to avoid breaking existing
2509-
code, even though this is not required by the standard.
2510-
2511-
Strict aliasing violations in the source may change program behavior and
2512-
``-fno-strict-aliasing`` disables use of the strict aliasing rules. There also
2513-
is an experimental :ref:`TypeSanitizer <TypeSanitizer>` to detect strict
2514-
aliasing violations.
2495+
The C and C++ standards require accesses to objects in memory to use l-values of
2496+
an appropriate type for the object. This is called *strict aliasing* or
2497+
*type-based alias analysis*. Strict aliasing enhances a variety of powerful
2498+
memory optimizations, including reordering, combining, and eliminating memory
2499+
accesses. These optimizations can lead to unexpected behavior in code that
2500+
violates the strict aliasing rules. For example:
2501+
2502+
.. code-block:: c++
2503+
2504+
void advance(size_t *index, double *data) {
2505+
double value = data[*index];
2506+
/* Clang may assume that this store does not change the contents of `data`. */
2507+
*index += 1;
2508+
/* Clang may assume that this store does not change the contents of `index`. */
2509+
data[*index] = value;
2510+
/* Either of these facts may create significant optimization opportunities
2511+
if Clang is able to inline this function. */
2512+
}
2513+
2514+
Strict aliasing can be explicitly enabled with ``-fstrict-aliasing`` and
2515+
disabled with ``-fno-strict-aliasing``. ``clang-cl`` defaults to
2516+
``-fno-strict-aliasing``; see :ref:`Strict aliasing in clang-cl.
2517+
<clang_cl_strict_aliasing>`. Otherwise, Clang defaults to ``-fstrict-aliasing``.
2518+
2519+
C and C++ specify slightly different rules for strict aliasing. To improve
2520+
language interoperability, Clang allows two types to alias if either language
2521+
would permit it. This includes applying the C++ similar types rule to C,
2522+
allowing ``int **`` to alias ``int const * const *``. Clang also relaxes the
2523+
standard aliasing rules in the following ways:
2524+
2525+
* All integer types of the same size are permitted to alias each other,
2526+
including signed and unsigned types.
2527+
* ``void*`` is permitted to alias any pointer type, ``void**`` is permitted to
2528+
alias any pointer to pointer type, and so on.
2529+
2530+
Code which violates strict aliasing has undefined behavior. A program that
2531+
works in one version of Clang may not work in another because of changes to the
2532+
optimizer. Clang provides a `:ref:TypeSanitizer <TypeSanitizer>` to help detect
2533+
violations of the strict aliasing rules, but it is currently still experimental.
2534+
Code that is known to violate strict aliasing should generally be built with
2535+
``-fno-strict-aliasing`` if the violation cannot be fixed.
2536+
2537+
Clang supports several ways to fix a violation of strict aliasing:
2538+
2539+
* L-values of the character types ``char`` and ``unsigned char`` (as well as
2540+
other types, depending on the standard) are permitted to access objects of
2541+
any type.
2542+
2543+
* Library functions such as ``memcpy`` and ``memset`` are specified as treating
2544+
memory as characters and therefore are not limited by strict aliasing. If a
2545+
value of one type must be reinterpreted as another (e.g. to read the bits of a
2546+
floating-point number), use ``memcpy`` to copy the representation to an object
2547+
of the destination type. This has no overhead over a direct l-value access
2548+
because Clang should reliably optimize calls to these functions to use simple
2549+
loads and stores when they are used with small constant sizes.
2550+
2551+
* The attribute ``may_alias`` can be added to a ``typedef`` to give l-values of
2552+
that type the same aliasing power as the character types.
2553+
2554+
Clang makes a best effort to avoid obvious miscompilations from strict aliasing
2555+
by only considering type information when it cannot prove that two accesses must
2556+
refer to the same memory. However, it is not recommended that programmers
2557+
intentionally rely on this instead of using one of the solutions above because
2558+
it is too easy for the compiler's analysis to be blocked in surprising ways.
2559+
2560+
In Clang 20, Clang strengthened its implementation of strict aliasing for
2561+
accesses of pointer type. Previously, all accesses of pointer type were
2562+
permitted to alias each other, but Clang now distinguishes different pointers
2563+
by their pointee type, except as limited by the relaxations around qualifiers
2564+
and `void*` described above. The previous behavior of treating all pointers as
2565+
aliasing can be restored using ``-fno-pointer-tbaa``.
25152566

25162567
Profile Guided Optimization
25172568
---------------------------

0 commit comments

Comments
 (0)