This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Lazy allocation of DECL_ASSEMBLER_NAME
Mark Mitchell <mark@codesourcery.com> writes:
> Geoff Keating wrote:
>>>From: Zack Weinberg <zack@codesourcery.com>
>>>The thrust of the (currently incomplete) work is now to always use
>>>the oldest decl, adding information from later ones as necessary.
>>
>>That does sound like a good plan. The difficulty will be in ensuring
>>that the newer decl is not used before duplicate_decls is called on
>>the pair of decls; in particular, this will require some changes to
>>IMA, merge_translation_unit_decls will need to go away because
>>duplicate_decls will have to be called when the decl is seen rather
>>than later on.
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.
Since these patches are only going onto mainline for the time being, I
expect the next couple patches will fix all the problems with
single-translation-unit mode at the expense of disabling IMA, and then
we can come back to IMA's problems.
>> Is this going to be necessary for 3.4?
>>
> No.
>
> Unfortunately, we hosed ourselves for 3.4. Zack started on this work
> to fix some problems in the C front end that have been there forever,
> and unfortunately didn't finish the project. So, now we have some old
> bugs fixed but we also have some regressions. As you say, it's too
> dramatic a change to try to fix all of the problems for 3.4, so we're
> going to have to live with some regressions.
I'm hoping that the patches will prove stable enough to backport in
the 3.4.1 time frame, and I'm maintaining a 3.4 backport tree with
that in mind.
zw