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 c
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
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 ma
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 behavior, then from the compiler's vi
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 to
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 loop will termina
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 s
ernel
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
wrote:
>>
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 C.
> All these options a
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 integer
> > > overflow. If the
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
> > does not handle the overf
l E. McKenney
> > > Sent: Thursday, 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.
ckBerry portable Babbage Device
>> > Original Message
>> > From: Paul E. McKenney
>> > Sent: Thursday, 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-...@lis
.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;
> torva...@linux-foundation.org; mi...@kernel.org
> Subject: [is
a.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:
htt
15 matches
Mail list logo
