On Sun, 02 Jul 2017 18:22:45 +0200, Jason Merrill wrote:
> I'd suggest "internal" rather than "static". Otherwise the patch looks good.
Checked in as r249883 with: DW_IDX_GNU_internal, DW_IDX_GNU_external
Jan
http://dwarfstd.org/ShowIssue.php?issue=170527.1
170527.1 Jan Kratochvil DW_IDX_* for static/extern symbols Enhancement Open
Section 6.1.1.4.7, pg 147
When a debugger wants to print 'somename' it logically tries to find first
'somename' as an
external symbol in all availa
http://dwarfstd.org/ShowIssue.php?issue=170527.1
170527.1 Jan Kratochvil DW_IDX_* for static/extern symbols Enhancement Open
Section 6.1.1.4.7, pg 147
When a debugger wants to print 'somename' it logically tries to find first
'somename' as an
external symbol in all availa
On Fri, 26 May 2017 20:14:08 +0200, Jan Kratochvil wrote:
> If those new DW_IDX_* get allocated in a reasonable time GDB could already use
> them, otherwise sending the patch below.
Preallocation of the numbers has been denied by DWARF committee. Therefore
asking for approval of this pa
sending the patch below.
These symbols are both produced and consumed only by GDB, not by GCC.
Jan
include/ChangeLog
2017-05-26 Jan Kratochvil
* dwarf2.def (DW_IDX_compile_unit, DW_IDX_type_unit, DW_IDX_die_offset)
(DW_IDX_parent, DW_IDX_type_hash, DW_IDX_lo_user,
On Wed, 04 Jan 2017 00:09:43 +0100, Jakub Jelinek wrote:
> Jan/Mark, are you going to adjust GDB/elfutils etc. correspondingly?
My GDB DWARF-5 patchset is still off-trunk so that is sure OK.
Jan
On Fri, 16 Dec 2016 14:17:32 +0100, Jonathan Wakely wrote:
> On 16/12/16 14:06 +0100, Jan Kratochvil wrote:
> > (gdb) p bb.c.d
> > $4 = (D &) @0x601028: {e = 0x601060 }
>
> Wat?
>
> bb.c.d is not a valid expression.
>
> B::c is a pointer, it shoul
On Fri, 16 Dec 2016 13:33:52 +0100, Jonathan Wakely wrote:
> We don't do auto-deref for std::shared_ptr or std::unique_ptr, even
> though we know the object they point to definitely is live and safe to
> access, and that's because those types have pointer semantics not
> reference semantics.
This
On Fri, 16 Dec 2016 02:07:07 +0100, Jonathan Wakely wrote:
> On 15/12/16 22:19 +0100, Jan Kratochvil wrote:
> > Just with the GDB 'compile' project (libcc1) which is planned to be used for
> > all GDB expressions evalation the Xmethods will no longer work.
>
> But
On Thu, 15 Dec 2016 15:18:17 +0100, Jonathan Wakely wrote:
> I'm going to add Xmethods for all our iterator types so that it will
> always be possible to do "print *iter", so if GDB supports Xmethods
> then we don't need to register the iterator printers.
Just with the GDB 'compile' project (libcc
lf-dwarf5.patch
OK for GCC trunk?
Sorry I have not regression tested it, I would handle that before a check-in.
Thanks,
Jan
gcc/
2016-11-24 Jan Kratochvil
* dwarf2out.c (output_file_names) Reorder DW_LNCT_directory_index and
DW_LNCT_path.
diff --git a/gcc/dwarf2out.c b/gc
On Fri, 21 Oct 2016 21:32:42 +0200, Jakub Jelinek wrote:
> This patch changes the .debug_info headers to follow the current
> specification (I still hope the useless padding1/padding2 fields will be
> removed), and also changes the -gsplit-dwarf stuff to move dwo_id into
> the header and use DW_UT_
On Fri, 20 Nov 2015 18:40:46 +0100, Jonathan Wakely wrote:
> The patch is OK for trunk and gcc-5-branch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68448
trunk:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=230669
5.x:
https://gcc.gnu.org/viewcvs/gcc?view=revision&revisi
On Thu, 19 Nov 2015 21:21:51 +0100, Jan Kratochvil wrote:
> * python/hook.in: Call register_libstdcxx_printers.
> * python/libstdcxx/v6/__init__.py: Wrap it to
> register_libstdcxx_printers.
[...]
> -import libstdcxx.v6
> +# Call a function as a plain import wo
Hi,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68448
https://bugzilla.redhat.com/show_bug.cgi?id=1279406
echo -e '#include \nint main(){std::vector l;\nreturn 0;}'|g++ -g
-Wall -x c++ -;gdb -q ./a.out -batch -ex 'b 3' -ex r -ex 'p l' -ex r -ex 'p l'
Actual:
[...]
$1 = std::vector of length 0,
Hi,
I was asked now about this [PATCH v3 1..4] series for a possible inclusion of
its GDB patches counterpart into gdb-7.10.
Jan
On Mon, 08 Jun 2015 09:46:59 +0200, Richard Biener wrote:
> adding a
>
> import sys
>
> makes it work fine though.
I do not see the sys error with either FSF GDB HEAD or Fedora 22 GDB.
I agree it probably should be there.
> Thus, ok with also adding a imoprt sys.
Done and checked in: r224223
On Thu, 04 Jun 2015 16:00:18 +0200, Jeff Law wrote:
> But my assertion is that stuff like what you've shown above simply isn't
> important to handle. What we need to look at are the common cases and I
> haven't seen a strong argument that the common cases can't be handled by
> gdb.
If we target
On Thu, 04 Jun 2015 10:55:59 +0200, Jakub Jelinek wrote:
> (gdb) p *(int (*)[4])&a[0]
> $1 = {1, 2, 3, 4}
> (gdb) p *(char (*)[4])&b[1]
> $2 = "bcde"
>
> Though, admittedly that is more typing than a[0]@4 or b[1]@4 .
I forgot during this discussion about the C style cast, you are right.
For some
On Thu, 04 Jun 2015 10:36:46 +0200, Manuel López-Ibáñez wrote:
> except for printing a memory
> region, and for that purpose one only needs to parse LHS@RHS and only
> one @ makes sense within the same print command.
Yes, just LHS or RHS can be pretty complicated containing the '@' character at
le
On Thu, 04 Jun 2015 09:24:36 +0200, Manuel López-Ibáñez wrote:
> On 3 June 2015 at 22:58, Jan Kratochvil wrote:
>
> > In general parsing LHS vs. RHS is not so trivial:
> > *array1@10
> > expression wrapped into ->
> > (*array2+&qu
On Wed, 03 Jun 2015 16:55:24 +0200, Jeff Law wrote:
> On 05/30/2015 03:47 AM, Jan Kratochvil wrote:
> > > So I guess at some level it's not clear to me why we need to support the @
> > > operator in libcc1. So perhaps starting with a justification for
> > > want
vect-stmts.c:7754
7754 free (stmt_info);
Jan
gcc/
2015-06-03 Jan Kratochvil
PR other/65366
* gdbhooks.py (intptr): New function. Replace int(...) by intptr(...).
diff --git a/gcc/gdbhooks.py b/gcc/gdbhooks.py
index 20842bb..fe83376 100644
--- a/gcc/gdbhooks
On Mon, 01 Jun 2015 22:59:03 +0200, Jason Merrill wrote:
> OK, thanks.
Checked in: r224012
Jan
--- Begin Message ---
gcc/c-family/
2015-03-27 Jan Kratochvil
* c-common.c (c_fully_fold_internal, binary_op_error): Add ATSIGN_EXPR.
* c-lex.c (c_lex_with_flags): Add ATSIGN_EXPR.
gcc/c/
2015-03-27 Jan Kratochvil
* c-parser.c (enum c_parser_prec): Add PREC_ATSIGN
On Sat, 30 May 2015 07:42:35 +0200, Jeff Law wrote:
> We're still digging out a
> bit from the patches queued while preparing for the gcc5 release.
gcc6
> So I guess at some level it's not clear to me why we need to support the @
> operator in
functionality impact, although the filename
gets used even for executing the command.
Jan
libcc1/ChangeLog
2015-05-24 Jan Kratochvil
* findcomp.cc: Include system.h.
(search_dir): Return absolute filename.
---
libcc1/findcomp.cc |3 ++-
1 file changed, 2 insertions(+), 1
Hi,
the libcc1 API change formerly approved for GCC was rejected by GDB, therefore
here is a new API + its implementation.
Jan
include/ChangeLog
2015-05-24 Jan Kratochvil
* gcc-interface.h (enum gcc_base_api_version): Add GCC_FE_VERSION_1.
libcc1/ChangeLog
2015-05-24 Jan
Hi,
GDB currently searches for /usr/bin/ARCH-OS-gcc and chooses one but it does not
display which one. It cannot, GCC method set_arguments() does not yet know
whether 'set debug compile' is enabled or not.
Jan
include/ChangeLog
2015-05-24 Jan Kratochvil
* gcc-interfa
Hi,
GDB currently searches for /usr/bin/ARCH-OS-gcc and chooses one but one cannot
override which one. GDB would provide new option 'set compile-gcc'.
Jan
include/ChangeLog
2015-05-24 Jan Kratochvil
* gcc-interface.h (enum gcc_base_api_version): Update c
On Thu, 23 Apr 2015 22:38:34 +0200, Jan Kratochvil wrote:
> Unfortunately this changes libcc1 API in an incompatible way. There is
> a possibility of a hack to keep the API the same - one could pass "-v" option
> explicitly to set_arguments(), set_arguments() could compare th
functionality impact, although the filename
gets used even for executing the command.
Jan
libcc1/ChangeLog
2015-04-21 Jan Kratochvil
* findcomp.cc: Include system.h.
(search_dir): Return absolute filename.
---
libcc1/findcomp.cc |3 ++-
1 file changed, 2 insertions(+), 1
p, X_OK) == 0)
GDB counterpart:
[PATCH v2 2/2] compile: Add 'set compile-gcc'
https://sourceware.org/ml/gdb-patches/2015-04/msg00910.html
Message-ID: <20150423203402.23140.92757.st...@host1.jankratochvil.net>
Jan
include/ChangeLog
2015-04-21 Jan Kratochvil
Hi,
in mail thread
https://sourceware.org/ml/gdb-patches/2015-04/msg00804.html
the idea of breaking libcc1.so compatibility was rejected.
Therefore this patch series implements full backward/forward GCC/GDB ABI
compatibility.
Jan
include/ChangeLog
2015-04-23 Jan Kratochvil
[PATCH v2 1/2] compile: set debug compile: Display GCC driver filename
https://sourceware.org/ml/gdb-patches/2015-04/msg00909.html
Message-ID: <20150423203402.23140.92757.st...@host1.jankratochvil.net>
Jan
include/ChangeLog
2015-04-23 Jan Kratochvil
* gcc-inter
matching regex
^(x86_64|i.86)(-[^-]*)?-linux(-gnu)?-gcc$
found compiler /usr/bin/x86_64-unknown-linux-gnu-gcc
I do not think the change will have functionality impact, although the filename
gets used even for executing the command.
Jan
libcc1/ChangeLog
2015-04-21 Jan Kratochvil
patches/2015-04/msg00808.html
Message-ID: <20150421213657.14147.60506.st...@host1.jankratochvil.net>
Jan
include/ChangeLog
2015-04-21 Jan Kratochvil
* gcc-interface.h (enum gcc_base_api_version): Add comment to
GCC_FE_VERSION_1.
(struct gcc_base_vtable): Describ
e can keep GDB<->GCC in sync.
GDB counterpart:
[PATCH 2/4] compile: Use libcc1.so.0->libcc1.so.1
https://sourceware.org/ml/gdb-patches/2015-04/msg00806.html
Message-ID: <20150421213642.14147.93210.st...@host1.jankratochvil.net>
Jan
include/ChangeLog
2
hes/2015-04/msg00807.html
Message-ID: <20150421213649.14147.79719.st...@host1.jankratochvil.net>
Jan
include/ChangeLog
2015-04-21 Jan Kratochvil
* gcc-interface.h (enum gcc_base_api_version): Add comment to
GCC_FE_VERSION_1.
(struct gcc_base_vtable): Move parameter verb
t least in Fedora we can keep GDB<->GCC in sync.
GDB counterpart:
[PATCH 1/4] compile: Use libcc1.so->libcc1.so.0
https://sourceware.org/ml/gdb-patches/2015-04/msg00805.html
Message-ID: <20150421213635.14147.15653.st...@host1.jankratochvil.net>
Jan
include
Hi,
ping:
[gcc patch] libcc1: '@' GDB array operator
https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01451.html
Message-ID: <20150327163646.ga16...@host1.jankratochvil.net>
Jan
missing when linking cc1plus. As there should be also C++ support for
libcc1 in the future c_binding_oracle will need to be present for both C and
C++. But so far I have left it as submitted.
GCC testsuite has passed without regressions.
Thanks,
Jan
gcc/c-family/
2015-03-27 Jan Kratochvil
-is-not-defined/14904834
Thanks,
Jan
2015-03-09 Jan Kratochvil
PR other/65366
* gdbhooks.py: Use int(...) instead of long(...). Use print(...)
instead of print ... .
Index: gcc/gdbhooks.py
===
---
On Tue, 03 Feb 2015 19:50:40 +0100, Doug Evans wrote:
> On Fri, Jan 16, 2015 at 2:42 PM, Jan Kratochvil
> wrote:
> > [...]
> > It is wrong that gcc puts -fpreprocessed into DW_AT_producer - I may post a
> > gcc
> > patch for it.
>
> Hi.
> I wasn'
On Sat, 17 Jan 2015 07:41:51 +0100, Jakub Jelinek wrote:
> > gcc/ChangeLog
> > * dwarf2out.c (gen_producer_string): Ignore also OPT_fpreprocessed.
>
> Ok for trunk, thanks.
Checked in: 219797
Jan
Hi,
I have provided a sufficient fix in GDB for the -fplugin=libcc1plugin feature:
[patch+7.9] compile: Filter out -fpreprocessed
https://sourceware.org/ml/gdb-patches/2015-01/msg00485.html
But still I think "-fpreprocessed" is inappropriate for DW_AT_producer.
Otherwise for an i
On Sun, 14 Sep 2014 17:07:05 +0200, Manuel López-Ibáñez wrote:
> What happened with this? I don't see any libcc1 in the gcc repository
> and this patch was never committed.
It was discussed internally and the patches are going to be updated, rebased
and later checked in.
Thanks,
Jan
On Tue, 05 Aug 2014 21:34:00 +0200, Tom Tromey wrote:
> > "Jeff" == Jeff Law writes:
> Jeff> Does this deserve a mention in the news file?
>
> I suppose so, I will get someone here to write it.
Attached (based on Tom's PATCH 0/5 mail).
Jan
Index: htdocs/gcc-5/changes.html
=
Hi,
[patch update] Support .eh_frame in crt1 x86_64 glibc (PR libgcc/57280,
libc/15407)
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00775.html
Message-ID: <20130514191244.ga12...@host2.jankratochvil.net>
Thanks,
Jan
Hi,
[patch update] Support .eh_frame in crt1 x86_64 glibc (PR libgcc/57280,
libc/15407)
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00775.html
Message-ID: <20130514191244.ga12...@host2.jankratochvil.net>
Thanks,
Jan
Hi,
[patch update] Support .eh_frame in crt1 x86_64 glibc (PR libgcc/57280,
libc/15407)
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00775.html
Message-ID: <20130514191244.ga12...@host2.jankratochvil.net>
Thanks,
Jan
able-libquadmath
--enable-targets=all
It would be good to test also on some of the *BSD hosts, I will try some from
the GCC Compile Farm if this patch gets approved.
Thanks,
Jan
gcc/
2013-05-14 Jan Kratochvil
* config/i386/gnu-user-common.h (USE_CRT_BEGIN1)
(GNU_USER_TA
argets=all
It would be good to test also on some of the *BSD hosts, I will try some from
the GCC Compile Farm if this patch gets approved.
Thanks,
Jan
gcc/
2013-05-06 Jan Kratochvil
* config/i386/gnu-user-common.h (USE_CRT_BEGIN1)
(GNU_USER_TARGET_BEGIN1_SPEC, STARTFILE_
Hi,
just forgot also about gdb.trace/unavailable.exp, equivalent to previous
gdb.trace/collection.exp workarounds.
Jan
gdb/testsuite/
2013-02-02 Jan Kratochvil
Workaround GCC PR debug/55056 and GDB PR server/15081.
* gdb.base/restore.c (caller3): Protect l1 by GCC_PR_55056
Hello Ian,
On Tue, 23 Oct 2012 06:55:01 +0200, Ian Lance Taylor wrote:
> PR 54918 points out that libgo is not using version numbers as it
> should. At present none of libgo in 4.6, 4.7 and mainline are
> compatible with each other. This patch to the 4.7 branch sets the
> version number for libg
Hi,
On Wed, 15 Aug 2012 17:44:32 +0200, Michael Matz wrote:
> On Wed, 15 Aug 2012, Jan Kratochvil wrote:
> It's not needless as the examples here show. gdb is about helping people
> debug their stuff, not about language lawyering.
In such case there should be a GDB setting for
On Wed, 15 Aug 2012 14:23:37 +0200, Diego Novillo wrote:
> GDB folks, would it be hard to figure out that there is a single
> variant of the called function and trust the user that they are
> passing the right pointer value?
It is a needless violation of C++ resolving rules. There are various eas
On Wed, 18 Jul 2012 20:05:46 +0200, Steven Bosscher wrote:
> I wouldn't know what to test for. Looking for a .loc marker seems a bit
> fragile.
What is fragile on
// { dg-final { scan-assembler-times "\\.loc\t1 3 0\\r\\n\t\[^.\]" 6 } }
or something like that. Line numbers are constant for the t
Hello Steven,
On Wed, 18 Jul 2012 19:46:16 +0200, Steven Bosscher wrote:
> This is my proposed fix for PR53948.
I can't speak for the GCC code but could it have a GCC testcase?
Thanks,
Jan
On Mon, 21 May 2012 02:30:58 +0200, Doug Evans wrote:
> Ping.
> On Thu, May 17, 2012 at 11:29 AM, Doug Evans wrote:
[...]
> > --- /dev/null 1 Jan 1970 00:00:00 -
> > +++ leb128.h 17 May 2012 18:23:29 -
[...]
> > +/* Get a definition for NULL. */
> > +#include
I think for NULL.
[
On Fri, 21 Oct 2011 21:11:16 +0200, Jakub Jelinek wrote:
> Well, you calculate the sizes multiple times anyway, so I don't see why you
> during the size calculations you couldn't start with DW_FORM_ref_udata
> as first guess and compute on the side also total sizes of those
> DW_FORM_ref_udata byte
On Fri, 21 Oct 2011 20:01:29 +0200, Jan Kratochvil wrote:
> No regressions on {x86_64,x86_64-m32,i686}-fedora16pre-linux-gnu
> (4.7.0 20111002).
A typo, only tested for x86_64-fedora16pre-linux-gnu, sorry.
Jan
ibling. That size decrease 3.49% will be less
after this patch; moreover when not all DW_AT_sibling attrs will be dropped.
Thanks,
Jan
gcc/
2011-10-21 Jan Kratochvil
* dwarf2out.c (DW_FORM_ref): Remove.
(size_of_die) : Use size_of_uleb128 for
!AT_ref_extern
On Fri, 21 Oct 2011 05:37:09 +0200, Laurynas Biveinis wrote:
> This patch is a no-op, as already pointed out. If this comes up again,
> I'd set a conditional breakpoint on ggc_set_mark if (arg == struct
> dw_loc_list_struct with the field that gets collected) and try to find
> out why the field doe
On Tue, 18 Oct 2011 10:38:23 +0200, Jakub Jelinek wrote:
> On Tue, Oct 18, 2011 at 10:28:09AM +0200, Jan Kratochvil wrote:
> > 2011-10-12 Jan Kratochvil
> >
> > Stop producing DW_AT_sibling without -gstrict-dwarf.
> > * dwarf2out.c (dwarf2o
c:36
And later it crashed on the mangled memory.
OK to check it in? No regression testing done.
Thanks,
Jan
gcc/
2011-10-20 Jan Kratochvil
* dwarf2out.c (struct dw_loc_list_struct): Add GTY for expr;
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -1211,7 +1210,7 @@ typedef struct
f doc and everything by an option
which will never get used. Wouldn't it be enough to disable it by
-gstrict-dwarf? While currently the -gstrict-dwarf meaning is different
I believe the purpose is correct - to be more backward compatible.
Thanks,
Jan
gcc/
2011-10-12 Jan Kratochvil
On Wed, 12 Oct 2011 16:18:07 +0200, Jan Kratochvil wrote:
> On Wed, 12 Oct 2011 16:07:24 +0200, Tristan Gingold wrote:
> > I fear that this may degrade performance of other debuggers. What about
> > adding a command line option ?
>
> I can test idb,
I do not find the
On Wed, 12 Oct 2011 16:07:24 +0200, Tristan Gingold wrote:
> I fear that this may degrade performance of other debuggers. What about
> adding a command line option ?
I can test idb, there aren't so many DWARF debuggers out there I think.
If the default is removed DW_AT_sibling a new options may
was used for `make check' regression testing.
Thanks,
Jan
gcc/
2011-10-12 Jan Kratochvil
Stop producing DW_AT_sibling.
* dwarf2out.c (add_sibling_attributes): Remove the declaration.
(add_sibling_attributes): Remove the function.
(dwarf2out_finish): Remove c
ping:
On Tue, 28 Jun 2011 22:15:04 +0200, Jan Kratochvil wrote:
Hi,
a mechanical patch which fixes during
#define CP_DEMANGLE_DEBUG
make check
->
/bin/sh: line 1: 9179 Segmentation fault ./test-demangle <
./demangle-expected
which also fixes confusing outp
On Fri, 01 Jul 2011 18:27:36 +0200, Jason Merrill wrote:
> OK.
Checked in:
http://gcc.gnu.org/viewcvs?view=revision&revision=175761
No regressions on gcc-4.6.1-1.fc15.x86_64 (it is not trunk but hopefully
similar enough).
Thanks,
Jan
(6))) t()
->
decltype (((long)(5))+(q(6))) t()
OK to check it in if the regression testing underway is OK?
Thanks,
Jan
libiberty/
2011-06-30 Jan Kratochvil
* cp-demangle.c (d_print_comp): Suppress argument list for function
references by the '&' unary
On Wed, 29 Jun 2011 22:56:26 +0200, Jason Merrill wrote:
> On 06/29/2011 04:00 PM, Jan Kratochvil wrote:
> > On Mon, 27 Jun 2011 20:00:24 +0200, Jason Merrill wrote:
> > # decltype/fn call test
> > --format=gnu-v3
> > _Z4add3IidEDTclL_Z1gEfp_fp0_EET_T0_
> &g
C) 4.7.0 20110629 (experimental)
(Regression testing underway.)
Thanks,
Jan
libiberty/
2011-06-29 Jan Kratochvil
* cp-demangle.c (d_print_comp): Suppress argument list for function
references by the '&' unary operator. Keep also already processed
var
binary operator
operator .
binary operator arguments
???---> template
name 'g'
template argument list
template parameter 1
argument list
Thanks,
Jan
libiberty/
2011-06
m)
<93> DW_AT_name: F
<95> DW_AT_type: <0x16f>
pointing (<0x16f>) to the member function so it is more up to the debugger (or
front-end) to show it. Had to file GDB PR c++/12933 for it, though.
Had to restrict the patch very much
On Mon, 13 Jun 2011 20:09:57 +0200, Ian Lance Taylor wrote:
> On Thu, Jun 2, 2011 at 7:17 AM, Jan Kratochvil
> wrote:
> >
> > libiberty/
> > 2011-05-24 Jan Kratochvil
> >
> > * cp-demangle.c (d_print_comp) :
> > Suppress d_print_mod fo
On Mon, 13 Jun 2011 20:08:40 +0200, Ian Lance Taylor wrote:
> On Thu, Jun 2, 2011 at 7:16 AM, Jan Kratochvil
> wrote:
> >
> > include/
> > 2011-05-24 Jan Kratochvil
> >
> > * demangle.h (DMGL_RET_POSTFIX): Extend the comment.
> > (DMGL_R
/libiberty/ChangeLog 2011/06/13 19:05:04 174998
+++ trunk/libiberty/ChangeLog 2011/06/13 22:30:02 174999
@@ -1,3 +1,12 @@
+2011-06-13 Jan Kratochvil
+
+ * cp-demangle.c (struct d_print_info): Remove field options.
+ (d_print_init): Remove paramet
(*(int (*)(long)))(long)
exp: outer2(int (*)(long))int (*)(long)
Thanks,
Jan
libiberty/
2011-05-24 Jan Kratochvil
* cp-demangle.c (d_print_comp) :
Suppress d_print_mod for DMGL_RET_POSTFIX.
* testsuite/demangle-expected: New testcases for --ret-postfix.
--- a/libiberty
Hi,
implement DMGL_RET_DROP as an alternative form of DMGL_RET_POSTFIX, as
described in [gcc patch 0/3].
Thanks,
Jan
include/
2011-05-24 Jan Kratochvil
* demangle.h (DMGL_RET_POSTFIX): Extend the comment.
(DMGL_RET_DROP): New.
libiberty/
2011-05-24 Jan Kratochvil
st was not needed so far.
Thanks,
Jan
libiberty/
2011-05-24 Jan Kratochvil
* cp-demangle.c (struct d_print_info): Remove field options.
(d_print_init): Remove parameter options.
(cplus_demangle_print_callback): Update all the callers.
(d_print_comp, d_prin
Hi,
introducing DMGL_RET_DROP which suppresses return type demangled from linkage
name for the toplevel function type.
DMGL_RET_POSTFIX is now in use only for DMGL_JAVA. Besides Java return types
in linkage name are in C++ present for function templates.
GDB since 7.2 provides convenience alias
On Mon, 25 Apr 2011 19:05:22 +0200, Ian Lance Taylor wrote:
> On Sun, Apr 24, 2011 at 11:02 PM, Jan Kratochvil
> wrote:
>
> > include/
> > 2011-04-25 Jan Kratochvil
> >
> > * ansidecl.h (ENUM_BITFIELD): New, from gcc/system.h.
> >
>
.
Is approved its unification into ansidecl.h across gcc/binutils/gdb?
GCC still builds with the patch.
Thanks,
Jan
include/
2011-04-25 Jan Kratochvil
* ansidecl.h (ENUM_BITFIELD): New, from gcc/system.h.
contrib/
2011-04-25 Jan Kratochvil
* paranoia.cc (ENUM_BITFIELD
On Thu, 31 Mar 2011 04:59:18 +0200, Richard Henderson wrote:
> On 03/30/2011 11:19 AM, Dodji Seketeli wrote:
> > First, it avoids emitting two consecutive .loc that are identical.
> > Strictly speaking that should fix this issue in this particular case.
>
> What's the compatibility strategy? I.e.
On Wed, 09 Mar 2011 16:02:36 +0100, Pedro Alves wrote:
> Thanks, had forgotten --enable-targets=all. Sorry about that.
It builds now OK.
Thanks,
Jan
On Wed, 09 Mar 2011 13:58:38 +0100, Pedro Alves wrote:
> Thanks. I've applied it.
nto-tdep.c:130:8: error: assignment discards ‘const’ qualifier from pointer
target type [-Werror]
gcc-4.6.0-0.12.fc15.x86_64
--with-system-zlib --enable-64-bit-bfd --enable-targets=all --enable-static
--disable-s
89 matches
Mail list logo
