On Thu, Apr 17, 2025 at 10:00:26AM +0300, Alexander Monakov wrote:
>
> On Thu, 17 Apr 2025, Sam James wrote:
>
> > --- a/gcc/doc/invoke.texi
> > +++ b/gcc/doc/invoke.texi
> > @@ -14649,12 +14649,14 @@ Enabled at levels @option{-O2}, @option{-O3},
> > @option{-Os}.
> > @item -fstrict-aliasing
> > 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.
> > +optimizations based on the type of expressions. In particular, accessing
> > +an object of one type via an expression of a different type is not allowed,
> > +unless the types are @dfn{compatible types}, differ in signedness or
>
> Maybe say "differ only in signedness..." (adding 'only') for clarity? No need
> to post a v3 with just that change, I cannot review/approve it (but fwiw it
> looks good to me).
The patch is ok with that change.
>
> > +qualifiers, or the expression has a character type. Accessing scalar
> > +objects via a corresponding vector type is also allowed.
> > +
> > +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.
> >
> > @anchor{Type-punning}Pay special attention to code like this:
> > @smallexample
> >
> > base-commit: 7b9d8d43154efcb56cee1787e3267183dd6a372e
Jakub
