> "Richard" == Richard Biener writes:
Richard> On Fri, Mar 28, 2025 at 8:32 AM Eric Botcazou
wrote:
>>
>> > Let's involve Eric here, I have no idea what was intended here.
>>
>> We discussed it with Tom internally and he makes the final decisions here.
Richard> Well the, Tom, go ahead.
> "Richard" == Richard Biener writes:
Sorry about the delay on this.
>> - mod_type_die = subrange_type_die (type, low, high, bias, context_die);
>> + mod_type_die = subrange_type_die (type, low, high, bias, mod_scope);
Richard> that looks good. But why not for the ARRAY_TYPE case
Tom> While working on this I found a couple of paths in modified_type_die
Tom> where "mod_scope" should be used, but is not. I suspect these cases
Tom> are only reachable by Ada code, as in both spots (subrange types and
Tom> base types), I believe that other languages don't generally have named
T
>>>>> "Tom" == Tom Tromey writes:
Tom> I am working on some changes to GNAT to emit hierarchical DWARF --
Tom> i.e., where entities will have simple names nested in a DW_TAG_module.
Tom> While working on this I found a couple of paths in modified_type_die
Tom
> "Jonathan" == Jonathan Wakely writes:
Jonathan> also unable to build GDB with Python 3? ... maybe unlikely) but nobody
Jonathan> should be stuck on 3.0 and unable to replace that with 3.12 or so.
gdb has one user (maybe more, but I doubt it) on Windows XP where the
latest available version
> "Jonathan" == Jonathan Wakely writes:
Jonathan> Using a keyword argument for count only became possible with Python
3.1
Jonathan> so introduce a new function to do the substitution.
gdb docs are inconsistent on this, but at least one spot says that the
minimum supported Python version is
I am working on some changes to GNAT to emit hierarchical DWARF --
i.e., where entities will have simple names nested in a DW_TAG_module.
While working on this I found a couple of paths in modified_type_die
where "mod_scope" should be used, but is not. I suspect these cases
are only reachable by
>>>>> "Richard" == Richard Biener writes:
Richard> Honoring DECL_NAMELESS is obvious enough to me that I'd approve
Richard> such a change
Ok, how about the appended?
thanks,
Tom
commit 01ce41f7e0b023b7f67b48d85ead11cea1c96205
Author: Tom Tromey
Da
> "Richard" == Richard Biener writes:
>> While working on a patch to the Ada compiler, I found a spot in
>> dwarf2out.cc that calls add_name_attribute where a call to
>> add_name_and_src_coords_attributes would be better, because the latter
>> respects DECL_NAMELESS.
Richard> If the point is
>>>>> "Tom" == Tom Tromey writes:
Tom> While working on a patch to the Ada compiler, I found a spot in
Tom> dwarf2out.cc that calls add_name_attribute where a call to
Tom> add_name_and_src_coords_attributes would be better, because the latter
Tom> r
While working on a patch to the Ada compiler, I found a spot in
dwarf2out.cc that calls add_name_attribute where a call to
add_name_and_src_coords_attributes would be better, because the latter
respects DECL_NAMELESS.
gcc
* dwarf2out.cc (modified_type_die): Call
add_name_and_src_c
>>>>> "Tom" == Tom Tromey writes:
Tom> DWARF is not especially clear on the distinction between
Tom> DW_TAG_namespace and DW_TAG_module, but I think that DW_TAG_module is
Tom> more appropriate for Ada. This patch changes the compiler to do this.
Tom> No
DWARF is not especially clear on the distinction between
DW_TAG_namespace and DW_TAG_module, but I think that DW_TAG_module is
more appropriate for Ada. This patch changes the compiler to do this.
Note that the Ada compiler does not yet create NAMESPACE_DECLs.
gcc
* dwarf2out.cc (gen_nam
> Qing Zhao writes:
> +The size of the union is as if the flexiable array member were omitted
> +except that it may have more trailing padding than the omission would imply.
> +
> +If all the members of a union are flexiable array member, the size of
There's a couple of spots that say "flex
>>>>> "Tom" == Tom Tromey writes:
Tom> This short series adds configuration files for black ("opinionated"
Tom> code formatter), isort (import sorter) and flake8 (Python lint) to
Tom> libstdc++.
Tom> I marked it as RFC since sometimes people d
Investigating GDB PR d/31580 showed that the libiberty demangler
doesn't automatically demangle D mangled names. However, I think it
should -- like C++ and Rust (new-style), D mangled names are readily
distinguished by the leading "_D", and so the likelihood of confusion
is low. The other non-"au
> So, let’s delay the possible support to gdb in a later patch.
> Does this sound reasonable to you?
It's not really up to me, but sure. I was just curious if it perhaps
already worked, but not enough to apply the patches and find out.
Tom
Kees> Does DWARF have such an annotation? Regardless, I think this could be a
Kees> future patch to not hold up landing the initial feature.
Sure, the compiler can emit the array length (and structure size) as a
DWARF expression using the length.
Tom
> Qing Zhao writes:
> This is the 8th version of the patch.
> compare with the 7th version, the difference are:
[...]
Hi. I was curious to know if the information supplied by this attribute
shows up in the DWARF. It would be good if it did, because that would
let gdb correctly print thes
When debugging gcc, I tried calling debug_dwarf_die and I saw this
output:
DW_AT_location: location descriptor:
(0x7fffe9c2e870) DW_OP_dup 0, 0
(0x7fffe9c2e8c0) DW_OP_bra location descriptor (0x7fffe9c2e640)
, 0
(0x7fffe9c2e820) DW_OP_lit4 4, 0
(0x7fffe9c2e910
> "Andrew" == Andrew Burgess writes:
Andrew> Thanks, that would be great, and would certainly fix the build problems
Andrew> I see.
I'm going to check it in to binutils-gdb in a minute.
For those reading on gcc-patches, please consider this a ping of the
patch.
thanks,
Tom
> "Andrew" == Andrew Burgess writes:
Andrew> After once again forgetting to add GUILE=guile2.2 to my GDB build I was
Andrew> thinking about this issue again.
Andrew> Given that GDB has a --with-guile=... configure option, and that our
Andrew> configure scripts try to identify a matching vers
> "Jeff" == Jeff Law writes:
>> I don't know how to fix this.
Jeff> Me neither, but I can suggest a hacky workaround.
FTR, I asked Jakub on irc and he fixed it, so thankfully I didn't have
to resort to the hack :-)
thanks,
Tom
> "Andrew" == Andrew Pinski writes:
Andrew> I don't know how to update the script server side after it is
Andrew> committed in git. the checker script is located in git though:
Thanks, I didn't realize it was there.
Could you check in your patch?
IMO it seems obvious.
Tom
> "Jeff" == Jeff Law writes:
Jeff> Given this is all libcc1 related and thus primarily of interest to
Jeff> gdb, if you're happy with it, then it's OK for the trunk.
Thank you.
I could not push this because:
remote: *** ChangeLog format failed:
remote: *** ERR: invalid PR component in subj
the C front end protocol version.
It also includes some updates to various comments in 'include', done
here to simplify the merge to binutils-gdb.
include/ChangeLog
2024-02-26 Tom Tromey
* gcc-cp-interface.h (gcc_cp_fe_context_function): Update
comment.
se be documented, but I
did that in a subsequent patch, in order to only have one patch
touching the 'include' directory and thus needing a merge to
binutils-gdb.
2024-02-26 Tom Tromey
* libcp1.cc (libcp1::libcp1): Use FE version number from context.
* libcc1.cc (libcc1::
ear that removing it doesn't cause any regressions in gdb.
However, rather than remove it, this patch changes it to handle
ERROR_MARK better, and then to fall back to the v0 code if the new
code fails to find the type it's looking for.
2024-02-26 Tom Tromey
* libcc1plugin.cc (saf
that was not. In both
cases gdb's "gdb.compile" tests were run.
---
Tom Tromey (3):
Change 'v1' float and int code to fall back to v0
Fix version negotiation in libcc1 plugins
Fix PR libcc1/113977
include/ChangeLog | 10 ++
includ
>>>>> "Andrew" == Andrew Burgess writes:
Andrew> Tom Tromey writes:
>> This reverts commit b7e5a29602143b53267efcd9c8d5ecc78cd5a62f.
>>
>> This patch caused problems for some users when building gdb, because
>> it would cause 'guild
This reverts commit b7e5a29602143b53267efcd9c8d5ecc78cd5a62f.
This patch caused problems for some users when building gdb, because
it would cause 'guild' to be invoked with the wrong versin of guile.
On the whole it seems simpler to just back this out.
* Makefile.in: Rebuild.
* Ma
Eric> I mean, I've been trying to figure out how to re-run cgen myself, to
Eric> regenerate some cgen-erated files in libopcodes to fix some compiler
Eric> warnings in them, but it's pretty hard to do so; I'd really appreciate
Eric> it if the whole process of regenerating files with cgen could be m
Andrew> This change is causing some problems for me.
Yeah, Tom de Vries as well.
Andrew> One of my build machines has 2 versions of guile installed. One is
Andrew> guile 2.0.14 and the other is guile 2.2.21.
Andrew> When GDB configures itself the configure script figures out that it
Andrew> sho
use 'make GUILE=guile3.0'.
ChangeLog
2023-12-30 Tom Tromey
* Makefile.in: Rebuild.
* Makefile.tpl (BASE_EXPORTS): Add GUILE.
(GUILE): New variable.
* Makefile.def (flags_to_pass): Add GUILE.
---
ChangeLog| 7 +++
Makefile.def | 1 +
Makefile.in | 8 ++
> "Jakub" == Jakub Jelinek writes:
Jakub> LGTM for GCC (but it needs a ChangeLog entry).
Oops, yeah -- I am out of the habit of writing those.
I'll add one before I push this.
Tom
I've reimplemented the .debug_names code in GDB -- it was quite far
from being correct, and the new implementation is much closer to what
is specified by DWARF.
However, the new writer in GDB needs to emit some symbol properties,
so that the reader can be fully functional. This patch adds a few n
> "Arsen" == Arsen Arsenović writes:
Arsen> Thanks. I'll wait for the Binutils and GDB maintainers to weigh in
Arsen> before pushing (plus, I can't push there).
Seems fine to me. Thank you.
Tom
The gdb tests of the libcc1 plugin have been failing lately. I
tracked this down to a crash trying to access an enum's underlying
type. This patch fixes the crash by setting this type.
libcc1/ChangeLog
* libcc1plugin.cc (plugin_build_enum_type): Set
ENUM_UNDERLYING_TYPE.
---
li
This changes libstdc++ to use the 'black' Python formatter. This
formatter is somewhat standard and fairly comprehensive. FWIW we use
this in gdb, mainly because it means we don't have to review Python
code for formatting style.
This patch also runs 'isort', which handles sorting the imports.
A
flake8 is a Python linter. This patch adds a .flake8 configuration
file (flake8 does not use pyproject.toml for some reason) and fixes a
few trivial flake8 warnings.
After this patch, the only remaining flake8 warnings are about unused
imports (there are two - but they are not completely trivial
This short series adds configuration files for black ("opinionated"
code formatter), isort (import sorter) and flake8 (Python lint) to
libstdc++.
I marked it as RFC since sometimes people don't like black's output.
In gdb we use it -- at first I found some of its decisions a little
odd, but overal
flake8 points out that the new call to _string_types from
StdExpAnyPrinter.__init__ is not correct -- it needs to be qualified.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py
(StdExpAnyPrinter.__init__): Qualify call to
_string_types.
---
libstdc++-v3/python/li
Some code in the pretty-printers seems to assume that the
_versioned_namespace global might be None (or the empty string).
However, doesn't occur, as the variable is never reassigned.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py: Assume that
_versioned_namespace is no
flake8 pointed out that is_specialization_of in xmethods.py looks at a
global that wasn't added to the file. This patch correct the
oversight.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/xmethods.py (_versioned_namespace):
Define.
---
libstdc++-v3/python/libstdcxx/v6/xmethods.
While I was working on the flake8/black patches, flake8 pointed out a
bug in xmethods.py. This is fixed in patch 1. Then I found the
checks of _versioned_namespace to be a bit odd, so I wrote patch 2.
Tested on x86-64 Fedora 36.
Tom
Jonathan> I've pushed the changes I wanted to make, so you'll have to rebase
Jonathan> your patches now, sorry.
No problem. I rebased & re-tested them.
I can send a v2 if you want to double-check (only this large patch
required any changes), or just go ahead. Let me know.
I may not be able to pu
Jonathan> I already have a patch to use r'...' for these, so we only
Jonathan> need the single backslash.
Yeah, probably nicer.
Jonathan> So please don't commit this one, I think it will be
Jonathan> unnecessary in a couple of hours.
No problem, I'll drop it when I rebase on top of your changes.
GDB 14 will add a new ValuePrinter tag class that will be used to
signal that pretty-printers will agree to the "extension protocol" --
essentially that they will follow some simple namespace rules, so that
GDB can add new methods over time.
A couple new methods have already been added to GDB, to
flake8 warns about code like
not something in "whatever"
Ordinarily in Python this should be written as:
something not in "whatever"
This patch makes this change.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (Printer.add_version)
(add_one_template_type_pri
flake8 pointed out some unused local variables in the libstdc++
pretty-printers. This removes them.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py
(StdExpOptionalPrinter.__init__, lookup_node_type):
Remove unused variables.
---
libstdc++-v3/python/libstdcxx/v6
flake8 pointed out that some regexes in the pretty-printers are
missing a backslash. This patch fixes these.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py
(StdExpAnyPrinter.__init__, StdExpOptionalPrinter.__init__):
Add missing backslash.
* python/libs
This removes the std_ratio_t_tuple function from the Python
pretty-printer code. It is not used. Apparently the relevant parts
were moved to StdChronoDurationPrinter._ratio at some point in the
past.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py (std_ratio_t_tuple):
flake8 pointed out some unused imports.
libstdc++-v3/ChangeLog:
* python/libstdcxx/v6/printers.py: Don't import 'os'.
* python/libstdcxx/v6/__init__.py: Don't import 'gdb'.
---
libstdc++-v3/python/libstdcxx/v6/__init__.py | 2 --
libstdc++-v3/python/libstdcxx/v6/printers.py | 1 -
GDB 14 will include a gdb.ValuePrinter tag class that can be used by
pretty-printers to signal they will accept any extensions that GDB
happens to make over time.
This series started as an attempt to change the libstdc++ printers to
support this. This just involves renaming a bunch of attributes.
This changes the libstdc++ test suite to arrange for gdb to show the
full Python stack if any sort of Python exception occurs. This makes
debugging the printers a little simpler.
libstdc++-v3/ChangeLog:
* testsuite/lib/gdb-test.exp (gdb-test): Enable Python
stack traces from gdb.
Jonathan> The changes made by black seem reasonable, though I prefer it
Jonathan> with -S to disable string-normalization. It also needs an
Jonathan> option to use 79 as the maximum line length.
I've got some patches I'm about to send.
I made a pyproject.toml to auto-configure black (and isort),
>> I have fixes for most of the issues that are worth fixing (I didn't
>> bother with line lengths -- FWIW in gdb we just run 'black' and don't
>> worry about these details),
Jonathan> I used autopep8 and committed the result as
Jonathan> e08559271b2d797f658579ac8610dbf5e58bcfd8 so the line length
> Jonathan Wakely via Gcc-patches writes:
Replying to a quite old email...
I ran a Python linter on the libstdc++ pretty-printers.
I have fixes for most of the issues that are worth fixing (I didn't
bother with line lengths -- FWIW in gdb we just run 'black' and don't
worry about these deta
> "Eric" == Eric Gallager via Gdb-patches
> writes:
Eric> Just as a point of reference, but the default makeinfo shipped with
Eric> macOS (/usr/bin/makeinfo) is stuck at version 4.8 due to the whole
Eric> GPL3 transition. The other makeinfos that I have installed are:
[...]
I think brew
> "Nick" == Nick Clifton via Gdb-patches
> writes:
Nick> The reason for the change is that the bfd documentation now needs at
Nick> least version 6.8 in order to build[1][2].
Sorry about this. It was fallout from my patch.
However, GDB has used this same one-argument @node syntax
> Jonathan Wakely writes:
> Looks good. OK for trunk, and OK to backport after some soak time on trunk.
> Thanks.
AdaCore doesn't need a backport of this, and I don't think it's
extremely important; so unless you want me to do it, I don't plan to.
I did check it in on trunk earlier today.
The libstdc++ test suite checks whether gdb type printers are
available like so:
set do_whatis_tests [gdb_batch_check "python print(gdb.type_printers)" \
"\\\[\\\]"]
This regexp assumes that the list of printers is empty. However,
sometimes it's convenient to ship
> "Segher" == Segher Boessenkool writes:
>> FWIW I sent a gdb patch to work around this bug. However, in my
>> examples, I only ever saw a nop following the call instruction -- so I
>> had gdb check for this.
Segher> GCC inserts just a nop in most cases, but the linker or dynamic linker
Seg
> "Segher" == Segher Boessenkool writes:
Segher> Yes. On most architectures you can get multiple machine instructions of
Segher> course (for long calls for example), but on rs6000 (with some ABIs, in
Segher> some circumstances) we generate a nop insn after calls, so that the
Segher> linker h
>> I think it's fine to move forward with this now.
>> Thank you again for doing this.
Andrew> Just to double check this is an approval?
Yes, sorry for being unclear.
Tom
> "Andrew" == apinski--- via Gdb-patches
> writes:
Andrew> From: Andrew Pinski
Andrew> This patch uses the toplevel configure parts for GMP/MPFR for
Andrew> gdb. The only thing is that gdb now requires MPFR for building.
Andrew> Before it was a recommended but not required library.
Andr
> "Joel" == Joel Brobecker via Gdb-patches
> writes:
Joel> ChangeLog:
Joel> * src-release.sh (GDB_SUPPORT_DIRS): Add libsframe.
Joel> Ok to apply to master?
Looks good to me.
I think we recently agreed that gdb and binutils maintainers can approve
patches like this... ?
thank
> "Jeff" == Jeff Law via Gcc-patches writes:
>> This patch uses the toplevel configure parts for GMP/MPFR for
>> gdb.
Jeff> If the GDB folks confirm they want this behavior, then the toplevel
Jeff> bits are fine.
I think we do, but my inclination is to wait until after GDB 13 branches.
CCin
> "Andrew" == apinski--- via Gcc-patches writes:
Andrew> From: Andrew Pinski
Andrew> This patch uses the toplevel configure parts for GMP/MPFR for
Andrew> gdb. The only thing is that gdb now requires MPFR for building.
Andrew> Before it was a recommended but not required library.
Andrew> Als
> "Ben" == Ben Boeckel via Gcc-patches writes:
Ben> - `-fdeps-file=` specifies the path to the file to write the format to.
I don't know how this output is intended to be used, but one mistake
made with the other dependency-tracking options was that the output file
isn't created atomically.
> "Mark" == Mark Wielaard writes:
Mark> DW_LANG_Rust_old was used by old rustc compilers <= 2016 before DWARF5
Mark> assigned an official number. It might be recognized by some
Mark> debuggers.
FWIW I wouldn't worry about it any more.
We could probably just remove the '_old' constant.
Tom
ver that wasn't removed by the earlier patch. This is also
removed here.
ChangeLog
2022-03-18 Tom Tromey
* configure.ac: Remove --with-mpfr-dir and --with-gmp-dir.
* configure: Rebuild.
---
ChangeLog| 5 +
configure| 22 +-
configure.ac |
This changes godump to use the new htab_eq_string function.
gcc
* godump.c (string_hash_eq): Remove.
(go_finish): Use htab_eq_string.
---
gcc/godump.c | 14 +++---
1 file changed, 3 insertions(+), 11 deletions(-)
diff --git a/gcc/godump.c b/gcc/godump.c
index 7864d9d63e5
This changes one spot in GCC to use the new htab_eq_string function.
gcc
* gengtype-state.c (read_state): Use htab_eq_string.
(string_eq): Remove.
---
gcc/gengtype-state.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/gcc/gengtype-state.c b/gcc/g
The libiberty hash table defines a hash function for strings, but not
an equality function. This means that various files have had to
implement their own comparison function over the years.
This series resolves this for gcc. Once this is in, I plan to import
the change into binutils-gdb and appl
The libiberty hash table includes a helper function for strings, but
no equality function. Consequently, this equality function has been
reimplemented a number of times in both the gcc and binutils-gdb
source trees. This patch adds the function to the libiberty hash
table, as a step toward the go
Jeff> OK
Jeff> I think that's the whole set. If not, let me know.
It is. Thank you for the reviews.
I am checking it in now.
Tom
> "Simon" == Simon Marchi via Gcc-patches writes:
Simon> For GDB, it's not supported to run gdb/configure directly, you need to
Simon> use the top-level configure. Is it supported from some of the other
Simon> projects in the repo?
It can be done sometimes but I think it isn't really a scen
>>>>> "Jeff" == Jeff Law writes:
Jeff> On 4/27/2021 7:01 PM, Tom Tromey wrote:
>> This changes libcc1 to use std::vector in the code that builds
>> function types. This avoids some explicit memory management.
>>
>> libcc1/ChangeLog
Both plugins in libcc1 share a fair amount of boilerplate. They both
share error-emission code, context management code, and tree GC code.
This patch unifies these two bodies of code, avoiding needless
duplication.
libcc1/ChangeLog
2021-04-27 Tom Tromey
* libcc1plugin.cc: Move code
rbose' setting. This patch adds a
'verbose' setting directly to the compiler object instead.
Second, the 'find' method implicitly knew which compiler base name
("gcc" or "g++") to use. This patch makes this a parameter that is
passed in by th
it turns out
that the approach taken here is basically equivalent to std::apply --
just a bit wordier.
libcc1/ChangeLog
2021-04-27 Tom Tromey
* rpc.hh (argument_wrapper) : Replace cast operator.
(argument_wrapper) : Likewise.
(unmarshall): Add std::tuple overloads
This is a trivial change to libcc1 to avoid an explicit call to c_str.
Passing by const reference is slightly less wordy.
libcc1/ChangeLog
2021-04-27 Tom Tromey
* compiler.cc (make_regexp): Take const std::string.
(cc1_plugin::compiler_triplet_regexp::find): Update
This changes one spot in libcc1 to use static_assert rather than the
old-style array declaration.
libcc1/ChangeLog
2021-04-27 Tom Tromey
* libcp1plugin.cc: Use static assert.
---
libcc1/ChangeLog | 4
libcc1/libcp1plugin.cc | 4 ++--
2 files changed, 6 insertions(+), 2
The two GDB plugins in libcc1 share a fair amount of code. This was
done by copy-and-paste, though in reality the underlying code is
nearly identical.
libcc1/ChangeLog
2021-04-27 Tom Tromey
* libcp1.cc (struct libcp1): Derive from base_gdb_plugin. Remove
shared code
base_gdb_plugin, which was
introduced earlier for this purpose.
libcc1/ChangeLog
2021-04-27 Tom Tromey
* libcp1.cc (libcp1): Change parameters. Update.
(libcp1_set_verbose, libcp1_set_arguments)
(libcp1_set_triplet_regexp, libcp1_set_driver_filename
.
libcc1/ChangeLog
2021-04-27 Tom Tromey
* libcp1.cc (vtable): Use GCC_FE_VERSION_1.
---
libcc1/ChangeLog | 4
libcc1/libcp1.cc | 2 +-
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/libcc1/libcp1.cc b/libcc1/libcp1.cc
index 6fb9fb4c9a6c..65e9770205c0 100644
--- a/libcc1
thing, plenty of other allocations do
not bother with this.
libcc1/ChangeLog
2021-04-27 Tom Tromey
* gdbctx.hh (do_compile): Use std::vector.
---
libcc1/ChangeLog | 4
libcc1/gdbctx.hh | 8 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/libcc1/gdbctx.hh b/l
PR c/94669 points out that a couple of spots in libcc1 take a
std::string where a reference would do. This changes these spots to
take a const char *, to reduce the number of copies.
libcc1/ChangeLog
2021-04-27 Tom Tromey
PR c/94669:
* compiler.hh (compiler_driver_filename
This changes libcc1 to ues foreach in a couple of spots.
libcc1/ChangeLog
2021-04-27 Tom Tromey
* libcp1plugin.cc (plugin_context::mark): Use foreach.
* libcc1plugin.cc (plugin_context::mark): Use foreach.
---
libcc1/ChangeLog | 5 +
libcc1/libcc1plugin.cc | 13
og
2021-04-27 Tom Tromey
* rpc.hh (deleter): Move template and some specializations to
deleter.hh.
(argument_wrapper): Use cc1_plugin::unique_ptr.
* marshall.cc (cc1_plugin::unmarshall): Use
cc1_plugin::unique_ptr.
* marshall-cp.hh (del
This changes libcc1 to use unique_ptr in a few more places, removing
some manual memory management.
libcc1/ChangeLog
2021-04-27 Tom Tromey
* libcp1.cc (struct libcp1) : Use
unique_ptr.
(~libcp1): Remove.
(libcp1_compile, libcp1_set_triplet_regexp
boilerplate code is completely shared, leaving
just the memory-management detail to the particular specializations.
libcc1/ChangeLog
2021-04-27 Tom Tromey
* rpc.hh (struct deleter): New template class and
specializations.
(argument_wrapper): Remove specializations. Add
This changes libcc1 to use std::vector in the code that builds
function types. This avoids some explicit memory management.
libcc1/ChangeLog
2021-04-27 Tom Tromey
* libcp1plugin.cc (plugin_build_function_type): Use std::vector.
* libcc1plugin.cc (plugin_build_function_type
This changes libcc1 to use variadic templates for the "call"
functions. The primary benefit is that this simplifies the code.
libcc1/ChangeLog
2021-04-27 Tom Tromey
* rpc.hh (call): Use variadic template. Remove overloads.
* marshall.hh (marshall): Add base over
This changes libcc1 to use variadic templates for the "rpc" functions.
This simplifies the code and removes some possibility for mistakes.
libcc1/ChangeLog
2021-04-27 Tom Tromey
* libcp1.cc (rpc): Use variadic template. Remove overloads.
* libcc1.cc (rpc): Us
Change libcc1 to use "= delete" for the copy constructor and
assignment operator, rather than the old approach of private methods
that are nowhere defined.
libcc1/ChangeLog
2021-04-27 Tom Tromey
* rpc.hh (argument_wrapper): Use delete for copy constructor.
* con
This changes libcc1 to use "override" where appropriate.
libcc1/ChangeLog
2021-04-27 Tom Tromey
* libcp1.cc (class compiler_triplet_regexp)
(class compiler_driver_filename, class libcp1_connection): Use
"override".
* libcc1.cc (class com
This changes libcc1 to inline a trivial method and to use the default
constructor.
libcc1/ChangeLog
2021-04-27 Tom Tromey
* connection.hh (~connection): Use default.
(print): Inline.
* connection.cc (cc1_plugin::connection::~connection)
(cc1_plugin::connection
Now that C++11 can be used in GCC, libcc1 can be changed to use
templates and type traits to handle unmarshalling all kinds of enums.
libcc1/ChangeLog
2021-04-27 Tom Tromey
* marshall.hh (cc1_plugin::unmarshall): Use type traits.
* marshall-cp.hh (cc1_plugin::unmarshall
1 - 100 of 579 matches
Mail list logo