erichkeane added a comment. In D129572#3646004 <https://reviews.llvm.org/D129572#3646004>, @nickdesaulniers wrote:
> In D129572#3645934 <https://reviews.llvm.org/D129572#3645934>, @erichkeane > wrote: > >> Our typical rule is to keep the 1st one I think, and reject the 2nd. > > But then the _codegen_ will differ from GCC. And we _want_ clang to be a > drop in replacement, so differing in behavior there is unacceptable. Right, I get that, which is why I said we need a different diagnostic than is 'typical' attribute merging. > 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). 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
