Hi Olivier, You can check gcc manual.
-fstrict-aliasing Allow the compiler to assume the strictest aliasing rules applicable to the language being compiled. For C (and C++), this activates optimizations based on the type of expressions. In particular, an object of one type is assumed never to reside at the same address as an object of a different type, unless the types are almost the same. For example, an "unsigned int" can alias an "int", but not a "void*" or a "double". A character type may alias any other type. So it should not be a bug, but I have no idea about why other version does not reproduce. Thanks, Michael On Wed, Dec 3, 2014 at 11:24 PM, Olivier MATZ <olivier.matz at 6wind.com> wrote: > Hi Bruce, > > On 12/03/2014 12:42 PM, Bruce Richardson wrote: > >> On Wed, Dec 03, 2014 at 07:28:19PM +0800, Michael Qiu wrote: >> >>> app/test-pmd/csumonly.c: In function ?get_psd_sum?: >>> build/include/rte_ip.h:161: error: dereferencing pointer ?u16? >>> does break strict-aliasing rules >>> build/include/rte_ip.h:157: note: initialized from here >>> ... >>> >>> The root cause is that, compile enable strict aliasing by default, >>> while in function rte_raw_cksum() try to convert 'const char *' >>> to 'const uint16_t *'. >>> >>> >> What compiler version is this with? Is there any other way to fix this >> other than disabling the compiler warnings. Turning off strict aliasing >> may >> affect performance as it reduces the number of optimizations that the >> compiler >> can perform. >> > > I can reproduce the issue with a gcc-4.4.6 toolchain. But I think it's > a toolchain bug as the warning does not occur with other versions I've > tested. > > If it's the case, we could either: > > - do nothing: in this case the user need to upgrade its toolchain, or > pass the -Wno-strict-aliasing manually in EXTRA_CFLAGS > > - add the -Wno-strict-aliasing only for gcc 4.4 in the Makefile > > What do you think? > > Regards, > Olivier > > -- Thanks & Best Regards Mike