similar to: Proposal for new memory_order_consume definition

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 it can be (1) applied > to all relevant pointer-like objects and (2) used in C as well

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 inserting a fence at the call site. Dependency-based ordering would be preserved in either case. But I think we're moving away from that

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 suggestion to the compiler that it should > preserve dependencies instead of inserting a fence

On Sun, Feb 28, 2016 at 12:27 AM, Markus Trippelsdorf <markus at trippelsdorf.de> 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 also have a negative

On Feb 27, 2016 09:06, "Paul E. McKenney" <paulmck at 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

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 at linux.vnet.ibm.com> > > wrote: > > > > > > > > > But we do already have something very similar with signed integer > > > overflow. If the

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 seen code that cared about signed integer overflow? > > Yeah,

On 2/28/16, Linus Torvalds <torvalds at linux-foundation.org> 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 view, there is no such thing as a bad program. All

On Sat, Feb 27, 2016 at 11:16:51AM -0800, Linus Torvalds wrote: > On Feb 27, 2016 09:06, "Paul E. McKenney" <paulmck at 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

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 something very strange. The standard > does not specify all the ways that the

Hi Sanitizer Runtime Developers, We recently ran into a problem building clang because some of the definitions in sanitizer_common conflicted with system definitions and later another system header was trying to use the system definition: .../usr/include/libkern/OSAtomicDeprecated.h:756:17: error: reference to 'memory_order_relaxed' is ambiguous __theAmount, memory_order_relaxed) +

> On Jul 1, 2016, at 12:10 PM, Dmitry Vyukov <dvyukov at google.com> wrote: > > On Fri, Jul 1, 2016 at 8:53 PM, Anna Zaks <ganna at apple.com> wrote: >> Hi Sanitizer Runtime Developers, >> >> We recently ran into a problem building clang because some of the >> definitions in sanitizer_common conflicted with system definitions and later >>

Hello, I was wondering what is the semantic of the carries_dependency attribute. On https://clang.llvm.org/docs/AttributeReference.html#carries-dependency it says some suspicious things to me (but I am probably interpreting that wrong, sorry about that): > The carries_dependency attribute specifies dependency propagation into > and out of functions. > Where can it be placed? (on

According to the IMAP spec if I do a search for "TO isocpp.org" it should find all the messages whose To: field contains the string "isocpp.org", but dovecot is returning me an empty list. However, a search for "TO tm at isocpp.org" produces a long list of messages. This behavior is present if I *even load* the lucene fts plugin. Note that lucene isn't in use

Hello, fencing enthusiasts! *TL;DR:* We'd like to propose an addition to the LLVM memory model requiring non-temporal accesses be surrounded by non-temporal load barriers and non-temporal store barriers, and we'd like to add such orderings to the fence IR opcode. We are open to different approaches, hence this email instead of a patch. *Who's "we"?* Philip Reames brought

On Sat, Sep 26, 2015 at 8:43 PM, Mehdi Amini <mehdi.amini at apple.com> wrote: > Hi Rail, > > You can unsubscribe here: > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > Note that the list is “subscriber only”, which means that future email you > will send to the list will have to be approved manually by a moderator. > Also you’ll receive answer to your

On Fri, Apr 18, 2014 at 11:13 AM, Dmitry Vyukov <dvyukov at google.com> wrote: > Hi, > > This is long thread, so I will combine several comments into single email. > > > >> - 8-bit per-thread counters, dumping into central counters on overflow. > >The overflow will happen very quickly with 8bit counter. > > Yes, but it reduces contention by 256x (a thread

On Fri, Jul 27, 2012 at 2:02 AM, Richard Smith <richard at metafoo.co.uk>wrote: > On Thu, Jul 26, 2012 at 4:24 PM, Jim Grosbach <grosbach at apple.com> wrote: > >> >> On Jul 26, 2012, at 4:07 PM, Chris Lattner <clattner at apple.com> wrote: >> >> > <dropping llvm-commits> >> > >> > On Jul 2, 2012, at 9:59 AM, Alexander

Ping. On Fri, Jul 27, 2012 at 3:42 AM, Alexander Kornienko <alexfh at google.com>wrote: > On Fri, Jul 27, 2012 at 2:02 AM, Richard Smith <richard at metafoo.co.uk>wrote: > >> On Thu, Jul 26, 2012 at 4:24 PM, Jim Grosbach <grosbach at apple.com> wrote: >> >>> >>> On Jul 26, 2012, at 4:07 PM, Chris Lattner <clattner at apple.com> wrote:

On Tue, Apr 17, 2012 at 9:16 AM, Renato Golin <rengolin at systemcall.org> wrote: > With FP precision, you might be able to use different instructions or > ignore specific traps on more relaxed models, and the back-end can > only know that if you kept the metadata until the end. > > I appreciate the cost of strict metadata semantics to the IR, but I > think we're at a