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