Hi Greg,
please apply the following patches.
to v4.4-stable and older:
cb36af3e48be sh: New gcc support to support gcc 8.1.0 for sh
to v4.9-stable and older:
009615ab7fd4 USB: serial: cp210x: use tcflag_t to fix incompatible pointer type to support gcc 7.3.0 for sparc
Copying Arnd - I can't get sparc images to compile with gcc 8.1.0. Any idea ?
Thanks, Guenter
On Mon, May 28, 2018 at 06:48:30AM -0700, Guenter Roeck wrote:
Hi Greg,
please apply the following patches.
to v4.4-stable and older:
cb36af3e48be sh: New gcc support to support gcc 8.1.0 for sh
I don't see that commit id in Linus's tree, are you sure it is correct?
to v4.9-stable and older:
009615ab7fd4 USB: serial: cp210x: use tcflag_t to fix incompatible pointer type to support gcc 7.3.0 for sparc
Now queued up, thanks.
greg k-h
On 05/30/2018 01:38 AM, Greg Kroah-Hartman wrote:
On Mon, May 28, 2018 at 06:48:30AM -0700, Guenter Roeck wrote:
Hi Greg,
please apply the following patches.
to v4.4-stable and older:
cb36af3e48be sh: New gcc support to support gcc 8.1.0 for sh
I don't see that commit id in Linus's tree, are you sure it is correct?
Oops, sorry, that was the sha after I test-applied it. Correct is
940d4113f330 sh: New gcc support
Guenter
to v4.9-stable and older:
009615ab7fd4 USB: serial: cp210x: use tcflag_t to fix incompatible pointer type to support gcc 7.3.0 for sparc
Now queued up, thanks.
greg k-h
On Wed, May 30, 2018 at 06:18:10AM -0700, Guenter Roeck wrote:
On 05/30/2018 01:38 AM, Greg Kroah-Hartman wrote:
On Mon, May 28, 2018 at 06:48:30AM -0700, Guenter Roeck wrote:
Hi Greg,
please apply the following patches.
to v4.4-stable and older:
cb36af3e48be sh: New gcc support to support gcc 8.1.0 for sh
I don't see that commit id in Linus's tree, are you sure it is correct?
Oops, sorry, that was the sha after I test-applied it. Correct is
940d4113f330 sh: New gcc support
Thanks, that worked.
greg k-h
On Mon, May 28, 2018 at 3:48 PM, Guenter Roeck linux@roeck-us.net wrote:
Hi Greg,
please apply the following patches.
to v4.4-stable and older:
cb36af3e48be sh: New gcc support to support gcc 8.1.0 for sh
to v4.9-stable and older:
009615ab7fd4 USB: serial: cp210x: use tcflag_t to fix incompatible pointer type to support gcc 7.3.0 for sparc
Copying Arnd - I can't get sparc images to compile with gcc 8.1.0. Any idea
No, sorry. I've just tried it again and couldn't find any problems with my gcc-8.1 binaries building either sparc32_defconfig or sparc64_defconfig.
Arnd
On Wed, May 30, 2018 at 11:27:50AM +0200, Arnd Bergmann wrote:
On Mon, May 28, 2018 at 3:48 PM, Guenter Roeck linux@roeck-us.net wrote:
Hi Greg,
please apply the following patches.
to v4.4-stable and older:
cb36af3e48be sh: New gcc support to support gcc 8.1.0 for sh
to v4.9-stable and older:
009615ab7fd4 USB: serial: cp210x: use tcflag_t to fix incompatible pointer type to support gcc 7.3.0 for sparc
Copying Arnd - I can't get sparc images to compile with gcc 8.1.0. Any idea
No, sorry. I've just tried it again and couldn't find any problems with my gcc-8.1 binaries building either sparc32_defconfig or sparc64_defconfig.
So you mean it works, or does not work?
And you are seeing loads of build warnings, right? I tried your 8.1 binary for s390 and had to just give up looking at the warnings :(
thanks,
greg k-h
On Wed, May 30, 2018 at 11:44 AM, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Wed, May 30, 2018 at 11:27:50AM +0200, Arnd Bergmann wrote:
On Mon, May 28, 2018 at 3:48 PM, Guenter Roeck linux@roeck-us.net wrote:
Hi Greg,
please apply the following patches.
to v4.4-stable and older:
cb36af3e48be sh: New gcc support to support gcc 8.1.0 for sh
to v4.9-stable and older:
009615ab7fd4 USB: serial: cp210x: use tcflag_t to fix incompatible pointer type to support gcc 7.3.0 for sparc
Copying Arnd - I can't get sparc images to compile with gcc 8.1.0. Any idea
No, sorry. I've just tried it again and couldn't find any problems with my gcc-8.1 binaries building either sparc32_defconfig or sparc64_defconfig.
So you mean it works, or does not work?
And you are seeing loads of build warnings, right? I tried your 8.1 binary for s390 and had to just give up looking at the warnings :(
It does work, but yes, there are many warnings. I still need to revisit my patch for the system call entry points: I posted one a long time ago, but then the mainline implementation changed and I never got around to sending an updated version. Similarly, I planned to send a patch that disables all the -Wstringop-truncated warnings unless 'make W=1' is used, but that ended up in my long backlog of minor fixes after my initial plan to fix address those warnings didn't work out.
Arnd
On Wed, May 30, 2018 at 11:52:14AM +0200, Arnd Bergmann wrote:
On Wed, May 30, 2018 at 11:44 AM, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Wed, May 30, 2018 at 11:27:50AM +0200, Arnd Bergmann wrote:
On Mon, May 28, 2018 at 3:48 PM, Guenter Roeck linux@roeck-us.net wrote:
Hi Greg,
please apply the following patches.
to v4.4-stable and older:
cb36af3e48be sh: New gcc support to support gcc 8.1.0 for sh
to v4.9-stable and older:
009615ab7fd4 USB: serial: cp210x: use tcflag_t to fix incompatible pointer type to support gcc 7.3.0 for sparc
Copying Arnd - I can't get sparc images to compile with gcc 8.1.0. Any idea
No, sorry. I've just tried it again and couldn't find any problems with my gcc-8.1 binaries building either sparc32_defconfig or sparc64_defconfig.
So you mean it works, or does not work?
And you are seeing loads of build warnings, right? I tried your 8.1 binary for s390 and had to just give up looking at the warnings :(
It does work, but yes, there are many warnings. I still need to revisit my patch for the system call entry points: I posted one a long time ago, but then the mainline implementation changed and I never got around to sending an updated version. Similarly, I planned to send a patch that disables all the -Wstringop-truncated warnings unless 'make W=1' is used, but that ended up in my long backlog of minor fixes after my initial plan to fix address those warnings didn't work out.
Given the recent mess that just happened yesterday when 0-day tried to use gcc-8 and started emailing tons of innocent developers, it might be good to dust those off soon :)
If you have a pointer to them, and are busy with other stuff, I can look at getting them merged.
thanks,
greg k-h
On 05/30/2018 02:27 AM, Arnd Bergmann wrote:
On Mon, May 28, 2018 at 3:48 PM, Guenter Roeck linux@roeck-us.net wrote:
Hi Greg,
please apply the following patches.
to v4.4-stable and older:
cb36af3e48be sh: New gcc support to support gcc 8.1.0 for sh
to v4.9-stable and older:
009615ab7fd4 USB: serial: cp210x: use tcflag_t to fix incompatible pointer type to support gcc 7.3.0 for sparc
Copying Arnd - I can't get sparc images to compile with gcc 8.1.0. Any idea
No, sorry. I've just tried it again and couldn't find any problems with my gcc-8.1 binaries building either sparc32_defconfig or sparc64_defconfig.
Interesting. With sparc64-linux-gcc (GCC) 8.1.0 from kernel.org:
make ARCH=sparc64 CROSS_COMPILE=sparc64-linux- allmodconfig make ARCH=sparc64 CROSS_COMPILE=sparc64-linux- arch/sparc/kernel/sys_sparc_64.o
results in:
./include/linux/syscalls.h:233:18: error: 'sys_sparc64_personality' alias between functions of incompatible types 'long int(long unsigned int)' and 'long int(long int)' [-Werror=attribute-alias]
and many more.
Presumably this is due to
arch/sparc/kernel/Makefile:ccflags-y := -Werror
Guenter
On Wed, May 30, 2018 at 3:31 PM, Guenter Roeck linux@roeck-us.net wrote:
On 05/30/2018 02:27 AM, Arnd Bergmann wrote:
On Mon, May 28, 2018 at 3:48 PM, Guenter Roeck linux@roeck-us.net wrote:
Hi Greg,
please apply the following patches.
to v4.4-stable and older:
cb36af3e48be sh: New gcc support to support gcc 8.1.0 for sh
to v4.9-stable and older:
009615ab7fd4 USB: serial: cp210x: use tcflag_t to fix incompatible pointer type to support gcc 7.3.0 for sparc
Copying Arnd - I can't get sparc images to compile with gcc 8.1.0. Any idea
No, sorry. I've just tried it again and couldn't find any problems with my gcc-8.1 binaries building either sparc32_defconfig or sparc64_defconfig.
Interesting. With sparc64-linux-gcc (GCC) 8.1.0 from kernel.org:
make ARCH=sparc64 CROSS_COMPILE=sparc64-linux- allmodconfig make ARCH=sparc64 CROSS_COMPILE=sparc64-linux- arch/sparc/kernel/sys_sparc_64.o
results in:
./include/linux/syscalls.h:233:18: error: 'sys_sparc64_personality' alias between functions of incompatible types 'long int(long unsigned int)' and 'long int(long int)' [-Werror=attribute-alias]
and many more.
Presumably this is due to
arch/sparc/kernel/Makefile:ccflags-y := -Werror
Right, I have disabled that warning locally, so I didn't get it despite the -Werror.
Arnd
On Wed, May 30, 2018 at 03:55:04PM +0200, Arnd Bergmann wrote:
On Wed, May 30, 2018 at 3:31 PM, Guenter Roeck linux@roeck-us.net wrote:
On 05/30/2018 02:27 AM, Arnd Bergmann wrote:
On Mon, May 28, 2018 at 3:48 PM, Guenter Roeck linux@roeck-us.net wrote:
Hi Greg,
please apply the following patches.
to v4.4-stable and older:
cb36af3e48be sh: New gcc support to support gcc 8.1.0 for sh
to v4.9-stable and older:
009615ab7fd4 USB: serial: cp210x: use tcflag_t to fix incompatible pointer type to support gcc 7.3.0 for sparc
Copying Arnd - I can't get sparc images to compile with gcc 8.1.0. Any idea
No, sorry. I've just tried it again and couldn't find any problems with my gcc-8.1 binaries building either sparc32_defconfig or sparc64_defconfig.
Interesting. With sparc64-linux-gcc (GCC) 8.1.0 from kernel.org:
make ARCH=sparc64 CROSS_COMPILE=sparc64-linux- allmodconfig make ARCH=sparc64 CROSS_COMPILE=sparc64-linux- arch/sparc/kernel/sys_sparc_64.o
results in:
./include/linux/syscalls.h:233:18: error: 'sys_sparc64_personality' alias between functions of incompatible types 'long int(long unsigned int)' and 'long int(long int)' [-Werror=attribute-alias]
and many more.
Presumably this is due to
arch/sparc/kernel/Makefile:ccflags-y := -Werror
Right, I have disabled that warning locally, so I didn't get it despite the -Werror.
Would it make sense to add KBUILD_CFLAGS += $(call cc-option,-Wno-attribute-alias) to the sparc Makefile ? It seems to fix the problem for me, and it would be easier to backport than a more comprehensive fix.
Guenter
On Wed, May 30, 2018 at 11:46:45AM -0700, Guenter Roeck wrote:
On Wed, May 30, 2018 at 03:55:04PM +0200, Arnd Bergmann wrote:
On Wed, May 30, 2018 at 3:31 PM, Guenter Roeck linux@roeck-us.net wrote:
On 05/30/2018 02:27 AM, Arnd Bergmann wrote:
On Mon, May 28, 2018 at 3:48 PM, Guenter Roeck linux@roeck-us.net wrote:
Hi Greg,
please apply the following patches.
to v4.4-stable and older:
cb36af3e48be sh: New gcc support to support gcc 8.1.0 for sh
to v4.9-stable and older:
009615ab7fd4 USB: serial: cp210x: use tcflag_t to fix incompatible pointer type to support gcc 7.3.0 for sparc
Copying Arnd - I can't get sparc images to compile with gcc 8.1.0. Any idea
No, sorry. I've just tried it again and couldn't find any problems with my gcc-8.1 binaries building either sparc32_defconfig or sparc64_defconfig.
Interesting. With sparc64-linux-gcc (GCC) 8.1.0 from kernel.org:
make ARCH=sparc64 CROSS_COMPILE=sparc64-linux- allmodconfig make ARCH=sparc64 CROSS_COMPILE=sparc64-linux- arch/sparc/kernel/sys_sparc_64.o
results in:
./include/linux/syscalls.h:233:18: error: 'sys_sparc64_personality' alias between functions of incompatible types 'long int(long unsigned int)' and 'long int(long int)' [-Werror=attribute-alias]
and many more.
Presumably this is due to
arch/sparc/kernel/Makefile:ccflags-y := -Werror
Right, I have disabled that warning locally, so I didn't get it despite the -Werror.
Would it make sense to add KBUILD_CFLAGS += $(call cc-option,-Wno-attribute-alias) to the sparc Makefile ? It seems to fix the problem for me, and it would be easier to backport than a more comprehensive fix.
Why is that not an option enabled for all arches right now for gcc-8?
thanks,
greg k-h
On Wed, May 30, 2018 at 9:24 PM, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
On Wed, May 30, 2018 at 11:46:45AM -0700, Guenter Roeck wrote:
On Wed, May 30, 2018 at 03:55:04PM +0200, Arnd Bergmann wrote:
On Wed, May 30, 2018 at 3:31 PM, Guenter Roeck linux@roeck-us.net wrote:
On 05/30/2018 02:27 AM, Arnd Bergmann wrote:
Presumably this is due to
arch/sparc/kernel/Makefile:ccflags-y := -Werror
Right, I have disabled that warning locally, so I didn't get it despite the -Werror.
Would it make sense to add KBUILD_CFLAGS += $(call cc-option,-Wno-attribute-alias) to the sparc Makefile ? It seems to fix the problem for me, and it would be easier to backport than a more comprehensive fix.
Why is that not an option enabled for all arches right now for gcc-8?
I would still want this warning enabled by default in future kernels, just disabled for the system call definitions (until we decide to rework the way they are defined).
What I'd suggest we do is a series of patches:
1. disable both -Wno-attribute-alias and -Wstringop-truncation by default, but leave them enabled in 'make W=1'. Mark this one for stable backports 2. add a macro to let users disable warnings locally within a file, based on _Pragma("GCC diagnostic ...") 3. change the system call macros to disable -Wno-attribute-alias inside of the SYSCALL_DEFINEx() macros 4. turn on -Wno-attribute-alias again by default.
Arnd
On Wed, May 30, 2018 at 09:34:34PM +0200, Arnd Bergmann wrote:
On Wed, May 30, 2018 at 9:24 PM, Greg Kroah-Hartman
Why is that not an option enabled for all arches right now for gcc-8?
I would still want this warning enabled by default in future kernels, just disabled for the system call definitions (until we decide to rework the way they are defined).
What I'd suggest we do is a series of patches:
- disable both -Wno-attribute-alias and -Wstringop-truncation by
default, but leave them enabled in 'make W=1'. Mark this one for stable backports 2. add a macro to let users disable warnings locally within a file, based on _Pragma("GCC diagnostic ...") 3. change the system call macros to disable -Wno-attribute-alias inside of the SYSCALL_DEFINEx() macros 4. turn on -Wno-attribute-alias again by default.
That sounds like a good plan to me.
On Wed, May 30, 2018 at 10:04:51PM +0200, Greg Kroah-Hartman wrote:
On Wed, May 30, 2018 at 09:34:34PM +0200, Arnd Bergmann wrote:
On Wed, May 30, 2018 at 9:24 PM, Greg Kroah-Hartman
Why is that not an option enabled for all arches right now for gcc-8?
I would still want this warning enabled by default in future kernels, just disabled for the system call definitions (until we decide to rework the way they are defined).
What I'd suggest we do is a series of patches:
- disable both -Wno-attribute-alias and -Wstringop-truncation by
default, but leave them enabled in 'make W=1'. Mark this one for stable backports 2. add a macro to let users disable warnings locally within a file, based on _Pragma("GCC diagnostic ...") 3. change the system call macros to disable -Wno-attribute-alias inside of the SYSCALL_DEFINEx() macros 4. turn on -Wno-attribute-alias again by default.
That sounds like a good plan to me.
Agreed.
Guenter
linux-stable-mirror@lists.linaro.org
-
Arnd Bergmann -
Greg Kroah-Hartman -
Guenter Roeck