ChanServ changed the topic of #lima to: Development channel for open source lima driver for ARM Mali4** GPUs - Kernel driver has landed in mainline, userspace driver is part of mesa - Logs at https://oftc.irclog.whitequark.org/lima/
<anarsoul>
enunes: there's no warning from gcc nor clang regarding violating strict aliasing rule in bitcopy fn
<anarsoul>
moreover I don't think it creates any aliases, so it should be fine
drod has joined #lima
inscriptions has joined #lima
drod has quit [Remote host closed the connection]
drod has joined #lima
drod has quit [Remote host closed the connection]
tlwoerner has quit [resistance.oftc.net graviton.oftc.net]
cyrozap has quit [resistance.oftc.net graviton.oftc.net]
narmstrong has quit [resistance.oftc.net graviton.oftc.net]
cyrozap has joined #lima
tlwoerner has joined #lima
narmstrong has joined #lima
narmstrong has quit [Read error: Connection reset by peer]
narmstrong has joined #lima
<enunes>
anarsoul: yeah I tried that, the warnings dont catch it at any level
<enunes>
so far my best guess is uint16_t output being casted to uint32_t
<enunes>
and building that code with fno-strict-aliasing works
<enunes>
also changing bitcopy to be based on unsigned char fixes it, so I think thats what we can go for
<enunes>
I have a pile of patches already for clang stuff, but deqp and piglit are still not clean