This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC turns &~ into | due to undefined bit-shift without warning
- From: Andrew Pinski <pinskia at gmail dot com>
- To: Allan Sandfeld Jensen <linux at carewolf dot com>
- Cc: GCC Mailing List <gcc at gcc dot gnu dot org>, Andrew Haley <aph at redhat dot com>, Jakub Jelinek <jakub at redhat dot com>
- Date: Fri, 22 Mar 2019 15:38:06 -0700
- Subject: Re: GCC turns &~ into | due to undefined bit-shift without warning
- References: <4af9e251-f4c3-a5a4-e33d-fb8750c87e36@redheads.de> <6941168.EvYhyI6sBW@twilight> <e2c37a42-5daa-1e6b-502e-767ffc14b332@redhat.com> <5234980.DvuYhMxLoT@twilight> <CA+=Sn1=9VDoft0K2Af-VMOQUmCtHAxGDqrSZ88WOPedyN7P8ug@mail.gmail.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
> >
> >
> >
> >