On Wed, Dec 12, 2018 at 09:17:01AM +0200, Ville Voutilainen wrote:
> On Tue, 11 Dec 2018 at 20:58, Marek Polacek wrote:
> >
> > On Thu, Sep 13, 2018 at 08:58:34PM +0300, Ville Voutilainen wrote:
> > > On 13 September 2018 at 20:41, Jason Merrill wrote:
> > > >> Okay. Do you think we should have a
On Tue, 11 Dec 2018 at 20:58, Marek Polacek wrote:
>
> On Thu, Sep 13, 2018 at 08:58:34PM +0300, Ville Voutilainen wrote:
> > On 13 September 2018 at 20:41, Jason Merrill wrote:
> > >> Okay. Do you think we should have an sfk_kind for non-canonical
> > >> copy/move operations? That would presumab
On Thu, Sep 13, 2018 at 08:58:34PM +0300, Ville Voutilainen wrote:
> On 13 September 2018 at 20:41, Jason Merrill wrote:
> >> Okay. Do you think we should have an sfk_kind for non-canonical
> >> copy/move operations? That would presumably make it a tad more
> >> straightforward to go from
> >> fn
On 13 September 2018 at 20:41, Jason Merrill wrote:
>> Okay. Do you think we should have an sfk_kind for non-canonical
>> copy/move operations? That would presumably make it a tad more
>> straightforward to go from
>> fndecl to whatever class bits, instead of what's currently there, where we
>>
On Thu, Sep 13, 2018 at 12:42 PM, Ville Voutilainen
wrote:
> On 13 September 2018 at 19:36, Jason Merrill wrote:
>> On Thu, Sep 13, 2018 at 9:41 AM, Ville Voutilainen
>> wrote:
>>> On 13 September 2018 at 13:41, Ville Voutilainen
>>> wrote:
> How does this work when:
> unsigned has_co
On 13 September 2018 at 19:36, Jason Merrill wrote:
> On Thu, Sep 13, 2018 at 9:41 AM, Ville Voutilainen
> wrote:
>> On 13 September 2018 at 13:41, Ville Voutilainen
>> wrote:
How does this work when:
unsigned has_complex_copy_ctor : 1;
>>> It doesn't. I need more bits. Luckily, we h
On Thu, Sep 13, 2018 at 9:41 AM, Ville Voutilainen
wrote:
> On 13 September 2018 at 13:41, Ville Voutilainen
> wrote:
>>> How does this work when:
>>> unsigned has_complex_copy_ctor : 1;
>> It doesn't. I need more bits. Luckily, we have some available.
>
> Here. I suppose this could theoretical
Hi!
On Thu, Sep 13, 2018 at 04:41:25PM +0300, Ville Voutilainen wrote:
> --- a/gcc/cp/cp-tree.h
> +++ b/gcc/cp/cp-tree.h
> @@ -2046,7 +2046,7 @@ struct GTY(()) lang_type {
>unsigned lazy_copy_assign : 1;
>unsigned lazy_destructor : 1;
>unsigned has_const_copy_ctor : 1;
> - unsigned ha
On 13 September 2018 at 13:41, Ville Voutilainen
wrote:
>> How does this work when:
>> unsigned has_complex_copy_ctor : 1;
> It doesn't. I need more bits. Luckily, we have some available.
Here. I suppose this could theoretically be done in some later stage
of class completion,
but that would pr
On 13 September 2018 at 13:03, Jakub Jelinek wrote:
> On Thu, Sep 13, 2018 at 12:56:59PM +0300, Ville Voutilainen wrote:
>> + else if (!TYPE_HAS_CONST_COPY_CTOR (class_type))
>> + TYPE_HAS_COMPLEX_COPY_CTOR (class_type) += 2;
>> + }
>> + else if (ctor > 1 && TYP
On Thu, Sep 13, 2018 at 12:56:59PM +0300, Ville Voutilainen wrote:
> + else if (!TYPE_HAS_CONST_COPY_CTOR (class_type))
> + TYPE_HAS_COMPLEX_COPY_CTOR (class_type) += 2;
> + }
> + else if (ctor > 1 && TYPE_HAS_COMPLEX_COPY_CTOR (class_type) == 2)
> + TYPE
On 13 September 2018 at 12:08, Ville Voutilainen
wrote:
> Curses.. the resetting is over-eager; we might have a non-trivial base
> or a member, and in those cases we shouldn't
> reset the triviality when we see a non-user-provided const copy. I
> think I'll hack around this with a non 0/1 value. :
On 13 September 2018 at 10:38, Ville Voutilainen
wrote:
> Howdy! The tricky details of copy constructors, part 76.
> In this approach, I let the const-copy "dominate"; that is, if
> a const-copy was found, a non-const-copy will not turn off triviality
> of the copy constructor, and a const-copy wi
Howdy! The tricky details of copy constructors, part 76.
In this approach, I let the const-copy "dominate"; that is, if
a const-copy was found, a non-const-copy will not turn off triviality
of the copy constructor, and a const-copy will reinstate triviality
of the copy constructor even if a non-con
14 matches
Mail list logo
