Skip to contentSkip to conversation

next build: 143 builds: 1 failed, 142 passed, 1 error, 22 warnings (next-20160801)

DISCUSSION Arnd Bergmann 5 participants 7 messages Aug 1, 2016 – Aug 4, 2016 1 message not in the archive Library code

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

#1 lore raw
Quoted 11 lines · CEST kernelci. org bot

next build: 143 builds: 1 failed, 142 passed, 1 error, 22 warnings (next-20160801)

Full Build Summary: https://kernelci.org/build/next/kernel/next-20160801/

Tree: next
Branch: local/master
Git Describe: next-20160801
Git Commit: c24c1308a5b274bbd90db927cb18efddc95340c7
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
Built: 3 unique architectures

Quoted 5 lines

Build Failure Detected:

arm: gcc version 5.3.1 20160113 (Linaro GCC 5.3-2016.02)

rpc_defconfig: FAIL

I have verified that Linaro GCC 5.3-2016.05 is fixed, only Linaro GCC 5.3-2016.02 and earlier have this problem, please upgrade if possible

Quoted 5 lines

Errors and Warnings Detected:

arm64: gcc version 5.2.1 20151005 (Linaro GCC 5.2-2015.11-2)

tinyconfig: 2 warnings

I now have a patch for it, just need to figure out who will merge it.

Quoted 3 lines

Warnings:

    drivers/tty/serial/8250/8250_fintek.c:34:0: warning: "IRQ_MODE" redefined

As commented in another thread, my patch is waiting to be picked up by Greg, and has been in that state for a while.

Quoted 6 lines

--------------------------------------------------------------------------------
allmodconfig (arm64) — PASS, 0 errors, 0 warnings, 0 section mismatches

--------------------------------------------------------------------------------
allmodconfig (x86) — PASS, 0 errors, 5 warnings, 0 section mismatches

Quoted 6 lines

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.

George, how about this version:

commit 9b3cb7d0777a81522b799b0362ea0864ab7de6e0

Author: Arnd Bergmann <[email protected]>
Date:   Tue May 31 10:27:08 2016 +0200

hash: fix gcc-4 build warnings in test_hash.c

The newly added lib/test_hash.c file builds fine with gcc-5 or newer, but causes some annoying warnings witih gcc-4.9 and older:

lib/test_hash.c: In function ‘test_hash_init’:
lib/test_hash.c:146:2: error: missing braces around initializer [-Werror=missing-braces] lib/test_hash.c:146:2: error: (near initialization for ‘hash_or[0]’) [-Werror=missing-braces] lib/test_hash.c:224:7: error: "HAVE_ARCH__HASH_32" is not defined [-Werror=undef] lib/test_hash.c:229:7: error: "HAVE_ARCH_HASH_32" is not defined [-Werror=undef] lib/test_hash.c:234:7: error: "HAVE_ARCH_HASH_64" is not defined [-Werror=undef]

This adds the braces and extra #ifdef checks for the macros to shut up those warnings.

lib/test_hash.c +4 -4
index 66c5fc8351e8..91a1dfa788d7 100644
@@ -143,7 +143,7 @@ static int __init
 test_hash_init(void)
 {
 	char buf[SIZE+1];
-	u32 string_or = 0, hash_or[2][33] = { 0 };
+	u32 string_or = 0, hash_or[2][33] = { { 0 } };
 	unsigned tests = 0;
 	unsigned long long h64 = 0;
 	int i, j;
@@ -221,17 +221,17 @@ 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
+#elif defined(HAVE_ARCH__HASH_32) && 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
+#elif defined(HAVE_ARCH_HASH_32) && 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
+#elif defined(HAVE_ARCH_HASH_64) && HAVE_ARCH_HASH_64 != 1
 	pr_info("hash_64() is arch-specific; not compared to generic.");
 #endif
 
Quoted 11 lines

--------------------------------------------------------------------------------
aspeed_g4_defconfig (arm) — PASS, 0 errors, 1 warning, 0 section mismatches

Warnings:
arch/arm/configs/aspeed_g4_defconfig:61:warning: symbol value '1' invalid for PRINTK_TIME

--------------------------------------------------------------------------------
aspeed_g5_defconfig (arm) — PASS, 0 errors, 1 warning, 0 section mismatches

Warnings:
arch/arm/configs/aspeed_g5_defconfig:62:warning: symbol value '1' invalid for PRINTK_TIME

This was caused by a commit I did to prepare for a patch turning the 'bool' symbol into an integer symbol. That patch is no longer in -next and we should revert my patch.

Arnd

#2 lore raw
Quoted 8 lines · Arnd Bergmann
Quoted 3 lines · CEST kernelci. org bot

arm: gcc version 5.3.1 20160113 (Linaro GCC 5.3-2016.02)

rpc_defconfig: FAIL

I have verified that Linaro GCC 5.3-2016.05 is fixed, only Linaro GCC 5.3-2016.02 and earlier have this problem, please upgrade if possible

Adding Kevin in directly.

#3 lore raw
In reply to Arnd Bergmann
Quoted 9 lines · Arnd Bergmann
Quoted 6 lines

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.

Quoted 67 lines · Geert Uytterhoeven

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")
---
 lib/test_hash.c | 24 +++++++++++++++---------
 1 file changed, 15 insertions(+), 9 deletions(-)
lib/test_hash.c +15 -9
index fd7a677100ebe935..a06ac379ad429c6b 100644
@@ -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);
 
Signature · 1 line
1.9.1
#4 lore raw

Hi George,

Quoted 16 lines · George Spelvin
Quoted 9 lines · Arnd Bergmann
Quoted 6 lines

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.

Quoted 7 lines

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.

As these patches were meant for generic non-m68k code, I didn't plan to take them
through my tree.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

#5 lore raw
Quoted 2 lines

As these patches were meant for generic non-m68k code, I didn't plan to take them through my tree.

Well, that explains everything. Sorry for letting it fall through the cracks. I assumed that since you send pull requests to Linus regularly, you'd send it directly.

That's why I only acked the patch rather than did anything with it.

So, who wants to send it now?

#6 lore raw

Hi Georges,

Quoted 10 lines · George Spelvin
Quoted 2 lines

As these patches were meant for generic non-m68k code, I didn't plan to take them through my tree.

Well, that explains everything. Sorry for letting it fall through the cracks. I assumed that since you send pull requests to Linus regularly, you'd send it directly.

That's why I only acked the patch rather than did anything with it.

So, who wants to send it now?

I think you should queue them in your git tree, and send a pull request to Linus, as that's how the original code went upstream.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]

In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

#7 lore raw
In reply to Arnd Bergmann
Quoted 12 lines · Arnd Bergmann
Quoted 11 lines · CEST kernelci. org bot

next build: 143 builds: 1 failed, 142 passed, 1 error, 22 warnings (next-20160801)

Full Build Summary: https://kernelci.org/build/next/kernel/next-20160801/

Tree: next
Branch: local/master
Git Describe: next-20160801
Git Commit: c24c1308a5b274bbd90db927cb18efddc95340c7
Git URL: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
Built: 3 unique architectures

Quoted 8 lines
Quoted 5 lines

Build Failure Detected:

arm: gcc version 5.3.1 20160113 (Linaro GCC 5.3-2016.02)

rpc_defconfig: FAIL

I have verified that Linaro GCC 5.3-2016.05 is fixed, only Linaro GCC 5.3-2016.02 and earlier have this problem, please upgrade if possible

I don't see this packaged up yet. I'll upgrade as soon as it shows up here:

https://releases.linaro.org/components/toolchain/binaries/latest-5/arm-linux-gnueabihf/

Thanks for testing and letting us know,

Kevin