[PATCH libdrm] xf86drm: fix aliasing violation

Emil Velikov emil.l.velikov at gmail.com
Wed Dec 14 15:46:03 UTC 2016


On 12 December 2016 at 23:28, Grazvydas Ignotas <notasas at gmail.com> wrote:
> On Mon, Dec 12, 2016 at 3:59 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>> On 11 December 2016 at 18:03, Grazvydas Ignotas <notasas at gmail.com> 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


More information about the dri-devel mailing list