linux-kernel - Re: [isocpp-parallel] Proposal for new memory_order

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 28 Feb 2016 09:27:02 +0100
From:	Markus Trippelsdorf <markus@...ppelsdorf.de>
To:	paulmck@...ux.vnet.ibm.com
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-arch@...r.kernel.org, gcc@....gnu.org,
	parallel@...ts.isocpp.org, llvm-dev@...ts.llvm.org,
	will.deacon@....com, linux-kernel@...r.kernel.org,
	dhowells@...hat.com, peterz@...radead.org,
	Ramana.Radhakrishnan@....com, Luc Maranget <luc.maranget@...ia.fr>,
	akpm@...ux-foundation.org, Jade Alglave <j.alglave@....ac.uk>,
	mingo@...nel.org
Subject: 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" <paulmck@...ux.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