On Wed, 26 Mar 2025, Sam James wrote:
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -14552,10 +14552,10 @@ Allow the compiler to assume the strictest aliasing
> rules applicable to
> the language being compiled. For C (and C++), this activates
> optimizations based on the type of expressions. In particular, an
> object of one type is assumed never to reside at the same address as an
> -object of a different type, unless the types are almost the same. For
> -example, an @code{unsigned int} can alias an @code{int}, but not a
> -@code{void*} or a @code{double}. A character type may alias any other
> -type.
> +object of a different type, unless the types are almost the same
> +(``compatible types''). For example, an @code{unsigned int} can alias an
> +@code{int}, but not a @code{void*} or a @code{double}. A character type may
> +alias any other type.
Obviously I support the general idea of referencing standard terms, but:
1) the statement being edited is factually incorrect; objects of different types
can reside "at the same address" just fine (at different points of time), what's
forbidden is accessing an object via an lvalue expression (usually a
dereference)
of a different type, with exceptions (using another compatible type, adding
qualifiers, changing signedness, using a character type is allowed).
2) the definition of "compatible types" in C is narrower than what is allowed
for accessing an object; in particular, 'int' and 'unsigned' are not compatible.
Can we rephrase the entire statement instead? Like, e.g.
In particular, accessing an object of one type via an expression of a different
type is not allowed, unless the types are compatible, differ in signedness or
qualifiers, or the expression has a character type. Accessing scalar objects via
a corresponding vector type is also allowed.
Alexander
