Re: [GIT PULL] x86/build changes for v4.17

On Thu, Jun 07, 2018 at 12:23:31PM -0700, Nick Desaulniers wrote: > On Wed, Apr 4, 2018 at 12:32 PM Josh Poimboeuf wrote: > > > > On Wed, Apr 04, 2018 at 04:53:52PM +, Nick Desaulniers wrote: > > > (re-sending as plain text) > > > > > > On Wed, Apr 4, 2018 at 2:38 AM Greg KH wrote: > > > >

Re: [GIT PULL] x86/build changes for v4.17

On Thu, Jun 07, 2018 at 12:23:31PM -0700, Nick Desaulniers wrote: > On Wed, Apr 4, 2018 at 12:32 PM Josh Poimboeuf wrote: > > > > On Wed, Apr 04, 2018 at 04:53:52PM +, Nick Desaulniers wrote: > > > (re-sending as plain text) > > > > > > On Wed, Apr 4, 2018 at 2:38 AM Greg KH wrote: > > > >

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 4, 2018 at 12:32 PM Josh Poimboeuf wrote: > > On Wed, Apr 04, 2018 at 04:53:52PM +, Nick Desaulniers wrote: > > (re-sending as plain text) > > > > On Wed, Apr 4, 2018 at 2:38 AM Greg KH wrote: > > > There are known-bugs with building a kernel with clang right now (I > > > pointed

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 4, 2018 at 12:32 PM Josh Poimboeuf wrote: > > On Wed, Apr 04, 2018 at 04:53:52PM +, Nick Desaulniers wrote: > > (re-sending as plain text) > > > > On Wed, Apr 4, 2018 at 2:38 AM Greg KH wrote: > > > There are known-bugs with building a kernel with clang right now (I > > > pointed

Re: [GIT PULL] x86/build changes for v4.17

On Thu, Apr 5, 2018 at 3:51 PM, James Y Knight wrote: > > Unfortunately, that behavior is required by the standard, it's not up to > compiler optimization to change. I actually mis-read your example - in your case it obviously does pass the array itself down to the call, and

Re: [GIT PULL] x86/build changes for v4.17

On Thu, Apr 5, 2018 at 3:51 PM, James Y Knight wrote: > > Unfortunately, that behavior is required by the standard, it's not up to > compiler optimization to change. I actually mis-read your example - in your case it obviously does pass the array itself down to the call, and yes, it obviously

Re: [GIT PULL] x86/build changes for v4.17

On Thu, Apr 5, 2018 at 5:13 PM Linus Torvalds wrote: > And btw, I hate how stupid gcc is about "constant size arrays but acts > as a VLA because it wasn't an integer-constant-expression size" > things. > Your code generation example really is a sad sad example of

Re: [GIT PULL] x86/build changes for v4.17

On Thu, Apr 5, 2018 at 5:13 PM Linus Torvalds wrote: > And btw, I hate how stupid gcc is about "constant size arrays but acts > as a VLA because it wasn't an integer-constant-expression size" > things. > Your code generation example really is a sad sad example of it. A good > optimizer should

Re: [GIT PULL] x86/build changes for v4.17

On Thu, Apr 5, 2018 at 1:51 PM, James Y Knight wrote: > > I had actually meant that the __builtin_constant_p **itself** had to be a > constant expression, not that its *argument* must be an I-C-E for > __builtin_constant_p to return true. I actually really wish that were

Re: [GIT PULL] x86/build changes for v4.17

On Thu, Apr 5, 2018 at 1:51 PM, James Y Knight wrote: > > I had actually meant that the __builtin_constant_p **itself** had to be a > constant expression, not that its *argument* must be an I-C-E for > __builtin_constant_p to return true. I actually really wish that were true, and that it would

Re: [GIT PULL] x86/build changes for v4.17

On Thu, Apr 5, 2018 at 2:06 PM Linus Torvalds wrote: > On Thu, Apr 5, 2018 at 10:46 AM, James Y Knight wrote: > > > > GCC, however, mixes up the concept of a C "constant expression" with the > > results of running optimization passes such as

Re: [GIT PULL] x86/build changes for v4.17

On Thu, Apr 5, 2018 at 2:06 PM Linus Torvalds wrote: > On Thu, Apr 5, 2018 at 10:46 AM, James Y Knight wrote: > > > > GCC, however, mixes up the concept of a C "constant expression" with the > > results of running optimization passes such as inlining for its > > definition/implementation of

Re: [GIT PULL] x86/build changes for v4.17

()() ha On Thu, Apr 5, 2018 at 10:46 AM, James Y Knight wrote: > > GCC, however, mixes up the concept of a C "constant expression" with the > results of running optimization passes such as inlining for its > definition/implementation of __builtin_constant_p. Clang does not,

Re: [GIT PULL] x86/build changes for v4.17

()() ha On Thu, Apr 5, 2018 at 10:46 AM, James Y Knight wrote: > > GCC, however, mixes up the concept of a C "constant expression" with the > results of running optimization passes such as inlining for its > definition/implementation of __builtin_constant_p. Clang does not, and quite > likely

Re: [GIT PULL] x86/build changes for v4.17

I think maybe you're confused; those functions do not appear to use __builtin_constant_p, which is the issue at hand. Clang's optimizer is of course not a complete joke...it can perfectly well optimize functions after inlining in order to not generate "shit code gen". GCC, however, mixes up the

Re: [GIT PULL] x86/build changes for v4.17

I think maybe you're confused; those functions do not appear to use __builtin_constant_p, which is the issue at hand. Clang's optimizer is of course not a complete joke...it can perfectly well optimize functions after inlining in order to not generate "shit code gen". GCC, however, mixes up the

Re: [GIT PULL] x86/build changes for v4.17

On Thu, Apr 5, 2018 at 12:24 AM, Peter Zijlstra wrote: > > I always assumed BT was a more expensive instruction than AND with > immediate. Oh, absolutely. That's why we do all those "depending on immediate or not". The reason I brought that case up is that "test_bit()" and

Re: [GIT PULL] x86/build changes for v4.17

On Thu, Apr 5, 2018 at 12:24 AM, Peter Zijlstra wrote: > > I always assumed BT was a more expensive instruction than AND with > immediate. Oh, absolutely. That's why we do all those "depending on immediate or not". The reason I brought that case up is that "test_bit()" and "set_bit()" do this

Re: [GIT PULL] x86/build changes for v4.17

On Thu, Apr 5, 2018 at 3:08 AM Peter Zijlstra wrote: > On Wed, Apr 04, 2018 at 10:21:05PM +, James Y Knight wrote: > > But allowing random pointer arithmetic, and pointer arithmetic wraparound, > > is still different than asserting that an object _field access_ can > >

Re: [GIT PULL] x86/build changes for v4.17

On Thu, Apr 5, 2018 at 3:08 AM Peter Zijlstra wrote: > On Wed, Apr 04, 2018 at 10:21:05PM +, James Y Knight wrote: > > But allowing random pointer arithmetic, and pointer arithmetic wraparound, > > is still different than asserting that an object _field access_ can > > overflow. Clang does

Re: [GIT PULL] x86/build changes for v4.17

On Thu, Apr 05, 2018 at 10:04:46AM +0200, Ingo Molnar wrote: >http://www.agner.org/optimize/instruction_tables.pdf > > The SkyLake costs for 'BT', 'AND' and 'TEST' variants are: > > BT m,i 2 2 > p06 p23 0.5

Re: [GIT PULL] x86/build changes for v4.17

On Thu, Apr 05, 2018 at 10:04:46AM +0200, Ingo Molnar wrote: >http://www.agner.org/optimize/instruction_tables.pdf > > The SkyLake costs for 'BT', 'AND' and 'TEST' variants are: > > BT m,i 2 2 > p06 p23 0.5

Re: [GIT PULL] x86/build changes for v4.17

* Peter Zijlstra wrote: > On Wed, Apr 04, 2018 at 05:05:25PM -0700, Linus Torvalds wrote: > > for some reason the test_bit() case looks like > > this: > > > > #define test_bit(nr, addr) \ > > (__builtin_constant_p((nr)) \ > >

Re: [GIT PULL] x86/build changes for v4.17

* Peter Zijlstra wrote: > On Wed, Apr 04, 2018 at 05:05:25PM -0700, Linus Torvalds wrote: > > for some reason the test_bit() case looks like > > this: > > > > #define test_bit(nr, addr) \ > > (__builtin_constant_p((nr)) \ > > ?

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 04, 2018 at 05:05:25PM -0700, Linus Torvalds wrote: > for some reason the test_bit() case looks like > this: > > #define test_bit(nr, addr) \ > (__builtin_constant_p((nr)) \ > ? constant_test_bit((nr), (addr)) \ > :

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 04, 2018 at 05:05:25PM -0700, Linus Torvalds wrote: > for some reason the test_bit() case looks like > this: > > #define test_bit(nr, addr) \ > (__builtin_constant_p((nr)) \ > ? constant_test_bit((nr), (addr)) \ > :

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 04, 2018 at 04:31:11PM -0700, Matthias Kaehlcke wrote: > From some experiments it looks like clang, in difference to gcc, does > not treat constant values passed as parameters to inline function as > constants. Then you're also missing a heap of optimizations in code like

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 04, 2018 at 04:31:11PM -0700, Matthias Kaehlcke wrote: > From some experiments it looks like clang, in difference to gcc, does > not treat constant values passed as parameters to inline function as > constants. Then you're also missing a heap of optimizations in code like

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 04, 2018 at 10:21:05PM +, James Y Knight wrote: > But allowing random pointer arithmetic, and pointer arithmetic wraparound, > is still different than asserting that an object _field access_ can > overflow. Clang does not believe that can happen -- it assumes that an > object will

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 04, 2018 at 10:21:05PM +, James Y Knight wrote: > But allowing random pointer arithmetic, and pointer arithmetic wraparound, > is still different than asserting that an object _field access_ can > overflow. Clang does not believe that can happen -- it assumes that an > object will

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 4, 2018 at 5:05 PM, Linus Torvalds wrote: > On Wed, Apr 4, 2018 at 4:31 PM, Matthias Kaehlcke wrote: >> >> From some experiments it looks like clang, in difference to gcc, does >> not treat constant values passed as parameters to

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 4, 2018 at 5:05 PM, Linus Torvalds wrote: > On Wed, Apr 4, 2018 at 4:31 PM, Matthias Kaehlcke wrote: >> >> From some experiments it looks like clang, in difference to gcc, does >> not treat constant values passed as parameters to inline function as >> constants. > > Yeah, I think gcc

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 4, 2018 at 4:31 PM, Matthias Kaehlcke wrote: > > From some experiments it looks like clang, in difference to gcc, does > not treat constant values passed as parameters to inline function as > constants. Yeah, I think gcc used to have those semantics a long time ago

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 4, 2018 at 4:31 PM, Matthias Kaehlcke wrote: > > From some experiments it looks like clang, in difference to gcc, does > not treat constant values passed as parameters to inline function as > constants. Yeah, I think gcc used to have those semantics a long time ago too. Many of our

Re: [GIT PULL] x86/build changes for v4.17

El Wed, Apr 04, 2018 at 03:39:24PM -0700 Linus Torvalds ha dit: > On Wed, Apr 4, 2018 at 3:17 PM, Matthias Kaehlcke wrote: > > > > Getting our compiler team high to look into this might affect a timely > > (and correct ...) implementation of asm-goto and others important > >

Re: [GIT PULL] x86/build changes for v4.17

El Wed, Apr 04, 2018 at 03:39:24PM -0700 Linus Torvalds ha dit: > On Wed, Apr 4, 2018 at 3:17 PM, Matthias Kaehlcke wrote: > > > > Getting our compiler team high to look into this might affect a timely > > (and correct ...) implementation of asm-goto and others important > > features. Arnd, do

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 4, 2018 at 10:13 AM Linus Torvalds < torva...@linux-foundation.org> wrote: > The fact that clang by default enables "-fmerge-all-constants" > behavior is just inexcusable. That's not just "let's do invalid > optimizations based on undefined behavior". That's an actual "let's do > known

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 4, 2018 at 10:13 AM Linus Torvalds < torva...@linux-foundation.org> wrote: > The fact that clang by default enables "-fmerge-all-constants" > behavior is just inexcusable. That's not just "let's do invalid > optimizations based on undefined behavior". That's an actual "let's do > known

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 4, 2018 at 12:17 PM Matthias Kaehlcke wrote: > Even with clang having known issues it would be preferable not to > break kernel builds with clang, if this doesn't place a signifcant > burden on the kernel. I'm not sure it is strictly necessary to 'wait' > for clang

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 4, 2018 at 12:17 PM Matthias Kaehlcke wrote: > Even with clang having known issues it would be preferable not to > break kernel builds with clang, if this doesn't place a signifcant > burden on the kernel. I'm not sure it is strictly necessary to 'wait' > for clang to enforce asm-goto

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 4, 2018 at 3:17 PM, Matthias Kaehlcke wrote: > > Getting our compiler team high to look into this might affect a timely > (and correct ...) implementation of asm-goto and others important > features. Arnd, do you have another, preferably simple instance to > keep

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 4, 2018 at 3:17 PM, Matthias Kaehlcke wrote: > > Getting our compiler team high to look into this might affect a timely > (and correct ...) implementation of asm-goto and others important > features. Arnd, do you have another, preferably simple instance to > keep our compiler folks

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 4, 2018 at 3:21 PM, James Y Knight wrote: > > But allowing random pointer arithmetic, and pointer arithmetic wraparound, > is still different than asserting that an object _field access_ can > overflow. But that's not what the code does. It never _accessed_ the

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 4, 2018 at 3:21 PM, James Y Knight wrote: > > But allowing random pointer arithmetic, and pointer arithmetic wraparound, > is still different than asserting that an object _field access_ can > overflow. But that's not what the code does. It never _accessed_ the field. It only looked

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 4, 2018 at 3:42 PM Linus Torvalds wrote: > So we'd definitely want that "-fno-strict-overflow" to affect pointer > arithmetic too (or have a separate flag for the pointer equivalent of > "we play games that may temporarily wrap pointer values around"..

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 4, 2018 at 3:42 PM Linus Torvalds wrote: > So we'd definitely want that "-fno-strict-overflow" to affect pointer > arithmetic too (or have a separate flag for the pointer equivalent of > "we play games that may temporarily wrap pointer values around".. The -fno-strict-overflow flag

Re: [GIT PULL] x86/build changes for v4.17

El Wed, Apr 04, 2018 at 02:59:09PM -0700 Linus Torvalds ha dit: > On Wed, Apr 4, 2018 at 2:46 PM, Matthias Kaehlcke wrote: > > > > I understand this is annoying, but it seems I'm missing something: > > I think you're looking at !AEABI case. > > The AEABI case is worse. It

Re: [GIT PULL] x86/build changes for v4.17

El Wed, Apr 04, 2018 at 02:59:09PM -0700 Linus Torvalds ha dit: > On Wed, Apr 4, 2018 at 2:46 PM, Matthias Kaehlcke wrote: > > > > I understand this is annoying, but it seems I'm missing something: > > I think you're looking at !AEABI case. > > The AEABI case is worse. It ends up getting the

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 4, 2018 at 2:46 PM, Matthias Kaehlcke wrote: > > I understand this is annoying, but it seems I'm missing something: I think you're looking at !AEABI case. The AEABI case is worse. It ends up getting the code from include/asm-generic/div64.h after defining a few

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 4, 2018 at 2:46 PM, Matthias Kaehlcke wrote: > > I understand this is annoying, but it seems I'm missing something: I think you're looking at !AEABI case. The AEABI case is worse. It ends up getting the code from include/asm-generic/div64.h after defining a few helper inline asm

Re: [GIT PULL] x86/build changes for v4.17

El Wed, Apr 04, 2018 at 11:11:36PM +0200 Arnd Bergmann ha dit: > On Wed, Apr 4, 2018 at 10:58 PM, Matthias Kaehlcke wrote: > > El Wed, Apr 04, 2018 at 10:33:19PM +0200 Arnd Bergmann ha dit: > >> > >> In most cases, this is used to implement a fast-path for a helper > >>

Re: [GIT PULL] x86/build changes for v4.17

El Wed, Apr 04, 2018 at 11:11:36PM +0200 Arnd Bergmann ha dit: > On Wed, Apr 4, 2018 at 10:58 PM, Matthias Kaehlcke wrote: > > El Wed, Apr 04, 2018 at 10:33:19PM +0200 Arnd Bergmann ha dit: > >> > >> In most cases, this is used to implement a fast-path for a helper > >> function, so not doing it

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 4, 2018 at 10:58 PM, Matthias Kaehlcke wrote: > El Wed, Apr 04, 2018 at 10:33:19PM +0200 Arnd Bergmann ha dit: >> >> In most cases, this is used to implement a fast-path for a helper >> function, so not doing it the same way as gcc just results in >> slower

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 4, 2018 at 10:58 PM, Matthias Kaehlcke wrote: > El Wed, Apr 04, 2018 at 10:33:19PM +0200 Arnd Bergmann ha dit: >> >> In most cases, this is used to implement a fast-path for a helper >> function, so not doing it the same way as gcc just results in >> slower execution, but I assume we

Re: [GIT PULL] x86/build changes for v4.17

El Wed, Apr 04, 2018 at 10:33:19PM +0200 Arnd Bergmann ha dit: > On Wed, Apr 4, 2018 at 9:17 PM, Matthias Kaehlcke wrote: > > El Wed, Apr 04, 2018 at 11:30:07AM +0200 Peter Zijlstra ha dit: > > > >> On Tue, Apr 03, 2018 at 11:06:58AM -0700, Matthias Kaehlcke wrote: > >> > >> >

Re: [GIT PULL] x86/build changes for v4.17

El Wed, Apr 04, 2018 at 10:33:19PM +0200 Arnd Bergmann ha dit: > On Wed, Apr 4, 2018 at 9:17 PM, Matthias Kaehlcke wrote: > > El Wed, Apr 04, 2018 at 11:30:07AM +0200 Peter Zijlstra ha dit: > > > >> On Tue, Apr 03, 2018 at 11:06:58AM -0700, Matthias Kaehlcke wrote: > >> > >> > Yes, Chrome OS R67

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 4, 2018 at 9:17 PM, Matthias Kaehlcke wrote: > El Wed, Apr 04, 2018 at 11:30:07AM +0200 Peter Zijlstra ha dit: > >> On Tue, Apr 03, 2018 at 11:06:58AM -0700, Matthias Kaehlcke wrote: >> >> > Yes, Chrome OS R67 (currently dev, soon beta) will ship a kernel built >> >

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 4, 2018 at 9:17 PM, Matthias Kaehlcke wrote: > El Wed, Apr 04, 2018 at 11:30:07AM +0200 Peter Zijlstra ha dit: > >> On Tue, Apr 03, 2018 at 11:06:58AM -0700, Matthias Kaehlcke wrote: >> >> > Yes, Chrome OS R67 (currently dev, soon beta) will ship a kernel built >> > with Clang for

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 4, 2018 at 12:26 PM, James Y Knight wrote: > > (OTOH, I _do_ expect clang to eventually gain support for a flag to treat > NULL-pointer deref as a legal operation instead of UB. I'm not really sure > it makes sense for the linux kernel, but it's a useful feature

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 4, 2018 at 12:26 PM, James Y Knight wrote: > > (OTOH, I _do_ expect clang to eventually gain support for a flag to treat > NULL-pointer deref as a legal operation instead of UB. I'm not really sure > it makes sense for the linux kernel, but it's a useful feature for the > compiler to

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 04, 2018 at 04:53:52PM +, Nick Desaulniers wrote: > (re-sending as plain text) > > On Wed, Apr 4, 2018 at 2:38 AM Greg KH wrote: > > There are known-bugs with building a kernel with clang right now (I > > pointed one out a few days ago about NULL

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 04, 2018 at 04:53:52PM +, Nick Desaulniers wrote: > (re-sending as plain text) > > On Wed, Apr 4, 2018 at 2:38 AM Greg KH wrote: > > There are known-bugs with building a kernel with clang right now (I > > pointed one out a few days ago about NULL checks being deleted from the > >

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 4, 2018 at 12:59 PM Greg KH wrote: > Here is another horrible work around that was needed to get clang to > stop generating invalid code, beaec533fc27 ("llist: clang: introduce > member_address_is_nonnull()") That one caused a lot of odd failures by >

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 4, 2018 at 12:59 PM Greg KH wrote: > Here is another horrible work around that was needed to get clang to > stop generating invalid code, beaec533fc27 ("llist: clang: introduce > member_address_is_nonnull()") That one caused a lot of odd failures by > users, I wonder what else is

Re: [GIT PULL] x86/build changes for v4.17

El Wed, Apr 04, 2018 at 11:30:07AM +0200 Peter Zijlstra ha dit: > On Tue, Apr 03, 2018 at 11:06:58AM -0700, Matthias Kaehlcke wrote: > > > Yes, Chrome OS R67 (currently dev, soon beta) will ship a kernel built > > with Clang for multiple x86 Chromebooks. > > But there are still _known_

Re: [GIT PULL] x86/build changes for v4.17

El Wed, Apr 04, 2018 at 11:30:07AM +0200 Peter Zijlstra ha dit: > On Tue, Apr 03, 2018 at 11:06:58AM -0700, Matthias Kaehlcke wrote: > > > Yes, Chrome OS R67 (currently dev, soon beta) will ship a kernel built > > with Clang for multiple x86 Chromebooks. > > But there are still _known_

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 4, 2018 at 9:49 AM, Nick Desaulniers wrote: > > It's definitely something curious that I'll need to sit down and investigate > more. If there are other known instances, it would be good to let me know. Note that we explicitly use

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 4, 2018 at 9:49 AM, Nick Desaulniers wrote: > > It's definitely something curious that I'll need to sit down and investigate > more. If there are other known instances, it would be good to let me know. Note that we explicitly use "-fno-delete-null-pointer-checks" because we do *not*

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 04, 2018 at 04:53:52PM +, Nick Desaulniers wrote: > (re-sending as plain text) > > On Wed, Apr 4, 2018 at 2:38 AM Greg KH wrote: > > There are known-bugs with building a kernel with clang right now (I > > pointed one out a few days ago about NULL

Re: [GIT PULL] x86/build changes for v4.17

On Wed, Apr 04, 2018 at 04:53:52PM +, Nick Desaulniers wrote: > (re-sending as plain text) > > On Wed, Apr 4, 2018 at 2:38 AM Greg KH wrote: > > There are known-bugs with building a kernel with clang right now (I > > pointed one out a few days ago about NULL checks being deleted from the > >

Re: [GIT PULL] x86/build changes for v4.17

(re-sending as plain text) On Wed, Apr 4, 2018 at 2:38 AM Greg KH wrote: > There are known-bugs with building a kernel with clang right now (I > pointed one out a few days ago about NULL checks being deleted from the > clang output for no good reason, which really is

Re: [GIT PULL] x86/build changes for v4.17

(re-sending as plain text) On Wed, Apr 4, 2018 at 2:38 AM Greg KH wrote: > There are known-bugs with building a kernel with clang right now (I > pointed one out a few days ago about NULL checks being deleted from the > clang output for no good reason, which really is scary for obvious >

Re: [GIT PULL] x86/build changes for v4.17

On Tue, Apr 03, 2018 at 09:58:03PM +, Nick Desaulniers wrote: > Speaking more with our internal LLVM teams, there ARE a few different > approaches to implementing asm-goto in LLVM proposed, by external parties > to Google. These proposals haven't progressed to code review, so we've > asked

Re: [GIT PULL] x86/build changes for v4.17

On Tue, Apr 03, 2018 at 09:58:03PM +, Nick Desaulniers wrote: > Speaking more with our internal LLVM teams, there ARE a few different > approaches to implementing asm-goto in LLVM proposed, by external parties > to Google. These proposals haven't progressed to code review, so we've > asked

Re: [GIT PULL] x86/build changes for v4.17

On Tue, Apr 03, 2018 at 11:06:58AM -0700, Matthias Kaehlcke wrote: > Yes, Chrome OS R67 (currently dev, soon beta) will ship a kernel built > with Clang for multiple x86 Chromebooks. But there are still _known_ miscompilations > Given that it takes time for distributions to roll out new

Re: [GIT PULL] x86/build changes for v4.17

On Tue, Apr 03, 2018 at 11:06:58AM -0700, Matthias Kaehlcke wrote: > Yes, Chrome OS R67 (currently dev, soon beta) will ship a kernel built > with Clang for multiple x86 Chromebooks. But there are still _known_ miscompilations > Given that it takes time for distributions to roll out new

Re: [GIT PULL] x86/build changes for v4.17

On Tue, Apr 03, 2018 at 09:58:03PM +, Nick Desaulniers wrote: > Speaking more with our internal LLVM teams, there ARE a few different > approaches to implementing asm-goto in LLVM proposed, by external parties > to Google. These proposals haven't progressed to code review, so we've > asked

Re: [GIT PULL] x86/build changes for v4.17

On Tue, Apr 03, 2018 at 09:58:03PM +, Nick Desaulniers wrote: > Speaking more with our internal LLVM teams, there ARE a few different > approaches to implementing asm-goto in LLVM proposed, by external parties > to Google. These proposals haven't progressed to code review, so we've > asked

Re: [GIT PULL] x86/build changes for v4.17

Speaking more with our internal LLVM teams, there ARE a few different approaches to implementing asm-goto in LLVM proposed, by external parties to Google. These proposals haven't progressed to code review, so we've asked our LLVM teams to reignite these discussions with increased priority, if not

Re: [GIT PULL] x86/build changes for v4.17

Speaking more with our internal LLVM teams, there ARE a few different approaches to implementing asm-goto in LLVM proposed, by external parties to Google. These proposals haven't progressed to code review, so we've asked our LLVM teams to reignite these discussions with increased priority, if not

Re: [GIT PULL] x86/build changes for v4.17

El Tue, Apr 03, 2018 at 11:51:18AM +0200 Ingo Molnar ha dit: > > * Peter Zijlstra wrote: > > > On Mon, Apr 02, 2018 at 02:44:48PM -0700, Linus Torvalds wrote: > > > On Mon, Apr 2, 2018 at 2:50 AM, Ingo Molnar wrote: > > > > > > > > The biggest change is

Re: [GIT PULL] x86/build changes for v4.17

El Tue, Apr 03, 2018 at 11:51:18AM +0200 Ingo Molnar ha dit: > > * Peter Zijlstra wrote: > > > On Mon, Apr 02, 2018 at 02:44:48PM -0700, Linus Torvalds wrote: > > > On Mon, Apr 2, 2018 at 2:50 AM, Ingo Molnar wrote: > > > > > > > > The biggest change is the forcing of asm-goto support on x86,

Re: [GIT PULL] x86/build changes for v4.17

On Tue, Apr 3, 2018 at 1:59 AM, Peter Zijlstra wrote: > > It's not just spectre, I believe you yourself wanted to use asm-goto > somewhere in the x86 code: Absolutely. But I don't want to make it impossible for clang people to get their work done. Linus

Re: [GIT PULL] x86/build changes for v4.17

On Tue, Apr 3, 2018 at 1:59 AM, Peter Zijlstra wrote: > > It's not just spectre, I believe you yourself wanted to use asm-goto > somewhere in the x86 code: Absolutely. But I don't want to make it impossible for clang people to get their work done. Linus

Re: [GIT PULL] x86/build changes for v4.17

On Tue, Apr 03, 2018 at 11:51:18AM +0200, Ingo Molnar wrote: > If it's being relied on, or if there's actually something firmly planned, > which we could track, then I'd have no problem with reverting this change > and waiting one more kernel cycle or so. I don't see why the clang people can't go

Re: [GIT PULL] x86/build changes for v4.17

On Tue, Apr 03, 2018 at 11:51:18AM +0200, Ingo Molnar wrote: > If it's being relied on, or if there's actually something firmly planned, > which we could track, then I'd have no problem with reverting this change > and waiting one more kernel cycle or so. I don't see why the clang people can't go

Re: [GIT PULL] x86/build changes for v4.17

* Peter Zijlstra wrote: > On Mon, Apr 02, 2018 at 02:44:48PM -0700, Linus Torvalds wrote: > > On Mon, Apr 2, 2018 at 2:50 AM, Ingo Molnar wrote: > > > > > > The biggest change is the forcing of asm-goto support on x86, which > > > effectively > > >

Re: [GIT PULL] x86/build changes for v4.17

* Peter Zijlstra wrote: > On Mon, Apr 02, 2018 at 02:44:48PM -0700, Linus Torvalds wrote: > > On Mon, Apr 2, 2018 at 2:50 AM, Ingo Molnar wrote: > > > > > > The biggest change is the forcing of asm-goto support on x86, which > > > effectively > > > increases the GCC minimum supported version

Re: [GIT PULL] x86/build changes for v4.17

On Mon, Apr 02, 2018 at 02:44:48PM -0700, Linus Torvalds wrote: > On Mon, Apr 2, 2018 at 2:50 AM, Ingo Molnar wrote: > > > > The biggest change is the forcing of asm-goto support on x86, which > > effectively > > increases the GCC minimum supported version to gcc-4.5 (on x86).

Re: [GIT PULL] x86/build changes for v4.17

On Mon, Apr 02, 2018 at 02:44:48PM -0700, Linus Torvalds wrote: > On Mon, Apr 2, 2018 at 2:50 AM, Ingo Molnar wrote: > > > > The biggest change is the forcing of asm-goto support on x86, which > > effectively > > increases the GCC minimum supported version to gcc-4.5 (on x86). > > So my biggest

Re: [GIT PULL] x86/build changes for v4.17

El Mon, Apr 02, 2018 at 03:38:21PM -0700 Matthias Kaehlcke ha dit: > El Mon, Apr 02, 2018 at 02:44:48PM -0700 Linus Torvalds ha dit: > > > On Mon, Apr 2, 2018 at 2:50 AM, Ingo Molnar wrote: > > > > > > The biggest change is the forcing of asm-goto support on x86, which > > >

Re: [GIT PULL] x86/build changes for v4.17

El Mon, Apr 02, 2018 at 03:38:21PM -0700 Matthias Kaehlcke ha dit: > El Mon, Apr 02, 2018 at 02:44:48PM -0700 Linus Torvalds ha dit: > > > On Mon, Apr 2, 2018 at 2:50 AM, Ingo Molnar wrote: > > > > > > The biggest change is the forcing of asm-goto support on x86, which > > > effectively > > >

Re: [GIT PULL] x86/build changes for v4.17

El Mon, Apr 02, 2018 at 02:44:48PM -0700 Linus Torvalds ha dit: > On Mon, Apr 2, 2018 at 2:50 AM, Ingo Molnar wrote: > > > > The biggest change is the forcing of asm-goto support on x86, which > > effectively > > increases the GCC minimum supported version to gcc-4.5 (on x86).

Re: [GIT PULL] x86/build changes for v4.17

El Mon, Apr 02, 2018 at 02:44:48PM -0700 Linus Torvalds ha dit: > On Mon, Apr 2, 2018 at 2:50 AM, Ingo Molnar wrote: > > > > The biggest change is the forcing of asm-goto support on x86, which > > effectively > > increases the GCC minimum supported version to gcc-4.5 (on x86). > > So my

Re: [GIT PULL] x86/build changes for v4.17

On Mon, Apr 2, 2018 at 2:50 AM, Ingo Molnar wrote: > > The biggest change is the forcing of asm-goto support on x86, which > effectively > increases the GCC minimum supported version to gcc-4.5 (on x86). So my biggest worry isn't gcc-4.5 (anybody who hasn't updated deserves to

Re: [GIT PULL] x86/build changes for v4.17

On Mon, Apr 2, 2018 at 2:50 AM, Ingo Molnar wrote: > > The biggest change is the forcing of asm-goto support on x86, which > effectively > increases the GCC minimum supported version to gcc-4.5 (on x86). So my biggest worry isn't gcc-4.5 (anybody who hasn't updated deserves to be forced, or can