From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18680 invoked by alias); 1 Mar 2004 22:03:26 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 18672 invoked from network); 1 Mar 2004 22:03:25 -0000 Received: from unknown (HELO mail.codesourcery.com) (65.74.133.6) by sources.redhat.com with SMTP; 1 Mar 2004 22:03:25 -0000 Received: (qmail 23365 invoked from network); 1 Mar 2004 22:03:24 -0000 Received: from 227.148-60-66-fuji-dsl.static.surewest.net (HELO codesourcery.com) (mitchell@66.60.148.227) by mail.codesourcery.com with SMTP; 1 Mar 2004 22:03:24 -0000 Message-ID: <4043B327.7040009@codesourcery.com> Date: Mon, 01 Mar 2004 22:03:00 -0000 From: Mark Mitchell Organization: CodeSourcery, LLC User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 MIME-Version: 1.0 To: Geoff Keating CC: zack@codesourcery.com, dalej@apple.com, gcc@gcc.gnu.org Subject: Re: Lazy allocation of DECL_ASSEMBLER_NAME References: <200403011910.i21JAWFo013955@sirius.codesourcery.com> <87oergpcfv.fsf@egil.codesourcery.com> <200403012021.i21KL77a010961@desire.geoffk.org> <40439C24.2050804@codesourcery.com> <87fzcsp8tz.fsf@egil.codesourcery.com> <200403012146.i21LkNqs011033@desire.geoffk.org> In-Reply-To: <200403012146.i21LkNqs011033@desire.geoffk.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00117.txt.bz2 Geoff Keating wrote: >>Yes. I have partial code implementing this. The fiddliest part is >>the nontransitive type comparison problem that Dale is encountering. >>I personally think that the front end should go to whatever lengths >>are necessary to present just one type to the language-independent >>compiler, even across multiple translation units, even in the presence >>of a nontransitive type system. I think this is easier than it might >>sound - the trick I have in mind is permuting TYPE_MAIN_VARIANT so >>that it's always the appropriate choice for *this* translation unit. >> >> > >It might be difficult to determine which translation unit is "this >unit" at any given point; you might have code that does: > > There are lots of things that are hard about inter-module analysis, as you of course know. :-) It's an inherent design problem: we're essentially trying to combine multiple C translation units into a single C translation unit, and C is not a language that permits that. Most object file formats are designed to support C, so we see these problems at that level too. For example, in the past, I've complained about the fact that if we have two static functions with the same name in different translation units, the single .o that we generate renames them. In the example that you give, the program is not conforming if the definitions of "struct foo" are not identical across translation units. (Or, at least, that would be true in ISO C++. It might not have to be true in ISO C. You may know more than I.) In any case, if the structures do not match up across the translation units, we should just not combine them. That is certainly not the common case. We'll likely break some aspects of inter-module optimization when we fix some of the single translation-unit issues. That is what we get for collectively not agreeing on a single development plan. -- Mark Mitchell CodeSourcery, LLC (916) 791-8304 mark@codesourcery.com