On 02/12/2015 11:27 AM, Jason Merrill wrote:
On 02/12/2015 01:04 PM, Aldy Hernandez wrote:
On 02/10/2015 02:52 AM, Richard Biener wrote:
On Fri, Feb 6, 2015 at 5:42 PM, Aldy Hernandez wrote:
Of course I wonder why you need to separate handling of functions and
variables
The variables need
On 02/12/2015 01:04 PM, Aldy Hernandez wrote:
On 02/10/2015 02:52 AM, Richard Biener wrote:
On Fri, Feb 6, 2015 at 5:42 PM, Aldy Hernandez wrote:
Of course I wonder why you need to separate handling of functions and
variables
The variables need to be handled earlier, else the call to
analy
On 02/10/2015 02:52 AM, Richard Biener wrote:
On Fri, Feb 6, 2015 at 5:42 PM, Aldy Hernandez wrote:
Of course I wonder why you need to separate handling of functions and variables
The variables need to be handled earlier, else the call to
analyze_functions() will remove some optimized glob
On 02/10/2015 05:52 AM, Richard Biener wrote:
I also wonder why you restrict it to functions with a GIMPLE body.
Likewise for
struct foo { int i; };
I guess these should depend on -feliminate-unused-debug-symbols and
-feliminate-unused-debug-types.
Jason
On Fri, Feb 6, 2015 at 5:42 PM, Aldy Hernandez wrote:
>
>>> +&& DECL_CONTEXT (snode->decl)
>>> +&& TREE_CODE (DECL_CONTEXT (snode->decl)) != FUNCTION_DECL)
>>
>>
>> I think this should be !decl_function_context (snode->decl), in case
>> there's a class or BLOCK between the symbol and its e
OK with that change.
Sweet! Thanks for everything.
Though he's been silent, I bet Richi is secretly dancing :-).
On 02/06/2015 11:42 AM, Aldy Hernandez wrote:
I was actually thinking of using dwarf2out_early_finish() to mop things up as
we generate early (or stream out) other auxiliary tables (pubname_table,
pubtype_table, file_table, etc). More details on that later. If so, can I
leave it as is?
OK.
+&& DECL_CONTEXT (snode->decl)
+&& TREE_CODE (DECL_CONTEXT (snode->decl)) != FUNCTION_DECL)
I think this should be !decl_function_context (snode->decl), in case
there's a class or BLOCK between the symbol and its enclosing function.
Done, also for the iteration through reachable func
On 02/05/2015 08:15 PM, Aldy Hernandez wrote:
Absolutely nothing, basically because #if 0 would have been too obvious. It
was actually there to test if you were on your game. You passed
Yay?
The attached patch still passes the guality tests with no regressions. My
apologies for the lack
And what about namespace-scope variables? Maybe instead of checking for
TRANSLATION_UNIT_DECL context this should check non-function context.
Done.
+ /* This is the second iteration through the global symbols. Here we
+ pick up function statics that have been discovered by the call
On 02/04/2015 07:27 PM, Aldy Hernandez wrote:
+ /* Anything who's context is not a TRANSLATION_UNIT_DECL will
+ be handled by either handling reachable functions below, or
+ by generating DIEs for types. */
"whose"
And what about namespace-scope variables? Maybe inste
Howdy!
Such simple requests. Such a pain in the ass to implement :).
I know Richard will be tickled pink with the attached patch-- well, at
least with the general approach, as generically handling DECLs has been
his desire all along. I hope I got it right, as it was a royal pain to
get the
On 02/01/2015 10:15 PM, Aldy Hernandez wrote:
Well, we'd also have to output globals, which we're currently not doing
in finalize_compilation_unit. But if you're ok with generating early
dwarf for functions as well as globals/statics from
finalize_compilation_unit() then we could get rid of virt
On 01/31/2015 10:22 PM, Jason Merrill wrote:
On 01/30/2015 06:49 PM, Aldy Hernandez wrote:
+ FOR_EACH_FUNCTION_WITH_GIMPLE_BODY (node)
+if (DECL_ABSTRACT_ORIGIN (node->decl))
If we do this for all functions, not just those with
DECL_ABSTRACT_ORIGIN set...
+ /* FIXME: What does this do
On 02/01/2015 03:42 AM, Richard Biener wrote:
I always thought a user expects debug information for all entities in the
source, not only those useb by the (optimized) binary.
Right, but the clones aren't in the source individually; the primary
constructor that they are cloned from should alwa
On February 1, 2015 7:22:29 AM CET, Jason Merrill wrote:
>On 01/30/2015 06:49 PM, Aldy Hernandez wrote:
>> + FOR_EACH_FUNCTION_WITH_GIMPLE_BODY (node)
>> +if (DECL_ABSTRACT_ORIGIN (node->decl))
>
>If we do this for all functions, not just those with
>DECL_ABSTRACT_ORIGIN set...
>
>> + /* FI
On January 30, 2015 11:04:23 PM CET, Jason Merrill wrote:
>On 01/30/2015 03:36 PM, Aldy Hernandez wrote:
>> /* It is possible to have both DECL_ABSTRACT_P and DECLARATION be
>true if we
>> started to generate the abstract instance of an inline, decided
>to output
>> its containing clas
On 01/30/2015 06:49 PM, Aldy Hernandez wrote:
+ FOR_EACH_FUNCTION_WITH_GIMPLE_BODY (node)
+if (DECL_ABSTRACT_ORIGIN (node->decl))
If we do this for all functions, not just those with
DECL_ABSTRACT_ORIGIN set...
+ /* FIXME: What does this do for templates? I think we don't want to
+
On 01/30/2015 02:04 PM, Jason Merrill wrote:
On 01/30/2015 03:36 PM, Aldy Hernandez wrote:
/* It is possible to have both DECL_ABSTRACT_P and DECLARATION be
true if we
started to generate the abstract instance of an inline, decided
to output
its containing class, and proceeded to emi
On 01/30/2015 03:36 PM, Aldy Hernandez wrote:
/* It is possible to have both DECL_ABSTRACT_P and DECLARATION be true if we
started to generate the abstract instance of an inline, decided to output
its containing class, and proceeded to emit the declaration of the inline
from the
On 01/28/2015 10:51 AM, Jason Merrill wrote:
On 01/28/2015 01:29 PM, Aldy Hernandez wrote:
+ /* It is rather unfortunate that Cilk creates trees this late +
(during gimplification). However, until this gets fixed, +
specially handle emitting DWARF for this new function and +
immediately clean
On 01/28/2015 01:29 PM, Aldy Hernandez wrote:
+ /* It is rather unfortunate that Cilk creates trees this late
+ (during gimplification). However, until this gets fixed,
+ specially handle emitting DWARF for this new function and
+ immediately clean up the limbo_die_list where the ne
On 01/16/2015 02:55 AM, Richard Biener wrote:
On Fri, Jan 16, 2015 at 4:11 AM, Jason Merrill wrote:
On 01/15/2015 09:58 PM, Aldy Hernandez wrote:
I hoped we wouldn't need the limbo list at all ... that is, parent DIEs
are always present when we create children. I think that should
work in p
And now with the actual patch ;-).
* c-family/cilk.c (create_cilk_wrapper_body): Emit debug
information for wrappers.
* cp/decl2.c (emit_debug_for_namespace): Add FIXME note for
templates.
* cp/optimize.c (maybe_clone_body): Emit early debug for clones.
On 01/27/2015 12:51 PM, Jason Merrill wrote:
On 01/23/2015 01:45 PM, Aldy Hernandez wrote:
It would expect [the flush] to be before free_lang_data and LTO
streaming.
The reason this wouldn't make a difference is because, as it stands,
dwarf for the clones are not generated until final.c:
i
On 01/23/2015 01:45 PM, Aldy Hernandez wrote:
It would expect [the flush] to be before free_lang_data and LTO streaming.
The reason this wouldn't make a difference is because, as it stands,
dwarf for the clones are not generated until final.c:
if (!DECL_IGNORED_P (current_function_decl))
On Fri, Jan 23, 2015 at 7:45 PM, Aldy Hernandez wrote:
> Phew... ok, I'm a little stuck here with the interaction between dwarf2out
> and LTO, and I'm hoping y'all can shed some light. Please bear with me
> through the verbosity, it gets clearer (I hope) near the end.
>
>
> On 01/16/2015 12:45 PM
Phew... ok, I'm a little stuck here with the interaction between
dwarf2out and LTO, and I'm hoping y'all can shed some light. Please
bear with me through the verbosity, it gets clearer (I hope) near the end.
On 01/16/2015 12:45 PM, Jason Merrill wrote:
On 01/16/2015 12:50 PM, Aldy Hernandez w
On 01/16/2015 12:50 PM, Aldy Hernandez wrote:
Can you remove the first flush and just do it in the second place?
If I only flush the limbo list in the second place, that's basically
what mainline does, albeit abstracted into a function. I thought the
whole point was to get rid of the limbo lis
On January 16, 2015 5:31:49 PM CET, Jason Merrill wrote:
>On 01/16/2015 05:55 AM, Richard Biener wrote:
>> I'd hope that in the very distant future all early DIEs would be
>"created"
>> by the frontends (that is, dwarf2out.c wouldn't walk into
>parents/siblings
>> so much).
>
>Are you thinking tha
On 01/16/2015 08:31 AM, Jason Merrill wrote:
On 01/16/2015 05:55 AM, Richard Biener wrote:
I'd hope that in the very distant future all early DIEs would be
"created"
by the frontends (that is, dwarf2out.c wouldn't walk into
parents/siblings
so much).
Are you thinking that the front end would i
On 01/15/2015 07:11 PM, Jason Merrill wrote:
On 01/15/2015 09:58 PM, Aldy Hernandez wrote:
Now back to limbdo_die_list... My approach is to flush the limbo list,
generically, after the front-ends have finished, by adding a new
"early_finish" debug hook. This gets rid of any permanence into LT
On 01/16/2015 05:55 AM, Richard Biener wrote:
I'd hope that in the very distant future all early DIEs would be "created"
by the frontends (that is, dwarf2out.c wouldn't walk into parents/siblings
so much).
Are you thinking that the front end would immediately call a debug hook
for every block,
On Fri, Jan 16, 2015 at 4:11 AM, Jason Merrill wrote:
> On 01/15/2015 09:58 PM, Aldy Hernandez wrote:
>>
>> The attached patch generates early DIEs for the C++
>> clones in the C++ parser.
>
>
> This strikes me as an unnecessary abstraction violation.
I'd hope that in the very distant future all
On 01/15/2015 09:58 PM, Aldy Hernandez wrote:
The attached patch generates early DIEs for the C++
clones in the C++ parser.
This strikes me as an unnecessary abstraction violation.
+ /* Emit debug information for clones. */
+ symtab_node *node;
+ FOR_EACH_DEFINED_SYMBOL (node)
+if (DE
Hi Jason. Hi Richard.
While adjusting the limbdo_die_list for early debug I noticed we weren't
early generating C++ constructors/destructors. This got me on a detour
of sorts.
I noticed dwarf2out's gen_member_die() disallows generation of clones
earlier, by design:
/* Don't include
36 matches
Mail list logo
