This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix PR c++/8171: Comparing pointer-to-member-functions of derived classes
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Volker Reichelt <v dot reichelt at netcologne dot de>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Sun, 11 Nov 2007 17:33:21 -0800
- Subject: Re: [PATCH] Fix PR c++/8171: Comparing pointer-to-member-functions of derived classes
- References: <tkrat.9fc3afb2b754eb46@netcologne.de>
Volker Reichelt wrote:
> :ADDPATCH C++:
>
>
> 2007-10-29 Volker Reichelt <v.reichelt@netcologne.de>
>
> PR c++/8171
> * typeck.c (comptypes) <METHOD_TYPE>: Do not fall-through to
> FUNCTION_TYPE, but use a slightly modified version: Compare the
> class-pointers according to the parameter STRICT.
> (build_binary_op) <EQ_EXPR, NE_EXPR>: Allow derived classes when
> comparing ptr-to-member-functions. Strip pointer before calling
> comptypes. Add delta offset if necessary.
How do we get a METHOD_TYPE down into comptypes? Did we start with a
pointer-to-member function type, and then pull the METHOD_TYPE out of that?
Your patch is probably OK, but I'm always unhappy to see METHOD_TYPEs
moving around the front end because usually these come from
pointers-to-members, and it's much easier to see that we're following
the standard if we operate on those types directly by, for example,
using TYPE_PTRMEM_CLASS_TYPE. Would you kind walking me through how we
get here to the comptypes change? I'm not entirely convinced we even
need METHOD_TYPEs at all -- but that, of course, is a big change, not to
be done now.
Also, I'd be happier with the build_binary_op code if we did it more
obviously following the standard. In particular, call common_type
(passing in the two pointer-to-member types), convert both arguments to
that type, and then compare them using the existing code.
Thanks,
--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713