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
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.
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
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
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
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
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
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
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
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
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
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
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;
>>
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-
.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
15 matches
Mail list logo