> That section is "Writing Robust Programs." Robustness guarantees have
> to be different for utilities and servers. A robust server doesn't
> crash because of arbitrary user input, but there are servers that
> demangle names that are provided by the user. So we need two modes for
> the demangle
> On testcases like that from PR60243 CFG build is dominated by
> assign_discriminators because it expands locations again and again
> and this got more expensive over the time.
>
> Cary - can you explain the overall logic of assign_discriminators,
> specifically why if the last stmt of a block has
> Ping. Is this alright to apply now or should I wait for Stage 1?
>
> * plugin-api.h (ld_plugin_get_wrap_symbols): New
> plugin interface.
I'd say go ahead and apply the patch in binutils, and wait for Stage 1
to sync back to GCC, unless someone there OKs it sooner.
Nick, is that OK?
-cary
> config-patches has nothing to do with the GCC config/ directory. It is
> the place to send patches for config.{guess,sub}. Taking if off the
> cc: line.
Sorry, Ben. I've started a new thread on gcc-patches for the config/
part of this patch.
https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01138.h
Please see this patch posted to the binutils list:
https://sourceware.org/ml/binutils/2018-02/msg00260.html
where Joshua proposes to add the ax_pthread.m4 script, from the
autoconf macro archive, to the config/ directory in order to improve
gold's configure-time detection of thread support.
I
>> First, do you or your company have a copyright assignment on file with FSF?
>
> I do not. What is the process for that? I don't need a company
> assignment, an individual contributor for me will be fine.
>
> If I sign that for this project, would it also cover GCC, or do I need
> one for each?
> The autotools library macro (AX_PTHREAD) is now used to detect if
> pthreads is present and multi-threaded linking in gold is automatically
> enabled if it is found. This enables multi-threaded gold on platforms
> where pthreads is enabled via other methods than just -lpthread (e.g.
> MinGW)
>
>
> include/ChangeLog:
> 2017-11-09 Stephen Crane
>
> * plugin-api.h: Add new plugin hook to allow processing of input
> files added by a plugin.
> (ld_plugin_new_input_handler): New funcion hook type.
> (ld_plugin_register_new_input): New interface.
> (LDPT
> 2017-09-21 Stephen Crane
>
> * plugin-api.h: Add new hook to the plugin transfer vector to
> support assigning plugin-generated sections to unique output
> segments.
> (ld_plugin_register_new_input): New hook.
> (ld_plugin_tag): Add LDPT_REGISTER_NEW_INPU
>> This is OK so far, but the DW_AT_alignment attribute also needs to be
>> added to the checksum computation in die_checksum and
>> die_checksum_ordered.
>
> Thanks. I see what to do in die_checksum_ordered, but die_checksum? It
> seems to handle attributes by value class, and AFAICT the classes
> for gcc/ChangeLog
>
> PR debug/63238
> * dwarf2out.c (clone_as_declaration): Drop DW_AT_alignment.
> (add_alignment_attribute): New.
> (base_type_die): Add alignment attribute.
> (subrange_type_die): Likewise.
> (modified_type_die): Likewise.
>
> OK on this proposal and to install this patch to gcc trunk?
>
> Hi GDB, Binutils maintainer:
>
> OK on this proposal and install this patch to binutils-gdb master?
>
> include/
> 2016-11-29 Richard Earnshaw
> Jiong Wang
>
> * dwarf2.def (DW_OP_AARCH64_operation): Re
> I'd like to point out that especially the vendor range of DW_OP_* is
> extremely scarce resource, we have only a couple of unused values, so taking
> 3 out of the remaining unused 12 for a single architecture is IMHO too much.
> Can't you use just a single opcode and encode which of the 3 operati
How about if instead of special DW_OP codes, you instead define a new
virtual register that contains the mangled return address? If the rule
for that virtual register is anything other than DW_CFA_undefined,
you'd expect to find the mangled return address using that rule;
otherwise, you would use t
I'm committing this patch to sync the top-level configure with binutils-gdb.
-cary
2016-03-17 Cary Coutant
* configure.ac: Add mips and s390 to the gold target check.
* configure: Regenerate.
Index: conf
I'm committing the attached patch to sync include/plugin-api.h with binutils.
-cary
2016-03-03 Than McIntosh
* plugin-api.h: Add new hooks to the plugin transfer vector to
to support querying section alignment and section size.
(ld_plugin_get_input_section_alignment):
> Thanks, will make those changes. Do you recommend a different name
> for this flag like -fmake-comdat-functions-static?
Well, the C++ ABI refers to this as "vague linkage." It may be a bit
too long or too ABI-specific, but maybe something like
-f[no-]use-vague-linkage-for-functions or
-f[no-]fu
> +@item -fno-weak-comdat-functions
> +@opindex fno-weak-comdat-functions
> +Do not use weak symbol support for comdat non-virtual functions, even if it
> +is provided by the linker. By default, G++ uses weak symbols if they are
> +available. This option is useful when comdat functions generated
Based on Richard's suggestion, I have a patch to localize comdat
functions which seems like a very effective solution to this problem.
The text size increase is limited to the extra comdat copies generated
for the specialized modules (modules with unsafe options) which is
u
> I'm currently working on migrating debugging information for Ada from GNAT
> encodings to standard DWARF. At the moment, I have worked on two topics that
> I believe are not (completely) supported in standard DWARF:
>
> - fixed point types with arbitrary scale factors;
> - scalar types with b
I'm retiring, and my last day at google is this Friday, April 10. I
plan to continue to contribute to GCC and binutils in my retirement.
I've updated the MAINTAINERS file to use my personal address,
ccout...@gmail.com.
-cary
2015-04-08 Cary Coutant
* MAINTAINERS: Updat
>> @@ -21817,22 +21823,39 @@ out_subprog_directive (subprog_entry *su
>> {
>>tree decl = subprog->decl;
>>tree decl_name = DECL_NAME (decl);
>> - const char *name;
>> + tree origin;
>
> Explicitly initialize origin to NULL_TREE;
Done.
>> + /* For inlined subroutines, use the linkage n
>> did with -gdwarf-4). We're still putting a version number of 2 in the
>> compilation unit header! But I guess even upgrading the CU header to
>
> We are not. On most targets we default to -gdwarf-4 and emit v. 4:
Oops, sorry, you're right. I carelessly misread this:
dw2_asm_output_data (2,
> PS: Talking about DWARF5, do you know when it will be available as public
> draft? I am especially looking forward to
> http://dwarfstd.org/ShowIssue.php?issue=121221.1 (Allow DW_AT_type with
> DW_TAG_string_type), which would be a low-hanging fruit in terms of
> implementation. Contrary to the a
> DW_LANG_Fortran03 and DW_LANG_Fortran08 DW_AT_language values were recently
> accepted into DWARF5. This patch changes GCC to handle those similarly to
> how e.g. the -std=c++11, -std=c++14 or -std=c11 are handled.
>
> As it will take some time for consumers to catch up, I'm enabling that
> only
>>If you're going to insist on calling the release_input_file API from
>>the claim_file handler, I'm going to have to fix gold to ignore the
>>call to avoid a premature unlock of the object file.
>
> What's the proper solution for not leaking those filedescriptors?
There was a bug in gold where it
Ping^3. Should I be addressing this to someone else?
-cary
On Mon, Dec 1, 2014 at 2:15 PM, Cary Coutant wrote:
> Ping^2.
>
> -cary
>
> On Wed, Oct 29, 2014 at 12:04 PM, Cary Coutant wrote:
>> Ping?
>>
>> On Mon, Oct 20, 2014 at 10:31 AM, Cary Coutant wrote:
&g
The plugin is not supposed to call release_input_file from the
claim_file handler. That interface is only for releasing a file
descriptor obtained via get_input_file during the all_symbols_read
callback. When the linker calls the claim_file handler, the file
descriptor is open, and the plugin is re
> I am forwarding this reply to Cary Coutant, Diego Novillo and Le-Chun
> Wu, as they were listed as the plugin maintainers.
>
> Cary, Diego, Le-Chun, please let me know if you are on it, or if I
> should send it to someone else.
Sorry, this isn't my kind of plugin -- I'm
Here's a very slightly revised patch, fixing a couple of bugs found
during GDB testing.
In out_logical_entry, I should pass along the value of is_stmt when
creating a logical for the calling context, so that we get a
breakpoint location for the point of call:
context = out_logical_entry (t
>>> Is it correct that block_num has 1-1 mapping with block_table. And
>>> block_table has 1-1 mapping with logical_table?
>>
>> The first part, yes -- there's one entry in block_table for each
>> block_num in the function tree. But two or more blocks may map to a
>> single logical, and some blocks
>> > Not quite clear why we need block_table. This table is not gonna be
>> > emitted. And we can easily get subprog_entry through block->block_num
>>
>> When final_scan_insn() calls dwarf2out_begin_block(), all it passes is
>> a block number. I don't know a way to get from block number to the
>> b
>> +static subprog_entry *
>> +add_subprog_entry (tree decl, bool is_inlined)
>> +{
>> + subprog_entry **slot;
>> + subprog_entry *entry;
>> +
>> + slot = subprog_table->find_slot_with_hash (decl, DECL_UID (decl), INSERT);
>> + if (*slot == HTAB_EMPTY_ENTRY)
>> +{
>> + entry = XCNEW (s
>>>This patch makes claim_file_handler to call release_input_file after it
>>>finishes processing input file. OK for trunk?
>>
>> OK. How did you test this?
>
> I did normal bootstrap and "make check" on Linux/x86-64.
> I also run ld.bfd and ld.gold by hand to verify that release_input_file
> is
Ping^2.
-cary
On Wed, Oct 29, 2014 at 12:04 PM, Cary Coutant wrote:
> Ping?
>
> On Mon, Oct 20, 2014 at 10:31 AM, Cary Coutant wrote:
>> This patch adds support for the mips target in gold.
>>
>> OK to commit?
>>
>> -cary
>>
>>
>> 2014-
[+cc Michael Eager]
> Rather than having to lobby to keep it unchanged because we jumped the gun,
> can we lobby to get the number assigned in the near future rather than in
> the potentially far future? That feels more cooperative to me :-)
>
> Would that make Michael happier?
I'm pretty confid
> Presumably we don't have any sense when the values will be assigned, right?
> Any chance we could speed that along a bit?
As Jason said, the value in the current draft is unlikely to change,
and I think he and I can probably lobby to keep it unchanged if there
any danger that the numbering will
Backport pending upstream patch to fix demangler crash.
https://gcc.gnu.org/ml/gcc-patches/2014-05/msg02279.html
This patch is for the google/gcc-4_9 branch.
Google ref: 17891596
-cary
2014-05-27 Pedro Alves
include/
* demangle.h (enum demangle_component_type)
: New value.
Ping. I'm getting more reports of this bug internally, and it would be
nice to have the fix upstream.
-cary
On Mon, Oct 13, 2014 at 11:43 AM, Cary Coutant wrote:
> Ping. Jason, do you still think the special-case for conversion ops is
> inappropriate?
>
> -cary
>
>
>
Ping?
On Mon, Oct 20, 2014 at 10:31 AM, Cary Coutant wrote:
> This patch adds support for the mips target in gold.
>
> OK to commit?
>
> -cary
>
>
> 2014-10-20 Cary Coutant
>
> * configure (--enable-gold): Add mips*-*-*.
> * configure.ac: R
This patch adds support for the mips target in gold.
OK to commit?
-cary
2014-10-20 Cary Coutant
* configure (--enable-gold): Add mips*-*-*.
* configure.ac: Regenerate.
Index: configure
===
--- configure
> My preference would be to add the | SECTION_EXCLUDE unconditionally, and
> instead guard the
> if (flags & SECTION_EXCLUDE)
> *f++ = 'e';
> in varasm.c (default_elf_asm_named_section). The only other user of
> SECTION_EXCLUDE seems to be -gsplit-dwarf right now, Cary, is such a change
> ok
Ping. Jason, do you still think the special-case for conversion ops is
inappropriate?
-cary
On Fri, Jul 25, 2014 at 2:16 AM, Pedro Alves wrote:
> On 07/24/2014 11:35 PM, Cary Coutant wrote:
>>> It seems that the problem here is more general; a template argument list is
>>>
> The question is what will old assemblers and/or linkers do with that, and
> if there are any that support linker plugins, but not SHF_EXCLUDE.
If it helps answer that question, SHF_EXCLUDE support has been in gold
for 6 years, and in gas for 4.
-cary
The linker already has a --strip-lto-sections option, and it's on by
default. I'll approve a patch that modifies gold to recognize
.gnu.offload_lto.* sections as part of --strip-lto-sections.
Really, though, you should be setting the SHF_EXCLUDE bit on these
sections. Do that and no special-casing
>> I'd suggest adding an alias for "-no-pie" (meaning "--no-pie") -- see
>> earlier in common.opt where "-pie" is declared as an alias for "pie",
>> and similarly for "-shared".
>
> Patch Updated.
OK for google/gcc-4_9 branch. Thanks!
-cary
>>> If adding a new option, you need to document it in invoke.texi.
>>
>> Patch updated.
>
> Is this alright for google/gcc-4_9?
+no-pie
+Driver RejectNegative Negative(pie)
+Create a position dependent executable
I'd suggest adding an alias for "-no-pie" (meaning "--no-pie") -- see
earlier in co
> O. Then I was indeed wrong and defaulted does not impact ABI at all.
> At least that is one worry less for the abi checkers :)
As Siva mentioned, it does in fact impact the ABI. A class with a
non-trivial destructor is not a POD, and affects the calling
convention, so the debugger needs to know
> Thank you! Now when I have your attention, perhaps we could discuss the
> original
> motivation of the change that exposed this bug.
> I was building libreoffice with profile feedback and I run into a message
>
> cannot load any more object with static TLS
>
> that took me a while to track as I
The plugin API doesn't have a way to mark a symbol as TLS, but it
doesn't really matter since the linker simply overrides the
placeholder from the claimed file with the symbol provided in the
replacement. Unfortunately, I excluded common symbols from this logic
in gold, so the symbol isn't getting
namespaces only.
-cary
2014-09-11 Cary Coutant
gcc/
* dwarf2out.c (output_pubname): Use a reserved bit in the flags
byte to tell gold it's OK to keep just one CU in the CU list
for this index entry.
Index: dwarf2
.
(assign_discriminators): Assign different discriminators for calls
belonging to the same source line.
OK for google/gcc-4_9 branch. Thanks!
-cary
On Fri, Aug 29, 2014 at 1:59 PM, Wei Mi wrote:
>> On Fri, Aug 29, 2014 at 10:11 AM, Cary Coutant wrote:
>>>> T
> To avoid the unused new discriminator value, I added a map
> "found_call_this_line" to track whether a call is the first call in a
> source line seen when assigning discriminators. For the first call in
> a source line, its discriminator is 0. For the following calls in the
> same source line, a
I've backported this patch from trunk r213765.
These sections were originally intended as targets for .gdb_index
entries that needed to point to type units. Because of the limitations
of the .debug_gnu_pubnames/pubtypes sections with split DWARF, we were
not able to pass along enough information
split DWARF by about 30%.
I've run both GCC and GDB tests, and found no new regressions.
Committed as r213765.
-cary
2014-08-08 Cary Coutant
gcc/
* dwarf2out.c (get_skeleton_type_unit): Remove.
(output_skeleton_debug_sections): Remove skeleton type
> static int
> -next_discriminator_for_locus (location_t locus)
> +increase_discriminator_for_locus (location_t locus, bool return_next)
> {
>struct locus_discrim_map item;
>struct locus_discrim_map **slot;
> @@ -934,8 +936,10 @@ next_discriminator_for_locus (location_t
>(*slot)->
>> In the case of loc_checksum(), we're tied to MD5 by the DWARF
>> standard. Otherwise, we could just rewrite it to use inchash
>> throughout.
>
> I'm not sure I understand the motivation. If gcc hashes in
> gcc specific stuff (and this hash, even before my changes is)
> then the output can never
> + /* ??? MD5 of another hash doesn't make a lot of sense... */
> + hash = hstate.end();
>CHECKSUM (hash);
[citation needed] I don't see why you think that. Maybe it'd be nicer
if we could use hash_loc_operands() to feed its input directly into
the MD5 checksum, but I think in this case it'
> It seems that the problem here is more general; a template argument list is
> not in scope within that same template argument list. Can't we fix that
> without special-casing conversion ops?
I think conversion ops really are a special case. It's the only case
where the template parameters refer
I've backported this patch from trunk at r212211. Committed to gcc-4_9
at r212434.
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00076.html
-cary
2014-07-01 Cary Coutant
gcc/
* dwarf2out.c (remove_addr_table_entry): Remove unnecessary hash table
l
Any objections to backporting these fixes to the 4.9 branch?
-cary
On Tue, Jul 1, 2014 at 2:37 PM, Cary Coutant wrote:
> This patch fixes a couple of ICEs when using -gsplit-dwarf.
>
> When compiling a small-enough compilation unit that has no address table
> entries, but complex
2014-07-01 Cary Coutant
gcc/
* dwarf2out.c (remove_addr_table_entry): Remove unnecessary hash table
lookup.
(resolve_addr_in_expr): When replacing the rtx in a location list
entry, get a new address table entry.
(dwarf2out_finish): Call
> This will increase c++ g1/g2 binary size a little. For all spec
> cint2006 benchmarks, the binary size change is shown below.
>
> 400 0.00% 0.00% 0.00% 0.00%
> 401 0.00% 0.00% 0.00% 0.00%
> 403 0.00% 0.00% 0.00% 0.00%
> 429 0.00% 0.00% 0.00% 0.00%
> 445 0.00% 0.00% 0.00% 0.00%
> 456 0.00% 0.00% 0
e ref: b/15417905
2014-06-04 Cary Coutant
gcc/
* dwarf2out.c (dwarf2out_finish): Call index_location_lists
even if addr_index_table is NULL.
Index: gcc/dwarf2out.c
===
--- gcc/dwarf2out.c (revision 211246)
++
> Fix this by adding a new DEMANGLE_COMPONENT_CONVERSION component type,
> which does what DEMANGLE_COMPONENT_CAST does today, and making
> DEMANGLE_COMPONENT_CAST just simply print its component subtree.
>
> I think we could instead reuse DEMANGLE_COMPONENT_CAST and in
> d_print_comp_inner still d
>> PR debug/61013
>> * opts.c (common_handle_option): Don't special-case "-g".
>> (set_debug_level): Default to at least level 2 with "-g".
>
> Ok. Thanks,
Forgot to ask -- OK to backport to the 4.9 branch?
-cary
the debug level to 2 if it was either off or at
level 1 before.
OK to commit?
-cary
2014-05-14 Cary Coutant
gcc/
PR debug/61013
* opts.c (common_handle_option): Don't special-case "-g".
(set_debug_level): Default to at least level 2 with "-g&q
> Attached patch passes regression tests and benchmark test. OK for google-4_9?
OK. Thanks again!
-cary
I've backported this patch from trunk at r210395.
-cary
gcc/
* opts.c (finish_options): Use -ggnu-pubnames with -gsplit-dwarf.
This patch forces the use of -ggnu-pubnames when using -gsplit-dwarf.
This is necessary so that the gold linker can generate .gdb_index
version 7.
No new regressions. Committed as trivial (has no effect if you're not
using -gsplit-dwarf).
-cary
2014-05-13 Cary Coutant
gcc/
* o
> The problem is that linemap_location_from_macro_expansion_p will
> always return true if locus has discriminator. And in linemap_lookup,
> this will lead to call linemap_macro_map_lookup, in which there is an
> assertion:
>
> linemap_assert (line >= LINEMAPS_MACRO_LOWEST_LOCATION (set));
>
> Howe
> Index: gcc/input.c
> ===
> --- gcc/input.c (revision 210338)
> +++ gcc/input.c (working copy)
> @@ -910,6 +910,8 @@ location_with_discriminator (location_t locus, int
>: next_discriminator_location);
>
>next_discriminator
of making it conditional on this flag.
OK to commit?
-cary
2014-05-12 Cary Coutant
gcc/
* dwarf2out.c (output_skeleton_debug_sections): Check
-fskeleton-type-units flag.
(output_comdat_type_unit): Likewise.
(dwarf2out_finish): Likewise.
* common.opt
> Yes, this patch is a combination of all these patches. Some of them
> are already in trunk.
OK for google 4.9 branch. Thanks!
-cary
On Mon, May 12, 2014 at 1:11 PM, Dehao Chen wrote:
> This patch backports r199154 from google-4_8 to google-4_9
>
> Bootstrapped and passed regression test.
>
> OK for google-4_9 branch?
Don't forget the follow-ons listed below. Any reason not to combine
them into this patch?
Looks good. Thanks!
I've backported the following patch from trunk at r209812. Committed
on the google/gcc-4_9 branch at r209875.
Google ref: 14230806.
-cary
gcc/
* dwarf2out.c (should_move_die_to_comdat): A type definition
can contain a subprogram definition, but don't move it to a
comdat u
What are the rules for backporting to 4.9.1? Should I backport this patch?
-cary
> 2014-04-25 Cary Coutant
>
> gcc/
> PR debug/60929
> * dwarf2out.c (should_move_die_to_comdat): A type definition
> can contain a subprogram definition, but
.
Committed as r209812.
-cary
2014-04-25 Cary Coutant
gcc/
PR debug/60929
* dwarf2out.c (should_move_die_to_comdat): A type definition
can contain a subprogram definition, but don't move it to a
comdat unit.
(clone_as_declaration): C
> + /* If HOST_WIDE_INT is big enough then represent the bound as
> + a constant value. Note that we need to make sure the type
> + is signed or unsigned. We cannot just add an unsigned
> + constant if the value itself is positive. Some DWARF
> + consume
> Added a clarifying comment to the code and reinstated the TODO for the
> double case. OK to push?
>
> * dwarf2out.c (gen_enumeration_type_die): Add DW_AT_const_value
> as unsigned or int depending on type and value used.
OK. Thanks!
-cary
>> Also note that size_of_die and value_format will still choose
>> DW_FORM_data[1248] for dw_val_class_unsigned_const in most cases.
>> Don't you really want to use DW_FORM_udata?
>
> DW_FORM_data[1248] is in many cases smaller than DW_FORM_udata (though, one
> has to take into account possibly la
>>* dwarf2out.c (gen_enumeration_type_die): Add DW_AT_const_value
>>as unsigned or int depending on type and value used.
>
> Since stage 1 opened up I would like to request approval again to push
> this. Patch rebased to current master attached.
The discussion that led to that TODO is here
>> The DWARF bits are fine with me.
>
> Thanks. Who can approve the other bits?
You should probably get C and C++ front end approval. I'm not really
sure who needs to review patches in c-family/. Since the part in c/ is
so tiny, maybe all you need is a C++ front end maintainer. Both
Richard Hender
> However it would be nice to be assured that the gcc change is ok in
> principle first.
The DWARF bits are fine with me.
-cary
> ChangeLog:
> 2014-03-25 Siva Chandra Reddy
>
> Fix PR debug/57519
>
> /cp
>
> PR debug/57519
> * class.c (handle_using_decl): Pass the correct scope to
> cp_emit_debug_info_for_using.
>
> testsuite/
>
> PR debug/57519
> * g++.dg/debug/dwarf2/
> gcc/cp/
> * dwarf2out.c (gen_enumeration_type_die): Add DW_AT_type if
> enum_underlying_base_type defined and DWARF version > 3.
> * langhooks.h (struct lang_hooks_for_types): Add
> enum_underlying_base_type.
> * langhooks-def.h (LANG_HOOKS_ENUM_UNDERLYING_
I've backported this patch from trunk at r205292. Committed on
google/gcc-4_8 branch as r207971.
Tested with make check in libiberty.
-cary
2013-11-22 Cary Coutant
libiberty/
* cp-demangle.c (struct d_info_checkpoint): New struct.
(struct d_print_info)
> gen_subprogram_die is often called more than once for the same decl
> (e.g. the first time through force_decl_die etc.), but it always
> unconditionally calls add_calling_convention_attribute which thus
> may add the attributes several times.
>
> Fixed thusly, bootstrapped/regtested on x86_64-lin
ation takes.
This patch is for the google/gcc-4_8 branch. I will submit it
for trunk when stage 1 is open.
Tested with crosstool_validate.py.
2014-02-11 Cary Coutant
* dwarf2out.c (add_top_level_skeleton_die_attrs): Don't add
DW_AT_GNU_addr_base to all ske
> in this bug we ICE in dwarf2out.c:is_base_type with -g, because it doesn't
> know how to handle the TEMPLATE_TYPE_PARM coming from the C++ front-end and
> representing 'auto' in this kind of C++1y code.
>
> That it shouldn't ICE and return 0 instead I'm pretty sure, I'm less sure
> about the next
> gcc/
> 2013-11-24 Tobias Burnus
>
> PR debug/37132
> * lto-streamer.h (LTO_tags): Add LTO_namelist_decl_ref.
> * tree.def (NAMELIST_DECL): Add.
> * tree.h (NAMELIST_DECL_ASSOCIATED_DECL): New macro.
> * tree.c (initialize_tree_contains_struct): Add asserts for it.
> This patches gen_compile_unit_die to use the DW_LANG_D DWARF language
> code for D. Is in relation to some other D language fixes that are
> going to be submitted to gdb.
Is this for a private front end? I'm not aware of any front ends that
set the language name to "GNU D".
Since it's so trivi
> gcc/ChangeLog
>
> 2013-12-02 Sterling Augustine
>
> * dwarf2out.c (output_pubnames): Use comp_unit_die ()->die_offset
> when there
> isn't a skeleton die.
This is OK, but your patch also has a local change to contrib/mklog.
Please be careful not to commit that.
Thanks!
-cary
> Having just looked at the opts.c and tree-ssa-live.c changes, they're fine.
Thanks, I've committed the patch.
-cary
>> Let me rebase the
>> patch, kick off a bootstrap and regression tests, and I think I can be
>> ready to submit it if there are no objections.
>
> Here's the rebased patch. I'm running the bootstrap and regression tests now.
The bootstrap passed with no new regressions. Do I need approval for
th
bstitution misnumbering in the current demangler.
-cary
> 2013-11-19 Cary Coutant
>
> libiberty/
> PR other/59195
> * cp-demangle.c (struct d_info_checkpoint): New struct.
> (struct d_print_info): Add current_template field.
> (d_operator_name): Set fl
> Let me rebase the
> patch, kick off a bootstrap and regression tests, and I think I can be
> ready to submit it if there are no objections.
Here's the rebased patch. I'm running the bootstrap and regression tests now.
-cary
commit 2d50b3878cd8e96e31b92a5f1d261cbcea6ce0e5
A
>> Sorry, I never saw any feedback, positive or negative, on that, and it
>> kind of fell off my radar. I think it should still be ready to go in
>> -- Stage 1 is still open for another day, right? Let me rebase the
>> patch, kick off a bootstrap and regression tests, and I think I can be
>> ready
>> Here, finally, is that patch again, reworked to generate line tables
>> at -g1. I plan to commit this when Stage 1 reopens, but I'd like to
>> verify that earlier consensus. I also plan to commit this to the
>> google/main branch, and future merges will go more smoothly if what I
>> put in googl
> 2013-11-13 Cary Coutant
>
> gcc/cp/
> * mangle.c (to_base36): New function.
> (dump_substitution_candidates): Add checks for NULL.
> Print substitution index in base 36.
Ping?
-cary
1 - 100 of 332 matches
Mail list logo
