Keith,
I think there might be some slight issue with some of the changes in the
drivers I did. In particular, I was under the impression it would be ok
to do something like
union a_union {
int i;
double d;
};
int f() {
double d = 3.0;
return ((union a_union *) &d)->i;
};
but in fact gcc manpage tells me it's not (the example is from gcc 4.4
manpage) - this site told me this is ok, "casting through a union (2)"
http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html,
I guess it was considered ok in 2006 but not now (though I'm not sure
why not)... I did that in some places because otherwise there's no way
around assigning the value to the union and pass that around instead.
Curiously though, despite the gcc manpage saying the code "might" not be
ok, gcc doesn't warn about it in the places I used it.
Anyway, I'm not sure it's worth bothering with this now, as drivers
could be fixed up without any interface changes.
Roland
unsigned i =
On 08.12.2009 17:19, Keith Whitwell wrote:
> Roland,
>
> This looks OK to me, hopefully this will see us getting on top of strict
> aliasing issues after all these years...
>
> Keith
>
> On Mon, 2009-12-07 at 18:14 -0800, Roland Scheidegger wrote:
>> Hello,
>>
>> I'm planning to merge gallium-strict-aliasing branch soon, which will
>> bring another gallium api change.
>> pipe_reference function has different arguments, because the old version
>> was pretty much not really useful for strict-aliasing compliant code
>> (util_color_pack functions also gets an update for the same reason).
>> The goal of course it to enable builds which do no longer need
>> -fno-strict-aliasing. scons builds already didn't do this (which was a
>> bug since the builds were indeed broken).
>> I didn't check all drivers for strict-aliasing compliance, but for
>> gallium everybody should make sure the code they are submitting is
>> according to strict aliasing rules (*). One downside of compiling with
>> -fno-strict-aliasing is also that you don't get the warnings wrt strict
>> aliasing, so you might have missed that in the past.
>> (There are no build system changes yet, there's still some strict
>> aliasing violating code in shader/grammar which should get replaced soon
>> anyway.)
>>
>> (*) Strictly speaking, it looks like c99 actually has undefined
>> behaviour writing and reading different members of a union (wtf?), but
>> this is considered acceptable here, and all compilers should support it.
>>
>> Roland
>>
>> ------------------------------------------------------------------------------
>> Return on Information:
>> Google Enterprise Search pays you back
>> Get the facts.
>> http://p.sf.net/sfu/google-dev2dev
>> _______________________________________________
>> Mesa3d-dev mailing list
>> Mesa3d-dev@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
>
------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
