On 5/2/24 2:47 AM, Richard Biener via Overseers wrote:> We'd only know for sure
if we try. But then I'm almost 100% sure that
> having to click in a GUI is slower than 'nrOK^X' in the text-mode mail UA
> I am using for "quick" patch review. It might be comparable to the
> review parts I do in
On 2024-05-01 16:53, Tom Tromey via Overseers wrote:
> 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
On 4/30/24 8:43 AM, Gaius Mulley wrote:
> Christophe Lyon writes:
>
>> On Tue, 30 Apr 2024 at 04:01, Simon Marchi wrote:
>>>
>>> I get a diff when running "autoreconf" in this directory. I think that
>>> the current state is e
On 4/30/24 4:54 AM, Christophe Lyon wrote:
> On Tue, 30 Apr 2024 at 04:25, Simon Marchi wrote:
>>
>> Add an "AC_CONFIG_MACRO_DIRS" call in configure.ac, with the same
>> directories as specified in "ACLOCAL_AMFLAGS", in Makefile.in.
>>
>> T
Add an "AC_CONFIG_MACRO_DIRS" call in configure.ac, with the same
directories as specified in "ACLOCAL_AMFLAGS", in Makefile.in.
This makes it possible to re-generate aclocal.m4 using "autoreconf".
---
fixincludes/configure| 1 +
fixincludes/configure.ac | 1 +
2 files changed, 2
I get a diff when running "autoreconf" in this directory. I think that
the current state is erroneous: it appears to have been generated using
aclocal -I ../config -I ..
even though configure.ac and Makefile.am list the include flag in the
reverse order:
aclocal -I .. -I ../config
On 2024-04-23 11:08, Tom Tromey wrote:
>> 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
On 2024-04-22 22:55, Jason Merrill via Overseers wrote:
> On Mon, Apr 22, 2024 at 11:42 AM Tom Tromey wrote:
>
>>> "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
On 2024-04-04 17:35, Mark Wielaard wrote:
> Hi Christophe,
>
> On Wed, Apr 03, 2024 at 10:22:24AM +0200, Christophe Lyon via Gdb wrote:
>> TL;DR: For the sake of improving precommit CI coverage and simplifying
>> workflows, I’d like to request a patch submission policy change, so
>> that we
On 4/3/24 4:22 AM, Christophe Lyon via Gdb wrote:
> Dear release managers and developers,
>
> TL;DR: For the sake of improving precommit CI coverage and simplifying
> workflows, I’d like to request a patch submission policy change, so
> that we now include regenerated files. This was discussed
On 2024-03-15 10:25, Tom Tromey wrote:
> gdb used to use a mish-mash of different approaches, some quite strange,
> but over the last few years we standardized on Python scripts that
> generate files. They're written to be seamless -- just invoke in the
> source dir; the output is then just
On 3/18/24 13:25, Christophe Lyon wrote:
> Well the rule to regenerate Makefile.in (eg in in opcodes/) is a bit
> more complex
> than just calling automake. IIUC it calls automake --foreign it any of
> *.m4 file from $(am__configure_deps) that is newer than Makefile.in
> (with an early exit in the
On 3/18/24 13:28, Christophe Lyon via Gdb wrote:
> I'm not up-to-date with gdb's policy about patches: are they supposed
> to be posted with or without the regenerated parts included?
> IIUC they are not included in patch submissions for binutils and gcc,
> which makes the pre-commit CI miss some
On 2024-03-15 04:50, Christophe Lyon via Gdb wrote:
> On Thu, 14 Mar 2024 at 19:10, Simon Marchi wrote:
>> My first thought it: why is it a Makefile target, instead of some script
>> on the side (like autoregen.sh). It would be nice / useful to be
>> able to it without c
On 2024-03-13 04:02, Christophe Lyon via Gdb wrote:
> Hi!
>
> After recent discussions on IRC and on the lists about maintainer-mode
> and various problems with auto-generated source files, I've written
> this small prototype.
>
> Based on those discussions, I assumed that people generally
Hi gcc-patches,
I had applied the patch below to binutils-gdb, but it recently got wiped
out by a gcc -> binutils-gdb configure.ac sync. Would it be possible to
apply it to the gcc repo so this doesn't happen again?
Thanks,
Simon
On 2022-03-15 17:26, Simon Marchi via Gdb-patches wrote:
>
Add
AC_CONFIG_MACRO_DIRS([../config])
So that just running:
$ autoreconf -vf
... does the right thing (no need to specify -I ../config).
Note: I don't have access to the gcc repo, so if this patch is approved,
can somebody push it there on my behalf? I can push it to binutils-gdb.
On 2022-04-08 10:32, Nick Clifton wrote:
> Hi Simon,
>
>> Ping.
>
> Patch approved - please apply.
>
> I appreciate that modifying these top level files is a bit nerve
> wracking, but I think that you have done a good job in this case. :-)
>
> Cheers
> Nick
>
Thanks Nick, pushed.
Simon
Ping.
On 2022-03-29 16:04, Simon Marchi wrote:
> Ping!
>
> On 2022-03-15 17:26, Simon Marchi wrote:
>> From: Simon Marchi
>>
>> [Sending to binutils, gdb-patches and gcc-patches, since it touches the
>> top-level Makefile/configure]
>>
>> I have my d
Ping!
On 2022-03-15 17:26, Simon Marchi wrote:
> From: Simon Marchi
>
> [Sending to binutils, gdb-patches and gcc-patches, since it touches the
> top-level Makefile/configure]
>
> I have my debuginfod library installed in a non-standard location
> (/opt/debuginfod), whi
From: Simon Marchi
[Sending to binutils, gdb-patches and gcc-patches, since it touches the
top-level Makefile/configure]
I have my debuginfod library installed in a non-standard location
(/opt/debuginfod), which requires me to set
PKG_CONFIG_PATH=/opt/debuginfod/lib/pkg-config. If I just set
On 2021-05-04 8:42 a.m., Nick Clifton wrote:
> Hi Guys,
>
> On 4/30/21 7:36 PM, Simon Marchi wrote:
>> I think this fix is obvious enough, I encourage you to push it,
>
> OK - I have pushed the patch to the mainline branches of both
> the gcc and binutils-gfdb r
On 2021-05-03 5:51 p.m., Alan Modra wrote:
> I wasn't talking about running configure, I was talking about running
> make. For example, you configure and make binutils as usual, then
> after making a change to ld/ files, run make in the ld build dir. I
> don't tend to do that myself but I do run
> Yes, I prefer the configure fix too. If we state we require C99 in
> binutils then we ought to be able to use C99..
>
> Nick, does the configure.ac change also need to go in all subdirs, to
> support people running make in say ld/ rather than running make in the
> top build dir?
For GDB, it's
On 2021-04-26 7:32 a.m., Nick Clifton via Gdb-patches wrote:> Hi Guys,
>
> Given that gcc, gdb and now binutils are all now requiring C99 as a
> minimum version of C, are there any objections to updating
> configure.ac to reflect this ?
>
> Cheers
> Nick
>
> diff --git a/configure.ac
On 2021-04-08 9:11 a.m., David Edelsohn wrote:
>>> AIX continues to use and support STABS, although it is transitioning
>>> to DWARF. If this is intended as a general statement about removal of
>>> STABS support in GCC,
>>
>> Yes, it is.
>>
>> Richard.
>
> Richard,
>
> It is inappropriate to
On 2021-04-05 3:36 p.m., Jim Wilson wrote:> On Sat, Apr 3, 2021 at 6:24 PM
Simon Marchi via Gcc mailto:gcc@gcc.gnu.org>> wrote:
>
> The default debug format (when using only -g) for the AVR target is
> stabs. Is there a reason for it not being DWARF, and would it
Hi,
The default debug format (when using only -g) for the AVR target is
stabs. Is there a reason for it not being DWARF, and would it be
possible to maybe consider possibly thinking about making it default to
DWARF? I am asking because the support for stabs in GDB is pretty much
untested and
Bring in a few lines that are in binutils-gdb's .gitignore but not
gcc's.
Note that I don't have push access to gcc, so I would appreciate
if somebody could push it for me.
ChangeLog:
* .gitignore: Sync with binutils-gdb.
---
.gitignore | 7 +++
1 file changed, 7 insertions(+)
On 2020-11-13 10:18 a.m., Mark Wielaard wrote:
> That too, but I was actually referring to the sections that define
> Range List and Location List Tables (7.28 and 7.29) which define the
> meaning of DW_AT_rnglists_base and DW_AT_loclists_base. But you could
> also look at 3.1.3 Split Full
On 2020-11-12 7:11 p.m., Mark Wielaard wrote:
> Hi Simon,
>
> On Thu, Nov 05, 2020 at 11:11:43PM -0500, Simon Marchi wrote:
>> I'm currently squashing some bugs related to .debug_rnglists in GDB, and
>> I happened to notice that clang and gcc do different things when
&
Hi,
I'm currently squashing some bugs related to .debug_rnglists in GDB, and
I happened to notice that clang and gcc do different things when
generating rnglists with split DWARF. I'd like to know if the two
behaviors are acceptable, and therefore if we need to make GDB accept
both. Or maybe
On 2020-07-28 2:31 p.m., H.J. Lu wrote:
>>> Unlike gdb, binutils should have as few external depecies as possible.
>>> debuginfod brings in some so many external depecies.
>>
>> I'm not a binutils maintainer, so that's not my role to decide about that
>> tradeoff... but we are talking about having
On 2020-07-28 1:26 p.m., H.J. Lu wrote:
> On Tue, Jul 28, 2020 at 9:28 AM Simon Marchi wrote:
>>
>> On 2020-07-28 12:07 p.m., H.J. Lu via Gdb-patches wrote:
>>> What doesn't work with my pkg.m4 change?
>>
>> (1) It deviates from upstream. I don't think we sho
On 2020-07-28 12:07 p.m., H.J. Lu via Gdb-patches wrote:
> What doesn't work with my pkg.m4 change?
(1) It deviates from upstream. I don't think we should do this unless
absolutely needed. That's not the case here, the change is just there
because you don't want to set up pkg-config
On 2020-07-28 11:05 a.m., H.J. Lu via Gdb-patches wrote:
>> Can you clarify how this magic works, is this standard autoconf? Because I
>> am trying this
>> on Fedora, so pretty much the same setup as you, and I don't see this
>> behavior:
>>
>> $ /home/simark/src/binutils-gdb/configure CC="gcc
On 2020-07-28 10:11 a.m., H.J. Lu wrote:
> On Tue, Jul 28, 2020 at 7:01 AM Simon Marchi wrote:
>>
>> On 2020-07-28 9:56 a.m., H.J. Lu wrote:
>>> On Tue, Jul 28, 2020 at 6:51 AM Andreas Schwab
>>> wrote:
>>>>
>>>> On Jul 28 2020, H.J. Lu
On 2020-07-28 9:56 a.m., H.J. Lu wrote:
> On Tue, Jul 28, 2020 at 6:51 AM Andreas Schwab wrote:
>>
>> On Jul 28 2020, H.J. Lu via Binutils wrote:
>>
>>> On x86, the native GCC can support -m32 and -m64. "gcc -m32" or "gcc -m64"
>>> are not cross compiling.
>>
>> You cannot link -m64 and -m32
On 2020-07-28 9:33 a.m., H.J. Lu wrote:
> On x86, the native GCC can support -m32 and -m64. "gcc -m32" or "gcc -m64"
> are not cross compiling.
And how does that make it not cross-compîling?
>> Anyway regardless of vocabulary, I don't think there was a problem to begin
>> with (not that I
On 2020-07-28 6:45 a.m., H.J. Lu wrote:
> On Mon, Jul 27, 2020 at 12:32 PM H.J. Lu wrote:
>>
>> On Mon, Jul 27, 2020 at 12:14 PM H.J. Lu wrote:
>>>
>>> On Mon, Jul 27, 2020 at 9:11 AM Aaron Merey wrote:
On Mon, Jul 27, 2020 at 11:32 AM H.J. Lu wrote:
>
> On Sat, Jul 25, 2020
On 2020-07-16 6:37 p.m., Aaron Merey wrote:
> On Fri, May 8, 2020 at 4:56 PM Tom Tromey wrote:
>>
>>> "Aaron" == Aaron Merey via Binutils writes:
>>
>> Aaron> * Makefile.in: Replace LIBDEBUGINFOD with DEBUGINFOD_LIBS.
>> Aaron> * aclocal.m4: Rebuild.
>>
>> Instead of inlining
On 2019-07-25 3:13 p.m., Simon Marchi wrote:
> Hi again!
>
> This is a little reminder about the Cauldron 2019. If you plan on attending,
> please
> take a few minutes to send your registration (instructions are on the wiki
> [1]), it
> helps us greatly if you do
On 2019-03-14 5:28 p.m., Simon Marchi wrote:
> Hi all,
>
> We are very pleased to invite you all to the GNU Tools Cauldron on 12-15
> September 2019. This year's Cauldron will be held in Montreal, Canada.
> See the wiki page for details:
>
> https://gcc.gnu.
On 2019-04-16 12:39 a.m., Eric Gallager wrote:
> Hey Montréal, I might actually be able to go this year! How do I register?
Hi Eric,
Happy to hear this! Please see the Registration section on the wiki:
https://gcc.gnu.org/wiki/cauldron2019#Registration
Simon
On 2019-04-15 12:42 p.m., Simon Marchi wrote:
> Hi,
>
> Here is a patch that adds a mention of the 2019 Cauldron, similar to the
> entries
> for the previous editions.
>
> Thanks,
>
> Simon
>
>
> Index: index.html
> ==
Hi,
Here is a patch that adds a mention of the 2019 Cauldron, similar to the entries
for the previous editions.
Thanks,
Simon
Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.1125
diff -u
Hi all,
We are very pleased to invite you all to the GNU Tools Cauldron on 12-15
September 2019. This year's Cauldron will be held in Montreal, Canada.
See the wiki page for details:
https://gcc.gnu.org/wiki/cauldron2019
The conference is free to attend, registration in advance is
From: Дилян Палаузов
[I (Simon) just pushed this to binutils-gdb, please consider merging it
in gcc to keep the files sync-ed(-ish).]
https://sourceware.org/bugzilla/show_bug.cgi?id=18632
The bundled libreadline is always built, even if the system is
./configure'd --with-system-readline and
On 2018-12-14 5:39 p.m., Jason Merrill wrote:
> GDB/binutils folks, how do you want to handle this? Shall I go ahead
> with this patch, with the understanding that there will be associated
> changes necessary when merging it into the binutils-gdb repository, or
> go with the small disabling patch
On 2018-11-06 11:37, Hafiz Abid Qadeer wrote:
Hi All,
I was investigating a character set related problem with windows hosted
GDB and I tracked it down to a typo in iconv.m4. This typo caused
libiconv detection to fail and related support was not built into gdb.
The problem is with the
On 2018-10-30 11:26 p.m., Joseph Myers wrote:
> This patch (diffs to generated files omitted below) updates GCC to use
> autoconf 2.69 and automake 1.15.1. (That's not the latest automake
> version, but it's the one used by binutils-gdb, with which consistency
> is desirable, and in any case
On 2018-08-01 03:58 PM, Simon Marchi wrote:
> This patch was tested to build binutils-gdb on GNU/Linux and macOS. It can be
> applied to the gcc repo too, after fixing some trivial merge conflicts
> (someone
> else will need to do it, as I don't have push access to gcc). Althoug
(CCing gcc-patches because of the change in include/dwarf2.h)
On 2018-08-23 13:35, John Darrington wrote:
* include/dwarf2.h (enum dwarf_unit_type)[DW_EH_PE_udata3]: New member.
* gdb/dwarf2-frame.c (encoding_for_size): Deal with case 3.
(read_encoded_value): Deal with case
On 2018-08-02 13:44, Tom Tromey wrote:
"Simon" == Simon Marchi writes:
Simon> intl/ChangeLog:
Simon> * libgnuintl.h (_INTL_MAY_RETURN_STRING_ARG, gettext, dgettext,
Simon> dcgettext, ngettext, dngettext, dcngettext): Backport changes
Simon> from upstre
On 2018-08-01 10:58, Simon Marchi wrote:
This patch was tested to build binutils-gdb on GNU/Linux and macOS. It
can be
applied to the gcc repo too, after fixing some trivial merge conflicts
(someone
else will need to do it, as I don't have push access to gcc). Although
I think
This patch was tested to build binutils-gdb on GNU/Linux and macOS. It can be
applied to the gcc repo too, after fixing some trivial merge conflicts (someone
else will need to do it, as I don't have push access to gcc). Although I think
it is relatively low-risk, building gcc on macOS was not
On 2018-02-07 12:30, Jonathan Wakely wrote:
Ah ok, the class name appears mangled in other entities' mangled name.
But
from what I understand there's no mangled name for the class such that
echo | c++filt
outputs the class name (e.g. "Foo<10>"). That wouldn't make sense,
since
there's
On 2018-02-07 12:08, Jonathan Wakely wrote:
Why would they not have a mangled name?
Interesting. What do they look like, and in what context do they
appear?
Anywhere you need a name for linkage purposes, such as in a function
signature, or as a template argument of another type, or in the
On 2018-02-07 11:50, Jonathan Wakely wrote:
On 7 February 2018 at 16:36, Simon Marchi wrote:
On 2018-02-07 11:26, Michael Matz wrote:
Hi,
On Wed, 7 Feb 2018, Simon Marchi wrote:
This addresses the issue of how to do good software design in GDB to
support different producers cleanly, but I
On 2018-02-07 11:26, Michael Matz wrote:
Hi,
On Wed, 7 Feb 2018, Simon Marchi wrote:
This addresses the issue of how to do good software design in GDB to
support different producers cleanly, but I think we have some issues
even before that, like how to support g++ 7.3 and up. I'll try
On 2018-02-07 02:21, Daniel Berlin wrote:
As the person who, eons ago, wrote a bunch of the the GDB code for this
C++
ABI support, and as someone who helped with DWARF support in both GDB
and
GCC, let me try to propose a useful path forward (in the hopes that
someone
will say "that's
On 2018-02-05 11:45, Martin Sebor wrote:
Yes, with auto, the type of the constant does determine the type
of the specialization of the template in the source code.
In non-type template arguments, and more to the point I was making,
in diagnostics, the suffix shouldn't or doesn't need to be what
Hi Martin,
Thanks for the reply.
On 2018-02-04 02:17 PM, Martin Sebor wrote:
> Printing the suffix is unhelpful because it leads to unnecessary
> differences in diagnostics (even in non-template contexts). For
> templates with non-type template parameters there is no difference
> between, say
On 2018-02-03 13:35, Manfred wrote:
> n4659 17.4 (Type equivalence) p1.3:
>
> Two template-ids refer to the same class, function, or variable if
> ...
> their corresponding non-type template arguments of integral or
> enumeration type have identical values
> ...
>
> It looks that for non-type
On 2018-02-02 22:17, Roman Popov wrote:
Hello,
I'm trying to switch from g++ 5.4 to g++ 7.2.
GDB 8.0.1 however does not understand RTTI generated by g++7.2, so my
Python scripts for GDB are not working.
Here is a code example:
struct base { virtual ~base(){} };
template< int IVAL, unsigned
65 matches
Mail list logo
