Re: c++/1617: partial ordering of function templates

Re: c++/1617: partial ordering of function templates

[Gabriel Dos Reis]

The following reply was made to PR c++/1617; it has been noted by GNATS.

From: Gabriel Dos Reis <gdr@codesourcery.com>
To: nathan@codesourcery.com
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c++/1617: partial ordering of function templates
Date: 11 Jan 2001 21:27:06 +0100

 nathan@codesourcery.com writes:
 
 | >Number:         1617
 | >Category:       c++
 | >Synopsis:       partial ordering of function templates
 | >Confidential:   no
 | >Severity:       serious
 | >Priority:       high
 | >Responsible:    unassigned
 | >State:          open
 | >Class:          rejects-legal
 | >Submitter-Id:   net
 | >Arrival-Date:   Thu Jan 11 05:26:01 PST 2001
 | >Closed-Date:
 | >Last-Modified:
 | >Originator:     Nathan
 | >Release:        cvs 20010111
 | >Organization:
 | >Environment:
 | 
 | >Description:
 | current/deduce.ii:6: call of overloaded `Foo(int*&)' is ambiguous
 | current/deduce.ii:1: candidates are: void Foo(T*) [with T = int]
 | current/deduce.ii:2:                 void Foo(T&) [with T = int*]
 | 
 | but I think the first choice is more specialized than the second. 14.5.5.2
 | tells us to take each choice in turn, synthesize a unique type for each
 | template type parameter into the function's parameter list and then try
 | type deduction using the other choice. The transformed template is at least
 | as specialized as the other if deduction succeeds and the deduced parameter
 | types are an exact match. In this case that gives us, with a unique type
 | called 'X'
 
 As discussed, GCC should accep the code and select void F(T*).
 
 -- Gaby
 CodeSourcery, LLC                       http://www.codesourcery.com
>From nathan@gcc.gnu.org Sun Apr 01 00:00:00 2001
From: nathan@gcc.gnu.org
To: nathan@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: c++/601
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010110150600.26857.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg00150.html
Content-length: 868

The following reply was made to PR c++/601; it has been noted by GNATS.

From: nathan@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org, nathan@gcc.gnu.org, sefer@hotmail.com
Cc:  
Subject: Re: c++/601
Date: 10 Jan 2001 15:00:00 -0000

 Synopsis: Newest snapshopts generate ICE on overloading operators
 
 State-Changed-From-To: analyzed->closed
 State-Changed-By: nathan
 State-Changed-When: Wed Jan 10 07:00:00 2001
 State-Changed-Why:
     2000-11-08  Nathan Sidwell  <nathan@codesourcery.com>
     
             * decl.c (grok_op_properties): Always use coerce_new_type and
             coerce_delete_type.
             * decl2.c (coerce_new_type): Use c_size_type_node. Preserve
             exception specification. Tidy up.
             (coerce_delete_type): Preserve exception specification. Tidy up.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=601&database=gcc
>From bryce@gcc.gnu.org Sun Apr 01 00:00:00 2001
From: bryce@gcc.gnu.org
To: apbianco@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: java/1261
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010303031602.18732.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg01920.html
Content-length: 824

The following reply was made to PR java/1261; it has been noted by GNATS.

From: bryce@gcc.gnu.org
To: apbianco@gcc.gnu.org, bryce@albatross.co.nz, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: java/1261
Date: 3 Mar 2001 03:14:23 -0000

 Synopsis: "protected" field access not restricted between packages
 
 State-Changed-From-To: feedback->closed
 State-Changed-By: bryce
 State-Changed-When: Fri Mar  2 19:14:23 2001
 State-Changed-Why:
     Confirmed fixed in gcc 3.0 branch:
     
     ]$ gcj -C pkg2/B.java 
     pkg2/B.java: In class `pkg2.B':
     pkg2/B.java: In method `(pkg1.A)':
     pkg2/B.java:7: Can't access protected field `pkg1.A.i' from `pkg2.B'.
                           int i = a.i;
                                    ^
     1 error
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1261&database=gcc

c++/1617: partial ordering of function templates

[nathan]

>Number:         1617
>Category:       c++
>Synopsis:       partial ordering of function templates
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    unassigned
>State:          open
>Class:          rejects-legal
>Submitter-Id:   net
>Arrival-Date:   Thu Jan 11 05:26:01 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Nathan
>Release:        cvs 20010111
>Organization:
>Environment:

>Description:
current/deduce.ii:6: call of overloaded `Foo(int*&)' is ambiguous
current/deduce.ii:1: candidates are: void Foo(T*) [with T = int]
current/deduce.ii:2:                 void Foo(T&) [with T = int*]

but I think the first choice is more specialized than the second. 14.5.5.2
tells us to take each choice in turn, synthesize a unique type for each
template type parameter into the function's parameter list and then try
type deduction using the other choice. The transformed template is at least
as specialized as the other if deduction succeeds and the deduced parameter
types are an exact match. In this case that gives us, with a unique type
called 'X'

a: Foo (T *) -> Foo (X *), using Foo (T &) deduce T to be X *, deduction succeeds.
b: Foo (T &) -> Foo (X &), using Foo (T *) deduction fails

so b is less specialized than a, and void Foo(T*) [with T = int] should
be selected

see http://gcc.gnu.org/ml/gcc-bugs/2001-01/msg00233.html
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="spec.ii"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="spec.ii"

dGVtcGxhdGUgPHR5cGVuYW1lIFQ+IHZvaWQgRm9vIChUICopOwp0ZW1wbGF0ZSA8dHlwZW5hbWUg
VD4gdm9pZCBGb28gKFQgJik7Cgp2b2lkIEJheiAoaW50ICpwdHIpCnsKICBGb28gKHB0cik7Cn0K
>From leo.dearden@acm.org Sun Apr 01 00:00:00 2001
From: leo.dearden@acm.org
To: gcc-gnats@gcc.gnu.org
Subject: c++/2215: ICE on compilation of code with -fhonor-std and -ggdb
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010307220108.4346.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg02094.html
Content-length: 6778

>Number:         2215
>Category:       c++
>Synopsis:       ICE on compilation of code with -fhonor-std and -ggdb
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    unassigned
>State:          open
>Class:          ice-on-illegal-code
>Submitter-Id:   net
>Arrival-Date:   Wed Mar 07 14:06:02 PST 2001
>Closed-Date:
>Last-Modified:
>Originator:     Leo Dearden (leo.dearden@acm.org)
>Release:        2.95.3 20010219 (prerelease)
>Organization:
>Environment:
debian unsable (woody) current 7/3/01, 
ALSA and NVdriver additional kernel modules,
default environment setteings,
IA-32 (intel celeron, i440BX chipset, 256MB RAM, 
UDMA (IDE) HD)
>Description:
the code is incorrect, in that ALSAExeption.h:9: should read ALSAException: public std::exception
	but reads:
ALSAException: public exception

hence the parse errors.

However with -ggdb or -ggdb3 the attempt to compile causes an ICE.

-ggdb1 or any -g[1,2,3] don't cause the ICE.

When I avoid the ICE by adding "std::" I get output code that I think is incorect, but that's in another bug report.

ld225@ld225:~/avm/main$ s
In file included from ALSAException.cpp:4:
ALSAException.h:10: parse error before `{'
ALSAException.h:14: parse error before `const'
ALSAException.h:15: destructors must be member functions
ALSAException.h:15: virtual outside class declaration
ALSAException.h:16: virtual outside class declaration
ALSAException.h:16: non-member function `what()' cannot have `const' method qualifier
ALSAException.h:17: virtual outside class declaration
ALSAException.h:17: non-member function `getErrorNumber()' cannot have `const' method qualifier
ALSAException.h:18: virtual outside class declaration
ALSAException.h:18: non-member function `getCall()' cannot have `const' method qualifier
ALSAException.h:20: parse error before `private'
ALSAException.h:27: parse error before `}'
ALSAException.cpp:10: invalid use of undefined type `class ALSAException'
ALSAException.h:9: forward declaration of `class ALSAException'
ALSAException.cpp: In method `ALSAException::ALSAException(int, const char *)':
ALSAException.cpp:12: class `ALSAException' does not have any field named `call'
ALSAException.cpp:13: class `ALSAException' does not have any field named `errorNumber'
ALSAException.cpp:15: class `ALSAException' does not have any field named `errorNumberText'
ALSAException.cpp:16: class `ALSAException' does not have any field named `errorNameText'
ALSAException.cpp:18: `call' undeclared (first use this function)
ALSAException.cpp:18: (Each undeclared identifier is reported only once
ALSAException.cpp:18: for each function it appears in.)
ALSAException.cpp:21: Internal compiler error in `scope_die_for', at dwarf2out.c:7804
Please submit a full bug report.
>How-To-Repeat:

// to get ICE:
// g++ -fhonor-std -ggdb -c -o ALSAException.o ALSAException.cpp

// I can't get mozilla to attach more than one file, so 
// here is the other part of the problem.
#ifndef AVM_ALSA_EXCEPTION_H
#define AVM_ALSA_EXCEPTION_H

#include <exception>

class ALSAException : public exception
{
public:
  //  ALSAException(char const * const call = "call unspecified.");
  ALSAException(int newErrorNumber, char const * newCall = "call unspecified");
  ALSAException(ALSAException const &);
  virtual ~ALSAException();
  virtual char const * what() const;
  virtual int getErrorNumber() const;
  virtual char const * getCall() const;

private:  
  char* call;
  //  bool const errorNumberValid;
  int errorNumber;
  char* errorNumberText; 
  char* errorNameText; 

};

#endif //AVM_ALSA_EXCEPTION_H


>Fix:
don't use -ggdb or -ggdb3 with -fhonor-std and lack of scope resolution.
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: text/cpp; name="ALSAException.cpp"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="ALSAException.cpp"

Ly8gYmFzZSBjbGFzcyBmb3IgYWxsIGV4Y2VwdGlvbnMKLy8gd3JpdHRlbiAzLzMvMDEgYnkgTGVv
IERlYXJkZW4KCiNpbmNsdWRlICJBTFNBRXhjZXB0aW9uLmgiCiNpbmNsdWRlIDxzeXMvYXNvdW5k
bGliLmg+Ci8vI2luY2x1ZGUgPGNzdHJpbmc+CiNpbmNsdWRlIDxjc3RkaW8+CgovLyBjYWxsID0g
bmFtZSBvZiBjYWxsIHdoaWNoIGZhaWxlZApBTFNBRXhjZXB0aW9uOjpBTFNBRXhjZXB0aW9uKGlu
dCBuZXdFcnJvck51bWJlciwgY2hhciBjb25zdCAqIG5ld0NhbGwpOgogIC8vIGNyZWF0ZSBhIG5l
dyBjaGFyW10gYmlnIGVub3VnaCB0byBob2xkIG5ld0NhbGwKICBjYWxsKG5ldyBjaGFyW3NpemVv
ZihuZXdDYWxsKV0pLAogIGVycm9yTnVtYmVyKG5ld0Vycm9yTnVtYmVyKSwKICAvLyBjaGFyIGFy
cmF5IHBsZW50eSBiaWcgZW5vdWdoIHRvIGhvbGQgdGhlIHRleHQgcmVwcmVzZW50YXRpb24gb2Yg
YW4gaW50CiAgZXJyb3JOdW1iZXJUZXh0KG5ldyBjaGFyWzE2XSksCiAgZXJyb3JOYW1lVGV4dChu
ZXcgY2hhcltzaXplb2Yoc25kX3N0cmVycm9yKGVycm9yTnVtYmVyKSldKQp7CiAgc3RyY3B5KGNh
bGwsIG5ld0NhbGwpOwogIHNwcmludGYoZXJyb3JOdW1iZXJUZXh0LCAiJWQiLCBlcnJvck51bWJl
cik7CiAgc3RyY3B5KGVycm9yTmFtZVRleHQsIHNuZF9zdHJlcnJvcihlcnJvck51bWJlcikpOyAg
Cn0KCi8vIG9ic2VydmF0aW9uIHdpdGggYSBkZWJ1Z2dlciBzaG93cyB0aGF0IGluIHRoaXMgY29u
c3RydWN0b3IsIG9yaWdpbmFsIHBvaW50cyB0byBzb21lIHZhbHVlLCBhbmQgdGhpcyBwb2ludHMg
dG8gdGhlIHZhbHVlIHRvIGJlIGR1cGxpY2F0ZWQKQUxTQUV4Y2VwdGlvbjo6QUxTQUV4Y2VwdGlv
bihBTFNBRXhjZXB0aW9uIGNvbnN0ICYgb3JpZ2luYWwpOgogIC8vIGNyZWF0ZSBhIG5ldyBjaGFy
W10gYmlnIGVub3VnaCB0byBob2xkIG5ld0NhbGwKICBjYWxsKG5ldyBjaGFyW3NpemVvZihvcmln
aW5hbC5nZXRDYWxsKCkpXSksCiAgZXJyb3JOdW1iZXIob3JpZ2luYWwuZ2V0RXJyb3JOdW1iZXIo
KSksCiAgLy8gY2hhciBhcnJheSBwbGVudHkgYmlnIGVub3VnaCB0byBob2xkIHRoZSB0ZXh0IHJl
cHJlc2VudGF0aW9uIG9mIGFuIGludAogIGVycm9yTnVtYmVyVGV4dChuZXcgY2hhclsxNl0pLAog
IGVycm9yTmFtZVRleHQobmV3IGNoYXJbc2l6ZW9mKHNuZF9zdHJlcnJvcihlcnJvck51bWJlcikp
XSkKewogIHN0cmNweShjYWxsLCBvcmlnaW5hbC5nZXRDYWxsKCkpOwogIHNwcmludGYoZXJyb3JO
dW1iZXJUZXh0LCAiJWQiLCBlcnJvck51bWJlcik7CiAgc3RyY3B5KGVycm9yTmFtZVRleHQsIHNu
ZF9zdHJlcnJvcihlcnJvck51bWJlcikpOyAgCiAgLy97CiAgLy8gIEFMU0FFeGNlcHRpb24ob3Jp
Z2luYWwuZ2V0RXJyb3JOdW1iZXIoKSwgb3JpZ2luYWwuZ2V0Q2FsbCgpKTsKfQoKCkFMU0FFeGNl
cHRpb246On5BTFNBRXhjZXB0aW9uKCkKewogIGRlbGV0ZSBbXWVycm9yTnVtYmVyVGV4dDsKICAv
LyBjYXVzZXMgYSBzZWcgZmF1bHQuIEkgZ3Vlc3MgdGhlIG91dHB1dCBvZiBzbmRfc3RyZXJyb3Ig
aXNuJ3Qgb3duZWQgYnkgQUxTQUV4Y2VwdGlvbi4KICBkZWxldGUgW11lcnJvck5hbWVUZXh0Owog
IC8vIGRpdHRvLCBvdXRwdXQgb2YKICBkZWxldGUgW11jYWxsOwogIAp9CgpjaGFyIGNvbnN0ICog
QUxTQUV4Y2VwdGlvbjo6d2hhdCgpIGNvbnN0CnsKICAvLyBBTFNBRXhjZXB0aW9uIGRvZXMgbm90
IG93biB0aGUgcmV0dXJuZWQgY2hhcltdCiAgY2hhciogcmV0dXJuU3RyaW5nID0gbmV3IGNoYXJb
c2l6ZW9mKGNhbGwpICsgc2l6ZW9mKCIgcmV0dXJuZWQgIikgKyBzaXplb2YoZXJyb3JOdW1iZXJU
ZXh0KSArIHNpemVvZigiOiAiKSArIHNpemVvZihlcnJvck5hbWVUZXh0KSArIDFdOwogIHNwcmlu
dGYocmV0dXJuU3RyaW5nLCAiJXMlcyVzJXMlcyIsIGNhbGwsICIgcmV0dXJuZWQgIiwgZXJyb3JO
dW1iZXJUZXh0LCAiOiAiLCAoY2hhciAqKSBlcnJvck5hbWVUZXh0KTsgCiAgcmV0dXJuIHJldHVy
blN0cmluZzsKfQoKaW50IEFMU0FFeGNlcHRpb246OmdldEVycm9yTnVtYmVyKCkgY29uc3QKewog
IHJldHVybiBlcnJvck51bWJlcjsKfQoKY2hhciBjb25zdCAqIEFMU0FFeGNlcHRpb246OmdldENh
bGwoKSBjb25zdAp7CiAgcmV0dXJuIGNhbGw7Cn0KCgoK

Re: c++/1617: partial ordering of function templates

[Nathan Sidwell]

The following reply was made to PR c++/1617; it has been noted by GNATS.

From: Nathan Sidwell <nathan@codesourcery.com>
To: Gabriel Dos Reis <gdr@codesourcery.com>,
        Martin Sebor <sebor@roguewave.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c++/1617: partial ordering of function templates
Date: Fri, 12 Jan 2001 11:31:41 +0000

 This is a multi-part message in MIME format.
 --------------0842A33EC7655510E79FBC38
 Content-Type: text/plain; charset=us-ascii
 Content-Transfer-Encoding: 7bit
 
 Hi,
 more partial ordering questions. I've got another corner case, which I'm unsure
 of which way to resolve.
 Consider
 template <typename T> int Bar (T const *const &);	#1
 template <typename T> int Bar (T *const &);		#2
 template <typename T> int Bar (T *);			#3
 
 int const *cp;
 int *p;
 
 Bar (cp);	#a
 Bar (p);	#b
 
 what should be called at #a and #b, or are either ambiguous. Here are the
 deductions,
 
 #a; #1->int, #2->const int, #3->const int
 #b; #1->int, #2->int, #3->int
 
 I think #1 should be more specilized than #2 and #2 should be more
 specialized than #3. #1 should be more specialized than #3. I'm having
 trouble getting that ordering to work for both #a and #b.
 
 I'd be interested what other compilers do on the attached program (modulo
 the __PRETTY_FUNCTION__ bit :-)
 
 nathan
     
 -- 
 Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
          'But that's a lie.' - 'Yes it is. What's your point?'
 nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org
 --------------0842A33EC7655510E79FBC38
 Content-Type: text/plain; charset=us-ascii;
  name="1617.ii"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: inline;
  filename="1617.ii"
 
 
 extern "C" int puts (char const *);
 
 template <typename T> int Foo (T *) {puts (__PRETTY_FUNCTION__); return 1;}
 template <typename T> int Foo (T &) {puts (__PRETTY_FUNCTION__); return 2;}
 template <typename T> int Foo (T const &) {puts (__PRETTY_FUNCTION__); return 3;}
 
 template <typename T> int Bar (T const *const &) {puts (__PRETTY_FUNCTION__); return 4;}
 template <typename T> int Bar (T *const &) {puts (__PRETTY_FUNCTION__); return 5;}
 template <typename T> int Bar (T *) {puts (__PRETTY_FUNCTION__); return 6;}
 
 template <typename T> int Quux (T *const &) {puts (__PRETTY_FUNCTION__); return 7;}
 template <typename T> int Quux (T const &) {puts (__PRETTY_FUNCTION__); return 8;}
 
 
 int Baz (int const *ptr, int *ptr2)
 {
   if (Foo (ptr) != 1)
     return 1;
   if (Foo (ptr2) != 1)
     return 2;
   if (Foo (*ptr) != 3)
     return 3;
   if (Foo (*ptr2) != 2)
     return 4;
   
   if (Bar (ptr) != 4)
     return 5;
   if (Bar (ptr2) != 5)
     return 6;
   
   if (Quux (ptr) != 7)
     return 5;
   if (Quux (ptr2) != 7)
     return 6;
   
   return 0;
 }
 
 int main ()
 {
   return Baz (0, 0);
 }
 
 --------------0842A33EC7655510E79FBC38--
 
>From rth@gcc.gnu.org Sun Apr 01 00:00:00 2001
From: rth@gcc.gnu.org
To: rth@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: optimization/286
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010116141602.30118.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg00345.html
Content-length: 814

The following reply was made to PR optimization/286; it has been noted by GNATS.

From: rth@gcc.gnu.org
To: rohit@synopsys.com, gcc-gnats@gcc.gnu.org, mchapman@synopsys.com,
  nobody@gcc.gnu.org, rth@gcc.gnu.org, sogania@synopsys.com
Cc:  
Subject: Re: optimization/286
Date: 16 Jan 2001 14:12:50 -0000

 Synopsis: optimizer uses 530mb in egcs-20000605  (barfs in 2.95.2)
 
 Responsible-Changed-From-To: unassigned->rth
 Responsible-Changed-By: rth
 Responsible-Changed-When: Tue Jan 16 06:12:49 2001
 Responsible-Changed-Why:
     Mine.
 State-Changed-From-To: open->closed
 State-Changed-By: rth
 State-Changed-When: Tue Jan 16 06:12:49 2001
 State-Changed-Why:
     Fixed.
     
     http://gcc.gnu.org/ml/gcc-patches/2001-01/msg01329.html
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=286&database=gcc
>From neil@gcc.gnu.org Sun Apr 01 00:00:00 2001
From: neil@gcc.gnu.org
To: gerald@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: web/1581
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010108120601.7310.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg00089.html
Content-length: 521

The following reply was made to PR web/1581; it has been noted by GNATS.

From: neil@gcc.gnu.org
To: brg@sartre.dgate.ORG, gcc-gnats@gcc.gnu.org, gerald@gcc.gnu.org
Cc:  
Subject: Re: web/1581
Date: 8 Jan 2001 12:01:45 -0000

 Synopsis: configure web page specifies cpplib never enabled by default
 
 State-Changed-From-To: open->closed
 State-Changed-By: neil
 State-Changed-When: Mon Jan  8 04:01:45 2001
 State-Changed-Why:
     Wording updated.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1581&database=gcc
>From lerdsuwa@gcc.gnu.org Sun Apr 01 00:00:00 2001
From: lerdsuwa@gcc.gnu.org
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: c++/676
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010211120600.1139.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg01128.html
Content-length: 585

The following reply was made to PR c++/676; it has been noted by GNATS.

From: lerdsuwa@gcc.gnu.org
To: gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org,
  web@boskawauter.student.utwente.nl
Cc:  
Subject: Re: c++/676
Date: 11 Feb 2001 11:57:49 -0000

 Synopsis: gcc ice on illegal use of conditional statements
 
 State-Changed-From-To: analyzed->closed
 State-Changed-By: lerdsuwa
 State-Changed-When: Sun Feb 11 03:57:49 2001
 State-Changed-Why:
     Fixed.  The current CVS version no longer ICE after syntax error.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=676&database=gcc

Re: c++/1617: partial ordering of function templates

[Martin Sebor]

The following reply was made to PR c++/1617; it has been noted by GNATS.

From: Martin Sebor <sebor@roguewave.com>
To: Nathan Sidwell <nathan@codesourcery.com>
Cc: Gabriel Dos Reis <gdr@codesourcery.com>, gcc-gnats@gcc.gnu.org
Subject: Re: c++/1617: partial ordering of function templates
Date: Fri, 12 Jan 2001 18:21:08 -0700

 Nathan Sidwell wrote:
 > 
 > Hi,
 > more partial ordering questions. I've got another corner case, which I'm
 > unsure
 > of which way to resolve.
 > Consider
 > template <typename T> int Bar (T const *const &);       #1
 > template <typename T> int Bar (T *const &);             #2
 > template <typename T> int Bar (T *);                    #3
 > 
 > int const *cp;
 > int *p;
 > 
 > Bar (cp);       #a
 > Bar (p);        #b
 > 
 > what should be called at #a and #b, or are either ambiguous. Here are
 > the deductions,
 > 
 > #a; #1->int, #2->const int, #3->const int
 > #b; #1->int, #2->int, #3->int
 > 
 > I think #1 should be more specilized than #2 and #2 should be more
 > specialized than #3. #1 should be more specialized than #3. I'm having
 > trouble getting that ordering to work for both #a and #b.
 
 Ouch, you're making my head hurt ;-)
 
 Despite what EDG thinks, I would probably agree that #1 is more specialized than
 #2 or #3, so #a should resolve to #1. I'm not so sure about the difference
 between #2 and #3, though. Taking #1 out of the set, I'd say the call #a should
 be ambiguous (EDG disagrees, picking #3 again).
 
 In the case of #b I'd probably consider #2 and #3 ambiguous. It would certainly
 be if the signatures did not involve pointers (ie., T const& and T,
 respectively).
 
          ARGUMENT        [DEDUCED TYPE]
 #a: cp : int const* <==> [T = int] const* const&    best viable   #1
                          [T = int const]* const&         viable   #2
                          [T = int const]*                viable   #3
                          
 #b: p  : int*       <==> [T = int] const* const&     not viable   #1
                          [T = int]* const&               viable   #2
                          [T = int]*                      viable   #3
                 
 
 > 
 > I'd be interested what other compilers do on the attached program
 > (modulo the __PRETTY_FUNCTION__ bit :-)
 
 Here are [some of] the mainstream compilers:
 
 +-------------+---+---+---+---++---+---++---+---+
 |call -->     | a | b | c | d || e | f || g | h |
 +=============+===+===+===+===++===+===++===+===+
 |EDG eccp 2.44| 1 | 1 | 3 | 2 || 6 | 6 || 7 | 7 |
 +-------------+---+---+---+---++---+---++---+---+
 |gcc 2.95.2   | E | E | 3 | 2 || E | E || 7 | 7 |
 +-------------+---+---+---+---++---+---++---+---+
 |HP aCC 3.26  | E | E | E | 2 || E | E || 7 | 7 |
 +-------------+---+---+---+---++---+---++---+---+
 |IBM xlC 5.0  | E | E | 3 | 2 || E | E || 7 | 7 |
 +-------------+---+---+---+---++---+---++---+---+
 |MSVC 6.0     | E | E | E | 2 || 6 | 6 || E | E |
 +-------------+---+---+---+---++---+---++---+---+
 |SunPro 5.2   | 2 | 2 | 3 | 2 || 5 | 5 || 7 | 7 |
 +-------------+---+---+---+---++---+---++---+---+
                 ^   ^  ...       ^   ^   ...
                 |   |            |   |
                 |   |            |   +-- your #b above
                 |   |            +------ your #a above
                 |   |
                 |   +- foo (ptr2)
                 +- foo (ptr)
 
 Martin
 
 
 $ for s in a b c d e f g h ; do printf "*** $%s: " $s ; $CC -D $s t.cpp
 >/dev/null 2>&1 ; if [ $? -eq 0 ] ; then ./a.out ; else echo "ERROR" ; fi ; done
 
 $ cat t.cpp
 
 extern "C" int puts (const char*);
 
 #define TEMPLATE(name, arg, n)   \
    template <class T> const char* name (arg) { return #name "(" #arg ") #" #n; }
 
 #if defined (a) || defined (b) || defined (c) || defined (d)
 TEMPLATE (foo, T*, 1)
 TEMPLATE (foo, T&, 2)
 TEMPLATE (foo, T const&, 3)
 #endif
 
 #if defined (e) || defined (f)
 TEMPLATE (bar, T const* const&, 4)
 TEMPLATE (bar, T* const&, 5)
 TEMPLATE (bar, T*, 6)
 #endif
 
 #if defined (g) || defined (h)
 TEMPLATE (quux, T* const&, 7)
 TEMPLATE (quux, T const&, 8)
 #endif
 
 void baz (int const *ptr, int *ptr2)
 {
 #ifdef a
     puts (foo (ptr));
 #endif
 #ifdef b
     puts (foo (ptr2));
 #endif
 #ifdef c
     puts (foo (*ptr));
 #endif
 #ifdef d
     puts (foo (*ptr2));
 #endif 
 
 #ifdef e
     puts (bar (ptr));
 #endif
 #ifdef f
     puts (bar (ptr2));
 #endif
 
 #ifdef g  
     puts (quux (ptr));
 #endif
 #ifdef h
     puts (quux (ptr2));
 #endif
 }
 
 int main ()
 {
     baz (0, 0);
 }
>From dobowman@cisco.com Sun Apr 01 00:00:00 2001
From: "Don Bowman" <dobowman@cisco.com>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: RE: c++/1571
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010107152601.28877.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg00077.html
Content-length: 1168

The following reply was made to PR c++/1571; it has been noted by GNATS.

From: "Don Bowman" <dobowman@cisco.com>
To: <neil@gcc.gnu.org>, <cgd@sibyte.com>, <gcc-gnats@gcc.gnu.org>,
        <nobody@gcc.gnu.org>
Cc:  
Subject: RE: c++/1571
Date: Sun, 7 Jan 2001 10:23:48 -0500

 Perhaps the message could be changed?
 
 In my case its still a problem since its an
 embedded system, I've got wchar_t == char,
 not int, but now the compiler has the wrong
 width.
 
 Also, some people may not have access to the
 system header files to change them to put
 the cplusplus protection around that type.
 Perhaps a command-line option to disable this
 internal type?
 
 -----Original Message-----
 From: neil@gcc.gnu.org [ mailto:neil@gcc.gnu.org ]
 Sent: January 7, 2001 6:45 AM
 To: dobowman@cisco.com; cgd@sibyte.com; gcc-gnats@gcc.gnu.org;
 nobody@gcc.gnu.org
 Subject: Re: c++/1571
 
 
 Synopsis: g++ is confused with by code that typedef's wchar_t.
 
 State-Changed-From-To: open->closed
 State-Changed-By: neil
 State-Changed-When: Sun Jan  7 03:44:32 2001
 State-Changed-Why:
     User-error :-)
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1571&database=gcc
 
>From neil@gcc.gnu.org Sun Apr 01 00:00:00 2001
From: neil@gcc.gnu.org
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org
Subject: Re: c/1814
Date: Sun, 01 Apr 2001 00:00:00 -0000
Message-id: <20010304002600.20064.qmail@sourceware.cygnus.com>
X-SW-Source: 2001-q1/msg01984.html
Content-length: 552

The following reply was made to PR c/1814; it has been noted by GNATS.

From: neil@gcc.gnu.org
To: dakott@pobox.com, gcc-gnats@gcc.gnu.org, nobody@gcc.gnu.org
Cc:  
Subject: Re: c/1814
Date: 4 Mar 2001 00:25:48 -0000

 Synopsis: fr30-elf 2.97 cross-compiler segmentation faults on FreeBSD 4.2-stable building libgcc
 
 State-Changed-From-To: feedback->closed
 State-Changed-By: neil
 State-Changed-When: Sat Mar  3 16:25:48 2001
 State-Changed-Why:
     No feedback forthcoming.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view&pr=1814&database=gcc