From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-return-147083-listarch-gcc=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 23719 invoked by alias); 5 Jun 2008 21:03:47 -0000
Received: (qmail 23707 invoked by uid 22791); 5 Jun 2008 21:03:47 -0000
X-Spam-Check-By: sourceware.org
Received: from smtp-out.google.com (HELO smtp-out.google.com) (216.239.33.17)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 05 Jun 2008 21:03:29 +0000
Received: from spaceape10.eur.corp.google.com (spaceape10.eur.corp.google.com [172.28.16.144]) 	by smtp-out.google.com with ESMTP id m55L3Lc9005747; 	Thu, 5 Jun 2008 22:03:21 +0100
Received: from localhost.localdomain.google.com (dhcp-172-18-116-187.corp.google.com [172.18.116.187]) 	(authenticated bits=0) 	by spaceape10.eur.corp.google.com with ESMTP id m55L3Ewg015981 	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); 	Thu, 5 Jun 2008 22:03:16 +0100
To: Nick Kledzik <kledzik@apple.com>
Cc: Chris Lattner <clattner@apple.com>,         Rafael Espindola <espindola@google.com>,         Diego Novillo <dnovillo@google.com>,         GCC Mailing List <gcc@gcc.gnu.org>,         Kenneth Zadeck <zadeck@naturalbridge.com>, Jan Hubicka <jh@suse.cz>,         Ollie Wild <aaw@google.com>, Robert Hundt <rhundt@google.com>,         Devang Patel <dpatel@apple.com>
Subject: Re: [whopr] Design/implementation alternatives for the driver and WPA
References: <b798aad50806030945r7e056592kf4584bf2de323164@mail.gmail.com> 	<96A87E23-CD76-41E3-A4BD-DD399C847F17@apple.com> 	<m3iqwp2sal.fsf@google.com> 	<D054C487-3C4A-4BCB-A27A-513412B5837E@apple.com> 	<m3wsl50yun.fsf@google.com> 	<48F70208-61C2-4D44-9531-E682C74647E6@apple.com> 	<38a0d8450806050141r46e19d1kc39c2564d8c78fa0@mail.gmail.com> 	<m3d4mwx9r4.fsf@google.com> 	<99880898-CC99-4F3B-99AD-4109D4C65E27@apple.com> 	<m3hcc7vktx.fsf@google.com> 	<6CB40CA7-C535-4659-AC0D-6D76D409A721@apple.com>
From: Ian Lance Taylor <iant@google.com>
Date: Thu, 05 Jun 2008 21:03:00 -0000
In-Reply-To: <6CB40CA7-C535-4659-AC0D-6D76D409A721@apple.com> (Nick Kledzik's message of "Thu\, 5 Jun 2008 11\:49\:38 -0700")
Message-ID: <m3r6bbtx0t.fsf@google.com>
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-IsSubscribed: yes
Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc/>
List-Post: <mailto:gcc@gcc.gnu.org>
List-Help: <http://gcc.gnu.org/ml/>
Sender: gcc-owner@gcc.gnu.org
X-SW-Source: 2008-06/txt/msg00129.txt.bz2

Nick Kledzik <kledzik@apple.com> writes:

>> How does the linker tell LTO that a symbol may be inlined, but must
>> also be externally visible?
> The linker just tells LTO which symbols must remain.  The LTO engine
> is free to inline anything that would improve codegen, with the
> exception
> that any weak definition that must remain (preserved) cannot be inlined.

I'll just note that that isn't optimal for ELF when producing an
executable.

Ian