From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1752 invoked by alias); 22 Sep 2011 22:33:45 -0000 Received: (qmail 1741 invoked by uid 22791); 22 Sep 2011 22:33:41 -0000 X-SWARE-Spam-Status: No, hits=-6.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS,TW_FN X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 22 Sep 2011 22:33:12 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p8MMXCBM022415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Sep 2011 18:33:12 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p8MMXBAi007481; Thu, 22 Sep 2011 18:33:12 -0400 Received: from [0.0.0.0] (ovpn-113-71.phx2.redhat.com [10.3.113.71]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p8MMXAvR015144; Thu, 22 Sep 2011 18:33:10 -0400 Message-ID: <4E7BB7A5.8020305@redhat.com> Date: Thu, 22 Sep 2011 23:48:00 -0000 From: Jason Merrill User-Agent: Mozilla/5.0 (X11; Linux i686; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Fabien_Ch=EAne?= CC: gcc-patches@gcc.gnu.org Subject: Re: [Patch] PR c++/26256 References: <4C6E0571.3070802@redhat.com> <4D1279FD.6010706@redhat.com> <4D7297F5.2000708@redhat.com> <4E020BE2.7080207@redhat.com> <4E77D811.5000701@redhat.com> <4E7A28A0.8020805@redhat.com> <4E7B5816.6010802@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org X-SW-Source: 2011-09/txt/msg01370.txt.bz2 On 09/22/2011 05:11 PM, Fabien Chêne wrote: > 2011/9/22 Jason Merrill: >> I don't, it just seemed strange to handle functions differently from other >> decls here. But when I look more closely I see that we're in >> lookup_field_1, which isn't interested in functions, so I guess we do want >> to ignore function using-declarations here. > > That's strange because if we do return FUNCTION_DECL, PR c++/30195 seems solved. It works for that testcase, but we need to handle functions in lookup_fnfields_1 since it's also called from other places. >> But check for is_overloaded_fn rather than just OVERLOAD. Also, it looks like the new code doesn't respect want_type. > > Er, I'm a bit lost, do you mean something like that ? > > if (TREE_CODE (field) == USING_DECL) > { > tree target_field = strip_using_decl (field); > if (target_field != field) > { > if (DECL_P (target_field)&& DECL_NAME (target_field) == name > || (is_overloaded_fn (target_field) > && DECL_NAME (get_first_fn (target_field)) == name)) > { > if (!want_type > || TREE_CODE (target_field) == TYPE_DECL) > return target_field; > } > > continue; > } > } I was thinking more like tree decl = field; if (TREE_CODE (decl) == USING_DECL) { decl = strip_using_decl (decl); if (is_overloaded_fn (decl)) continue; } if (DECL_NAME (decl) == name ... Jason