From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-517790-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 113623 invoked by alias); 20 Jan 2020 14:47:06 -0000
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
Received: (qmail 110695 invoked by uid 89); 20 Jan 2020 14:47:04 -0000
Authentication-Results: sourceware.org; auth=none
X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=HX-HELO:sk:mail-ot, H*RU:209.85.210.66, HX-Spam-Relays-External:209.85.210.66
X-HELO: mail-ot1-f66.google.com
Received: from mail-ot1-f66.google.com (HELO mail-ot1-f66.google.com) (209.85.210.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 20 Jan 2020 14:46:54 +0000
Received: by mail-ot1-f66.google.com with SMTP id 77so28879754oty.6        for <gcc-patches@gcc.gnu.org>; Mon, 20 Jan 2020 06:46:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;        d=gmail.com; s=20161025;        h=mime-version:references:in-reply-to:from:date:message-id:subject:to         :cc;        bh=PO30qwvzQheM8YPnx6SzUHPuWFhv+0Z59rUj5mprkhs=;        b=O3+x5MWJt6aCPjTcXzMPrJzleOsDsyVijLdt+BdKNdkQN6eE/nKZBY60epqk5rZ2iO         565Gam+Awwa+AS9QWLJ57/t0IyX5gvXfKmmJr1+B+qqeUYVUEYiWdp3Tpzfpfqe2+IbX         V49gmfr6Oa79omEdq+GPEotuONu1zHpqvSf+oAjU39WDs5haSvvAvxjbYGJnkLFWPz/Q         d8cC8KqzDgyLmMhW2gvSxhDv60pIQoH8p/vCFNbd0RqA2/wIVk1C9myPkZkJap+X55kK         KhSaoRAlFSKOF6zdDV6eb4KVGxoqZzkyEaU9LIoxxyCngQgozQ/v+ksfxjWbQPxPqzC5         uxKQ==
MIME-Version: 1.0
References: <eb85e847-a0d5-ed3a-534d-f67738c8281f@suse.cz> <CAFiYyc0duhXUwHZ027pCx-gbkuU9N7VcvNCDts2yMa0AvK+5JQ@mail.gmail.com> <CAMe9rOpRBNHdgcmz2haiTwyJQ2S9A9Yi1in57sHLMiUbkK+pSw@mail.gmail.com> <alpine.LNX.2.20.13.2001201635130.7204@monopod.intra.ispras.ru> <CAMe9rOqbo7H8-aGB+ua-eey43uJqqJRdtoan+G5cMhZps3_yhQ@mail.gmail.com> <alpine.LNX.2.20.13.2001201712580.7204@monopod.intra.ispras.ru> <CAMe9rOr=x5N=6uzVfh2+EzTWsHm7=90-dEjBKNHdbF2B9Zs0bw@mail.gmail.com> <alpine.LNX.2.20.13.2001201736410.7204@monopod.intra.ispras.ru>
In-Reply-To: <alpine.LNX.2.20.13.2001201736410.7204@monopod.intra.ispras.ru>
From: "H.J. Lu" <hjl.tools@gmail.com>
Date: Mon, 20 Jan 2020 14:55:00 -0000
Message-ID: <CAMe9rOrvHuaD4XDwAZckSMMB_bW7H0eXd26BcHXqpHDoxnFQKQ@mail.gmail.com>
Subject: Re: [PATCH] Make target_clones resolver fn static.
To: Alexander Monakov <amonakov@ispras.ru>
Cc: Richard Biener <richard.guenther@gmail.com>, =?UTF-8?Q?Martin_Li=C5=A1ka?= <mliska@suse.cz>, 	Uros Bizjak <ubizjak@gmail.com>, GCC Patches <gcc-patches@gcc.gnu.org>
Content-Type: text/plain; charset="UTF-8"
X-IsSubscribed: yes
X-SW-Source: 2020-01/txt/msg01235.txt.bz2

On Mon, Jan 20, 2020 at 6:41 AM Alexander Monakov <amonakov@ispras.ru> wrote:
>
>
>
> On Mon, 20 Jan 2020, H.J. Lu wrote:
>
> > > Bare IFUNC's don't seem to have this restriction. Why do we want to
> > > constrain target clones this way?
> > >
> >
> > foo's resolver acts as foo.  It should have the same visibility as foo.
>
> What do you mean by that? From the implementation standpoint, there's
> two symbols of different type with the same value. There's no problem
> allowing one of them have local binding and the other have global binding.
>
> Is there something special about target clones that doesn't come into
> play with ifuncs?
>

I stand corrected.   Resolver should be static and it shouldn't be weak.


-- 
H.J.