All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas.monjalon@6wind.com>
To: Keith Wiles <keith.wiles@intel.com>
Cc: dev@dpdk.org, huawei.xie@intel.com, yuanhan.liu@linux.intel.com,
	adrien.mazarguil@6wind.com
Subject: Re: [PATCH] gcc compiler option -Og warnings fix
Date: Mon, 04 Apr 2016 16:10:54 +0200	[thread overview]
Message-ID: <22459074.ccNYgpjxy1@xps13> (raw)
In-Reply-To: <1459538419-81284-1-git-send-email-keith.wiles@intel.com>

2016-04-01 14:20, Keith Wiles:
> The new compiler option -Og causes a few warning on variables
> being used before being set warnings.

Sometimes the compiler is wrong. It seems this option makes it
even wronger. Why not use -Wno-error with -Og?

More details below:

>  lib/librte_eal/linuxapp/eal/eal_pci_uio.c | 2 +-
>  lib/librte_lpm/rte_lpm6.c                 | 1 +
>  lib/librte_vhost/vhost_rxtx.c             | 4 ++--

There are also some warnings in mlx drivers, solved with patch below:

--- a/drivers/net/mlx4/mlx4.c
+++ b/drivers/net/mlx4/mlx4.c
@@ -5415,7 +5415,7 @@ mlx4_pci_devinit(struct rte_pci_driver *pci_drv, struct rte_pci_device *pci_dev)
        int err = 0;
        struct ibv_context *attr_ctx = NULL;
        struct ibv_device_attr device_attr;
-       unsigned int vf;
+       unsigned int vf = 0;
        int idx;
        int i;
 
--- a/drivers/net/mlx5/mlx5.c
+++ b/drivers/net/mlx5/mlx5.c
@@ -260,8 +260,8 @@ mlx5_pci_devinit(struct rte_pci_driver *pci_drv, struct rte_pci_device *pci_dev)
        int err = 0;
        struct ibv_context *attr_ctx = NULL;
        struct ibv_device_attr device_attr;
-       unsigned int vf;
-       unsigned int mps;
+       unsigned int vf = 0;
+       unsigned int mps = 0;
        int idx;
        int i;

> --- a/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> +++ b/lib/librte_eal/linuxapp/eal/eal_pci_uio.c
> @@ -152,7 +152,7 @@ pci_get_uio_dev(struct rte_pci_device *dev, char *dstbuf,
>  			   unsigned int buflen, int create)
>  {
>  	struct rte_pci_addr *loc = &dev->addr;
> -	unsigned int uio_num;
> +	unsigned int uio_num = 0;

This one is OK to fix.

> --- a/lib/librte_lpm/rte_lpm6.c
> +++ b/lib/librte_lpm/rte_lpm6.c
> @@ -381,6 +381,7 @@ add_step(struct rte_lpm6 *lpm, struct rte_lpm6_tbl_entry *tbl,
>  	int8_t bitshift;
>  	uint8_t bits_covered;
>  
> +	*tbl_next = NULL;
>  	/*
>  	 * Calculate index to the table based on the number and position
>  	 * of the bytes being inspected in this step.

It would be more logical to set this variable in the right condition branch:
--- a/lib/librte_lpm/rte_lpm6.c
+++ b/lib/librte_lpm/rte_lpm6.c
@@ -429,6 +429,7 @@ add_step(struct rte_lpm6 *lpm, struct rte_lpm6_tbl_entry *tbl,
                        }
                }
 
+               *tbl_next = NULL;
                return 0;
        }

> --- a/lib/librte_vhost/vhost_rxtx.c
> +++ b/lib/librte_vhost/vhost_rxtx.c
> @@ -295,7 +295,7 @@ virtio_dev_rx(struct virtio_net *dev, uint16_t queue_id,
>  	for (i = 0; i < count; i++) {
>  		uint16_t desc_idx = desc_indexes[i];
>  		uint16_t used_idx = (res_start_idx + i) & (vq->size - 1);
> -		uint32_t copied;
> +		uint32_t copied = 0;

This variable is not used if copy_mbuf_to_desc fails, so it is always
initialised before being used.
We can workaround the silly compiler while avoiding a performance hit
by resetting the variable only in the error case of copy_mbuf_to_desc:

--- a/lib/librte_vhost/vhost_rxtx.c
+++ b/lib/librte_vhost/vhost_rxtx.c
@@ -147,8 +147,10 @@ copy_mbuf_to_desc(struct virtio_net *dev, struct vhost_virtqueue *vq,
        struct virtio_net_hdr_mrg_rxbuf virtio_hdr = {{0, 0, 0, 0, 0, 0}, 0};
 
        desc = &vq->desc[desc_idx];
-       if (unlikely(desc->len < vq->vhost_hlen))
+       if (unlikely(desc->len < vq->vhost_hlen)) {
+               *copied = 0;
                return -1;
+       }

>  		err = copy_mbuf_to_desc(dev, vq, pkts[i], desc_idx, &copied);
> @@ -531,7 +531,7 @@ virtio_dev_merge_rx(struct virtio_net *dev, uint16_t queue_id,
>  {
>  	struct vhost_virtqueue *vq;
>  	uint32_t pkt_idx = 0, nr_used = 0;
> -	uint16_t start, end;
> +	uint16_t start = 0, end = 0;

I don't understand this one because the variables are not used if
reserve_avail_buf_mergeable fails.
I don't see any smart workaround.
Huawei, Yuanhan, can we expect a little slowdown with this change?

  reply	other threads:[~2016-04-04 14:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-01 19:20 [PATCH] gcc compiler option -Og warnings fix Keith Wiles
2016-04-04 14:10 ` Thomas Monjalon [this message]
2016-04-04 19:56   ` Yuanhan Liu
2016-04-04 23:03   ` Wiles, Keith
2016-04-05  8:23     ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=22459074.ccNYgpjxy1@xps13 \
    --to=thomas.monjalon@6wind.com \
    --cc=adrien.mazarguil@6wind.com \
    --cc=dev@dpdk.org \
    --cc=huawei.xie@intel.com \
    --cc=keith.wiles@intel.com \
    --cc=yuanhan.liu@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.