From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26007 invoked by alias); 7 Jul 2012 06:06:26 -0000 Received: (qmail 25995 invoked by uid 22791); 7 Jul 2012 06:06:24 -0000 X-SWARE-Spam-Status: No, hits=-7.1 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD 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; Sat, 07 Jul 2012 06:06:06 +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 q67661Nv005525 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 7 Jul 2012 02:06:01 -0400 Received: from [10.3.113.56] (ovpn-113-56.phx2.redhat.com [10.3.113.56]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q6765w8M003218; Sat, 7 Jul 2012 02:05:59 -0400 Message-ID: <4FF7D1C6.90407@redhat.com> Date: Sat, 07 Jul 2012 06:06:00 -0000 From: Jason Merrill User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120605 Thunderbird/13.0 MIME-Version: 1.0 To: Sriraman Tallam CC: mark@codesourcery.com, nathan@codesourcery.com, "H.J. Lu" , Richard Guenther , Jan Hubicka , Uros Bizjak , reply@codereview.appspotmail.com, gcc-patches@gcc.gnu.org, David Li Subject: Re: User directed Function Multiversioning via Function Overloading (issue5752064) References: <20120307004630.A503DB21B6@azwildcat.mtv.corp.google.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 2012-07/txt/msg00265.txt.bz2 On 06/14/2012 04:13 PM, Sriraman Tallam wrote: > C++ Frontend maintainers, Could you please take a look at the > front-end part when you find the time? It seems to me that what you have here are target-specific attributes that affect the signature of a function such that they make two declarations different that would otherwise declare the same function. Stepping away from the specific notion of versioning, it seems that these are the questions that you want the front end to be able to ask about these attributes: * Does this attribute affect a function signature? * Do the attributes on these two declarations make them different? * Do the attributes on these two declarations make one a better match? * Given a call to function X, should I call another function instead? * Return a string representation of the attributes on this function that affect its signature. Does this seem like a worthwhile direction to other people, or do you like better the approach the patch takes, handling versioning directly? Jason