[Bug c++/13294] New: namespace associations vs. specializations

[Bug c++/13294] New: namespace associations vs. specializations

[bkoz at gcc dot gnu dot org]

Implementation of namespace associations unfinished: namespace association
should keep specializations in the namespace where they are defined.

We went back and forth about this, and this is just a note to clarify the
implemenation status.

-benjamin

-----

#include <vector>

struct MyType { };

namespace std 
{
  template<>
  class vector<MyType>
  {
  public:
    vector();
  };

  vector<MyType>::vector() {  }
}

int main()
{
  std::vector<MyType> obj;
  return 0;
}

// Both should be in std::
//00000020 T _ZNSt6vectorI6MyTypeSaIS1_EEC1Ev

// (normal)
//00000020 T _ZN10__gnu_norm6vectorI6MyTypeSaIS1_EEC1Ev

// (debug) ie -D_GLIBCXX_DEBUG
// 00000020 T _ZN15__gnu_debug_def6vectorI6MyTypeSaIS1_EEC1Ev

-- 
           Summary: namespace associations vs. specializations
           Product: gcc
           Version: 3.4
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: bkoz at gcc dot gnu dot org
                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=13294

[Bug c++/13294] namespace associations vs. specializations

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2003-12-04 08:03 -------
Confirmed (this an issue which really should be resloved before 3.4 gets release).

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2003-12-04 08:03:30
               date|                            |
   Target Milestone|---                         |3.4


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

[Bug c++/13294] namespace associations vs. specializations

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2003-12-17 05:38 -------
Assigned to Jason, since he implemented __attribute__((strong)).

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |jason at redhat dot com
                   |dot org                     |
             Status|NEW                         |ASSIGNED


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

[Bug c++/13294] [3.4 Regression] namespace associations vs. specializations

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-01-14 03:36 -------
This is a regression, in name friendly for debuging you code.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|namespace associations vs.  |[3.4 Regression] namespace
                   |specializations             |associations vs.
                   |                            |specializations


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

[Bug c++/13294] [3.4/3.5 Regression] namespace associations vs. specializations

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-03-09 10:48 -------
Jason, just checking: any word on this one?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jason at redhat dot com


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

[Bug c++/13294] [3.4/3.5 Regression] namespace associations vs. specializations

[jason at redhat dot com]

------- Additional Comments From jason at redhat dot com  2004-03-25 22:12 -------
Subject: PATCH Re:  [3.4/3.5 Regression] namespace
 associations vs. specializations

This patch seems to implement the desired behavior, which IIRC was to use
the specialization context for specializations of namespace-scope class
templates, but use the template context in all other cases.  Testing now.

2004-03-25  Jason Merrill  <jason@redhat.com>

	PR c++/13294
	* pt.c (maybe_process_partial_specialization): Remember the
	context of a specialization.

*** pt.c.~1~	2004-03-25 15:27:22.000000000 -0500
--- pt.c	2004-03-25 17:03:32.000000000 -0500
*************** maybe_process_partial_specialization (tr
*** 733,739 ****
  	{
  	  tree tpl_ns = decl_namespace_context (CLASSTYPE_TI_TEMPLATE (type));
  	  if (is_associated_namespace (current_namespace, tpl_ns))
! 	    /* Same or super-using namespace.  */;
  	  else
  	    {
  	      pedwarn ("specializing `%#T' in different namespace", type);
--- 733,747 ----
  	{
  	  tree tpl_ns = decl_namespace_context (CLASSTYPE_TI_TEMPLATE (type));
  	  if (is_associated_namespace (current_namespace, tpl_ns))
! 	    /* Same or super-using namespace.  */
! 	    {
! 	      if (DECL_NAMESPACE_SCOPE_P (CLASSTYPE_TI_TEMPLATE (type)))
! 		/* If this is a specialization of a namespace-scope class
! 		   template, remember the context of the
! 		   specialization.  */
! 		TYPE_CONTEXT (type) = DECL_CONTEXT (TYPE_NAME (type))
! 		  = FROB_CONTEXT (current_namespace);
! 	    }
  	  else
  	    {
  	      pedwarn ("specializing `%#T' in different namespace", type);


-- 


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

Re: [Bug c++/13294] [3.4/3.5 Regression] namespace associations vs. specializations

[Gabriel Dos Reis]

"jason at redhat dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| This patch seems to implement the desired behavior, which IIRC was to use
| the specialization context for specializations of namespace-scope class
| templates, but use the template context in all other cases.  Testing now.

That looks to me to be the desired behaviour.  Benjamin?

-- gaby

[Bug c++/13294] [3.4/3.5 Regression] namespace associations vs. specializations

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2004-03-26 06:41 -------
Subject: Re:  [3.4/3.5 Regression] namespace associations vs. specializations

"jason at redhat dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| This patch seems to implement the desired behavior, which IIRC was to use
| the specialization context for specializations of namespace-scope class
| templates, but use the template context in all other cases.  Testing now.

That looks to me to be the desired behaviour.  Benjamin?

-- gaby


-- 


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

[Bug c++/13294] [3.4/3.5 Regression] namespace associations vs. specializations

[bkoz at gcc dot gnu dot org]

------- Additional Comments From bkoz at gcc dot gnu dot org  2004-03-26 17:22 -------

jason, this looks good to me too, thanks

-benjamin

-- 


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

[Bug c++/13294] [3.4/3.5 Regression] namespace associations vs. specializations

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-03-26 19:20 -------
Subject: Bug 13294

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	jason@gcc.gnu.org	2004-03-26 19:20:50

Modified files:
	gcc/cp         : ChangeLog pt.c 

Log message:
	PR c++/13294
	* pt.c (maybe_process_partial_specialization): Remember the
	context of a specialization.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4015&r2=1.4016
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.843&r2=1.844



-- 


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

[Bug c++/13294] [3.4 Regression] namespace associations vs. specializations

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-03-26 19:35 -------
Mark is this Okay for 3.4.0?

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mmitchel at gcc dot gnu dot
                   |                            |org
            Summary|[3.4/3.5 Regression]        |[3.4 Regression] namespace
                   |namespace associations vs.  |associations vs.
                   |specializations             |specializations


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

[Bug c++/13294] [3.4 Regression] namespace associations vs. specializations

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-03-30 17:58 -------
Yes, this is OK for 3.4.0.

-- 


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

[Bug c++/13294] [3.4 Regression] namespace associations vs. specializations

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-03-31 02:10 -------
Subject: Bug 13294

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_4-branch
Changes by:	jason@gcc.gnu.org	2004-03-31 02:10:00

Modified files:
	gcc/cp         : ChangeLog pt.c 

Log message:
	PR c++/13294
	* pt.c (maybe_process_partial_specialization): Remember the
	context of a specialization.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3892.2.90&r2=1.3892.2.91
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.816.2.22&r2=1.816.2.23



-- 


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

[Bug c++/13294] [3.4 Regression] namespace associations vs. specializations

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-03-31 02:28 -------
Fixed.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


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

[Bug c++/13294] [3.4 Regression] namespace associations vs. specializations

[jason at gcc dot gnu dot org]

------- Additional Comments From jason at gcc dot gnu dot org  2004-04-05 23:20 -------
Unfortunately, my patch doesn't completely fix this bug.  This testcase, which
depends on the patch for 14500, shows the problem:

namespace A {
  template<class T> struct X { };
  template<class T> void f(X<T>&); // #1
}
 
namespace B {
  using namespace A __attribute__((strong));
 
  template<> struct X<int> { };
  template<> void f(X<int>&) { }   // #2
}
 
int main()
{
  B::X<int> x;
  B::f(x);                    // calls #1 instead of #2
}

The specialization of f is mangled as _ZN1B1fIiEEvRN1A1XIT_EE, which demangles
to void B::f<int>(A::X<int>&).  The specialization of X is being mangled using
the template context, rather than the specialization context as desired in this bug.

I think that this must be resolved before 3.4.0, since it affects the ABI.  I
will try to fix it tonight.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |critical
             Status|RESOLVED                    |REOPENED
           Priority|P2                          |P1
         Resolution|FIXED                       |


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

[Bug c++/13294] [3.4 Regression] namespace associations vs. specializations

[jason at gcc dot gnu dot org]

------- Additional Comments From jason at gcc dot gnu dot org  2004-04-06 04:38 -------
On second thought, I'm not sure this is really a problem.  It only occurs with
specializations of function templates, where the demangled form is the result of
substituting "int" into f(A::X<T>).  Opinions?

-- 


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

[Bug c++/13294] [3.4 Regression] namespace associations vs. specializations

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-04-06 09:01 -------
As the inventor of strong using, I'd say you get to pick what it means. :-)

However, it seems to me that the problem you point out is still problematic in
that it means that the mangling of the specialization of "f" differs depending
on the strongly-used namespace.  I'd think that we want the mangling to be
independent of that so that debug/optimized versions of the library get the same
mangled name.

I'm not going to hold up the first prerelease for this bug, but, since there is
going to be ABI impact, let's do try to get this fixed.

Or decide it's not a bug.

Thanks!

-- 


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

[Bug c++/13294] [3.4 Regression] namespace associations vs. specializations

[jason at redhat dot com]

------- Additional Comments From jason at redhat dot com  2004-04-07 17:58 -------
Subject: Re:  [3.4 Regression] namespace associations vs.
 specializations

On 6 Apr 2004 09:01:22 -0000, "mmitchel at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> wrote:

> However, it seems to me that the problem you point out is still problematic in
> that it means that the mangling of the specialization of "f" differs depending
> on the strongly-used namespace.  I'd think that we want the mangling to be
> independent of that so that debug/optimized versions of the library get the same
> mangled name.

Yes, after thinking about it some more I think we need to handle this case
the same as the other.

Unfortunately, the ABI mangling scheme doesn't really allow for this; a
function template instantiation/specialization is mangled using the
signature of the template and then the parameters; see
get_mostly_instantiated_function_type.  To properly reflect the scope of
the specialization under this scheme we would need to tweak the template
signature, pretending that this is a specialization of some other imaginary
template.  This is doable, but not attractive.

I don't think we want to change how specializations are mangled in general.

Another possibility would be to change our minds and go back to using the
template context in mangling.

My feeling is that the ugly option above is the best one, but I'm very
interested in other thoughts.

I should be able to have it implemented tomorrow if people agree.

Jason


-- 


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

[Bug c++/13294] [3.4 Regression] namespace associations vs. specializations

[mark at codesourcery dot com]

------- Additional Comments From mark at codesourcery dot com  2004-04-07 19:17 -------
Subject: Re:  [3.4 Regression] namespace associations vs. specializations

jason at redhat dot com wrote:

>------- Additional Comments From jason at redhat dot com  2004-04-07 17:58 -------
>Subject: Re:  [3.4 Regression] namespace associations vs.
> specializations
>
>On 6 Apr 2004 09:01:22 -0000, "mmitchel at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> wrote:
>
>  
>
>>However, it seems to me that the problem you point out is still problematic in
>>that it means that the mangling of the specialization of "f" differs depending
>>on the strongly-used namespace.  I'd think that we want the mangling to be
>>independent of that so that debug/optimized versions of the library get the same
>>mangled name.
>>    
>>
>
>Yes, after thinking about it some more I think we need to handle this case
>the same as the other.
>
>Unfortunately, the ABI mangling scheme doesn't really allow for this; a
>function template instantiation/specialization is mangled using the
>signature of the template and then the parameters; see
>get_mostly_instantiated_function_type.  To properly reflect the scope of
>the specialization under this scheme we would need to tweak the template
>signature, pretending that this is a specialization of some other imaginary
>template.  This is doable, but not attractive.
>
>I don't think we want to change how specializations are mangled in general.
>
>Another possibility would be to change our minds and go back to using the
>template context in mangling.
>
>My feeling is that the ugly option above is the best one, but I'm very
>interested in other thoughts.
>  
>
Changing the overall mangling of specializations is, I think, a complete 
non-starter; it would totally break conformance to the ABI.  I don't 
think we should consider that at all.

I agree that the ugly option is the one consistent with the intended 
semantics of strong using.  Hopefully there cannot be another template 
with the same name in the using namespace?

All GCC extensions are evil, even yours. :-) :-)

(I've vaguely wondered if the thing you're doing with strong using 
couldn't be accomplished with linker magic, but it would definitely be 
ugly and GNU-ld specific.)



-- 


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

[Bug c++/13294] [3.4 Regression] namespace associations vs. specializations

[bkoz at gcc dot gnu dot org]

------- Additional Comments From bkoz at gcc dot gnu dot org  2004-04-08 20:35 -------

Ahh. I see, now. You want

B::f<int>(B::X<int>&)

instead of the current

B::f<int>(A::X<int>&)

Yes, this would probably be the most consistent. So, I guess ugly it is...

-benjamin


-- 


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

[Bug c++/13294] [3.4 Regression] namespace associations vs. specializations

[bkoz at gcc dot gnu dot org]

------- Additional Comments From bkoz at gcc dot gnu dot org  2004-04-08 20:37 -------

Ok, whatever. I should have collected my thoughts on this.... I'll note that
with your patch the behavior is already correct, but the mangling is still
subject to improvement. What you are suggesting is getting both of these items,
right?

-benjamin

-- 


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

[Bug c++/13294] [3.4 Regression] namespace associations vs. specializations

[jason at redhat dot com]

------- Additional Comments From jason at redhat dot com  2004-04-08 20:43 -------
Subject: Re:  [3.4 Regression] namespace associations vs.
 specializations

On 8 Apr 2004 20:37:14 -0000, "bkoz at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> wrote:

> Ok, whatever. I should have collected my thoughts on this.... I'll note
> that with your patch the behavior is already correct, but the mangling is
> still subject to improvement. What you are suggesting is getting both of
> these items, right?

Yes.

Jason


-- 


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

[Bug c++/13294] [3.4 Regression] namespace associations vs. specializations

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2004-04-08 22:46 -------
Subject: Re:  [3.4 Regression] namespace associations vs. specializations

"jason at redhat dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| Subject: Re:  [3.4 Regression] namespace associations vs.
|  specializations
| 
| On 6 Apr 2004 09:01:22 -0000, "mmitchel at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> wrote:
| 
| > However, it seems to me that the problem you point out is still problematic in
| > that it means that the mangling of the specialization of "f" differs depending
| > on the strongly-used namespace.  I'd think that we want the mangling to be
| > independent of that so that debug/optimized versions of the library get the same
| > mangled name.
| 
| Yes, after thinking about it some more I think we need to handle this case
| the same as the other.
| 
| Unfortunately, the ABI mangling scheme doesn't really allow for this; a
| function template instantiation/specialization is mangled using the
| signature of the template and then the parameters; see
| get_mostly_instantiated_function_type.  To properly reflect the scope of
| the specialization under this scheme we would need to tweak the template
| signature, pretending that this is a specialization of some other imaginary
| template.  This is doable, but not attractive.
| 
| I don't think we want to change how specializations are mangled in general.
| 
| Another possibility would be to change our minds and go back to using the
| template context in mangling.
| 
| My feeling is that the ugly option above is the best one, but I'm very
| interested in other thoughts.


If by "ugly" you mean what you described in the second paragraph of
your message, then I agree it gives the expected semantics.

-- Gaby


-- 


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

[Bug c++/13294] [3.4 Regression] namespace associations vs. specializations

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2004-04-08 22:48 -------
Subject: Re:  [3.4 Regression] namespace associations vs. specializations

"mark at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| Subject: Re:  [3.4 Regression] namespace associations vs. specializations
| 
| jason at redhat dot com wrote:
| 
| >Subject: Re:  [3.4 Regression] namespace associations vs.
| > specializations
| >
| >On 6 Apr 2004 09:01:22 -0000, "mmitchel at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> wrote:
| >
| >  
| >
| >>However, it seems to me that the problem you point out is still problematic in
| >>that it means that the mangling of the specialization of "f" differs depending
| >>on the strongly-used namespace.  I'd think that we want the mangling to be
| >>independent of that so that debug/optimized versions of the library get the same
| >>mangled name.
| >>    
| >>
| >
| >Yes, after thinking about it some more I think we need to handle this case
| >the same as the other.
| >
| >Unfortunately, the ABI mangling scheme doesn't really allow for this; a
| >function template instantiation/specialization is mangled using the
| >signature of the template and then the parameters; see
| >get_mostly_instantiated_function_type.  To properly reflect the scope of
| >the specialization under this scheme we would need to tweak the template
| >signature, pretending that this is a specialization of some other imaginary
| >template.  This is doable, but not attractive.
| >
| >I don't think we want to change how specializations are mangled in general.
| >
| >Another possibility would be to change our minds and go back to using the
| >template context in mangling.
| >
| >My feeling is that the ugly option above is the best one, but I'm very
| >interested in other thoughts.
| >  
| >
| Changing the overall mangling of specializations is, I think, a complete 
| non-starter; it would totally break conformance to the ABI.  I don't 
| think we should consider that at all.
| 
| I agree that the ugly option is the one consistent with the intended 
| semantics of strong using.  Hopefully there cannot be another template 
| with the same name in the using namespace?

no, there should not be -- it should be a hard error.

| All GCC extensions are evil, even yours. :-) :-)

Bah :-)

| (I've vaguely wondered if the thing you're doing with strong using 
| couldn't be accomplished with linker magic, but it would definitely be 
| ugly and GNU-ld specific.)

that was tried before; it led us to the namespace association
proposal.

-- Gaby


-- 


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

[Bug c++/13294] [3.4 Regression] namespace associations vs. specializations

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2004-04-08 22:49 -------
Subject: Re:  [3.4 Regression] namespace associations vs. specializations

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

| Ahh. I see, now. You want
| 
| B::f<int>(B::X<int>&)
| 
| instead of the current
| 
| B::f<int>(A::X<int>&)
| 
| Yes, this would probably be the most consistent. So, I guess ugly it is...

Everybody is saying it is ugly, but I can't see why.
Can someone help me?

-- Gaby


-- 


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

[Bug c++/13294] [3.4 Regression] namespace associations vs. specializations

[bkoz at gcc dot gnu dot org]

------- Additional Comments From bkoz at gcc dot gnu dot org  2004-04-08 23:04 -------
> Everybody is saying it is ugly, but I can't see why.
> Can someone help me?

I don't think the proposed behavior or mangling is ugly (it's only different by
one letter), but instead that the implementation sketched by Jason might be ugly.

I think we are all on the same page at this point (== in agreement), even though
some of these messages have been confused.

-benjamin

-- 


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

[Bug c++/13294] [3.4 Regression] namespace associations vs. specializations

[jason at redhat dot com]

------- Additional Comments From jason at redhat dot com  2004-04-09 06:37 -------
Subject: Re:  [3.4 Regression] namespace associations vs.
 specializations

On 8 Apr 2004 23:04:38 -0000, "bkoz at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> wrote:

> I don't think the proposed behavior or mangling is ugly (it's only
> different by one letter), but instead that the implementation sketched by
> Jason might be ugly.

It's ugly because it requires us to pervert the ABI mangling scheme, which
leads me to wonder whether or not this is really what we want.  It comes
down to a question of whether a particular specialization is its own entity
or part of the template.  The mangling scheme assumes the latter; this
change moves more toward the former.  I wonder which will sound better to
the committee.

The question from a language perspective is whether or not a specialization
declared in two translation units is the same from an ODR perspective even
when it specializes templates from different strongly-used namespaces.

Jason


-- 


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

[Bug c++/13294] [3.4 Regression] namespace associations vs. specializations

[jason at redhat dot com]

------- Additional Comments From jason at redhat dot com  2004-04-13 18:36 -------
Subject: Re:  [3.4 Regression] namespace associations vs.
 specializations

Here is a patch which fixes more cases.  But this still isn't enough to
handle this testcase:

namespace A {
  template<class T> struct X { typedef T A; };
  template<class T> typename X<T>::A f(X<T>&); // #1
}

namespace B {
  using namespace A __attribute__((strong));

  template<> struct X<int> { typedef int A; };
  template<> int f(X<int>&) { }   // #2

  void f (X<int>&) {}
}

int main()
{
  B::X<int> x;
  B::f(x);
}

Doing better would mean intercepting the specialization much earlier.  At
this point, I'm feeling pretty strongly that this is not worth doing, and
that we should revert my earlier patch.

*** cp/pt.c.~1~	2004-04-12 16:03:23.000000000 -0400
--- cp/pt.c	2004-04-12 17:55:53.000000000 -0400
*************** tsubst_enum (tree tag, tree newtag, tree
*** 11439,11444 ****
--- 11454,11615 ----
      = DECL_SOURCE_LOCATION (TYPE_NAME (tag));
  }
  
+ static tree
+ make_spoof_type (tree type)
+ {
+   int is_main = (type == TYPE_MAIN_VARIANT (type));
+   type = copy_node (type);  
+   if (is_main)
+     {
+       TYPE_MAIN_VARIANT (type) = type;
+       TYPE_NAME (type) = copy_node (TYPE_NAME (type));
+     }
+   else
+     {
+       TYPE_MAIN_VARIANT (type) = make_spoof_type (TYPE_MAIN_VARIANT (type));
+       TYPE_NAME (type) = TYPE_NAME (TYPE_MAIN_VARIANT (type));
+     }
+ 
+   return type;
+ }
+ 
+ static tree fake_fn_type (tree, tree);
+ 
+ static tree
+ fake_arg_type (tree tmpl_type, tree spec_type)
+ {
+   tree type = tmpl_type;
+   tree sub;
+   int i;
+ 
+   ++processing_template_decl;
+   i = dependent_type_p (type);
+   --processing_template_decl;
+   if (!i)
+     return type;
+ 
+   switch (TREE_CODE (type))
+     {
+     case POINTER_TYPE:
+     case REFERENCE_TYPE:
+     case ARRAY_TYPE:
+       sub = fake_arg_type (TREE_TYPE (type), TREE_TYPE (spec_type));
+       if (sub != TREE_TYPE (type))
+ 	{
+ 	  type = copy_node (type);
+ 	  TREE_TYPE (type) = sub;
+ 	}
+       break;
+ 
+     case OFFSET_TYPE:
+       {
+ 	tree base = fake_arg_type (TYPE_OFFSET_BASETYPE (type),
+ 				   TYPE_OFFSET_BASETYPE (spec_type));
+ 	sub = fake_arg_type (TREE_TYPE (type), TREE_TYPE (spec_type));
+ 	if (sub != TREE_TYPE (type) || base != TYPE_OFFSET_BASETYPE (type))
+ 	  {
+ 	    type = copy_node (type);
+ 	    TREE_TYPE (type) = sub;
+ 	    TYPE_OFFSET_BASETYPE (type) = base;
+ 	  }
+       }
+       break;
+ 
+     case FUNCTION_TYPE:
+     case METHOD_TYPE:
+       type = fake_fn_type (tmpl_type, spec_type);
+       break;
+ 
+     case TYPENAME_TYPE:
+ #if 0
+       /* FIXME how do I derive the desired context from a resolved type?  */
+       sub = fake_arg_type (TYPE_CONTEXT (type), TYPE_CONTEXT (spec_type));
+       if (sub != TYPE_CONTEXT (type))
+ 	{
+ 	  type = copy_node (type);
+ 	  TYPE_CONTEXT (type) = sub;
+ 	}
+ #endif
+       break;
+ 
+     case RECORD_TYPE:
+       if (TYPE_PTRMEMFUNC_P (type))
+ 	{
+ 	  sub = fake_arg_type (TYPE_PTRMEMFUNC_FN_TYPE (type),
+ 			       TYPE_PTRMEMFUNC_FN_TYPE (spec_type));
+ 	  if (sub != TYPE_PTRMEMFUNC_FN_TYPE (type))
+ 	    type = build_ptrmemfunc_type (sub);
+ 	  break;
+ 	}
+       /* else FALLTHROUGH */
+     case UNION_TYPE:
+     case ENUMERAL_TYPE:
+       if (TYPE_CONTEXT (type) != TYPE_CONTEXT (spec_type))
+ 	{
+ 	  type = copy_node (type);
+ 	  TYPE_CONTEXT (type) = DECL_CONTEXT (TYPE_NAME (type))
+ 	    = TYPE_CONTEXT (spec_type);
+ 	}
+       break;
+ 
+     default:
+       break;
+     }
+ 
+   return type;
+ }
+ 
+ /* Subroutine of get_mostly_instantiated_function_type.  If any types
+    in TMPL_ARGS have
+ 
+    FIXME I don't think this will work yet for nested types */
+ 
+ static tree
+ fake_arg_types (tree tmpl_args, tree spec_args)
+ {
+   tree chain;
+   tree type;
+ 
+   if (tmpl_args == NULL_TREE)
+     return NULL_TREE;
+ 
+   chain = fake_arg_types (TREE_CHAIN (tmpl_args), TREE_CHAIN (spec_args));
+   type = fake_arg_type (TREE_VALUE (tmpl_args), TREE_VALUE (spec_args));
+   if (chain != TREE_CHAIN (tmpl_args) || type != TREE_TYPE (tmpl_args))
+     return tree_cons (NULL_TREE, type, chain);
+ 
+   return tmpl_args;
+ }
+ 
+ static tree
+ fake_fn_type (tree tmpl_type, tree spec_type)
+ {
+   tree type = tmpl_type;
+   tree tmpl_args = TYPE_ARG_TYPES (type);
+   tree args = fake_arg_types (tmpl_args, TYPE_ARG_TYPES (spec_type));
+   tree ret = fake_arg_type (TREE_TYPE (type), TREE_TYPE (spec_type));
+   tree tmpl_base, base;
+ 
+   if (TREE_CODE (type) == METHOD_TYPE)
+     {
+       tmpl_base = TYPE_METHOD_BASETYPE (type);
+       base = fake_arg_type (tmpl_base, TYPE_METHOD_BASETYPE (spec_type));
+     }
+   else
+     base = tmpl_base = NULL_TREE;
+ 
+   if (args != tmpl_args || ret != TREE_TYPE (type) || base != tmpl_base)
+     {
+       type = copy_node (type);
+       TYPE_ARG_TYPES (type) = args;
+       TREE_TYPE (type) = ret;
+       if (base)
+ 	TYPE_METHOD_BASETYPE (type) = base;
+     }
+ 
+   return type;
+ }
+ 
  /* DECL is a FUNCTION_DECL that is a template specialization.  Return
     its type -- but without substituting the innermost set of template
     arguments.  So, innermost set of template parameters will appear in
*************** get_mostly_instantiated_function_type (t
*** 11505,11511 ****
        pop_access_scope (decl);
      }
  
!   return fn_type;
  }
  
  /* Return truthvalue if we're processing a template different from
--- 11676,11682 ----
        pop_access_scope (decl);
      }
  
!   return fake_fn_type (fn_type, TREE_TYPE (decl));
  }
  
  /* Return truthvalue if we're processing a template different from


-- 


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

[Bug c++/13294] [3.4 Regression] namespace associations vs. specializations

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-04-13 22:12 -------
Jason, I agree with your assessment.

This is looking far too involved to be considering at this point.

Please revert your earlier patch, so that things are consistent, and then either
close or retarget this PR.

(It appears to me that this outcome means that standards-conforming programs do
not follow the C++ ABI in that specializations of types in "std" are mangled
incorrectly.  That's observable to user programs by using "typeid".  This is
presumably a bug in our library implementation, but one that's not easy to fix,
and hopefully not terribly important to anybody.)

Thank you for persevering with this issue; without having gone this far, we
probably would not have known what the issues were.

-- 


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

[Bug c++/13294] [3.4 Regression] namespace associations vs. specializations

[bkoz at redhat dot com]

------- Additional Comments From bkoz at redhat dot com  2004-04-14 04:08 -------
Subject: Re:  [3.4 Regression] namespace associations vs.
 specializations


>(It appears to me that this outcome means that standards-conforming programs do
>not follow the C++ ABI in that specializations of types in "std" are mangled
>incorrectly.  That's observable to user programs by using "typeid".  This is
>presumably a bug in our library implementation, but one that's not easy to fix,
>and hopefully not terribly important to anybody.)
>
>Thank you for persevering with this issue; without having gone this far, we
>probably would not have known what the issues were.

I'm wondering if we should punt on this stuff for 3.4.0, and revert to STL in namespace std.

-benjamin


-- 


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

[Bug c++/13294] [3.4 Regression] namespace associations vs. specializations

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-04-14 10:10 -------
(In reply to comment #29)

> I'm wondering if we should punt on this stuff for 3.4.0, and revert to STL 
> in namespace std.

You mean pulling the debug stuff from 3.4.0? Isn't that too much an invasive 
change right now? We are a tad late.

-- 


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

[Bug c++/13294] [3.4 Regression] namespace associations vs. specializations

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-04-14 12:55 -------
Did I hear someone say that gcc extensions are a double-edged sword? :-) 
 
W. 

-- 


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

[Bug c++/13294] [3.4 Regression] namespace associations vs. specializations

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2004-04-14 18:27 -------
Subject: Re:  [3.4 Regression] namespace associations vs. specializations

"bkoz at redhat dot com" <gcc-bugzilla@gcc.gnu.org> writes:

| Subject: Re:  [3.4 Regression] namespace associations vs.
|  specializations
| 
| 
| >(It appears to me that this outcome means that standards-conforming programs do
| >not follow the C++ ABI in that specializations of types in "std" are mangled
| >incorrectly.  That's observable to user programs by using "typeid".  This is
| >presumably a bug in our library implementation, but one that's not easy to fix,
| >and hopefully not terribly important to anybody.)
| >
| >Thank you for persevering with this issue; without having gone this far, we
| >probably would not have known what the issues were.
| 
| I'm wondering if we should punt on this stuff for 3.4.0, and revert
| to STL in namespace std. 

Ahem.  With Jason's patch (not the recent), how serious is the
remaining part of the problem?  (This is not a rhetorical question, I
just want to hear of a nother evaluation). 
Is the real problem the fact that the current mangling implementation
does nto take context into account?

-- Gaby


-- 


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

[Bug c++/13294] [3.4 Regression] namespace associations vs. specializations

[jason at redhat dot com]

------- Additional Comments From jason at redhat dot com  2004-04-14 19:27 -------
Subject: Re:  [3.4 Regression] namespace associations vs.
 specializations

On 14 Apr 2004 18:27:14 -0000, "gdr at integrable-solutions dot net" <gcc-bugzilla@gcc.gnu.org> wrote:

> Ahem.  With Jason's patch (not the recent), how serious is the
> remaining part of the problem?  (This is not a rhetorical question, I
> just want to hear of a nother evaluation). 
> Is the real problem the fact that the current mangling implementation
> does not take context into account?

No.  The real problem, as I see it now, is that we're trying to warp the
mangling implementation in order to make it easier to break code in subtle
and surprising ways, as you described in your message titled "ODR violation
made easy".  Which I regret not having responded to sooner.

  http://gcc.gnu.org/ml/libstdc++/2004-03/msg00016.html

I don't think supporting transparent interlinking of code compiled in
different modes is a good idea.  Requiring the debug and normal containers
to be ABI-compatible with one another would seem to restrict the checking
abilities of the debug containers quite a bit.  And if we don't require
that, any interlinking will cause horrible breakage.

The feature described in 13294 is intended to make this interlinking work
for specializations.  Given my skepticism about the usefulness of
interlinking in the first place, I don't think going out of our way to make
it work in more cases is appropriate.

Jason


-- 


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

[Bug c++/13294] [3.4 Regression] namespace associations vs. specializations

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-04-14 19:45 -------
Subject: Bug 13294

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-3_4-branch
Changes by:	jason@gcc.gnu.org	2004-04-14 19:45:17

Modified files:
	gcc/cp         : ChangeLog pt.c 

Log message:
	Revert:
	PR c++/13294
	* pt.c (maybe_process_partial_specialization): Remember the
	context of a specialization.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3892.2.97&r2=1.3892.2.98
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.816.2.23&r2=1.816.2.24



-- 


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

[Bug c++/13294] [3.4 Regression] namespace associations vs. specializations

[cvs-commit at gcc dot gnu dot org]

------- Additional Comments From cvs-commit at gcc dot gnu dot org  2004-04-14 19:46 -------
Subject: Bug 13294

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	jason@gcc.gnu.org	2004-04-14 19:46:36

Modified files:
	gcc/cp         : ChangeLog pt.c 

Log message:
	Revert:
	PR c++/13294
	* pt.c (maybe_process_partial_specialization): Remember the
	context of a specialization.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4032&r2=1.4033
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.847&r2=1.848



-- 


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

[Bug c++/13294] [3.4 Regression] namespace associations vs. specializations

[jason at gcc dot gnu dot org]

------- Additional Comments From jason at gcc dot gnu dot org  2004-04-14 19:47 -------
I no longer think that the requested behavior is desirable.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |WONTFIX


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

[Bug c++/13294] [3.4 Regression] namespace associations vs. specializations

[mark at codesourcery dot com]

------- Additional Comments From mark at codesourcery dot com  2004-04-16 18:34 -------
Subject: Re:  [3.4 Regression] namespace associations vs. specializations

bkoz at redhat dot com wrote:

>------- Additional Comments From bkoz at redhat dot com  2004-04-14 04:08 -------
>Subject: Re:  [3.4 Regression] namespace associations vs.
> specializations
>
>
>  
>
>>(It appears to me that this outcome means that standards-conforming programs do
>>not follow the C++ ABI in that specializations of types in "std" are mangled
>>incorrectly.  That's observable to user programs by using "typeid".  This is
>>presumably a bug in our library implementation, but one that's not easy to fix,
>>and hopefully not terribly important to anybody.)
>>
>>Thank you for persevering with this issue; without having gone this far, we
>>probably would not have known what the issues were.
>>    
>>
>
>I'm wondering if we should punt on this stuff for 3.4.0, and revert to STL in namespace std.
>
Do we know how to do that?



-- 


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

[Bug c++/13294] [3.4 Regression] namespace associations vs. specializations

[bkoz at redhat dot com]

------- Additional Comments From bkoz at redhat dot com  2004-04-16 19:10 -------
Subject: Re:  [3.4 Regression] namespace associations vs.
 specializations


>OK, please put this in.

The latest version of this patch is now in gcc/gcc-3_4-branch. 

thanks,
benjamin


-- 


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

[Bug c++/13294] [3.4 Regression] namespace associations vs. specializations

[mark at codesourcery dot com]

------- Additional Comments From mark at codesourcery dot com  2004-04-16 22:12 -------
Subject: Re:  [3.4 Regression] namespace associations vs. specializations

bkoz at redhat dot com wrote:

>------- Additional Comments From bkoz at redhat dot com  2004-04-16 19:10 -------
>Subject: Re:  [3.4 Regression] namespace associations vs.
> specializations
>
>
>  
>
>>OK, please put this in.
>>    
>>
>
>The latest version of this patch is now in gcc/gcc-3_4-branch. 
>  
>
Yippee.



-- 


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