MEMBER_TYPE and CV qualifiers

MEMBER_TYPE and CV qualifiers

[Nathan Sidwell]

I'm looking at holding the CV qualifiers of a member function on the MEMBER_TYPE
node itself, rather than only on the this pointer argument.

this brings up a design issue of what TYPE_MAIN_VARIANT should be of a cv
qualified member function.  Should it be itself (thereby breaking the invariant
that T_M_V is always unqualified), or should it be the cv unqualified member
function?  Our current behaviour is such that T_M_V of a member function is a
self reference.

Clearly cp_build_qualified_type should continue to reject cv qualifying a
MEMBER_TYPE.  We'd need a new cp_build_qualified_member_type to do that, so we
can correctly deal with the syntactic differences.

thoughts?

nathan
-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

Re: MEMBER_TYPE and CV qualifiers

[Mark Mitchell]

Nathan Sidwell wrote:
> I'm looking at holding the CV qualifiers of a member function on the MEMBER_TYPE
> node itself, rather than only on the this pointer argument.

I don't think that's a good idea.  The "const" on the member function 
really does apply to the type pointed to be the "this" pointer, and it 
doesn't have much significance beyond that.  (For example, the reason 
you can't call a non-const member function on a cost object is just that 
you can't pass a "T*" to a function expecting "T const*".)

I can see that -- purely for convenience or efficiency -- it might make 
sense to also maintain the cv-qualifiers on the FUNCTION_TYPE itself, 
but I'd want to see proof first, as that does mean that we'd have to 
keep the two copes in synch, which has historically been a source of bugs.

> this brings up a design issue of what TYPE_MAIN_VARIANT should be of a cv
> qualified member function.  Should it be itself (thereby breaking the invariant
> that T_M_V is always unqualified), or should it be the cv unqualified member
> function?  Our current behaviour is such that T_M_V of a member function is a
> self reference.

I think that's the right choice.  The function type is no more 
cv-qualified than any other function type; the only thing that's 
cv-qualified is the type pointed to by the first argument.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: MEMBER_TYPE and CV qualifiers

[Giovanni Bajo]

Mark Mitchell <mark@codesourcery.com> wrote:

> The function type is no more
> cv-qualified than any other function type; the only thing that's
> cv-qualified is the type pointed to by the first argument.

The standard does not agree with you though, see 9.3.1/3. In fact, what
happens is that we currently deduce the type wrong (PR 8271) because of the
fact that the METHOD_TYPE is not cv-qualified. So either we special-case
this, or we represent it correctly.

FWIW, Jason agreed that the right way to fix this problem is to put cv
qualification on METHOD_TYPE, rather than special-case hacks:

http://gcc.gnu.org/ml/gcc-patches/2004-07/msg00550.html
http://gcc.gnu.org/ml/gcc-patches/2004-07/msg00630.html
-- 
Giovanni Bajo

Re: MEMBER_TYPE and CV qualifiers

[Mark Mitchell]

Giovanni Bajo wrote:
> Mark Mitchell <mark@codesourcery.com> wrote:
> 
> 
>>The function type is no more
>>cv-qualified than any other function type; the only thing that's
>>cv-qualified is the type pointed to by the first argument.
> 
> 
> The standard does not agree with you though, see 9.3.1/3.

It does indeed say that.

I've already said that it might make sense to put the cv-qualifiers in 
both places, but I've also said that I think it's dangerous, because you 
have to keep the two places in synch, and that's always been risky.  You 
also have to deal with the fact that much of the compiler may assume 
function types are not cv-qualified.  Furthermore, you have to be 
careful of things like the fact that you cannot assign a 
pointer-to-nonconst-member-function to a 
pointer-to-const-member-function, even though, of course, you can assign 
a "T*" to a "const T*" if "T" is an object type.  So, there are still 
special cases.

Furthermore, 9.3.1/3 is at odds with 3.9.3/1, which says:

   Each type which is  a  cv-unqualified  complete  or
   incomplete  object  type  or  is void (_basic.types_) has three corre-
   sponding cv-qualified versions of its type: a const-qualified version,
   a  volatile-qualified version, and a const-volatile-qualified version.

Note that it explicitly leaves out function types.

Obviously, the most important thing is to get the right behavior. 
Following the standard in our internal representation is secondary -- 
but highly desirable.  In this case, my opinion is that it's a bad idea 
to put the cv-qualifiers on the FUNCTION_TYPE; I'd rather see the 
special cases.  And, maybe, cp_type_quals should be taught about this 
case -- we're already supposed to be using that in most places.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: MEMBER_TYPE and CV qualifiers

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| Furthermore, 9.3.1/3 is at odds with 3.9.3/1, which says:
| 
|    Each type which is  a  cv-unqualified  complete  or
|    incomplete  object  type  or  is void (_basic.types_) has three corre-
|    sponding cv-qualified versions of its type: a const-qualified version,
|    a  volatile-qualified version, and a const-volatile-qualified version.
| 
| Note that it explicitly leaves out function types.

Yes.  For some reasons (I have not gotten explanations for yet), the
specification of member functions seems to be very odd at different
places in the standard :-(

-- Gaby

Re: MEMBER_TYPE and CV qualifiers

[Jason Merrill]

I think that the underlying problem here, as with pointers to data members,
comes from using POINTER_TYPE in the first type.  Pointers to members are
not pointers, and so using POINTER_TYPE just causes confusion.

Jason

Re: MEMBER_TYPE and CV qualifiers

[Mark Mitchell]

Jason Merrill wrote:
> I think that the underlying problem here, as with pointers to data members,
> comes from using POINTER_TYPE in the first type.  Pointers to members are
> not pointers, and so using POINTER_TYPE just causes confusion.

I heartily agree.  PTRMEM_CST was a step in the right direction, on the 
object-representation side; we need a PTRMEM_TYPE on the type side as 
well.  Because we don't have a proper lowering phase, the difficulty is 
that we need to transmute PTRMEM_TYPE into OFFSET_TYPE/RECORD_TYPE at 
some point.

However, that's no excuse for forming a POINTER_TYPE pointing to a 
METHOD_TYPE or member FUNCTION_TYPE.  Such things should be replaced 
with the RECORD_TYPEs we presently use to represent pointers to member 
functions.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: MEMBER_TYPE and CV qualifiers

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| Jason Merrill wrote:
| > I think that the underlying problem here, as with pointers to data members,
| > comes from using POINTER_TYPE in the first type.  Pointers to members are
| > not pointers, and so using POINTER_TYPE just causes confusion.
| 
| I heartily agree.  PTRMEM_CST was a step in the right direction, on

Agreed.

| the object-representation side; we need a PTRMEM_TYPE on the type side
| as well.  Because we don't have a proper lowering phase, the
| difficulty is that we need to transmute PTRMEM_TYPE into
| OFFSET_TYPE/RECORD_TYPE at some point.
| 
| However, that's no excuse for forming a POINTER_TYPE pointing to a
| METHOD_TYPE or member FUNCTION_TYPE.  Such things should be replaced
| with the RECORD_TYPEs we presently use to represent pointers to member
| functions.

Hmm, using RECORD_TYPE for both classes and pointer to member
functions seem to me to be less desirable as say, using tree for just
about any data structure.  I would think as we gradually move toward 
representations closer to the standard specification we would represent
distinct notions by distinct data structures.  I recon that such
representation needs a lowering stage, but it looks like we're doing
that more or less already.  Do I miss something?

-- Gaby

Re: MEMBER_TYPE and CV qualifiers

[Mark Mitchell]

Gabriel Dos Reis wrote:

> | the object-representation side; we need a PTRMEM_TYPE on the type side
> | as well.  Because we don't have a proper lowering phase, the
> | difficulty is that we need to transmute PTRMEM_TYPE into
> | OFFSET_TYPE/RECORD_TYPE at some point.
> | 
> | However, that's no excuse for forming a POINTER_TYPE pointing to a
> | METHOD_TYPE or member FUNCTION_TYPE.  Such things should be replaced
> | with the RECORD_TYPEs we presently use to represent pointers to member
> | functions.
> 
> Hmm, using RECORD_TYPE for both classes and pointer to member
> functions seem to me to be less desirable as say, using tree for just
> about any data structure.  I would think as we gradually move toward 
> representations closer to the standard specification we would represent
> distinct notions by distinct data structures.  

Isn't that exactly what I just said above?

 > I recon that such
> representation needs a lowering stage, but it looks like we're doing
> that more or less already.  Do I miss something?

Yes -- we don't really have a lowering stage, unless you count 
transformation to GENERIC.  Doing proper lowering would means lots of 
changes throughout the front end.  For example, "(a.*b)()" gets turned 
into various manipulations of low-level as soon as it is processed.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: MEMBER_TYPE and CV qualifiers

[Gabriel Dos Reis]

Mark Mitchell <mark@codesourcery.com> writes:

| Gabriel Dos Reis wrote:
| 
| > | the object-representation side; we need a PTRMEM_TYPE on the type side
| > | as well.  Because we don't have a proper lowering phase, the
| > | difficulty is that we need to transmute PTRMEM_TYPE into
| > | OFFSET_TYPE/RECORD_TYPE at some point.
| > | | However, that's no excuse for forming a POINTER_TYPE pointing to
| > a
| > | METHOD_TYPE or member FUNCTION_TYPE.  Such things should be replaced
| > | with the RECORD_TYPEs we presently use to represent pointers to member
| > | functions.
| > Hmm, using RECORD_TYPE for both classes and pointer to member
| > functions seem to me to be less desirable as say, using tree for just
| > about any data structure.  I would think as we gradually move toward
| > representations closer to the standard specification we would
| > represent
| > distinct notions by distinct data structures.
| 
| Isn't that exactly what I just said above?

I did not understand it that way.  Thanks for the clarification.

| 
|  > I recon that such
| > representation needs a lowering stage, but it looks like we're doing
| > that more or less already.  Do I miss something?
| 
| Yes -- we don't really have a lowering stage, unless you count
| transformation to GENERIC.

Yes, I had transformation to GENERIC in mind.  Were you thinking of
having another stage in addition of transformation to GENERIC?  What
would be its distinctive characeteristics?

-- Gaby

Re: MEMBER_TYPE and CV qualifiers

[Mark Mitchell]

Gabriel Dos Reis wrote:

> |  > I recon that such
> | > representation needs a lowering stage, but it looks like we're doing
> | > that more or less already.  Do I miss something?
> | 
> | Yes -- we don't really have a lowering stage, unless you count
> | transformation to GENERIC.
> 
> Yes, I had transformation to GENERIC in mind.  Were you thinking of
> having another stage in addition of transformation to GENERIC?  What
> would be its distinctive characeteristics?

I'm not sure whether or not a separate stage makes sense.  The point is 
that it's a lot of work, and we don't have it yet, so RECORD_TYPEs are 
going to continue be used to represent pointers-to-member functions for 
some time.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304