[Bug c++/6424] sizeof() with overload resolution (core issue 339)

[Bug c++/6424] sizeof() with overload resolution (core issue 339)

[giovannibajo at libero dot it]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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


giovannibajo at libero dot it changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |SUSPENDED


------- Additional Comments From giovannibajo at libero dot it  2003-07-01 18:24 -------
Now on mainline we get:

/cygdrive/e/code/ice/pr6424.cpp:10: sorry, unimplemented: call_expr cannot be 
mangled due to a defect in the C++ ABI

I suspend the bug until the C++ ABI is fixed in this regard.

[Bug c++/6424] sizeof() with overload resolution (core issue 339)

[pinskia at gcc dot gnu dot org]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

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


pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gccbugs at contacts dot
                   |                            |eelis dot net


------- Additional Comments From pinskia at gcc dot gnu dot org  2003-08-09 16:32 -------
*** Bug 11869 has been marked as a duplicate of this bug. ***

[Bug c++/6424] [DR 339] sizeof() with overload resolution

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-08-09 02:40 -------
The point is that the ABI doesn't say how to mangle the number of the arguments 
for the "cl" operator. In fact, it expects operators to have a fixed arity, 
which is not true for "cl". Something like:

<expression> ::= <n-ary operator name> <number> <expression>*

would work, if we classify "cl" in such a class. This definitely does not break 
any existing code because "cl" is totally broken at this point. 


How does the ICC mangle this? I suppose something like this. I think we should 
go ahead and fix this bug, instead of waiting for the C++ ABI. We have never 
heard something back about this issue after all.

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


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

[Bug c++/6424] [DR 339] sizeof() with overload resolution

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-08-09 11:50 -------
Actually, icc doesn't handle this at all: it rejects the code 
with the error message 
 
g/x> icc -c x.cc 
x.cc(10): error: no instance of function template "f" matches the argument 
list 
            argument types are: (int) 
    f(1); 
    ^ 
 
The same happens if I explicitly say f<int>(1) in the call in main(). 
 
 
I never quite understood why we have to mangle the return expression 
for examples like this, i.e. mangle A<sizeof(xxx((T)0))> instead of 
A<1>. I know that the ABI says so, but can someone point me to a 
simple explanation _why_ it says so? 
 
W. 

-- 


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

[Bug c++/6424] [DR 339] sizeof() with overload resolution

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2004-08-09 12:19 -------
Subject: Re:  [DR 339] sizeof() with overload resolution

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

| I never quite understood why we have to mangle the return expression 
| for examples like this, i.e. mangle A<sizeof(xxx((T)0))> instead of 
| A<1>. I know that the ABI says so, but can someone point me to a 
| simple explanation _why_ it says so? 

I may be wrong but I believe the idea is that one should be able to
check when two symbols actually refers to the same function.  
For non-template functions, the return type does not really matter 
-- actually that is incorrect, but the only way you could screw things
up is when you violate the ODR rule.

For functions templates, the situation is radically different because
the expressions involved in function template declarations are part of
its signature.  And you can get function templates with "neighboor"
signatures co-existing in the same translation unit, without violating
the ODR.  

-- Gaby


-- 


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

[Bug c++/6424] [DR 339] sizeof() with overload resolution

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-08-09 14:58 -------
This is getting off-topic, but maybe you have a short answer anyway: 
 
> For functions templates, the situation is radically different because 
> the expressions involved in function template declarations are part of 
> its signature.  And you can get function templates with "neighboor" 
> signatures co-existing in the same translation unit, without violating 
> the ODR.  
 
I understand that the return type is important for things like SFINAE, 
in order to decide which function to actually call. However, once this 
is decided, there needs to be exactly one instance, with a presumably 
unique signature, constants being folded or not. 
 
For example, this code is valid: 
----------------- 
template <int> struct S {}; 
 
template <typename T> 
S<sizeof(T)> foo (T); 
 
template <typename T> 
S<sizeof(T)*2/2> foo (T); 
----------------- 
However, when you want to call these functions, you get an ambiguity. Do 
you an example where it would lead to confusion if the return expression 
would be constant folded? 
 
W. 

-- 


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

[Bug c++/6424] [DR 339] sizeof() with overload resolution

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-08-09 15:28 -------
(In reply to comment #9)

> For example, this code is valid: 
> ----------------- 
> template <int> struct S {}; 
>  
> template <typename T> 
> S<sizeof(T)> foo (T); 
>  
> template <typename T> 
> S<sizeof(T)*2/2> foo (T); 
> ----------------- 
> However, when you want to call these functions, you get an ambiguity. 

Yes, but you must be able to define those two functions in two different 
translation units, instantiate them, and link the whole program without getting 
a symbol conflict.

> Do you an example where it would lead to confusion if the return expression 
> would be constant folded? 

Last time I asked this to Mark, the explanation was that it was too hard to 
describe *exactly* in the ABI specification what had to be folded and what had 
not. Plus, you would force compilers to do things not required by the C++ 
standard (which says, IIRC, that we are not forced to understand that foo(A<2>) 
and foo(A<1+1>) are the same declaration -- but notice I don't have the 
standard handy now), so in the end the best solution was to just mangle the 
unfolded expression.


-- 


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

[Bug c++/6424] [DR 339] sizeof() with overload resolution

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-08-09 15:44 -------
Ah, ok, what you quote Mark says makes sense. 
 
> Yes, but you must be able to define those two functions in two different  
> translation units, instantiate them, and link the whole program without  
> getting a symbol conflict. 
 
But that assumes that the two signatures I mentioned actually refer to 
two different functions. However, I don't see why that should be so, though 
answering that question is completely off-topic for this PR and we shouldn't 
do it here. 
 
W. 

-- 


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

[Bug c++/6424] [DR 339] sizeof() with overload resolution

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2004-08-09 16:56 -------
Subject: Re:  [DR 339] sizeof() with overload resolution

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

| This is getting off-topic, but maybe you have a short answer anyway: 
|  
| > For functions templates, the situation is radically different because 
| > the expressions involved in function template declarations are part of 
| > its signature.  And you can get function templates with "neighboor" 
| > signatures co-existing in the same translation unit, without violating 
| > the ODR.  
|  
| I understand that the return type is important for things like SFINAE, 
| in order to decide which function to actually call.

But, it is not just limited to SFINAE.

| However, once this is decided, there needs to be exactly one
| instance, with a presumably unique signature, constants being folded
| or not.  
|  
| For example, this code is valid: 
| ----------------- 
| template <int> struct S {}; 
|  
| template <typename T> 
| S<sizeof(T)> foo (T); 
|  
| template <typename T> 
| S<sizeof(T)*2/2> foo (T); 
| ----------------- 
| However, when you want to call these functions, you get an ambiguity. Do 

If you get an ambiguity then you get a compile-time error, so there
would be no worry about mangling anything because we don't have
anything to mangle. 

The real issue is when you don't have ambiguity.

The fundamental point is that every specialization "belongs" to its
primary template.  We know a specialization only through its
primary template and the template arguments list used to get that
specialization.  Not through its mangled name.  Primary templates that
are considered distinct should engender distinct specializations.
Otherwise you would introduce an ODR violation where the C++ standard
does not say there is.  For example, consider the language in 14.5.5.1/5.

  // h1.H

  template<int, int> struct X { /* ... */ };
  template<in> struct Y { /* ... */ };

  // h2.H
  #include "h1.H"
  export template<int I, int J> X<I+J> f(Y<I>, Y<J>);

  // h3.H
  #include "h1.H"
  export template<int I, int J> X<I-J> f(Y<I>, Y<J>);

  // t2.C
  #include "h2.H"

  X<0> g()
  {
      Y<0> y0;
      Y<0> y1;
      return f(y0, y1);         // call f from h2.H
  }

  // t3.C
  #include "h3.H"

  X<0> h()
  {
      Y<0> y0;
      Y<0> y1;
      return f(y0, y1);         // call f from h3.H
  }


  // main.C
  #include "h1.H"
  extern X<0> g();
  extern X<0> h();

  int main()
  {
     g();
     h();
  }

Consider the program main.C + t2.C + t3.C.  How do you make sure that
the different functions f() (usually referenced through their mangled
names) get correctly referenced without transmuting the program
semantics? 

-- Gaby


-- 


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

[Bug c++/6424] [DR 339] sizeof() with overload resolution

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2004-08-09 16:59 -------
Subject: Re:  [DR 339] sizeof() with overload resolution

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

| (In reply to comment #9)
| 
| > For example, this code is valid: 
| > ----------------- 
| > template <int> struct S {}; 
| >  
| > template <typename T> 
| > S<sizeof(T)> foo (T); 
| >  
| > template <typename T> 
| > S<sizeof(T)*2/2> foo (T); 
| > ----------------- 
| > However, when you want to call these functions, you get an ambiguity. 
| 
| Yes, but you must be able to define those two functions in two different 
| translation units, instantiate them, and link the whole program without getting 
| a symbol conflict.

Indeed.

| > Do you an example where it would lead to confusion if the return expression 
| > would be constant folded? 
| 
| Last time I asked this to Mark, the explanation was that it was too hard to 
| describe *exactly* in the ABI specification what had to be folded and what had 
| not.

Yes, the issue boils down to find normal forms for C++ expressions,
without introducing ODR violation where they do not exist.

-- Gaby


-- 


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

[Bug c++/6424] [DR 339] sizeof() with overload resolution

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2004-08-09 17:02 -------
Subject: Re:  [DR 339] sizeof() with overload resolution

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

| Ah, ok, what you quote Mark says makes sense. 
|  
| > Yes, but you must be able to define those two functions in two different  
| > translation units, instantiate them, and link the whole program without  
| > getting a symbol conflict. 
|  
| But that assumes that the two signatures I mentioned actually refer to 
| two different functions. However, I don't see why that should be so, though 
| answering that question is completely off-topic for this PR and we shouldn't 
| do it here. 

Consider

   template<int I, int J>
     Y<I+J> f(X<I>, X<J>);              // #1

   template<int I, int J>
     Y<I-J> f(X<I>, X<J>);              // #2

C++ standard says that #1 and #2 declare different function templates.
Consider the instantiations you get with I = 0 and J = 0.

-- Gaby


-- 


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

[Bug c++/6424] [DR 339] sizeof() with overload resolution

[bangerth at dealii dot org]

------- Additional Comments From bangerth at dealii dot org  2004-08-09 17:41 -------
Thanks, Gaby. I had seen this example in the standard, but didn't really 
understand why it is important to keep the two functions apart since 
I didn't think of the case I=J=0. That clarifies the matter for me :-) 
 
Thanks 
 W. 

-- 


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

[Bug c++/6424] [DR 339] sizeof() with overload resolution

[jason at gcc dot gnu dot org]

------- Comment #16 from jason at gcc dot gnu dot org  2009-03-03 21:28 -------
Fixed by some of my recent mangling work.


-- 

jason at gcc dot gnu dot org changed:

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


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