From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7642 invoked by alias); 12 Jul 2007 06:20:26 -0000 Received: (qmail 7597 invoked by alias); 12 Jul 2007 06:20:13 -0000 Date: Thu, 12 Jul 2007 06:20:00 -0000 Message-ID: <20070712062013.7596.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug c++/32232] [4.1 Regression] ICE in resolve_overloaded_unification In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "mark at codesourcery dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2007-07/txt/msg01360.txt.bz2 ------- Comment #7 from mark at codesourcery dot com 2007-07-12 06:20 ------- Subject: Re: [4.1 Regression] ICE in resolve_overloaded_unification reichelt at gcc dot gnu dot org wrote: > template struct A > { > A& operator<<(void (*)(A&)); > }; > > template A& operator<<(A&, const A&); > > template void foo(A&); > > void bar() > { > A() << (1, foo); > } As I (thought I? meant to?) said in the patch submission mail, I don't think this is valid. The syntactic form of the expression matters for deduction purposes, and my reading of the standard is that only a (generalized) identifier is allowed. (It's not very clear, but I didn't see anything to suggest that your code was valid.) The version of the EDG front end I had on hand agreed with me. :-) You could certainly ask on the core reflector, etc. The issue about printing "(0, ...)" instead of "(1, ...)" is certainly a bug, but a different one from this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32232