This is the mail archive of the 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: [RFC] PR 12389

On Sun, 19 Oct 2003 10:23:24 +0200, Jan Hubicka <> wrote:

>> On Sun, 19 Oct 2003 10:00:39 +0200, Jan Hubicka <> wrote:

>> > Also what about COMDAT functions?  I guess the debug info should be
>> > conservative then and always claim that function has been inlined as it
>> > may be inlined in the other compilation unit, right?
>> I don't see what COMDAT has to do with this.  If the function is inlined in
>> another translation unit, it will have debug info there.
> So the debug info above is generated for each inline copy of the given
> function separately?  How we can end up with DW_INL_declared_not_inlined
> then?

If a function is declared inline but not actually inlined, we may still
separate it into abstract and inline instances, in which case we would use
DW_INL_declared_not_inlined.  This is useful for -feliminate-dwarf2-dups,
which relies on the debug info for a particular header being identical in
different translation units.

> In the case it is generated just once, I would expect commonized
> functions after linking to also commonize the debug info so it should be
> conservative?

When we use section groups, we can discard the debug info for a function
along with the function itself.  But in the case of an inline function,
this only applies to the concrete instance; we will still have a separate
abstract instance.


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