[PATCH] Use DW_TAG_module for Ada

2024-05-03 Thread Tom Tromey
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

Re: [RFC][PATCH v1 1/4] Documentation change

2024-04-19 Thread Tom Tromey
> 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

Re: [RFC 0/2] black, isort, and flake8 configuration

2024-04-04 Thread Tom Tromey
>>>>> "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 peopl

[PATCH] libiberty: Invoke D demangler when --format=auto

2024-03-30 Thread Tom Tromey
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

Re: [PATCH v8 0/5] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

2024-03-29 Thread Tom Tromey
> 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

Re: [PATCH v8 0/5] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

2024-03-29 Thread Tom Tromey
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

Re: [PATCH v8 0/5] New attribute "counted_by" to annotate bounds for C99 FAM(PR108896)

2024-03-29 Thread Tom Tromey
> 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

[PATCH] Prettify output of debug_dwarf_die

2024-03-28 Thread Tom Tromey
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

Re: [PATCH] Revert "Pass GUILE down to subdirectories"

2024-03-22 Thread Tom Tromey
> "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

Re: [PATCH] Revert "Pass GUILE down to subdirectories"

2024-03-08 Thread Tom Tromey
> "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

Re: [PATCH 1/3] Change 'v1' float and int code to fall back to v0

2024-02-29 Thread Tom Tromey
> "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

Re: [PATCH 1/3] Change 'v1' float and int code to fall back to v0

2024-02-28 Thread Tom Tromey
> "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

Re: [PATCH 1/3] Change 'v1' float and int code to fall back to v0

2024-02-28 Thread Tom Tromey
> "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

[PATCH 3/3] Fix PR libcc1/113977

2024-02-26 Thread Tom Tromey
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. * gcc-c

[PATCH 2/3] Fix version negotiation in libcc1 plugins

2024-02-26 Thread Tom Tromey
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::libcc1): Use FE

[PATCH 1/3] Change 'v1' float and int code to fall back to v0

2024-02-26 Thread Tom Tromey
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 (safe_lookup_builtin_type): Handle

[PATCH 0/3] Fix libcc1 failure

2024-02-26 Thread Tom Tromey
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 ++ include/gcc-c-fe.def

Re: [PATCH] Revert "Pass GUILE down to subdirectories"

2024-02-10 Thread Tom Tromey
>>>>> "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

[PATCH] Revert "Pass GUILE down to subdirectories"

2024-01-22 Thread Tom Tromey
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. *

Re: [PATCH] Pass GUILE down to subdirectories

2024-01-22 Thread Tom Tromey
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

Re: [PATCH] Pass GUILE down to subdirectories

2024-01-18 Thread Tom Tromey
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>

[PATCH] Pass GUILE down to subdirectories

2023-12-30 Thread Tom Tromey
E=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 ++-- Makefile.tpl | 7

Re: [PATCH] Add some new DW_IDX_* constants

2023-12-10 Thread Tom Tromey
> "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

[PATCH] Add some new DW_IDX_* constants

2023-12-09 Thread Tom Tromey
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

Re: [PATCH] gettext: disable install, docs targets, libasprintf, threads

2023-12-04 Thread Tom Tromey
> "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

[PATCH] Fix crash in libcc1

2023-11-14 Thread Tom Tromey
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. ---

[RFC 1/2] libstdc++: Use 'black' and 'isort' in pretty printers

2023-10-04 Thread Tom Tromey
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.

[RFC 2/2] libstdc++: Add flake8 configuration

2023-10-04 Thread Tom Tromey
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

[RFC 0/2] black, isort, and flake8 configuration

2023-10-04 Thread Tom Tromey
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

[PATCH] libstdc++: Correctly call _string_types function

2023-10-04 Thread Tom Tromey
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. ---

[PATCH 2/2] libstdc++: _versioned_namespace is always non-None

2023-10-03 Thread Tom Tromey
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

[PATCH 1/2] libstdc++: Define _versioned_namespace in xmethods.py

2023-10-03 Thread Tom Tromey
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. ---

[PATCH 0/2] A couple minor _versioned_namespace patches

2023-10-03 Thread Tom Tromey
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

Re: [PATCH 2/7] libstdc++: Use gdb.ValuePrinter base class

2023-09-28 Thread Tom Tromey
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

Re: [PATCH 6/7] libstdc++: Fix regex escapes in pretty-printers

2023-09-28 Thread Tom Tromey
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

[PATCH 2/7] libstdc++: Use gdb.ValuePrinter base class

2023-09-28 Thread Tom Tromey
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

[PATCH 7/7] libstdc++: Use Python "not in" operator

2023-09-28 Thread Tom Tromey
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)

[PATCH 4/7] libstdc++: Remove unused locals from printers.py

2023-09-28 Thread Tom Tromey
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. ---

[PATCH 6/7] libstdc++: Fix regex escapes in pretty-printers

2023-09-28 Thread Tom Tromey
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. *

[PATCH 5/7] libstdc++: Remove std_ratio_t_tuple

2023-09-28 Thread Tom Tromey
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):

[PATCH 3/7] libstdc++: Remove unused Python imports

2023-09-28 Thread Tom Tromey
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

[PATCH 0/7] libstdc++: Use gdb.ValuePrinter in pretty-printers

2023-09-28 Thread Tom Tromey
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

[PATCH 1/7] libstdc++: Show full Python stack on error

2023-09-28 Thread Tom Tromey
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

Re: [committed] libstdc++: Add GDB printers for types

2023-09-28 Thread Tom Tromey
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),

Re: [committed] libstdc++: Add GDB printers for types

2023-09-27 Thread Tom Tromey
>> 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

Re: [committed] libstdc++: Add GDB printers for types

2023-09-27 Thread Tom Tromey
> 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

Re: RFC: Top level configure: Require a minimum version 6.8 texinfo

2023-08-30 Thread Tom Tromey
> "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

Re: RFC: Top level configure: Require a minimum version 6.8 texinfo

2023-08-29 Thread Tom Tromey
> "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

Re: [PATCH] Relax type-printer regexp in libstdc++ test suite

2023-06-29 Thread Tom Tromey via Gcc-patches
> 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.

[PATCH] Relax type-printer regexp in libstdc++ test suite

2023-06-28 Thread Tom Tromey via Gcc-patches
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

Re: [PATCH] [rs6000] adjust return_pc debug attrs

2023-03-24 Thread Tom Tromey via Gcc-patches
> "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

Re: [PATCH] [rs6000] adjust return_pc debug attrs

2023-03-17 Thread Tom Tromey via Gcc-patches
> "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

Re: [PATCHv2] Use toplevel configure for GMP and MPFR for gdb

2022-12-21 Thread Tom Tromey
>> 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

Re: [PATCHv2] Use toplevel configure for GMP and MPFR for gdb

2022-12-20 Thread Tom Tromey
> "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.

Re: [RFA] src-release.sh: Fix gdb source tarball build failure due to libsframe

2022-11-28 Thread Tom Tromey
> "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... ?

Re: [PATCHv2] Use toplevel configure for GMP and MPFR for gdb

2022-11-16 Thread Tom Tromey
> "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.

Re: [PATCH] Use toplevel configure for GMP and MPFR for gdb

2022-11-10 Thread Tom Tromey
> "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>

Re: [PATCH v2 3/3] p1689r5: initial support

2022-11-01 Thread Tom Tromey
> "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.

Re: [PATCH Rust front-end v3 01/46] Use DW_ATE_UTF for the Rust 'char' type

2022-10-31 Thread Tom Tromey via Gcc-patches
> "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

[PATCH] Remove --with-gmp-dir and --with-mpfr-dir

2022-03-18 Thread Tom Tromey via Gcc-patches
hat 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 | 14 ++-

[PATCH 3/3] go: use htab_eq_string in godump

2021-05-05 Thread Tom Tromey
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

[PATCH 2/3] gcc: use htab_eq_string

2021-05-05 Thread Tom Tromey
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

[PATCH 0/3] Add htab_eq_string to libiberty

2021-05-05 Thread Tom Tromey
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

[PATCH 1/3] libiberty: add htab_eq_string

2021-05-05 Thread Tom Tromey
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

Re: [PATCH v2 19/21] libcc1: use variadic templates for callbacks

2021-05-04 Thread Tom Tromey
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

Re: RFC: Changing AC_PROG_CC to AC_PROG_CC_C99 in top level configure

2021-05-03 Thread Tom Tromey
> "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

Re: [PATCH v2 07/21] libcc1: use std::vector when building function types

2021-04-28 Thread Tom Tromey
>>>>> "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

[PATCH v2 14/21] libcc1: share basic context code

2021-04-27 Thread Tom Tromey
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

[PATCH v2 11/21] libcc1: unify compiler handling

2021-04-27 Thread Tom Tromey
' 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 the plugin. libcc1/ChangeLog 20

[PATCH v2 19/21] libcc1: use variadic templates for callbacks

2021-04-27 Thread Tom Tromey
, but 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

[PATCH v2 21/21] libcc1: avoid a call to c_str

2021-04-27 Thread Tom Tromey
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

[PATCH v2 13/21] libcc1: use static_assert

2021-04-27 Thread Tom Tromey
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

[PATCH v2 15/21] libcc1: share GDB plugin code

2021-04-27 Thread Tom Tromey
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

[PATCH v2 17/21] libcc1: share the GCC interface code

2021-04-27 Thread Tom Tromey
into 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

[PATCH v2 16/21] libcc1: use GCC_FE_VERSION_1 in C++ plugin

2021-04-27 Thread Tom Tromey
. 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

[PATCH v2 18/21] libcc1: fix a memory leak

2021-04-27 Thread Tom Tromey
, 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/libcc1

[PATCH v2 20/21] libcc1: avoid extra string copies

2021-04-27 Thread Tom Tromey
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

[PATCH v2 12/21] libcc1: use foreach

2021-04-27 Thread Tom Tromey
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

[PATCH v2 09/21] libcc1: add more uses of 'deleter'

2021-04-27 Thread Tom Tromey
-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 (deleter): New

[PATCH v2 10/21] libcc1: use unique_ptr more

2021-04-27 Thread Tom Tromey
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

[PATCH v2 08/21] libcc1: add deleter objects

2021-04-27 Thread Tom Tromey
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

[PATCH v2 07/21] libcc1: use std::vector when building function types

2021-04-27 Thread Tom Tromey
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

[PATCH v2 05/21] libcc1: use variadic templates for "call"

2021-04-27 Thread Tom Tromey
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

[PATCH v2 06/21] libcc1: use variadic templates for "rpc"

2021-04-27 Thread Tom Tromey
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

[PATCH v2 04/21] libcc1: delete copy constructor and assignment operators

2021-04-27 Thread Tom Tromey
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

[PATCH v2 02/21] libcc1: use "override"

2021-04-27 Thread Tom Tromey
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

[PATCH v2 03/21] libcc1: inline some simple methods

2021-04-27 Thread Tom Tromey
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

[PATCH v2 01/21] libcc1: use templates to unmarshall enums

2021-04-27 Thread Tom Tromey
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

[PATCH v2 00/21] C++11-based improvements for libcc1

2021-04-27 Thread Tom Tromey
Here is v2 of my series to simplify libcc1 through the use of C++11 constructs. v1 is here: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/562668.html I never pinged it because I'd sent it in the wrong stage. As with v1, this brings libcc1 much closer to how I originally wanted it

Re: [PATCH] Use hardware_concurrency only if _GLIBCXX_HAS_GTHREADS

2021-04-21 Thread Tom Tromey
> "Jakub" == Jakub Jelinek via Gcc-patches writes: Jakub> What would be IMHO a good idea would be to use configure test for Jakub> #include Jakub> int t = std::thread::hardware_concurrency (); Jakub> and in that case use that as a fallback to the previous implementation, Jakub> that will be

Re: [PATCH] libgccjit: Handle truncation and extension for casts [PR 95498]

2021-02-20 Thread Tom Tromey
> "Antoni" == Antoni Boucher via Gcc-patches > writes: Antoni> gcc/jit/ Antoni> PR target/95498 Antoni> * jit-playback.c: Add support to handle truncation and extension Antoni> in the convert function. Antoni> + switch (dst_code) Antoni> +{ Antoni> +

Re: [PATCH] Fix producer string memory leaks

2021-02-16 Thread Tom Tromey
> "Martin" == Martin Sebor via Gcc-patches writes: Martin> FWIW, I have prototyped Martin> a simple string class over the weekend (based on auto_vec) that I'm Martin> willing to contribute if std::string turns out to be out of favor. I wonder whether GDB and GCC can or should collaborate in

Re: [PATCH 00/10] C++11-based improvements for libcc1

2021-01-03 Thread Tom Tromey
>>>>> "Tom" == Tom Tromey writes: Tom> This short series uses C++11 features to simplify libcc1. This brings Tom> the code closer to how I pictured it when I first wrote it. (It would Tom> be further improved by std::apply, but this isn't available until

[PATCH 10/10] libcc1: use unique_ptr more

2021-01-03 Thread Tom Tromey
This changes libcc1 to use unique_ptr in a few more places, removing some manual memory management. libcc1/ChangeLog 2021-01-03 Tom Tromey * libcp1.cc (struct libcp1) : Use unique_ptr. (~libcp1): Remove. (libcp1_compile, libcp1_set_triplet_regexp

[PATCH 09/10] libcc1: add more uses of 'deleter'

2021-01-03 Thread Tom Tromey
-03 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 (deleter): New

[PATCH 08/10] libcc1: add deleter objects

2021-01-03 Thread Tom Tromey
boilerplate code is completely shared, leaving just the memory-management detail to the particular specializations. libcc1/ChangeLog 2021-01-03 Tom Tromey * rpc.hh (struct deleter): New template class and specializations. (argument_wrapper): Remove specializations. Add

[PATCH 04/10] libcc1: delete copy constructor and assignment operators

2021-01-03 Thread Tom Tromey
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-01-03 Tom Tromey * rpc.hh (argument_wrapper): Use delete for copy constructor. * con

[PATCH 06/10] libcc1: use variadic templates for "rpc"

2021-01-03 Thread Tom Tromey
This changes libcc1 to use variadic templates for the "rpc" functions. This simplifies the code and removes some possibility for mistakes. libcc1/ChangeLog 2021-01-03 Tom Tromey * libcp1.cc (rpc): Use variadic template. Remove overloads. * libcc1.cc (rpc): Us

[PATCH 07/10] libcc1: use std::vector when building function types

2021-01-03 Thread Tom Tromey
This changes libcc1 to use std::vector in the code that builds function types. This avoids some explicit memory management. libcc1/ChangeLog 2021-01-03 Tom Tromey * libcp1plugin.cc (plugin_build_function_type): Use std::vector. * libcc1plugin.cc (plugin_build_function_type

[PATCH 05/10] libcc1: use variadic templates for "call"

2021-01-03 Thread Tom Tromey
This changes libcc1 to use variadic templates for the "call" functions. The primary benefit is that this simplifies the code. libcc1/ChangeLog 2021-01-03 Tom Tromey * rpc.hh (call): Use variadic template. Remove overloads. * marshall.hh (marshall): Add base over

  1   2   3   4   5   6   >