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
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
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
On Thu, Feb 25, 2016 at 04:46:50PM -0800, Hans Boehm wrote:
> If carries_dependency affects semantics, then it should not be an attribute.
I am not picky about the form of the marking.
> The original design, or at least my understanding of it, was that it not
> have semantics; it was only a sugge
On 2/25/16, Hans Boehm wrote:
> If carries_dependency affects semantics, then it should not be an
> attribute.
>
> The original design, or at least my understanding of it, was that it not
> have semantics; it was only a suggestion to the compiler that it should
> preserve dependencies instead of i
On Fri, Feb 19, 2016 at 09:15:16PM -0500, Tony V E wrote:
> There's at least one easy answer in there:
>
> > If implementations must support annotation, what form should that
> annotation take? P0190R0 recommends the [[carries_dependency]]
> attribute, but I am not picky as long as i
There's at least one easy answer in there:
> If implementations must support annotation, what form should that
annotation take? P0190R0 recommends the [[carries_dependency]]
attribute, but I am not picky as long as it can be (1) applied
to all relevant pointer-like object
13 matches
Mail list logo
