[PATCH] D129572: [X86] initial -mfunction-return=thunk-extern support

Tue Jul 12 13:13:58 PDT 2022

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