search for: carries_dependency

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

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 > as C++.  ;-) > > If an implementation must support it, then it is not an annotation but a keyword. So no [[]]  I would be good with that approach...

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

...an be quite difficult to carry out on unannotated code. In addition, it seems likely that annotations can enable much better diagnostics. P0190R0 therefore recommends this approach. o 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 as C++. ;-) o If memory_order_consume dependency ordering can be used in unannotated code, how best to define the situations where the compiler can determine the ex...

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