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

[Andrew Pinski <pinskia at gmail dot com>]

On Fri, Mar 22, 2019 at 3:08 PM Andrew Pinski <pinskia@gmail.com> wrote:
>
> 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.

It also referenced in the implementation defined section of the manual:
https://gcc.gnu.org/onlinedocs/gcc/Structures-unions-enumerations-and-bit-fields-implementation.html#Structures-unions-enumerations-and-bit-fields-implementation
Oh and it is implementation defined in C90 (but undefined in C99 and
C++) :).  So it is more complex than what you pointed out.

Thanks,
Andrew


> 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
> >
> >
> >
> >