Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1345185
| From | Markus Trippelsdorf <markus@trippelsdorf.de> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [isocpp-parallel] Proposal for new memory_order_consume definition |
| Date | 2016-02-28 09:30 +0100 |
| Message-ID | <r74TL-80Z-1@gated-at.bofh.it> (permalink) |
| References | (2 earlier) <r4lR7-2q1-7@gated-at.bofh.it> <r6AsG-2v7-7@gated-at.bofh.it> <r6Qxs-6i3-19@gated-at.bofh.it> <r6Wjw-1MZ-15@gated-at.bofh.it> <r6Wjw-1MZ-13@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [isocpp-parallel] Proposal for new memory_order_consume definition "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-27 18:10 +0100
Re: [isocpp-parallel] Proposal for new memory_order_consume definition "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-02-28 00:20 +0100
Re: [isocpp-parallel] Proposal for new memory_order_consume definition Markus Trippelsdorf <markus@trippelsdorf.de> - 2016-02-28 09:30 +0100
Re: [isocpp-parallel] Proposal for new memory_order_consume definition Linus Torvalds <torvalds@linux-foundation.org> - 2016-02-28 17:20 +0100
Re: [llvm-dev] [isocpp-parallel] Proposal for new memory_order_consume definition cbergstrom@pathscale.com - 2016-02-28 18:00 +0100
Re: [isocpp-parallel] Proposal for new memory_order_consume definition Michael Matz <matz@suse.de> - 2016-02-29 18:40 +0100
Re: [isocpp-parallel] Proposal for new memory_order_consume definition Linus Torvalds <torvalds@linux-foundation.org> - 2016-02-29 19:00 +0100
Re: [isocpp-parallel] Proposal for new memory_order_consume definition Lawrence Crowl <Lawrence@Crowl.org> - 2016-02-29 20:40 +0100
Re: [llvm-dev] [isocpp-parallel] Proposal for new memory_order_consume definition James Y Knight <jyknight@google.com> - 2016-02-29 22:20 +0100
Re: [isocpp-parallel] Proposal for new memory_order_consume definition Toon Moene <toon@moene.org> - 2016-02-29 22:40 +0100
Re: [isocpp-parallel] Proposal for new memory_order_consume definition Michael Matz <matz@suse.de> - 2016-02-29 19:20 +0100
Re: [isocpp-parallel] Proposal for new memory_order_consume definition "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> - 2016-03-01 02:30 +0100
csiph-web