aaron.ballman added a comment. In D129572#3646074 <https://reviews.llvm.org/D129572#3646074>, @MaskRay wrote:
> In D129572#3646044 <https://reviews.llvm.org/D129572#3646044>, @erichkeane > wrote: > >> In D129572#3646004 <https://reviews.llvm.org/D129572#3646004>, >> @nickdesaulniers wrote: >> >>> https://godbolt.org/z/rf16T83Kj >>> >>> IMO, the standards bodies focusing on standardizing attributes should >>> clarify the semantics of attribute merging, _then_ compiler vendors should >>> fix their compilers. >> >> They HAVE FWIW, by not creating attributes that have a 'merge' problem(yet). >> They end up being able to be completely additive (with the exception of the >> 'reason' ones like nodiscard/deprecated, at which point the standards decide >> that is implementation defined IIRC). > > In case of a conflict, picking the first does not appear to be universal in > GCC attributes. I haven't made a thorough survey, > but `visibility` picks the first and `patchable_function_entry` picks the > second. Someone can ask what should be the rule and which attribute behavior > should be considered a bug. Correct, there are examples of vendor attributes which want to resolve in both directions when merging. I don't envision the standard specifying the merging behavior because I think that's going to need to be on a per-attribute basis and so I would imagine it would remain implementation defined. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D129572/new/ https://reviews.llvm.org/D129572 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
