All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Trippelsdorf via llvm-dev <llvm-dev@lists.llvm.org>
To: paulmck@linux.vnet.ibm.com
Cc: linux-arch@vger.kernel.org, gcc@gcc.gnu.org,
	parallel@lists.isocpp.org, llvm-dev@lists.llvm.org,
	will.deacon@arm.com, linux-kernel@vger.kernel.org,
	dhowells@redhat.com, peterz@infradead.org,
	Ramana.Radhakrishnan@arm.com,
	Luc Maranget <luc.maranget@inria.fr>,
	akpm@linux-foundation.org, Jade Alglave <j.alglave@ucl.ac.uk>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	mingo@kernel.org
Subject: Re: [isocpp-parallel] Proposal for new memory_order_consume definition
Date: Sun, 28 Feb 2016 09:27:02 +0100	[thread overview]
Message-ID: <20160228082702.GA300@x4> (raw)
In-Reply-To: <20160227231033.GW3522@linux.vnet.ibm.com>

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
_______________________________________________
LLVM Developers mailing list
llvm-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

WARNING: multiple messages have this Message-ID (diff)
From: Markus Trippelsdorf <markus@trippelsdorf.de>
To: paulmck@linux.vnet.ibm.com
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	linux-arch@vger.kernel.org, gcc@gcc.gnu.org,
	parallel@lists.isocpp.org, llvm-dev@lists.llvm.org,
	will.deacon@arm.com, linux-kernel@vger.kernel.org,
	dhowells@redhat.com, peterz@infradead.org,
	Ramana.Radhakrishnan@arm.com,
	Luc Maranget <luc.maranget@inria.fr>,
	akpm@linux-foundation.org, Jade Alglave <j.alglave@ucl.ac.uk>,
	mingo@kernel.org
Subject: Re: [isocpp-parallel] Proposal for new memory_order_consume definition
Date: Sun, 28 Feb 2016 09:27:02 +0100	[thread overview]
Message-ID: <20160228082702.GA300@x4> (raw)
Message-ID: <20160228082702.-7-wHG-AW9RCnpfrSRYUAufpNJD7K8KAGtkwyZFYSds@z> (raw)
In-Reply-To: <20160227231033.GW3522@linux.vnet.ibm.com>

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

  reply	other threads:[~2016-02-28  8:27 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-18  1:10 Proposal for new memory_order_consume definition Paul E. McKenney
2016-02-20  2:15 ` [isocpp-parallel] " Tony V E
2016-02-20  2:15   ` Tony V E
2016-02-20 19:53   ` Paul E. McKenney
2016-02-26  0:46     ` Hans Boehm via llvm-dev
2016-02-26 23:56       ` Lawrence Crowl
2016-02-27 17:06       ` Paul E. McKenney
2016-02-27 19:16         ` Linus Torvalds via llvm-dev
2016-02-27 23:10           ` Paul E. McKenney via llvm-dev
2016-02-27 23:10             ` Paul E. McKenney
2016-02-28  8:27             ` Markus Trippelsdorf via llvm-dev [this message]
2016-02-28  8:27               ` Markus Trippelsdorf
2016-02-28 16:13               ` Linus Torvalds
2016-02-28 16:50                 ` via llvm-dev
2016-02-28 16:50                   ` [llvm-dev] " cbergstrom
2016-02-29 17:37                 ` Michael Matz
2016-02-29 17:57                   ` Linus Torvalds via llvm-dev
2016-02-29 17:57                     ` Linus Torvalds
2016-02-29 19:38                 ` Lawrence Crowl
2016-02-29 21:10                   ` James Y Knight via llvm-dev
2016-02-29 21:12                   ` James Y Knight via llvm-dev
2016-02-29 21:12                     ` [llvm-dev] " James Y Knight
2016-02-29 20:45                 ` Toon Moene
2016-02-29 18:17         ` Michael Matz
2016-03-01  1:28           ` Paul E. McKenney via llvm-dev
2016-03-01  1:28             ` Paul E. McKenney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160228082702.GA300@x4 \
    --to=llvm-dev@lists.llvm.org \
    --cc=Ramana.Radhakrishnan@arm.com \
    --cc=akpm@linux-foundation.org \
    --cc=dhowells@redhat.com \
    --cc=gcc@gcc.gnu.org \
    --cc=j.alglave@ucl.ac.uk \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luc.maranget@inria.fr \
    --cc=markus@trippelsdorf.de \
    --cc=mingo@kernel.org \
    --cc=parallel@lists.isocpp.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=peterz@infradead.org \
    --cc=torvalds@linux-foundation.org \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.