From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-343356-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 17200 invoked by alias); 11 Jun 2013 09:23:52 -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 17172 invoked by uid 89); 11 Jun 2013 09:23:50 -0000
X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD autolearn=ham version=3.3.1
Received: from nikam.ms.mff.cuni.cz (HELO nikam.ms.mff.cuni.cz) (195.113.20.16)    by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 11 Jun 2013 09:23:49 +0000
Received: by nikam.ms.mff.cuni.cz (Postfix, from userid 16202)	id EBA19541D89; Tue, 11 Jun 2013 11:23:46 +0200 (CEST)
Date: Tue, 11 Jun 2013 09:23:00 -0000
From: Jan Hubicka <hubicka@ucw.cz>
To: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
Cc: Xinliang David Li <davidxl@google.com>, Dehao Chen <dehao@google.com>,	GCC Patches <gcc-patches@gcc.gnu.org>, Jan Hubicka <hubicka@ucw.cz>,	"Joseph S. Myers" <joseph@codesourcery.com>
Subject: Re: [GOOGLE] Avoid emitting duplicated weakref
Message-ID: <20130611092346.GC14227@kam.mff.cuni.cz>
References: <CAO2gOZUpcpdSSaaXU4zUAV2WOzE3A18zzQe858MnQeBWEXagjA@mail.gmail.com> <CAAkRFZJSHoTAQ_q7TSkxU_RAbAdBxi1z=3penQf+TzmFGUet=Q@mail.gmail.com> <CAC1BbcSv4arkRMD5tvL5ApUU=cfv4pAzcyTXZ10sycz4KawyLQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAC1BbcSv4arkRMD5tvL5ApUU=cfv4pAzcyTXZ10sycz4KawyLQ@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-SW-Source: 2013-06/txt/msg00568.txt.bz2

> On 9 June 2013 05:31, Xinliang David Li <davidxl@google.com> wrote:
> > Guard also with L_IPO_COMP_MODE as this is lipo specific.
> 
> Sounds like this is the LIPO incarnation of http://gcc.gnu.org/PR31537
> 
> See the patch at http://gcc.gnu.org/PR31537#c9 for not adding the
> alias in the first place (back then, honza may have changed that
> recently on trunk).
> 
> Honza, Joseph,
> Are there rules for handling weakrefs in some standard? If so, which ones?

Not that I would know of. It is an extension engineered for glibc pthreads.  in
mainline I quite changed way weakrefs are handled and I still plan to do more.
What LTO does now is to  handle weakref symbol as static symbol despite it has
DECL_EXTERNAL on it.  (I have patch in queue to really make it static).
This is because the symbol never hits the exported symbol table anyhow.

I.e. you can have:
 cat f1.i
static __gthrw_pthread_once __attribute__ ((__weakref__ ("pthread_once")));
$ cat f2.i
static __gthrw_pthread_once __attribute__ ((__weakref__ ("comething_completely_else")));

that will break with your do_assemble_alias change. with LTO you will now get
__gthrw_pthread_once.1 and __gthrw_pthread_once.2 with proper weakref targets.

Honza