[cfe-dev] [libcxx] Removing _LIBCPP_TRIVIAL_PAIR_COPY_CTOR option.

[Eric Fiselier via cfe-dev]

Thinking out loud: The Itanium spec specifies that the calling conventions
for non-trivial types only occurs when both the copy constructor and
destructor are trivial.

I have some upcoming changes to pair that depend on the copy constructor
being implicitly generated, which means killing those constructors.
Perhaps we could find another way to make either the destructor or
implicitly generated copy constructor non-trivial?

I wonder if giving pair a dummy base class with a non-trivial destructor
could serve as an alternative solution?

/Eric



On Tue, Jun 14, 2016 at 8:25 AM, Eric Fiselier <eric at efcs.ca> wrote:

> Well that's unfortunate :-( I'll revert it later today, and we can work on
> a solution from there.
>
> I would strongly encourage you to submit FreeBSD specific patches
> upstream. It's very helpful to see who (if anybody) is using specific ABI
> options or seemingly dead conditional compilation branches.
>
> /Eric
>
>
>
>
>
> On Tue, Jun 14, 2016 at 4:02 AM, Dimitry Andric <dimitry at andric.com>
> wrote:
>
>> We still turn off, and have always turned off, the
>> _LIBCPP_TRIVIAL_PAIR_COPY_CTOR option in FreeBSD, since we are supposed to
>> be backwards compatible with previous versions of libc++ that we shipped;
>> see
>> https://svnweb.freebsd.org/base/head/contrib/libc++/include/__config?view=markup#l733
>>
>> If the option is completely removed, we will either have to supply two
>> versions of libc++, or bolt on some sort of backwards compatibility
>> versioned symbols.  Alternatively, we can add a local hack to put back the
>> non-trivial copy constructor, but that might lead to other headaches.
>>
>> David, do you have any good ideas for this?  I think your idea was to
>> burn all backwards compatibility bridges, but we can't really do that for
>> FreeBSD 11.0 at this point, so we would have to start backporting fixes
>> from trunk libc++, instead of importing it wholesale.  For FreeBSD 12.0 we
>> could ship only the new libc++, and provide the older libc++ as a
>> compatibility package.
>>
>> -Dimitry
>>
>> On 14 Jun 2016, at 03:44, Eric Fiselier via cfe-dev <
>> cfe-dev at lists.llvm.org> wrote:
>>
>> I have removed this option from in the libc++ in r272613.  I believe it
>> has no clients.
>> If anybody uses this option please contact me.
>>
>> This option was used to turn off std::pair's trivial copy constructor,
>> instead selecting an older non-trivial implementation.
>>
>> It was added in r194742, on November 14th 2013. At that time Apple
>> platforms used this option to turn off pairs trivial constructor. Two weeks
>> later, on November 26th 2013, the default value for Apple platforms was
>> removed in r195796.
>>
>> Defining `_LIBCPP_TRIVIAL_PAIR_COPY_CTOR` will now cause an explicit
>> error informing the client that the option has been removed. I will remove
>> this diagnostic after the 3.9 release.
>>
>> /Eric
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160614/cfa6b5cc/attachment.html>