All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>
To: Arnd Bergmann <arnd@arndb.de>, Michal Marek <mmarek@suse.com>
Cc: linux-arm-kernel@lists.infradead.org,
	linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 5/5] gcov: disable -Wmaybe-uninitialized warning
Date: Mon, 15 Feb 2016 15:35:21 +0100	[thread overview]
Message-ID: <56C1E229.4050308@linux.vnet.ibm.com> (raw)
In-Reply-To: <1455293187-179811-6-git-send-email-arnd@arndb.de>

On 12.02.2016 17:06, Arnd Bergmann wrote:
> When gcov profiling is enabled, we see a lot of spurious warnings about
> possibly uninitialized variables being used:
> 
> arch/arm/mm/dma-mapping.c: In function 'arm_coherent_iommu_map_page':
> arch/arm/mm/dma-mapping.c:1085:16: warning: 'start' may be used uninitialized in this function [-Wmaybe-uninitialized]
> drivers/clk/st/clk-flexgen.c: In function 'st_of_flexgen_setup':
> drivers/clk/st/clk-flexgen.c:323:9: warning: 'num_parents' may be used uninitialized in this function [-Wmaybe-uninitialized]
> kernel/cgroup.c: In function 'cgroup_mount':
> kernel/cgroup.c:2119:11: warning: 'root' may be used uninitialized in this function [-Wmaybe-uninitialized]
> 
> All of these are false positives, so it seems better to just disable
> the warnings whenever GCOV is enabled. Most users don't enable GCOV,
> and based on a prior patch, it is now also disabled for 'allmodconfig'
> builds, so there should be no downsides of doing this.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Sounds sane.

Acked-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>

> ---
>  Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Makefile b/Makefile
> index 6bb89728a9d1..7b6900931a47 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -364,7 +364,7 @@ AFLAGS_MODULE   =
>  LDFLAGS_MODULE  =
>  CFLAGS_KERNEL	=
>  AFLAGS_KERNEL	=
> -CFLAGS_GCOV	= -fprofile-arcs -ftest-coverage -fno-tree-loop-im
> +CFLAGS_GCOV	= -fprofile-arcs -ftest-coverage -fno-tree-loop-im -Wno-maybe-uninitialized
>  CFLAGS_KCOV	= -fsanitize-coverage=trace-pc
> 
> 


-- 
Peter Oberparleiter
Linux on z Systems Development - IBM Germany


WARNING: multiple messages have this Message-ID (diff)
From: oberpar@linux.vnet.ibm.com (Peter Oberparleiter)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 5/5] gcov: disable -Wmaybe-uninitialized warning
Date: Mon, 15 Feb 2016 15:35:21 +0100	[thread overview]
Message-ID: <56C1E229.4050308@linux.vnet.ibm.com> (raw)
In-Reply-To: <1455293187-179811-6-git-send-email-arnd@arndb.de>

On 12.02.2016 17:06, Arnd Bergmann wrote:
> When gcov profiling is enabled, we see a lot of spurious warnings about
> possibly uninitialized variables being used:
> 
> arch/arm/mm/dma-mapping.c: In function 'arm_coherent_iommu_map_page':
> arch/arm/mm/dma-mapping.c:1085:16: warning: 'start' may be used uninitialized in this function [-Wmaybe-uninitialized]
> drivers/clk/st/clk-flexgen.c: In function 'st_of_flexgen_setup':
> drivers/clk/st/clk-flexgen.c:323:9: warning: 'num_parents' may be used uninitialized in this function [-Wmaybe-uninitialized]
> kernel/cgroup.c: In function 'cgroup_mount':
> kernel/cgroup.c:2119:11: warning: 'root' may be used uninitialized in this function [-Wmaybe-uninitialized]
> 
> All of these are false positives, so it seems better to just disable
> the warnings whenever GCOV is enabled. Most users don't enable GCOV,
> and based on a prior patch, it is now also disabled for 'allmodconfig'
> builds, so there should be no downsides of doing this.
> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Sounds sane.

Acked-by: Peter Oberparleiter <oberpar@linux.vnet.ibm.com>

> ---
>  Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Makefile b/Makefile
> index 6bb89728a9d1..7b6900931a47 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -364,7 +364,7 @@ AFLAGS_MODULE   =
>  LDFLAGS_MODULE  =
>  CFLAGS_KERNEL	=
>  AFLAGS_KERNEL	=
> -CFLAGS_GCOV	= -fprofile-arcs -ftest-coverage -fno-tree-loop-im
> +CFLAGS_GCOV	= -fprofile-arcs -ftest-coverage -fno-tree-loop-im -Wno-maybe-uninitialized
>  CFLAGS_KCOV	= -fsanitize-coverage=trace-pc
> 
> 


-- 
Peter Oberparleiter
Linux on z Systems Development - IBM Germany

  reply	other threads:[~2016-02-15 14:35 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-12 16:06 [PATCH 0/5] gcov fixes and maybe-uninitialized warnings Arnd Bergmann
2016-02-12 16:06 ` Arnd Bergmann
2016-02-12 16:06 ` [PATCH 1/5] Kbuild: change CC_OPTIMIZE_FOR_SIZE definition Arnd Bergmann
2016-02-12 16:06   ` Arnd Bergmann
2016-02-12 16:06 ` [PATCH 2/5] Kbuild: disable 'maybe-uninitialized' warning for CONFIG_PROFILE_ALL_BRANCHES Arnd Bergmann
2016-02-12 16:06   ` Arnd Bergmann
2016-02-15 17:46   ` Steven Rostedt
2016-02-15 17:46     ` Steven Rostedt
2016-02-12 16:06 ` [PATCH 3/5] gcov: disable for COMPILE_TEST Arnd Bergmann
2016-02-12 16:06   ` Arnd Bergmann
2016-02-15 14:23   ` Peter Oberparleiter
2016-02-15 14:23     ` Peter Oberparleiter
2016-02-12 16:06 ` [PATCH 4/5] gcov: disable tree-loop-im to reduce stack usage Arnd Bergmann
2016-02-12 16:06   ` Arnd Bergmann
2016-02-15 14:34   ` Peter Oberparleiter
2016-02-15 14:34     ` Peter Oberparleiter
2016-02-12 16:06 ` [PATCH 5/5] gcov: disable -Wmaybe-uninitialized warning Arnd Bergmann
2016-02-12 16:06   ` Arnd Bergmann
2016-02-15 14:35   ` Peter Oberparleiter [this message]
2016-02-15 14:35     ` Peter Oberparleiter
  -- strict thread matches above, loose matches on Subject: below --
2016-04-25 15:35 [RESEND PATCH 0/5] gcov fixes and maybe-uninitialized warnings Arnd Bergmann
2016-04-25 15:35 ` [PATCH 5/5] gcov: disable -Wmaybe-uninitialized warning Arnd Bergmann
2016-04-25 15:35   ` Arnd Bergmann

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=56C1E229.4050308@linux.vnet.ibm.com \
    --to=oberpar@linux.vnet.ibm.com \
    --cc=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mmarek@suse.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.