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 Wend
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 hav
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
&
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 co
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
> >
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 in
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 lurk
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, g
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.
wra
9 matches
Mail list logo
