[Mesa-dev] [PATCH] Fix strict-aliasing violations in GLSL shader list implementation

Dave Airlie airlied at gmail.com
Tue Jun 23 19:41:30 PDT 2015

>> And do things with p2 and hope that p will get them, because
>> the compiler wants to store things its doing to p in registers,
>> and when you go and do something in p2 it can't work out it's the
>> same thing, so it has to spill/reload.
> Which I think is different from what Davin was saying, but I may be
> misunderstanding the whole thing.  That's why I'd like to see spec
> language.  The part that really gets me is that this is across a
> function boundary... that's generally a sacred line, so I'm surprised
> that the compiler is allowed to disregard what it's told in that scenario.

inlining makes function boundaries nothing, and gcc will really
try and inline things.

> I'd also like to see assembly dumps with and without
> -fno-strict-aliasing of some place where this goes wrong.  If you,
> Davin, or someone else can point out a specific function that actually
> does the wrong thing, I can generate assembly myself.
> For that matter... how the heck is the ralloc (or any memory allocator)
> implementation valid?

There are rules on types that can alias, void * and char * are allowed
unions are allowed.


More information about the mesa-dev mailing list