This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] add __is_final trait to fix libstdc++/51365
On Tue, Dec 13, 2011 at 12:02 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 13 December 2011 17:01, Paolo Carlini <pcarlini@gmail.com> wrote:
>> Hi,
>>>
>>> This patch seems pretty simple and safe. ?Are you (Gaby and Paolo) arguing that even so, it shouldn't go in?
>>
>> As far as I'm concerned, definetely not! I also think that it would be great if, for 4.7, Jon could handle the library issues with EBO by exploiting it.
>
> Yes, if this goes in for 4.7 I will definitely follow it with the
> library changes to make use of it.
>
>> I only meant to say that something seems to me more fundamentally wrong at the design level about 'final' vs EBO, my hope is that for 4.8 we'll have a longer term stable solution based on a ISO Committee position.
>
> In one of the earlier bug report comments I proposed a
> __gnu_cxx::is_final<T> library trait to expose the __is_final(T)
> intrinsic for users, but decided against it precisely because I don't
> know how the committee will want to deal with the issue longer term.
>
> So the proposed patch just adds the __is_final intrinsic for use
> internally by the library, to allow library changes so the test cases
> in the bug report will pass. ?If preferred I won't even add __is_final
> to the extend.texi docs, to leave it as an undocumented extension that
> we could more easily remove (or deprecate) later if necessary.
Leaving __is_final undocumented is probably a good compromise.