[Bug c++/13316] New: g++ does not follow mangling ABI for pointer to qualified member function

[Bug c++/13316] New: g++ does not follow mangling ABI for pointer to qualified member function

[ian at airs dot com]

g++ does not follow the rules described in the mangling ABI.  The mangling ABI
can be found at http://www.codesourcery.com/cxx-abi/abi.html#mangling.  The
problem is when using a pointer to a qualified member function, as in `int
(G::*) const'.  g++ does not treat the qualified function type as a substitution
candidate, as is required by the ABI.

The mangling ABI says that whenever the grammar uses <substitution>, that is a
substitution candidate (with some restrictions which are not relevant here). 
The grammar includes these productions:
    <type> ::= <substitution>
    <pointer-to-member-type> ::= M <type> <type>
This clearly suggests that the second <type> in <pointer-to-member-type> is a
substitution candidate.

However, g++ does not work that way.  Only the base type of the second <type> is
a substitution candidate.  If the second <type> is CV-qualified, the fully
qualified type is not a substitution candidate.

The ABI specifies that any CV-qualifiers on the second <type> are qualifiers for
the member function which is being pointed to.  So the second <type> is slightly
unusual.  But the ABI does not say that those CV-qualifiers are not themselves a
substitution candidate as is indicated by the grammar.

In the code in cp/mangle.c, see write_function_type().  For a
pointer-to-member-function, it writes out the CV qualifiers for the first
parameter to the function type, and it passes the function type to
write_bare_function_type(), but it never calls add_substitution() for the
qualified type.  This is understandable, since it does not have the correct type
to pass to add_substitution().  But to me it looks like a violation of the
mangling ABI.

Here is a test case:

class G { int g; }; class H { int h; };
template<class t> class what { int w1; };
template<class t> class what2 { int w2; };
void r(int (G::*)(), int (G::*)() const, G, int (H::*)(), int (G::*)(),
       what<G const>, what2<G const>, int (G::*)() const) {}

The mangled name of the function r is
    _Z1rM1GFivEMS_KFivES_M1HFivES1_4whatIKS_E5what2IS8_ES3_
which demangles into
    r(int (G::*)(), int (G::*)() const, G, int (H::*)(), int (G::*)(), what<G
const>, what2<G const>, int (G::*)() const)

Breaking this down, we get (substitution candidates are labelled with
SUB and the substitution index):

_Z                   (prefix)
 1r                  (name 'r')
 M                   (pointer to member)
  1G                 (name 'G') (SUB 0)
  F                  (function)
   i                 (int--return type)
   v                 (void--no parameters)
  E                  (end function) (fn is SUB 1) (ptr-to-mem is SUB 2)
 M                   (pointer to member)
  S_                 (substitution 0 == name 'G')
  K                  (const)
   FivE              (function as above) (fn is SUB 3) (p-to-m is SUB 4) ***
 S_                  (substitution 0 == name 'G')
 M1HFivE             (pointer to member as above)
                     ('H' is SUB 5) (fn is SUB 6) (p-to-m is SUB 7)
 S1_                 (substitution 2 == first ptr-to-mem above)
 4what               (name 'what') (SUB 8)
  I                  (template arguments follow)
   K                 (const)
    S_               (substitution 0 == name 'G') (SUB 9)
  E                  (end template arguments)
 5what2              (name 'what2') (SUB 10)
  I                  (template arguments follow)
   S8_               (substitution 9 == 'G const')
  E                  (end template arguments)
 S3_                 (substitution 4 == second ptr-to-mem above)

So, if you followed all that, look closely at the line with ***. There you see
that the function FivE is a substitution candidate, and the full pointer to
member MS_KFivE is a substitution candidate. However, by the reading of the
grammar, the qualified type KFivE should also be a substitution candidate. 
However, it is not.  If it were, the rest of the name would be mangled
incorrectly, because the references to substitution 4 and 9 would refer to the
incorrect types.

One way to fix this would be to change g++ to follow the mangling ABI correctly.

Another way to fix this would be to change the mangling ABI itself.  I think the
ABI fix would be simple; just change <pointer-to-member-type> to be this:
    <pointer-to-member-type> ::= M <type> <CV-qualifers> <type>
That would clarify that the <CV-qualifiers> do not form a substitution candidate
with the second <type>.

Either way, I think this is a moderately serious issue which should be
addressed.  The point of a mangling ABI is to permit interoperability.  When a
compiler does not follow the ABI, interoperability is lost.  Then there is
little point to having an ABI at all.

-- 
           Summary: g++ does not follow mangling ABI for pointer to
                    qualified member function
           Product: gcc
           Version: 3.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: ian at airs dot com
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13316

[Bug c++/13316] [ABI] g++ does not follow mangling ABI for pointer to qualified member function

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2003-12-05 23:44 -------
ABI issue raising severity.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |critical
            Summary|g++ does not follow mangling|[ABI] g++ does not follow
                   |ABI for pointer to qualified|mangling ABI for pointer to
                   |member function             |qualified member function
   Target Milestone|---                         |3.4


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13316

[Bug c++/13316] g++ does not follow mangling ABI for pointer to qualified member function

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |ABI
            Summary|[ABI] g++ does not follow   |g++ does not follow mangling
                   |mangling ABI for pointer to |ABI for pointer to qualified
                   |qualified member function   |member function


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13316

[Bug c++/13316] g++ does not follow mangling ABI for pointer to qualified member function

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13316

[Bug c++/13316] g++ does not follow mangling ABI for pointer to qualified member function

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|wrong-code                  |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13316

[Bug c++/13316] g++ does not follow mangling ABI for pointer to qualified member function

[dberlin at gcc dot gnu dot org]

------- Additional Comments From dberlin at gcc dot gnu dot org  2004-01-11 21:19 -------
ICC 6, 7, 7.1, and 8.0 produce
00000000 T _Z1rM1GFivEMS_KFivES_M1HFivES1_4whatIKS_E5what2IS8_ES3_


IE the same as gcc.


Thus, if we changed gcc to be "correct", we'd actually *break* compatibility with at least one other 
compiler.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13316

[Bug c++/13316] g++ does not follow mangling ABI for pointer to qualified member function

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-01-11 22:32 -------
Ian,

I agree with your reading of the ABI. Let's pretend for a moment we want to fix 
this one: I made a patch which makes GCC emits this:

_Z1rM1GFivEMS_KS0_S_M1HFivES1_4whatIKS_E5what2IS8_ES3_

It's still not 100% perfect because there is a "FivE" occurrence which is not 
substitued by S0_, but it looks better. The output of the demangler is:

r(int (G::*)(), int ()() const G::*, G, int (H::*)(), int (G::*)(), what<G 
const>, what2<G const>, int ()() const G::*)

which looks wrong. It seems that not even the demangler is ready to handle 
substitutions in that context.

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13316

[Bug c++/13316] g++ does not follow mangling ABI for pointer to qualified member function

[giovannibajo at libero dot it]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |giovannibajo at libero dot
                   |                            |it


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13316

[Bug c++/13316] g++ does not follow mangling ABI for pointer to qualified member function

[ian at airs dot com]

------- Additional Comments From ian at airs dot com  2004-01-11 22:50 -------
Subject: Re:  g++ does not follow mangling ABI for pointer to qualified member function

"dberlin at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

> ICC 6, 7, 7.1, and 8.0 produce
> 00000000 T _Z1rM1GFivEMS_KFivES_M1HFivES1_4whatIKS_E5what2IS8_ES3_
> 
> 
> IE the same as gcc.
> 
> 
> Thus, if we changed gcc to be "correct", we'd actually *break* compatibility with at least one other 
> compiler.

That's good to hear.  Personally, I think that changing the ABI is a
better option than changing the compiler.

Ian


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13316

[Bug c++/13316] g++ does not follow mangling ABI for pointer to qualified member function

[ian at wasabisystems dot com]

------- Additional Comments From ian at wasabisystems dot com  2004-01-11 22:57 -------
Subject: Re:  g++ does not follow mangling ABI for pointer to qualified member function

"giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes:

> I agree with your reading of the ABI. Let's pretend for a moment we want to fix 
> this one: I made a patch which makes GCC emits this:
> 
> _Z1rM1GFivEMS_KS0_S_M1HFivES1_4whatIKS_E5what2IS8_ES3_
> 
> It's still not 100% perfect because there is a "FivE" occurrence which is not 
> substitued by S0_, but it looks better. The output of the demangler is:
> 
> r(int (G::*)(), int ()() const G::*, G, int (H::*)(), int (G::*)(), what<G 
> const>, what2<G const>, int ()() const G::*)
> 
> which looks wrong. It seems that not even the demangler is ready to handle 
> substitutions in that context.

Yes, that is inevitable.  The demangler and the compiler have to agree
on the substitution algorithm.  I know of two demanglers, and both of
them follow the algorithm used by gcc.  The demangler has no way to
figure out the substitution algorithm on the fly.

This means that, if gcc is changed, the demanglers will require a user
option to demangle older names correctly.

In the libiberty demangler I wrote this comment:

  /* The ABI specifies that any type can be a substitution source, and
     that M is followed by two types, and that when a CV-qualified
     type is seen both the base type and the CV-qualified types are
     substitution sources.  The ABI also specifies that for a pointer
     to a CV-qualified member function, the qualifiers are attached to
     the second type.  Given the grammar, a plain reading of the ABI
     suggests that both the CV-qualified member function and the
     non-qualified member function are substitution sources.  However,
     g++ does not work that way.  g++ treats only the CV-qualified
     member function as a substitution source.  FIXME.  So to work
     with g++, we need to pull off the CV-qualifiers here, in order to
     avoid calling add_substitution() in cplus_demangle_type().  */

In the libstdc++ demangler, Carlo wrote this:

		// It is unclear why g++ doesn't add a substitution for
		// "<Q2>F<R><B>E" as it should I think.

Ian


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13316

[Bug c++/13316] g++ does not follow mangling ABI for pointer to qualified member function

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-01-11 23:19 -------
Subject: Re:  g++ does not follow mangling ABI for pointer to qualified member function

ian at wasabisystems dot com wrote:

> In the libiberty demangler I wrote this comment:
>
>   /* The ABI specifies that any type can be a substitution source, and
>      that M is followed by two types, and that when a CV-qualified
>      type is seen both the base type and the CV-qualified types are
>      substitution sources.  The ABI also specifies that for a pointer
>      to a CV-qualified member function, the qualifiers are attached to
>      the second type.  Given the grammar, a plain reading of the ABI
>      suggests that both the CV-qualified member function and the
>      non-qualified member function are substitution sources.  However,
>      g++ does not work that way.  g++ treats only the CV-qualified
>      member function as a substitution source.  FIXME.  So to work
>      with g++, we need to pull off the CV-qualifiers here, in order to
>      avoid calling add_substitution() in cplus_demangle_type().  */

Alas, there is another, more subtle issue.

Mangling of: void (G::*)(void)   ->   M1GFvvE

Now, FvvE is the function type "void ()". Here, there is no problem with the
CV-qualifier, so even allowing the bug you noted, GCC should still create 3
substitution entries:

- one for the base type (1G)
- one for the member function (FvvE)
- one for the whole pointer to member (M1FGvvE).

What happens is that the substitution entry for the member function (FvvE) is
created in a way that it's never matched (bug!). So, if there is a "void
(H::*)(void)" to mangle later, it will be mangled as "M1HGvvE" instead of
"M1HS#_".  Also, it won't even match the plain function type, as in A<void ()>
(again FvvE). You can notice this bug in your analysys, here:

 M1HFivE             (pointer to member as above)
                     ('H' is SUB 5) (fn is SUB 6) (p-to-m is SUB 7)

fn should really re-use SUB1, but it doesn't.

This happens because the substitution in mangle.c works by storing the trees of
the types. The tree stored for a member function is a METHOD_TYPE which keeps
tracks of its base type, so it will not match with any METHOD_TYPE of other
classes. I tried to lower it to a FUNCTION_TYPE with the same signature (which
is what we are really trying to encode here), but you need to cv-qualify it to
not lose information, and our type compare machinery does not expect
cv-qualified function types (I think because of DR295, which is PR 10807, but I
have not investigated yet). Of course it can be done somehow, but I'm still
thinking of the best way of doing it.

This is even more delicate, because we are *creating* a substitution entry, but
not *using* it. I don't think you can modify the ABI document to match this,
and fixing this breaks ABI for sure.

Giovanni Bajo




-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13316

[Bug c++/13316] g++ does not follow mangling ABI for pointer to qualified member function

[ian at wasabisystems dot com]

------- Additional Comments From ian at wasabisystems dot com  2004-01-12 00:24 -------
Subject: Re:  g++ does not follow mangling ABI for pointer to qualified member function

This issue is indeed subtle.  The ABI specifies that ``the type of a
non-static member function is considered to be different, for the
purposes of substitution, from the type of a namespace-scope or static
member function whose type appears similar.''  The ABI also specifies
that ``all substitutions are for entities that would appear in a
symbol table.''

What you are saying is that g++ currently does not apply a
substitution when there is a match of the function signatures of
non-static member functions in different classes.  Is the function
signature of a non-static member function an ``entity that would
appear in a symbol table?''  I think it could be argued either way.
The ABI is certainly rather vague in its description of substitution,
since substitution is described using loosely defined terms like
symbol tables and types, rather than, say, in terms of literal
strings.

I don't know what the intent of the ABI is here.  I think the ABI
could be changed to match the current behaviour of g++ by adding
something like ``the type of non-static member functions in different
classes are considered to be different for the purposes of
substitution.''

Or g++ could be changed to match what I agree is the most plausible
reading of the ABI.  Now would be the time to do it, since g++ is
switching to abi-version=2 for 3.4.0 anyhow.

Ian


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13316

[Bug c++/13316] g++ does not follow mangling ABI for pointer to qualified member function

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-01-12 01:18 -------
Yes, I agree. I think the original intent of the ABI committee was to FORBID 
the additional substition. They don't want a METHOD_TYPE to be lowered to a 
FUNCTION_TYPE, in other words.

Nathan, do you have a position on both the issues in this PR? Should we ask to 
the Itanium ABI committee? It would be great to do something before GCC 3.4.0 
comes out.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nathan at gcc dot gnu dot
                   |                            |org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13316

[Bug c++/13316] g++ does not follow mangling ABI for pointer to qualified member function

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-02-20 08:51 -------
The intent of the ABI is that two member function types should be considered
identical for substitution purposes only if they have the same argument types,
same return types, save cv-qualification, and are members are of the same class.

That's not clearly expressed.

The ABI does clearly express that namespace-scope function types are considered
different from member function types.

Therefore, EDG and G++ have implemented the ABI correctly.

HP's compiler differs, but it is incorrect.  (It does not even distinguish
between the namespace-scope function type and the member function type.)

I will post a message to the ABI list to update the ABI specification.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13316

[Bug c++/13316] g++ does not follow mangling ABI for pointer to qualified member function

[ian at wasabisystems dot com]

------- Additional Comments From ian at wasabisystems dot com  2004-02-23 18:51 -------
Subject: Re:  g++ does not follow mangling ABI for pointer to qualified member function

"mmitchel at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:

> The intent of the ABI is that two member function types should be considered
> identical for substitution purposes only if they have the same argument types,
> same return types, save cv-qualification, and are members are of the same class.

Note that merely expressing that correctly will not fix this bug.

This bug is about the numbering of substitution candidates.  You are
describing an issue about when substitution candidates may be used.
That is an important issue, and it is Giovanni is talking about in his
comment in this PR.  But it is not what I am talking about in this PR.

In my example in the initial bug report, the issue is not that there
is no match for the KFivE substitution candidate.  The issue is that
KFivE substitution candidate is not being counted as a valid
substitution candidate, although the grammar clearly requires it.

You can fix this by changing the mangling ABI as I suggest, to change
the definition of <pointer-to-member-type>.  You can't fix it by
adding text to the ABI about when member function types are considered
identical for substitution purposes.

I will leave this PR closed as you assert that g++ is following the
ABI, and you are much closer to the ABI than I am.  But please do
correct the ABI to count substitution candidates correctly.

Ian


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13316