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

On Mon, Feb 29, 2016 at 07:17:55PM +0100, Michael Matz wrote: > Hi, > > On Sat, 27 Feb 2016, Paul E. McKenney 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

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: [isocpp-parallel] Proposal for new memory_order_consume definition

On 02/28/2016 05:13 PM, Linus Torvalds wrote: Yeah, let's just say that the original C designers were better at their job than a gaggle of standards people who were making bad crap up to make some Fortran-style programs go faster. The original C designers were defining a language that would

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

On 2/28/16, Linus Torvalds wrote: > The fact is, undefined compiler behavior is never a good idea. Not for > serious projects. Actually, undefined behavior is essential for serious projects, but not for the reasons mentioned. If the language has no undefined

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

Hi, On Sat, 27 Feb 2016, Paul E. McKenney 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

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

On Mon, Feb 29, 2016 at 9:37 AM, Michael Matz wrote: > >The important part is with induction variables controlling > loops: > > short i; for (i = start; i < end; i++) > vs. > unsigned short u; for (u = start; u < end; u++) > > For the former you're allowed to assume that the

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

Hi, On Sun, 28 Feb 2016, Linus Torvalds wrote: > > 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. > > They really don't. They do. > Have you ever

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

Mailing List; David Howells; Peter Zijlstra; Ramana Radhakrishnan; Luc Maranget; Andrew Morton; Paul McKenney; Ingo Molnar Subject: Re: [llvm-dev] [isocpp-parallel] Proposal for new memory_order_consume definition On Sun, Feb 28, 2016 at 12:27 AM, Markus Trippelsdorf <mar...@trippelsdorf

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

On Sun, Feb 28, 2016 at 12:27 AM, Markus Trippelsdorf wrote: >> > >> > -fno-strict-overflow >> >> -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

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

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" > > wrote: > > > > > > > > > But we do already have something very similar with signed

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

On Sat, Feb 27, 2016 at 11:16:51AM -0800, Linus Torvalds wrote: > On Feb 27, 2016 09:06, "Paul E. McKenney" > 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

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

February 18, 2016 4:58 AM > > > To: paral...@lists.isocpp.org; linux-ker...@vger.kernel.org; > > linux-a...@vger.kernel.org; gcc@gcc.gnu.org; llvm-...@lists.llvm.org > > > Reply To: paral...@lists.isocpp.org > > > Cc: pet...@infradead.org; j.algl...@ucl.ac.uk; will.dea...@arm.com

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

s.llvm.org >> > Reply To: paral...@lists.isocpp.org >> > Cc: pet...@infradead.org; j.algl...@ucl.ac.uk; will.dea...@arm.com; >> dhowe...@redhat.com; ramana.radhakrish...@arm.com; luc.maran...@inria.fr; >> a...@linux-foundation.org; peter.sew...@cl.cam.ac.uk; >>

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

pp.org > Cc: pet...@infradead.org; j.algl...@ucl.ac.uk; will.dea...@arm.com; > dhowe...@redhat.com; ramana.radhakrish...@arm.com; luc.maran...@inria.fr; > a...@linux-foundation.org; peter.sew...@cl.cam.ac.uk; > torva...@linux-foundation.org; mi...@kernel.org > Subject: [isocpp-

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

.fr; a...@linux-foundation.org; peter.sew...@cl.cam.ac.uk; torva...@linux-foundation.org; mi...@kernel.org Subject: [isocpp-parallel] Proposal for new memory_order_consume definition Hello! A proposal (quaintly identified as P0190R0) for a new memory_order_consume definition may be found here: http://w