This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C++ PATCH] PR c++/87051
- From: Marek Polacek <polacek at redhat dot com>
- To: Ville Voutilainen <ville dot voutilainen at gmail dot com>
- Cc: Jason Merrill <jason at redhat dot com>, Jakub Jelinek <jakub at redhat dot com>, gcc-patches List <gcc-patches at gcc dot gnu dot org>, Nathan Sidwell <nathan at acm dot org>
- Date: Tue, 11 Dec 2018 13:58:34 -0500
- Subject: Re: [C++ PATCH] PR c++/87051
- References: <CAFk2RUYfaVBdJD-AJw1G0BjMas1m=R3mD0_x6B56WObPccY6mQ@mail.gmail.com> <CAFk2RUbM25vDOPXzM9_3MOuRmFGXg=P=M+P4VbVX+Fi8=uRv8Q@mail.gmail.com> <CAFk2RUYZ-t1f_OhK1BGcEaUp4UCD2R+pj7ph5kJSkVwak7R4jw@mail.gmail.com> <20180913100306.GN8250@tucnak> <CAFk2RUbvo2_JTp_boZzPhTWm3yY+RW6=3KPEq=AZ9=aRsmZ50g@mail.gmail.com> <CAFk2RUYrAYD+WbT4dZEQUbadQOi=F3ObTyMMOUb1pYaqj6NDVw@mail.gmail.com> <CADzB+2mJzmAf1pFkwcT22pOrW0rdVzDwv5VW5Dn11ctiwmrqDg@mail.gmail.com> <CAFk2RUZHNW_KYsJq2G2qkNz-oCWMEOsMmDEwHtu0+QgBqhFsvA@mail.gmail.com> <CADzB+2nHt3J-B5h1WLSm3qchPzJW1RTWV7_u1OubmUkH6XG4wQ@mail.gmail.com> <CAFk2RUZPHhDT1t+mu7y_Jh2pcuzDydup2ATP4RGfNXPFq8Cpcw@mail.gmail.com>
On Thu, Sep 13, 2018 at 08:58:34PM +0300, Ville Voutilainen wrote:
> On 13 September 2018 at 20:41, Jason Merrill <jason@redhat.com> 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 say "yeah I had a fndecl,
> >> now I turned it into an sfk_kind that says it's a copy constructor, but guess which one when you're
> >> deeming its triviality". ;)
> >
> > I suppose it would be possible to have a more detailed sfk_kind for
> > distinguishing between different signatures, but I'm inclined instead
> > to stop using sfk_kind in trivial_fn_p. Even if having an enumeration
> > is convenient for dispatch (or bitmapping), it doesn't need to be the
> > same enum.
>
> Yeah, the idea of using a different enum dawned on me straight after
> sending that email. ;)
> I'll give this approach a spin, more bits into the lang_type and a
> different mapping, that way we should indeed
> get correct answers for all cases.
Hi Ville, any updates?
Marek