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 required
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.org/
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 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 U
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 tem
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 A<
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
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 horrible,
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 t
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 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
st
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 n
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
&
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 Compilat
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 bit
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 be
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 uni
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 wan
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 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 p
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 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 par
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 dur
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 now
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-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 full
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 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 th
28 matches
Mail list logo
