This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Lazy allocation of DECL_ASSEMBLER_NAME


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]