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 _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
