Re: [llvm-dev] [isocpp-parallel] Proposal for new memory_order_consume definition

No, you really don't need undefined behavior in the standard in order to enable bug-finding. The standard could've (and still could...) make signed integer overflow "implementation-defined" rather than "undefined". Compilers would thus be required to have *some documented meaning* for it (e.g.

Re: clang asm-goto support (Was Re: [PATCH v2] x86/retpoline: Add clang support)

I'd be definitely in favor having clang support asm goto. I wouldn't want to exclude having other conversations about how to more directly provide compiler features that the linux kernel could use, ALSO, but I do not think that conversation should block implementing asm-goto. IMO, inline asm is,

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 Thu, Apr 5, 2018 at 2:06 PM Linus Torvalds <torva...@linux-foundation.org> wrote: > On Thu, Apr 5, 2018 at 10:46 AM, James Y Knight <jykni...@google.com> wrote: > > > > GCC, however, mixes up the concept of a C "constant expression" with the >

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 3:08 AM Peter Zijlstra <pet...@infradead.org> wrote: > On Wed, Apr 04, 2018 at 10:21:05PM +0000, James Y Knight wrote: > > But allowing random pointer arithmetic, and pointer arithmetic wraparound, > > is still different than asserting that an obje

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 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: clang asm-goto support (Was Re: [PATCH v2] x86/retpoline: Add clang support)

I'd be definitely in favor having clang support asm goto. I wouldn't want to exclude having other conversations about how to more directly provide compiler features that the linux kernel could use, ALSO, but I do not think that conversation should block implementing asm-goto. IMO, inline asm is,

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

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

On Thu, Apr 5, 2018 at 3:08 AM Peter Zijlstra wrote: > On Wed, Apr 04, 2018 at 10:21:05PM +0000, 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

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 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 it

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: [PATCH] be2net: fix adapter->big_page_size miscaculation

On Mon, Jul 22, 2019 at 5:13 PM Qian Cai wrote: > > On Fri, 2019-07-19 at 17:47 -0400, Qian Cai wrote: > > On Thu, 2019-07-18 at 16:29 -0700, David Miller wrote: > > > From: Qian Cai > > > Date: Thu, 18 Jul 2019 19:26:47 -0400 > > > > > > > > > > > > > > > > On Jul 18, 2019, at 5:21 PM, Bill

Re: [llvm-dev] [isocpp-parallel] Proposal for new memory_order_consume definition

No, you really don't need undefined behavior in the standard in order to enable bug-finding. The standard could've (and still could...) make signed integer overflow "implementation-defined" rather than "undefined". Compilers would thus be required to have *some documented meaning* for it (e.g.