next build: 143 builds: 1 failed, 142 passed, 1 error, 22 warnings (next-20160801)
A message that is not in the archive (sent off-list or not yet received): [email protected]
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
@@ -143,7 +143,7 @@ static int __inittest_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 mismatchesWarnings:
arch/arm/configs/aspeed_g4_defconfig:61:warning: symbol value '1' invalid forPRINTK_TIME--------------------------------------------------------------------------------
aspeed_g5_defconfig(arm) — PASS, 0 errors, 1 warning, 0 section mismatchesWarnings:
arch/arm/configs/aspeed_g5_defconfig:62:warning: symbol value '1' invalid forPRINTK_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
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: FAILI 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.
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")Signed-off-by Geert Uytterhoeven <[email protected]>--- lib/test_hash.c | 24 +++++++++++++++--------- 1 file changed, 15 insertions(+), 9 deletions(-)lib/test_hash.c +15
-9@@ -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
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=146454366131111Perhaps 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
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?
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
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: FAILI 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