On 16 Jan 2019, at 20:03, Richard Smith wrote: > On Wed, 16 Jan 2019 at 16:20, John McCall via cfe-commits < > cfe-commits@lists.llvm.org> wrote: > >> On 16 Jan 2019, at 18:32, Richard Smith wrote: >> >>> On Wed, 16 Jan 2019 at 09:10, John McCall via cfe-commits < >>> cfe-commits@lists.llvm.org> wrote: >>> >>>> On 16 Jan 2019, at 9:13, Aaron Ballman wrote: >>>> >>>>> On Wed, Jan 16, 2019 at 1:57 AM Akira Hatanaka <ahatan...@apple.com> >>>>> wrote: >>>>>> >>>>>> Yes, the behavior of the compiler doesn’t match what’s explained >>>>>> in the documentation anymore. >>>>>> >>>>>> Please take a look at the attached patch, which updates the >>>>>> documentation. >>>>> >>>>> Patch mostly LGTM, but I did have one wording suggestion. >>>>> >>>>>> diff --git a/include/clang/Basic/AttrDocs.td >>>>>> b/include/clang/Basic/AttrDocs.td >>>>>> index 5773a92c9c..ca3cfcf9b2 100644 >>>>>> --- a/include/clang/Basic/AttrDocs.td >>>>>> +++ b/include/clang/Basic/AttrDocs.td >>>>>> @@ -2478,15 +2478,20 @@ def TrivialABIDocs : Documentation { >>>>>> let Category = DocCatVariable; >>>>>> let Content = [{ >>>>>> The ``trivial_abi`` attribute can be applied to a C++ class, struct, >>>>>> or union. >>>>>> -It instructs the compiler to pass and return the type using the C >>>>>> ABI for the >>>>>> +``trivial_abi`` has the following effects: >>>>>> + >>>>>> +- It instructs the compiler to pass and return the type using the C >>>>>> ABI for the >>>>>> underlying type when the type would otherwise be considered >>>>>> non-trivial for the >>>>>> purpose of calls. >>>>>> -A class annotated with `trivial_abi` can have non-trivial >>>>>> destructors or copy/move constructors without automatically becoming >>>>>> non-trivial for the purposes of calls. For example: >>>>>> +- It makes the destructor and copy and move constructors of the >>>>>> class trivial >>>>>> +that would otherwise be considered non-trivial under the C++ ABI >>>>>> rules. >>>>> >>>>> How about: It makes the destructor, copy constructors, and move >>>>> constructors of the class trivial even if they would otherwise be >>>>> non-trivial under the C++ ABI rules. >>>> >>>> Let's not say that it makes them trivial, because it doesn't. It causes >>>> their immediate non-triviality to be ignored for the purposes of >>>> deciding >>>> whether the type can be passed in registers. >>>> >>> >>> Given the attribute now forces the type to be passed in registers, I >> think >>> it'd be more to the point to say that it makes the triviality of those >>> special members be ignored when deciding whether to pass a type with a >>> subobject of this type in registers. >> >> Wait, it forces it to be passed in registers? I thought the design >> was that it didn't override the non-trivial-abi-ness of subobjects; >> see all the discussion of trivially_relocatable. >> > > The attribute is ill-formed if applied to a class that has a subobject that > can't be passed in registers (or that has a vptr). And then as a weird > special case we don't instantiate the attribute when instantiating a class > if it would be ill-formed (well, we instantiate it and then remove it > again, but the effect is the same). > > The commit at the start of this email chain switches us from the "just > override the trivialness for the purposes of the ABI" model to /also/ > forcing the type to be passed in registers (the type would otherwise not be > passed in registers in some corner cases, such as if all its copy/move > special members are deleted).
I see. Alright, I accept your wording, then. John. _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits