Re: [dpdk-dev] [PATCH] test-pmd: Fix pointer aliasing error

[Dayu Qiu <qdy220091330@gmail.com>]

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@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