Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1345185

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

From Markus Trippelsdorf <markus@trippelsdorf.de>
Newsgroups linux.kernel
Subject Re: [isocpp-parallel] Proposal for new memory_order_consume definition
Date 2016-02-28 09:30 +0100
Message-ID <r74TL-80Z-1@gated-at.bofh.it> (permalink)
References (2 earlier) <r4lR7-2q1-7@gated-at.bofh.it> <r6AsG-2v7-7@gated-at.bofh.it> <r6Qxs-6i3-19@gated-at.bofh.it> <r6Wjw-1MZ-15@gated-at.bofh.it> <r6Wjw-1MZ-13@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On 2016.02.27 at 15:10 -0800, Paul E. McKenney via llvm-dev wrote:
> On Sat, Feb 27, 2016 at 11:16:51AM -0800, Linus Torvalds wrote:
> > On Feb 27, 2016 09:06, "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> > wrote:
> > >
> > >
> > > But we do already have something very similar with signed integer
> > > overflow.  If the compiler can see a way to generate faster code that
> > > does not handle the overflow case, then the semantics suddenly change
> > > from twos-complement arithmetic to something very strange.  The standard
> > > does not specify all the ways that the implementation might deduce that
> > > faster code can be generated by ignoring the overflow case, it instead
> > > simply says that signed integer overflow invoked undefined behavior.
> > >
> > > And if that is a problem, you use unsigned integers instead of signed
> > > integers.
> > 
> > Actually, in the case of there Linux kernel we just tell the compiler to
> > not be an ass. We use
> > 
> >   -fno-strict-overflow
> 
> That is the one!
> 
> > or something. I forget the exact compiler flag needed for "the standard is
> > as broken piece of shit and made things undefined for very bad reasons".
> > 
> > See also there idiotic standard C alias rules. Same deal.
> 
> For which we use -fno-strict-aliasing.

Do not forget -fno-delete-null-pointer-checks. 

So the kernel obviously is already using its own C dialect, that is
pretty far from standard C.
All these options also have a negative impact on the performance of the
generated code.

-- 
Markus

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [isocpp-parallel] Proposal for new memory_order_consume  definition "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-27 18:10 +0100
  Re: [isocpp-parallel] Proposal for new memory_order_consume  definition "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-28 00:20 +0100
    Re: [isocpp-parallel] Proposal for new memory_order_consume  definition Markus Trippelsdorf <markus@trippelsdorf.de> - 2016-02-28 09:30 +0100
      Re: [isocpp-parallel] Proposal for new memory_order_consume definition Linus Torvalds <torvalds@linux-foundation.org> - 2016-02-28 17:20 +0100
        Re: [llvm-dev] [isocpp-parallel] Proposal for new memory_order_consume definition cbergstrom@pathscale.com - 2016-02-28 18:00 +0100
        Re: [isocpp-parallel] Proposal for new memory_order_consume  definition Michael Matz <matz@suse.de> - 2016-02-29 18:40 +0100
          Re: [isocpp-parallel] Proposal for new memory_order_consume definition Linus Torvalds <torvalds@linux-foundation.org> - 2016-02-29 19:00 +0100
        Re: [isocpp-parallel] Proposal for new memory_order_consume definition Lawrence Crowl <Lawrence@Crowl.org> - 2016-02-29 20:40 +0100
          Re: [llvm-dev] [isocpp-parallel] Proposal for new memory_order_consume  definition James Y Knight <jyknight@google.com> - 2016-02-29 22:20 +0100
        Re: [isocpp-parallel] Proposal for new memory_order_consume  definition Toon Moene <toon@moene.org> - 2016-02-29 22:40 +0100
  Re: [isocpp-parallel] Proposal for new memory_order_consume  definition Michael Matz <matz@suse.de> - 2016-02-29 19:20 +0100
    Re: [isocpp-parallel] Proposal for new memory_order_consume  definition "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-03-01 02:30 +0100

csiph-web