This is the mail archive of the gcc-patches@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: [trunk<-vta] Re: [vta,vta4.3,trunk?] defer computation of DECL_ASSEMBLER_NAME in dwarf2out


On Jun  2, 2009, Diego Novillo <dnovillo@google.com> wrote:

> On Tue, Jun 2, 2009 at 05:14, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>> On Mon, Jun 1, 2009 at 10:04 AM, Alexandre Oliva <aoliva@redhat.com> wrote:
>>> On Sep 11, 2008, Alexandre Oliva <aoliva@redhat.com> wrote:
>>> 
>>>> Another issue that came up in -fcompare-debug dumps. ÂA symbol whose
>>>> assembler name didn't get computed when compiling without debug info
>>>> had it computed when compiling with debug info. ÂIn C++, computing the
>>>> assembler name sometimes causes templates to be instantiated, because
>>>> of mangling. ÂThis is Bad (TM): debug info shouldn't ever affect
>>>> template instantiation. ÂThis patch fixes it.
>>> 
>>> Ok for trunk?
>> 
>> Please coordinate with LTO folks (and I'd like to hear C++ maintainer
>> opinions). ÂISTR LTO has similar issues with DECL_ASSEMBLER_NAME.

> In LTO, the assembler name is computed fairly early when removing all
> FE data in pass_ipa_free_lang_data.  Every decl that passes the test
> need_assembler_name_p() is given one.

I get the impression that this should be fine, as far as the C++
standard is concerned.

The bug here was not so much about when templates were instantiated, but
rather about their being instantiated or not depending on -g.

If LTO does not make DECL_ASSEMBLER_NAME computation change depending on
-g, there's no overlap or need for coordination.

Now, if LTO changes the logic of computing DECL_ASSEMBLER_NAMES *only*
when LTO is enabled, then it may affect the generated code and even the
compiler error output, and it may add compile time (instantiating
templates) that non-LTO compiles wouldn't incur.

That's indeed the same kind of issue I'm facing in debug-info code or
internal compiler debugging code, but that the specification of the
problem sounds similar doesn't mean the solutions should be similar, or
that one should get in the way of the other.

-- 
Alexandre Oliva, freedom fighter    http://FSFLA.org/~lxoliva/
You must be the change you wish to see in the world. -- Gandhi
Be Free! -- http://FSFLA.org/   FSF Latin America board member
Free Software Evangelist      Red Hat Brazil Compiler Engineer


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