On Fri, Mar 22, 2019 at 3:08 PM Andrew Pinski <pins...@gmail.com> wrote: > > On Fri, Mar 22, 2019 at 7:35 AM Allan Sandfeld Jensen > <li...@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 > > > > > > > >