[dpdk-dev] [PATCH v5 00/21] Fixes for GCC8 against lagopus

Andy Green andy at warmcat.com
Mon May 21 04:06:01 CEST 2018



On 05/21/2018 06:18 AM, Thomas Monjalon wrote:
>> Andy Green (21):
>>        lib/librte_ethdev: change eth-dev-ops API to return int
>>        rte_string_fns.h: fix gcc8.1 sign conv warning in lstrcpy
>>        lib/librte_eal: explicit tmp cast
>>        /lib/librte_eal: stage cast from uint64 to long
>>        rte_ring_generic.h: stack declarations before code
>>        rte_ring.h: remove signed type flipflopping
>>        rte_mbuf.h: avoid warnings from inadvertant promotion
>>        rte_mbuf.h: explicit casts for int16 to uint16
>>        rte_mbuf.h: make sure RTE-MIN compares same types
>>        rte_mbuf.h: explicit cast restricting ptrdiff to uint16
>>        rte_ether.h: explicit cast avoiding truncation warning
>>        rte_rwlock.h: gcc8 sign conversion warnings
>>        rte_ip.h: cast input to bswap16 to be uint16
>>        rte_ip.h: cast around promotion to int
>>        rte_ip.h: cast type decided by sizeof to uint32
>>        rte_ip.h: cast return checksum size to uint16
>>        rte_ip.h: cast away gcc8 warning on rte_ipv6_phdr_cksum
>>        rte_mbuf.h: explicit cast for size type to uint32
>>        rte_mbuf.h: explicit casts to uint16 to avoid warnings
>>        rte_ethdev.h: align sign and scope of temp var
>>        rte_byteorder.h: explicit cast for return promotion
> 
> 16 patches have been applied.
> The tags Fixes and Cc:stable have been added, so they can be backported.

Thanks a lot for the help.

> 5 patches are missing:
> 	lib/librte_eal: explicit tmp cast
> 	rte_rwlock.h: gcc8 sign conversion warnings
> 	rte_ip.h: cast type decided by sizeof to uint32
> 	rte_mbuf.h: explicit casts to uint16 to avoid warnings
> 	rte_ethdev.h: align sign and scope of temp var
> Those patches are either not reviewed, or not safe enough at this release stage.

Well, at least several of them are actually a NOP wrt "safety", since 
they just do the cast that pre-gcc v8 was doing silently until now.  I 
can see it's not exactly easy to know that at a glance though.

I added a rationale for what each patch is doing making it clear where 
it is effectively a NOP just making explicit what was implicit before.

> Please, feel free to send them again in a v6 to make clear they need more review.

... well, you may find them easier to parse in the v6 I just pushed.

> I think the mbuf one (for uint16_t) may deserve to be split.

Yes looking at it, it is three patches in one.  I split it out.

-Andy

> Thanks
> 
> 


More information about the dev mailing list