mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "George Spelvin" <linux@sciencehorizons.net>
To: arnd@arndb.de, geert@linux-m68k.org,
	kernel-build-reports@lists.linaro.org
Cc: bot@kernelci.org, linux-kernel@vger.kernel.org,
	linux@sciencehorizons.net
Subject: Re: next build: 143 builds: 1 failed, 142 passed, 1 error, 22 warnings (next-20160801)
Date: 1 Aug 2016 10:57:24 -0400	[thread overview]
Message-ID: <20160801145724.14528.qmail@ns.sciencehorizons.net> (raw)
In-Reply-To: <2085340.PjMT6yBB6A@wuerfel>

Arnd Bergmann <arnd@arndb.de> wrote:
>> Warnings:
>>     lib/test_hash.c:224:7: warning: "HAVE_ARCH__HASH_32" is not defined [-Wundef]
>>     lib/test_hash.c:229:7: warning: "HAVE_ARCH_HASH_32" is not defined [-Wundef]
>>     lib/test_hash.c:234:7: warning: "HAVE_ARCH_HASH_64" is not defined [-Wundef]
>>     lib/test_hash.c:146:2: warning: missing braces around initializer [-Wmissing-braces]
>>     lib/test_hash.c:146:2: warning: (near initialization for 'hash_or[0]') [-Wmissing-braces]

> Upgrading to gcc-4.9 will fix avoid that, and a couple of workarounds have
> been discussed before, but I don't know why none of them got merged.

Geert Uytterhoeven was the first to find this problem and propose a
patch, which I acked, and thought it was going in via the m68k tree.
Helge Deller did the same a couple days later, and I told him not to
bother because Geert had taken care of it.

Here are the patches:
https://marc.info/?l=linux-kernel&m=146454366031110
https://marc.info/?l=linux-kernel&m=146454366131111

Perhaps there was some confusion about whose version was going in, or
via which tree.  Maybe I was wrong to assume Geert was putting them in
the m68k tree.

On Sun, 29 May 2016 19:28:42 +0200, Geert Uytterhoeven <geert@linux-m68k.org>
wrote:
> Some versions of gcc don't like tests for the value of an undefined
> preprocessor symbol, even in the #else branch of an #ifndef:
> 
>     lib/test_hash.c:224:7: warning: "HAVE_ARCH__HASH_32" is not defined [-Wundef]
>      #elif HAVE_ARCH__HASH_32 != 1
> 	   ^
>     lib/test_hash.c:229:7: warning: "HAVE_ARCH_HASH_32" is not defined [-Wundef]
>      #elif HAVE_ARCH_HASH_32 != 1
> 	   ^
>     lib/test_hash.c:234:7: warning: "HAVE_ARCH_HASH_64" is not defined [-Wundef]
>      #elif HAVE_ARCH_HASH_64 != 1
> 	   ^
> 
> Seen with gcc 4.9, not seen with 4.1.2.
> 
> Change the logic to only check the value inside an #ifdef to fix this.
> 
> Fixes: 468a9428521e7d00 ("<linux/hash.h>: Add support for architecture-specific functions")
> Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
> ---
>  lib/test_hash.c | 24 +++++++++++++++---------
>  1 file changed, 15 insertions(+), 9 deletions(-)
> 
> diff --git a/lib/test_hash.c b/lib/test_hash.c
> index fd7a677100ebe935..a06ac379ad429c6b 100644
> --- a/lib/test_hash.c
> +++ b/lib/test_hash.c
> @@ -219,21 +219,27 @@ test_hash_init(void)
>  	}
>  
>  	/* Issue notices about skipped tests. */
> -#ifndef HAVE_ARCH__HASH_32
> -	pr_info("__hash_32() has no arch implementation to test.");
> -#elif HAVE_ARCH__HASH_32 != 1
> +#ifdef HAVE_ARCH__HASH_32
> +#if HAVE_ARCH__HASH_32 != 1
>  	pr_info("__hash_32() is arch-specific; not compared to generic.");
>  #endif
> -#ifndef HAVE_ARCH_HASH_32
> -	pr_info("hash_32() has no arch implementation to test.");
> -#elif HAVE_ARCH_HASH_32 != 1
> +#else
> +	pr_info("__hash_32() has no arch implementation to test.");
> +#endif
> +#ifdef HAVE_ARCH_HASH_32
> +#if HAVE_ARCH_HASH_32 != 1
>  	pr_info("hash_32() is arch-specific; not compared to generic.");
>  #endif
> -#ifndef HAVE_ARCH_HASH_64
> -	pr_info("hash_64() has no arch implementation to test.");
> -#elif HAVE_ARCH_HASH_64 != 1
> +#else
> +	pr_info("hash_32() has no arch implementation to test.");
> +#endif
> +#ifdef HAVE_ARCH_HASH_64
> +#if HAVE_ARCH_HASH_64 != 1
>  	pr_info("hash_64() is arch-specific; not compared to generic.");
>  #endif
> +#else
> +	pr_info("hash_64() has no arch implementation to test.");
> +#endif
>  
>  	pr_notice("%u tests passed.", tests);
>  
> -- 
> 1.9.1
> 

  parent reply	other threads:[~2016-08-01 14:58 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <579ee2e6.68adc20a.8208b.b5be@mx.google.com>
2016-08-01 13:17 ` Arnd Bergmann
2016-08-01 13:36   ` Mark Brown
2016-08-01 14:57   ` George Spelvin [this message]
2016-08-04 13:36     ` Geert Uytterhoeven
2016-08-04 14:49       ` George Spelvin
2016-08-04 14:58         ` Geert Uytterhoeven
2016-08-02 18:55   ` Kevin Hilman

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=20160801145724.14528.qmail@ns.sciencehorizons.net \
    --to=linux@sciencehorizons.net \
    --cc=arnd@arndb.de \
    --cc=bot@kernelci.org \
    --cc=geert@linux-m68k.org \
    --cc=kernel-build-reports@lists.linaro.org \
    --cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®