>>> But if the consensus turns out to be that enumerators should be in
>>> pubnames, wouldn't it also be fairly easy to change prune_unused_types
>>> so that it doesn't mark enumerators, and change output_pubnames to
>>> skip enumerators that have been pruned?
>>
>> This makes sense to me.
>
> Encl
On Mon, Jun 25, 2012 at 7:13 PM, Mike Stump wrote:
> On Jun 25, 2012, at 3:15 PM, Sterling Augustine wrote:
>> On Sat, Jun 23, 2012 at 3:55 AM, Dominique Dhumieres
>> wrote:
As I don't have access to a Darwin machine to test a fix, would you
mind updating the test?
>>>
>>> The failures
Committed as posted.
On Mon, Jun 25, 2012 at 8:35 PM, Jason Merrill wrote:
> OK.
>
> Jason
OK.
Jason
On Jun 25, 2012, at 3:15 PM, Sterling Augustine wrote:
> On Sat, Jun 23, 2012 at 3:55 AM, Dominique Dhumieres
> wrote:
>>> As I don't have access to a Darwin machine to test a fix, would you
>>> mind updating the test?
>>
>> The failures are gone with the obvious patch:
> I will commit this if
On Fri, Jun 22, 2012 at 9:46 PM, Jason Merrill wrote:
> On 06/22/2012 02:15 PM, Cary Coutant wrote:
>>
>> But if the consensus turns out to be that enumerators should be in
>> pubnames, wouldn't it also be fairly easy to change prune_unused_types
>> so that it doesn't mark enumerators, and change
On Sat, Jun 23, 2012 at 3:55 AM, Dominique Dhumieres wrote:
>> As I don't have access to a Darwin machine to test a fix, would you
>> mind updating the test?
>
> The failures are gone with the obvious patch:
>
> diff -up ../_clean/gcc/testsuite/gcc.dg/pubtypes-2.c
> gcc/testsuite/gcc.dg/pubtypes-
> As I don't have access to a Darwin machine to test a fix, would you
> mind updating the test?
The failures are gone with the obvious patch:
diff -up ../_clean/gcc/testsuite/gcc.dg/pubtypes-2.c
gcc/testsuite/gcc.dg/pubtypes-2.c
--- ../_clean/gcc/testsuite/gcc.dg/pubtypes-2.c 2009-11-25 18:15:43
On 06/22/2012 02:15 PM, Cary Coutant wrote:
But if the consensus turns out to be that enumerators should be in
pubnames, wouldn't it also be fairly easy to change prune_unused_types
so that it doesn't mark enumerators, and change output_pubnames to
skip enumerators that have been pruned?
This m
> prune_unused_types marks everything in the pubnames_table. If the
> enumerators go in the pubname table (but the enum itself goes in the
> pubtype table), then the unused enum becomes reachable from the
> pubnames table.
>
> The least complicated solution is to put them back in the
> pubtypes_tab
On Fri, Jun 22, 2012 at 2:47 AM, Dominique Dhumieres wrote:
>> I've heard reports of new test failures due to this patch:
>>
>> FAIL: gcc.dg/pubtypes-2.c scan-assembler long+[ \\t]+0x6a+[ \\t]+[#;]+[
>> \\t]+Length of Public Type Names Info
>> FAIL: gcc.dg/pubtypes-3.c scan-assembler long+[ \\t]+
On Fri, Jun 22, 2012 at 2:35 AM, Jason Merrill wrote:
> FAIL: g++.dg/debug/dwarf2/static-data-member2.C -std=gnu++98
> scan-assembler-not DW_TAG_enumerator
> FAIL: g++.dg/debug/dwarf2/static-data-member2.C -std=gnu++98
> scan-assembler-not DW_TAG_enumeration_type
> FAIL: g++.dg/debug/dwarf2/static
On Fri, Jun 22, 2012 at 2:47 AM, Dominique Dhumieres wrote:
>> I've heard reports of new test failures due to this patch:
>>
>> FAIL: gcc.dg/pubtypes-2.c scan-assembler long+[ \\t]+0x6a+[ \\t]+[#;]+[
>> \\t]+Length of Public Type Names Info
>> FAIL: gcc.dg/pubtypes-3.c scan-assembler long+[ \\t]+
> I've heard reports of new test failures due to this patch:
>
> FAIL: gcc.dg/pubtypes-2.c scan-assembler long+[ \\t]+0x6a+[ \\t]+[#;]+[
> \\t]+Length of Public Type Names Info
> FAIL: gcc.dg/pubtypes-3.c scan-assembler long+[ \\t]+0x6a+[ \\t]+[#;]+[
> \\t]+Length of Public Type Names Info
> FAIL
On 06/21/2012 11:18 AM, Sterling Augustine wrote:
Committed as attached. Thanks for your reviews.
I've heard reports of new test failures due to this patch:
FAIL: gcc.dg/pubtypes-2.c scan-assembler long+[ \\t]+0x6a+[ \\t]+[#;]+[
\\t]+Length of Public Type Names Info
FAIL: gcc.dg/pubtypes-3.c
Committed as attached. Thanks for your reviews.
Sterling
gcc/ChangeLog
2012-06-21 Sterling Augustine
Cary Coutant
* dwarf2out.c (is_cu_die, is_namespace_die, is_class_die,
add_AT_pubnames, add_enumerator_pubname, want_pubnames): New functions.
(comdat_type_
OK.
Jason
>> + /* If we're putting types in their own .debug_types sections,
>> + the .debug_pubtypes table will still point to the compile
>> + unit (not the type unit), so we want to use the offset of
>> + the skeleton DIE (if there is one). */
>> + if (pub
On 06/19/2012 10:12 AM, Sterling Augustine wrote:
+ /* If we're putting types in their own .debug_types sections,
+the .debug_pubtypes table will still point to the compile
+unit (not the type unit), so we want to use the offset of
+the skeleton DIE (if
On Wed, Jun 13, 2012 at 10:47 PM, Jason Merrill wrote:
> On 06/13/2012 04:26 PM, Sterling Augustine wrote:
>>>
>>> I lean toward -g myself, since there doesn't seem to be a strong rule one
>>> way or the other.
>>
>>
>> Unless there are further comments, I'll stick with -g then.
>>
>> I think that
On 06/13/2012 04:26 PM, Sterling Augustine wrote:
I lean toward -g myself, since there doesn't seem to be a strong rule one
way or the other.
Unless there are further comments, I'll stick with -g then.
I think that covers all the comments, so I think I will commit this
Friday morning unless I
> I lean toward -g myself, since there doesn't seem to be a strong rule one
> way or the other.
Unless there are further comments, I'll stick with -g then.
I think that covers all the comments, so I think I will commit this
Friday morning unless I hear anything further.
Sterling
On 06/08/2012 05:22 PM, Cary Coutant wrote:
I kind of prefer -g, but I did notice that it's -fdebug-types-section,
so I could go with -f[no-]pubnames (or, as Jakub suggests,
-f[no-]debug-pubnames-section). On the other hand, there's
-g[no-]record-gcc-switches. What would you prefer?
If we change
On Fri, Jun 8, 2012 at 3:03 PM, Sterling Augustine
wrote:
[Regarding generating pubnames]
> OK, I've updated the patch with all these additional comments. Just
> waiting on the decision between -f and -g. I'll repost and then commit
> it when that is settled--hopefully soon.
>
> Next up, the big
On Fri, Jun 8, 2012 at 2:22 PM, Cary Coutant wrote:
>> Hmm, I thought the convention for this sort of flag was to start with -f,
>> that -g flags were only for selecting the type and level of debug info. But
>> I see that there are other debug dialect switches that use -g, so I guess
>> this is O
> Hmm, I thought the convention for this sort of flag was to start with -f,
> that -g flags were only for selecting the type and level of debug info. But
> I see that there are other debug dialect switches that use -g, so I guess
> this is OK.
I kind of prefer -g, but I did notice that it's -fdeb
On Fri, Jun 08, 2012 at 02:45:09PM -0400, Jason Merrill wrote:
> On 06/01/2012 01:58 PM, Sterling Augustine wrote:
> >It also adds and documents a new option "-g[no-]pubtypes" which allows users
> >to generate pubtypes even if the target disables them by default.
>
> Hmm, I thought the convention
On 06/01/2012 01:58 PM, Sterling Augustine wrote:
It also adds and documents a new option "-g[no-]pubtypes" which allows users
to generate pubtypes even if the target disables them by default.
Hmm, I thought the convention for this sort of flag was to start with
-f, that -g flags were only for
The enclosed patch updates the earlier patch to address all of the feedback I
have gotten regarding generating pubnames. It fixes the offset problem in
the pubtypes table; switches DW_AT_pubtypes to a flag and so on.
It also adds and documents a new option "-g[no-]pubtypes" which allows users
to g
29 matches
Mail list logo
