I see this warning:
gimpcpuaccel.c: In function ‘arch_get_vendor’:
gimpcpuaccel.c:182: warning: dereferencing type-punned pointer will
break strict-aliasing rules
Which is gcc's way of telling you that when optimization is turned on
gcc will feel free to generate code that ignores any changes you made
via the type punned pointers. Although it's doing what you expect right
now, you're just getting away with it--gcc on any release may break this
code.
If you want more details you could look at the section I wrote about
this gcc warning in:
https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines
for more information. Under the latest C++ standard rules, gcc is free
to assume that in spite of the assignments:
*(int *)&id[0] = ebx;
*(int *)&id[4] = edx;
*(int *)&id[8] = ecx;
id[12] = '\0';
that only the 13th byte is initialized and if it's convenient to the
optimizer, throw away the results of the assignments to the type-punned
pointer indirections and directly use the original values of those
bytes. This would most likely result in the routine always returning:
return ARCH_X86_VENDOR_UNKNOWN;
which wouldn't be a disaster I imagine, but would interfere with your
ability to do your own optimizations knowing the CPU architecture. To
fix it, you could use the argument -fno-strict-aliasing to tell the
optimizer never to do this sort of optimization, but then you might have
worse code. The fix would be to make a union:
union {
gchar idaschars[16];
int idasints[4];
} id;
and access the appropriate sections.
id.idasints[0] = ebx;
id.idasints[1] = edx;
id.idasints[2] = ecx;
id.idaschars[12] = '\0';
then do the comparisons against id.idaschars.
I know this seems quite annoying and it seems that gcc should be able to
see that the assignments are into the array storage area, but really,
gcc is doing the right thing according to the standard which made the
requirement at the request of some of the compiler companies to make a
class of optimization possible.
Patrick
