Re: RFA/RFC: Add stack recursion limit to libiberty's demangler

> 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

Re: [PATCH] Avoid excessive location expansion in assign_discriminators

> 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

Re: plugin-api.h patch to add a new interface for linker plugins

> 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

Re: [PATCH] gold: Use autotools pthread macro

> 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.

[config patch] Fwd from binutils: add ax_pthread.m4 to config/ directory

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.

Re: [PATCH] gold: Use autotools pthread macro

>> 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?

Re: [PATCH] gold: Use autotools pthread macro

> 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) > >

Re: [PATCH] [GOLD] Add plugin API for processing plugin-added input files

> 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

Re: [PATCH] Add linker plugin API for processing plugin-added input files

> 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

Re: [PR63238] output alignment debug information

>> 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

Re: [PR63238] output alignment debug information

> 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. >

Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space

> 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 > > *

Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space

> 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

Re: [1/9][RFC][DWARF] Reserve three DW_OP numbers in vendor extension space

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

Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 [aka should we revert the fix for 65248]

> As one of the strong advocates for the fix that was made to make > protected visibility work correctly with data symbols, I'd like to > explain why it was the right decision and why it matters. This whole > process is really frustrating to me -- having invested a lot of effort > into getting

Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 [aka should we revert the fix for 65248]

> Another old bug: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10908 Filed by you, and resolved (correctly) as invalid. Again, the real problem was the lack of a linker diagnostic. -cary

Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 [aka should we revert the fix for 65248]

> Cary, please stop spreading the incorrect information. There is > at lease one GCC bug against protected symbol: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55012 > > which was reported by other people. OK, so it got reported once by someone else. But that bug was based on an incorrect

Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 [aka should we revert the fix for 65248]

>> So with all this it sounds that current protected visibility is just >> broken and we should forgo with it, making it equal to default >> visibility? > > Like how? You mean in GCC regarding protected as default visibility? No, > that's just throwing out the baby with the water. We should

Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 [aka should we revert the fix for 65248]

>> That is why protected visibility is such a mess. > > Not mess, but it comes with certain limitations. And that's okay. It's > intended as an optimization, and it should do that optimization if > requested, and error out if it can't be done for whatever reason. I completely agree. > E.g. one

Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 [aka should we revert the fix for 65248]

>> Given a shared library that defines a variable, and a non-PIC >> executable that references that variable, the linker makes a duplicate >> of the variable in the executable .dynbss section and arranges to have >> the copy initialized by the dynamic loader with a copy relocation. >> .dynbss is a

Re: [GCC Wiki] Update of "DebugFission" by CaryCoutant

We're in the final stages of finalizing the DWARF v5 spec, which will include the Fission extensions. When that's done, we'll start converting GCC and gold over to use the official DWARF features rather than the GNU extensions. >> + The "Fission" project was started in response to the problems

[committed patch] Sync top-level configure.ac with binutils-gdb

I'm committing this patch to sync the top-level configure with binutils-gdb. -cary 2016-03-17 Cary Coutant <ccout...@gmail.com> * configure.ac: Add mips and s390 to the gold target check. * configure: Regenerate. Index: con

[commit] Sync include/plugin-api.h with binutils

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.

Re: RFA: Add GCC Runtime Library Exception to include/plugin-api.h

> include/plugin-api.h defines an ABI between linker and compiler, > which can be used to implement linker plug-in by any compilers. > I'd like to add GCC Runtime Library Exception to include/plugin-api.h > so that the linker plug-in can have non-GPL licenses. This is OK with me. -cary

Re: [RFC] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking

> 3.3.2 Static Linking Object Acceptance Rules > > The static linker shall follow the user selection as to the linking mode > used, either of `strict' and `relaxed'. The selection will be made > according to the usual way assumed for the environment used, which may be > a command-line option, a

Re: [RFC] COMDAT Safe Module Level Multi versioning

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 usually only a few.

Re: Adding static-PIE support to binutils

Does static pie (ET_DYN with non-fixed load address, _DYNAMIC relocations, but no PT_INTERP, DT_NEEDEDs, or symbolic relocations) currently work with gold? If so, what is the way to request it? I would say it would make sense to try to do things the same, but from what you're saying it sounds

Re: Adding static-PIE support to binutils

This is OK to commit with a suitable ChangeLog. I think a separate ld option is best too, because historically -static and its aliases -Bstatic, -dn, -non_shared really are about what type of libraries are accepted rather than choosing linker output type. Gold actually separates these

Re: [RFC] COMDAT Safe Module Level Multi versioning

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

Re: [RFC] COMDAT Safe Module Level Multi versioning

+@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 in

Re: Adding static-PIE support to binutils

So far, I've been prototyping static PIE support by having GCC pass the following options to ld instead of -static -pie: -static -shared -Bsymbolic This partly works, but since ld does not know it's producing a main executable, it misses important details, including the ability to

Re: [PATCH] Add extensions to dwarf2.def

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 biased

[patch] Update my email address

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 ccout...@gmail.com * MAINTAINERS

Re: [google/gcc-4_9] Minor changes to -ftwo-level-line-tables

@@ -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 name. + If

Re: [RFC PATCH] Emit DW_LANG_Fortran{03,08}

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

Re: [RFC PATCH] Emit DW_LANG_Fortran{03,08}

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 array

Re: [RFC PATCH] Emit DW_LANG_Fortran{03,08}

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, ver,

Re: PR lto/64837: lto plugin doesn't call ld_plugin_release_input_file

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 wasn't

Re: [PATCH] Add top-level config support for gold mips target

Ping^3. Should I be addressing this to someone else? -cary On Mon, Dec 1, 2014 at 2:15 PM, Cary Coutant ccout...@google.com wrote: Ping^2. -cary On Wed, Oct 29, 2014 at 12:04 PM, Cary Coutant ccout...@google.com wrote: Ping? On Mon, Oct 20, 2014 at 10:31 AM, Cary Coutant ccout

Re: PR lto/64837: lto plugin doesn't call ld_plugin_release_input_file

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: [PATCH] Added PLUGIN_FINISH_TYPE callback on enum type processing

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 a maintainer for the LTO

Re: [google/gcc-4_9] Add -ftwo-level-line-tables and -gline-tables-only options

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 may not

Re: [google/gcc-4_9] Add -ftwo-level-line-tables and -gline-tables-only options

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

Re: [google/gcc-4_9] Add -ftwo-level-line-tables and -gline-tables-only options

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 block, so I

Re: [google/gcc-4_9] Add -ftwo-level-line-tables and -gline-tables-only options

+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 (struct

Re: PR lto/64837: lto plugin doesn't call ld_plugin_release_input_file

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 called. But

Re: [PATCH] DWARF add DW_AT_noreturn on noreturn function subprogram.

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

Re: [PATCH] DWARF add DW_AT_noreturn on noreturn function subprogram.

[+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 confident

Re: [PATCH] Add top-level config support for gold mips target

Ping^2. -cary On Wed, Oct 29, 2014 at 12:04 PM, Cary Coutant ccout...@google.com wrote: Ping? On Mon, Oct 20, 2014 at 10:31 AM, Cary Coutant ccout...@google.com wrote: This patch adds support for the mips target in gold. OK to commit? -cary 2014-10-20 Cary Coutant ccout

Re: [PATCH 2/3] PR other/61321 - demangler crash on casts in template parameters

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 ccout...@google.com wrote: Ping. Jason, do you still think the special-case for conversion ops is inappropriate? -cary On Fri, Jul 25

[google/gcc-4_9] Backport pending patch to fix demangler crash

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 pal...@redhat.com include/ * demangle.h (enum demangle_component_type)

Re: [PATCH] Add top-level config support for gold mips target

Ping? On Mon, Oct 20, 2014 at 10:31 AM, Cary Coutant ccout...@google.com wrote: This patch adds support for the mips target in gold. OK to commit? -cary 2014-10-20 Cary Coutant ccout...@google.com * configure (--enable-gold): Add mips*-*-*. * configure.ac: Regenerate

[PATCH] Add top-level config support for gold mips target

This patch adds support for the mips target in gold. OK to commit? -cary 2014-10-20 Cary Coutant ccout...@google.com * configure (--enable-gold): Add mips*-*-*. * configure.ac: Regenerate. Index: configure

Re: [PATCH 4/n] OpenMP 4.0 offloading infrastructure: lto-wrapper

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 with

Re: [PATCH 2/3] PR other/61321 - demangler crash on casts in template parameters

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 pal...@redhat.com wrote: On 07/24/2014 11:35 PM, Cary Coutant wrote: It seems that the problem here is more general; a template argument list

Re: [PATCH 4/n] OpenMP 4.0 offloading infrastructure: lto-wrapper

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

Re: [PATCH 4/n] OpenMP 4.0 offloading infrastructure: lto-wrapper

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

Re: [google/gcc-4_9] Add gcc driver option -no-pie

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 common.opt

Re: [google/gcc-4_9] Add gcc driver option -no-pie

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

Re: [PATCH 2/2] PR debug/63240 Add DWARF representation for C++11 defaulted member function.

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

Re: Avoid privatization of TLS variables

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

Re: Avoid privatization of TLS variables

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 did not

[google/4_9] Add a new flag bit to .debug_gnu_pubnames entries

and namespaces only. -cary 2014-09-11 Cary Coutant ccout...@google.com 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: dwarf2out.c

Re: [GOOGLE, AUTOFDO] Assign different discriminators to calls with the same lineno

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 new

Re: [GOOGLE, AUTOFDO] Assign different discriminators to calls with the same lineno

for next_discriminator_for_locus. (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 w...@google.com wrote: On Fri, Aug 29, 2014 at 10:11 AM, Cary Coutant ccout

[google/gcc-4_9] Remove skeleton type units that were being produced with -gsplit-dwarf.

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

Re: [GOOGLE, AUTOFDO] Assign different discriminators to calls with the same lineno

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)-locus =

Re: [PATCH 1/6] RTL dwarf2out changes

+ /* ??? 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's

Re: [PATCH 1/6] RTL dwarf2out changes

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 be

Re: [PATCH 2/3] PR other/61321 - demangler crash on casts in template parameters

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

[patch] [4.9] Backport fix for ICEs with -gsplit-dwarf

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 ccout...@google.com gcc/ * dwarf2out.c (remove_addr_table_entry): Remove unnecessary hash table lookup

[patch] Fix ICEs with -gsplit-dwarf

2014-07-01 Cary Coutant ccout...@google.com 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

Re: [patch] Fix ICEs with -gsplit-dwarf

Any objections to backporting these fixes to the 4.9 branch? -cary On Tue, Jul 1, 2014 at 2:37 PM, Cary Coutant ccout...@google.com 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

Re: [GOOGLE] Emit linkage_name when built with -gmlt and for abstract decls

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.00%

[google/gcc-4_8] Fix ICE with -gsplit-dwarf and FDO

: b/15417905 2014-06-04 Cary Coutant ccout...@google.com gcc/ * dwarf2out.c (dwarf2out_finish): Call index_location_lists even if addr_index_table is NULL. Index: gcc/dwarf2out.c === --- gcc/dwarf2out.c

Re: [PATCH 2/3] PR other/61321 - demangler crash on casts in template parameters

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 do:

[patch] PR debug/61013: Change -g so that it will override -g1 but not -g3

the debug level to 2 if it was either off or at level 1 before. OK to commit? -cary 2014-05-14 Cary Coutant ccout...@google.com 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. Index

Re: [patch] PR debug/61013: Change -g so that it will override -g1 but not -g3

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

Re: [GOOGLE] Updates highest_location when updating next_discriminator_location

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);

Re: [GOOGLE] Updates highest_location when updating next_discriminator_location

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)); However,

[PATCH] 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 ccout...@google.com gcc

[google/gcc-4_9] Force the use of -ggnu-pubnames when using -gsplit-dwarf

I've backported this patch from trunk at r210395. -cary gcc/ * opts.c (finish_options): Use -ggnu-pubnames with -gsplit-dwarf.

Re: [GOOGLE] Updates highest_location when updating next_discriminator_location

Attached patch passes regression tests and benchmark test. OK for google-4_9? OK. Thanks again! -cary

Re: [GOOGLE] backport discriminator support from google-4_8 to google-4_9

On Mon, May 12, 2014 at 1:11 PM, Dehao Chen de...@google.com 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

Re: [GOOGLE] backport discriminator support from google-4_8 to google-4_9

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

[google/gcc-4_8] Add -fskeleton-type-units flag.

it conditional on this flag. OK to commit? -cary 2014-05-12 Cary Coutant ccout...@google.com gcc/ * dwarf2out.c (output_skeleton_debug_sections): Check -fskeleton-type-units flag. (output_comdat_type_unit): Likewise. (dwarf2out_finish): Likewise

Re: PR debug/60929: Fix a few ICEs and other problems with -fdebug-types-sections

What are the rules for backporting to 4.9.1? Should I backport this patch? -cary 2014-04-25 Cary Coutant ccout...@google.com gcc/ PR debug/60929 * dwarf2out.c (should_move_die_to_comdat): A type definition can contain a subprogram definition, but don't move

[google/gcc-4_9] PR debug/60929: Fix a few ICEs and other problems with -fdebug-types-sections

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

PR debug/60929: Fix a few ICEs and other problems with -fdebug-types-sections

2014-04-25 Cary Coutant ccout...@google.com 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): Copy DW_AT_abstract_origin attribute

Re: [PATCH] Add DW_AT_const_value as unsigned or int depending on type and value used.

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

Re: [PATCH] dwarf2out: Use normal constant values in bound_info if possible.

+ /* 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 + consumers

Re: [PATCH] Add DW_AT_const_value as unsigned or int depending on type and value used.

* 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:

Re: [PATCH] Add DW_AT_const_value as unsigned or int depending on type and value used.

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 larger

Re: [PATCH] PR debug/16063. Add DW_AT_type to DW_TAG_enumeration.

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 Henderson

Re: [PATCH] PR debug/16063. Add DW_AT_type to DW_TAG_enumeration.

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

Re: [PATCH] PR debug/57519 - Emit DW_TAG_imported_declaration under the right class for 'using' statements in a class

ChangeLog: 2014-03-25 Siva Chandra Reddy sivachan...@google.com 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 *

Re: [PATCH] PR debug/16063. Add DW_AT_type to DW_TAG_enumeration.

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

[google/gcc-4_8] Fix demangler to handle conversion operators correctly

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 ccout...@google.com libiberty/ * cp-demangle.c (struct d_info_checkpoint): New struct. (struct

Re: [PATCH] Don't add DW_AT_{main_subprogram,calling_convention} attributes more than once (PR debug/60152)

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-linux

[google gcc-4_8] Remove DW_AT_GNU_addr_base from skeleton type unit DIEs

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 ccout...@google.com * dwarf2out.c (add_top_level_skeleton_die_attrs): Don't add DW_AT_GNU_addr_base to all skeleton DIEs

  1   2   3   4   >