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

[Gabriel Dos Reis <gdr@codesourcery.com>]

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