[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