search for: cicular

...d of lots of heap-allocated data items, the compiler really cannot deduce anything. Other safe pointer use cases involve statically allocated data items whose contents are compile-time constants (thus avoiding the need for any sort of ordering) and sentinel data items (as in the Linux kernel's cicular linked lists) where there is no dereferencing. > Thus I see no way to both avoid adding syntax to functions that preserve > dependencies and continue to allow existing transformations that remove > dependencies we care about, e.g. due to equality comparisons. We can > hopefully ensure...

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 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