Re: GCC turns &~ into | due to undefined bit-shift without warning

[Andrew Pinski <pinskia at gmail dot com>]

On Fri, Mar 22, 2019 at 7:35 AM Allan Sandfeld Jensen
<linux@carewolf.com> wrote:
>
> On Freitag, 22. März 2019 14:38:10 CET Andrew Haley wrote:
> > On 3/22/19 10:20 AM, Allan Sandfeld Jensen wrote:
> > > On Freitag, 22. März 2019 11:02:39 CET Andrew Haley wrote:
> > >> On 3/21/19 10:19 PM, Allan Sandfeld Jensen wrote:
> > >>> From having fixed UBSAN warnings, I have seen many cases where undefined
> > >>> behavior was performed, but where the code was aware of it and the final
> > >>> result of the expression was well defined nonetheless.
> > >>
> > >> Is this belief about undefined behaviour commonplace among C programmers?
> > >> There's nothing in the standard to justify it: any expression which
> > >> contains UB is undefined.
> > >
> > > Yes, even GCC uses undefined behavior when it is considered defined for
> > > specific architecture,
> >
> > If it's defined for a specific architecture it's not undefined. Any compiler
> > is entitled to do anything with UB, and "anything" includes extending the
> > language to make it well defined.
>
> True, but in the context of "things UBSAN warns about", that includes
> architecture specific details.
>
> And isn't unaligned access real undefined behavior that just happens to work
> on x86 (and newer ARM)?
>
> There are also stuff like type-punning unions which is not architecture
> specific, technically undefined, but which GCC explicitly tolerates (and needs
> to since some NEON intrinsics use it).

For type-punning unions, GCC goes out of its way and documents that is
defined.  This documented at:
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-fstrict-aliasing
"The practice of reading from a different union member than the one
most recently written to (called “type-punning”) is common. Even with
-fstrict-aliasing, type-punning is allowed, provided the memory is
accessed through the union type."
Maybe it should be more explicit saying even though the C/C++
Langauges make it undefined, GCC makes it defined.
As for unaligned accesses, they don't always work even on x86 because
GCC does assume (in some cases; since 4.0 at least) the alignment that
is required for that type.  For an example the auto-vectorizer does
use that fact about the alignment and types.  There has been some bug
reports about those cases too.   Even on x86, there are some
instructions (mostly SSE) which take only aligned memory locations (in
some micro-architecture, the aligned load/store instructions give
better performance than the unaligned ones) and will cause a fault.

Thanks,
Andrew Pinski

>
> 'Allan
>
>
>
>