On 12 December 2016 at 23:28, Grazvydas Ignotas <notasas@xxxxxxxxx> wrote: > On Mon, Dec 12, 2016 at 3:59 PM, Emil Velikov <emil.l.velikov@xxxxxxxxx> wrote: >> On 11 December 2016 at 18:03, Grazvydas Ignotas <notasas@xxxxxxxxx> wrote: >>> Just tell the compiler that drm_event will alias the char buffer, >>> so that it has no excuse to warn or generate bad code. >>> >> Afacit this patch [1] from Thierry should correctly address the issue, correct ? > > From what I've read, gcc's "strict aliasing" means that it's illegal > to access the same memory location using pointers of different types, > with only one exception - accessing an object of any type through a > char pointer. What is done here is the opposite - char array is read > as a struct, so according to that it's still wrong. > > That said I haven't seen any compiler causing problems in this case, > and Thierry's solution indeed silences the warning, so I guess you can > take his patch if you prefer. > I've seen a lot of noise on the topic of strict aliasing yet never had the time to investigate [too much]. There's some argument(s) that with type based (strict) aliasing the GCC [used to at least] make incorrect assumptions reordering code (stores). Latter of which causing issues when combined with optimisations. That aside: afaict the warning there is triggered since we have "& some_char" on rhs, rather than "some_char_or_void_star". With the latter of which explicitly allowed on the topic. The strange this is that fleshing a [identical] small example triggers no warning, regardless of the level (1,2,3) $ gcc -Wall -Wextra -Wstrict-aliasing=3 ss.c Barring any objections I'm leaning towards Thierry's patch. Thierry did you see any side-effect with [1] or you simply did not have time to double-check/investigate if the problem is truly fixed. Just double-checking. Thanks ! Emil [1] https://cgit.freedesktop.org/~tagr/drm/commit/?h=staging/fixes&id=4ebf7b59e69e43cc3810141dff8e3ef3535f03b2 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel