All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: kernel-build-reports@lists.linaro.org,
	Build bot for Mark Brown <broonie@kernel.org>,
	linaro-kernel@lists.linaro.org, stable@vger.kernel.org,
	akpm@linux-foundation.org, linux-kernel@vger.kernel.org
Subject: Re: v4.4.14 build: 0 failures 1 warnings (v4.4.14)
Date: Sat, 25 Jun 2016 11:23:05 +0200	[thread overview]
Message-ID: <3979206.RoHYNJ6ueF@wuerfel> (raw)
In-Reply-To: <E1bGaez-000554-AS@optimist>

On Saturday, June 25, 2016 12:37:17 AM CEST Build bot for Mark Brown wrote:
> Warnings Summary: 1
> arm64-allmodconfig : PASS, 0 errors, 1 warnings, 0 section mismatches
>           1 ../drivers/xen/balloon.c:155:13: warning:
>             'release_memory_resource' declared 'static' but never defined
> -------------------------------------------------------------------------------
> Passed with no errors, warnings or mismatches:
> 
> arm64-allnoconfig
> arm-multi_v5_defconfig
> arm-multi_v7_defconfig
> x86_64-defconfig
> arm-allmodconfig
> arm-allnoconfig
> x86_64-allnoconfig
> arm64-defconfig

Hi Greg,

It seems we're down to a single warning on ARM and ARM64 now, and
the fix just got merged as commit

842775f15090 ("xen/balloon: Fix declared-but-not-defined warning")

so we can for the first time have a stable kernel that builds
without warnings on these architectures, nice!

On 4.7-rc, there are currently two warnings:
> fs/reiserfs/ibalance.c:1156:2: warning: 'new_insert_key' may be
>         used uninitialized in this function [-Wmaybe-uninitialized]
> drivers/staging/iio/adc/ad7606_spi.c:24:18: warning: 'data' may be
>         used uninitialized in this function [-Wmaybe-uninitialized]

The first one is an old issue that gcc recently started warning for,
a workaround (reiserfs: fix "new_insert_key may be used uninitialized
...") is currently in Andrew's akpm-current, but I think it's not
planned for 4.7 since it's not a regression and the code works
correctly.

The second one is a real bug, and the fix is now in the staging-linus
tree.

	Arnd

  reply	other threads:[~2016-06-25  9:20 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-24 23:37 v4.4.14 build: 0 failures 1 warnings (v4.4.14) Build bot for Mark Brown
2016-06-25  9:23 ` Arnd Bergmann [this message]
2016-07-24 23:59   ` Greg KH

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=3979206.RoHYNJ6ueF@wuerfel \
    --to=arnd@arndb.de \
    --cc=akpm@linux-foundation.org \
    --cc=broonie@kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=kernel-build-reports@lists.linaro.org \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stable@vger.kernel.org \
    /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.