Re: configure adds -std=gnu++11 to CXX variable

> "Jason" == Jason Merrill writes: Jason> Thanks, though I don't think all that code needs to go; Jason> AC_PROG_CXX_STDCXX_EDITION_TRY still looks useful for a project that Jason> relies on features from a particular standard. We just don't want Jason> AC_PROG_CXX to invoke it. I didn't

[gcc r15-637] Use DW_TAG_module for Ada

https://gcc.gnu.org/g:9b6acf5357818ce7ff234c504ed79078a06d0e0f commit r15-637-g9b6acf5357818ce7ff234c504ed79078a06d0e0f Author: Tom Tromey Date: Thu Apr 18 09:08:23 2024 -0600 Use DW_TAG_module for Ada DWARF is not especially clear on the distinction between DW_TAG_namespace

Re: [PATCH] Use DW_TAG_module for Ada

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

[PATCH] Use DW_TAG_module for Ada

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: Updated Sourceware infrastructure plans

> Do you (or others) have any thoughts about GitLab FOSS? Dunno about the FOSS edition specifically, but I've used many review tools in anger in the last 5 years: github, gitlab, gerrit, phabricator, and a couple that ran in bugzilla ("MozReview", not sure if it had some other name; and a second

Re: Updated Sourceware infrastructure plans

Mark> See also https://sourceware.org/bugzilla/show_bug.cgi?id=30997 Mark> We really should automate this. There are several people running Mark> scripts by hand. The easiest would be to simply run it from a git Mark> hook. patchwork comes with a simple script that just calculates the Mark> hash

Re: Updated Sourceware infrastructure plans

> Indeed. Though Patchwork is another option for patch tracking, that > glibc seem to be having success with. We tried this in gdb as well. It was completely unworkable -- you have to manually clear out the patch queue, meaning it's normally full of patches that already landed. I know glibc

Re: Updated Sourceware infrastructure plans

Jason> Someone mentioned earlier that gerrit was previously tried Jason> unsuccessfully. We tried it and gdb and then abandoned it. We tried to integrate it into the traditional gdb development style, having it send email to gdb-patches. I found these somewhat hard to read and in the end we

Re: Updated Sourceware infrastructure plans

> "Frank" == Frank Ch Eigler writes: >> [...] I suggest that a basic principle for such a system is that it >> should be *easy* to obtain and maintain a local copy of the history >> of all pull requests. That includes all versions of a pull request, >> if it gets rebased, and all versions

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

> 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

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

Re: Sourceware mitigating and preventing the next xz-backdoor

> "Florian" == Florian Weimer writes: Florian> Everyone still pushes their own patches, and there are no Florian> technical countermeasures in place to ensure that the pushed version is Florian> the reviewed version. This is a problem for gdb as well. Probably we should switch to some kind

[gcc r14-9760] libiberty: Invoke D demangler when --format=auto

https://gcc.gnu.org/g:ca2f7c84927f85b95f0f48f82b93f1460c372db4 commit r14-9760-gca2f7c84927f85b95f0f48f82b93f1460c372db4 Author: Tom Tromey Date: Sat Mar 30 13:48:30 2024 -0600 libiberty: Invoke D demangler when --format=auto Investigating GDB PR d/31580 showed that the libiberty

[gcc r14-9754] Prettify output of debug_dwarf_die

https://gcc.gnu.org/g:1e459e6625ff86babc461f8ceada0a63aee5b7a5 commit r14-9754-g1e459e6625ff86babc461f8ceada0a63aee5b7a5 Author: Tom Tromey Date: Thu Mar 28 13:22:34 2024 -0600 Prettify output of debug_dwarf_die When debugging gcc, I tried calling debug_dwarf_die and I saw

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

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)

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

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)

> 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

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"

> "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: [RFC] add regenerate Makefile target

> not sure if the current autoregen.py is in sync with that? I'm curious why "autoreconf -f" is insufficient. It seems to me that this should work. > Also... I discovered the existence of an automake rule: > am--refresh which IIUC is intended to automake the update of Makefile > and its

Re: [RFC] add regenerate Makefile target

> "Eric" == Eric Gallager writes: Eric> Also there are the files generated by cgen, too, which no one seems to Eric> know how to regenerate, either. I thought I sent out some info on this a while ago. Anyway what I do is make a symlink to the cgen source tree in the binutils-gdb source

Re: Using std types and functions within GCC

> "David" == David Malcolm via Gcc writes: David> For example, there's at David> least one place where I'd have used std::optional, but that's C++14 and David> so unavailable. FWIW, gdb had its own gdb::optional (which was really just a stripped-down copy of the one from libstdc++) to fill

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

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

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

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

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

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

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

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

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"

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

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

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

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>

Re: lambda coding style

> "Jason" == Jason Merrill via Gcc writes: Jason> I think we probably want the same formatting for lambdas in function Jason> argument lists, e.g. Jason> algorithm ([] (parms) Jason> { Jason> return foo; Jason> }); Jason> Any other opinions? FWIW gdb did pretty much this same

[PATCH] Pass GUILE down to subdirectories

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

> 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

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

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

> 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

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

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

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

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

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

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

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

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

> "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 v2 3/3] p1689r5: initial support

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

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

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

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

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

Re: Issue with pointer types marked with scalar_storage_order

> "Ulrich" == Ulrich Weigand via Gcc writes: Ulrich> If we do want to byte-swap pointer types, then I guess we need Ulrich> to still fix the debug info problem, which I guess would at a Ulrich> minimum require extending DWARF to allow DW_AT_endianity as an Ulrich> attribute to

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

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

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

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

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

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

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

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

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

' 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

, 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

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

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

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

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

. 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

, 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

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

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'

-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

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

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

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

  1   2   3   4   5   6   7   8   9   >