> This patch has now been committed.
It breaks bootstap on x86_64-apple-darwin14:
...
make[3]: Entering directory `/opt/gcc/p_build/libcc1'
make all-am
make[4]: Entering directory `/opt/gcc/p_build/libcc1'
make[4]: *** No rule to make target `../libiberty/pic/libiberty.a', nee
On Tue, Oct 28, 2014 at 01:05:00AM +0100, Dominique Dhumieres wrote:
> > This patch has now been committed.
>
> It breaks bootstap on x86_64-apple-darwin14:
>
> ...
> make[3]: Entering directory `/opt/gcc/p_build/libcc1'
> make all-am
> make[4]: Entering di
> This patch has now been committed.
Also breaks bootstap on x86_64-linux-gnu, CentOS 5.11:
gmake[4]: Entering directory `/home/uros/gcc-build/libcc1'
/bin/sh ./libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.
-I../../gcc-svn/trunk/libcc1 -I ../../gcc-svn/trunk/libcc1/../in
On 28/10/14 08:13, Jakub Jelinek wrote:
> On Tue, Oct 28, 2014 at 01:05:00AM +0100, Dominique Dhumieres wrote:
>>> This patch has now been committed.
>> It breaks bootstap on x86_64-apple-darwin14:
>>
>> ...
>> make[3]: Entering directory `/opt/gcc/p_bui
>>> ...
>>> make[3]: Entering directory `/opt/gcc/p_build/libcc1'
>>> make all-am
>>> make[4]: Entering directory `/opt/gcc/p_build/libcc1'
>>> make[4]: *** No rule to make target `../libiberty/pic/libiberty.a', needed
>>> by `libcc1.
On 28/10/14 08:36, Uros Bizjak wrote:
>> This patch has now been committed.
> Also breaks bootstap on x86_64-linux-gnu, CentOS 5.11:
>
> gmake[4]: Entering directory `/home/uros/gcc-build/libcc1'
> /bin/sh ./libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I.
> -I
n14:
> >>
> >> ...
> >> make[3]: Entering directory `/opt/gcc/p_build/libcc1'
> >> make all-am
> >> make[4]: Entering directory `/opt/gcc/p_build/libcc1'
> >> make[4]: *** No rule to make target `../libiberty/pic/libiberty.a', needed
On Tue, Oct 28, 2014 at 9:50 AM, Phil Muldoon wrote:
> On 28/10/14 08:36, Uros Bizjak wrote:
>>> This patch has now been committed.
>> Also breaks bootstap on x86_64-linux-gnu, CentOS 5.11:
>>
>> gmake[4]: Entering directory `/home/uros/gcc-build/libcc1'
>
--disable-werror.
Untested though.
--- libcc1/Makefile.am 2014-10-28 09:07:57.443711725 +0100
+++ libcc1/Makefile.am 2014-10-28 10:32:09.712135034 +0100
@@ -22,8 +22,7 @@ AM_CPPFLAGS = -I $(srcdir)/../include -I
-I $(gcc_build_dir) -I$(srcdir)/../gcc \
-I $(srcdir)/../gcc/c -I $(srcdir
x that, WARN_FLAGS should
> already contain -Werror during stage2/stage3 unless --disable-werror.
> Untested though.
No, it still fails, although with one -Werror less in the compile flags:
gmake[4]: Entering directory `/home/uros/gcc-build/libcc1'
/bin/sh ./libtool --tag=CXX --mode=c
On 28/10/14 09:57, Uros Bizjak wrote:
> On Tue, Oct 28, 2014 at 10:35 AM, Jakub Jelinek wrote:
>> On Tue, Oct 28, 2014 at 09:36:45AM +0100, Uros Bizjak wrote:
This patch has now been committed.
>>>
>>> Also breaks bootstap on x86_64-linux-gnu, CentOS 5.11:
>>
>> For -Werror, I'd think that sh
t have access to a system compiler of the version you have, so I
> am unable to test.
Yes, this patch allows bootstrap to pass stage1, although with a new warning:
*** Warning: Linking the shared library libcc1.la against the
*** static library ../libiberty/pic/libiberty.a is not portable!
Thanks,
Uros.
figure work?
>>
>> I don't have access to a system compiler of the version you have, so I
>> am unable to test.
> Yes, this patch allows bootstrap to pass stage1, although with a new warning:
>
> *** Warning: Linking the shared library libcc1.la against the
> *** sta
gt; Does removing it from configure.ac and regenerating configure work?
>>
>> I don't have access to a system compiler of the version you have, so I
>> am unable to test.
>
> Yes, this patch allows bootstrap to pass stage1, although with a new warning:
>
> ***
nux (--with-build-config=bootstrap-ubsan), that was build without
ada, on x86_64-linux the build failed because of some recent ada vs.
bootstrap-ubsan incompatibilities unrelated to libcc1 (but libcc1 built
fine).
So I'm proposing my patch (which is modeled after lto-plugin changes by
myself
)),,$(libiberty)))
libcc1_la_LDFLAGS = -module -export-symbols $(srcdir)/libcc1.sym
libcc1_la_SOURCES = findcomp.cc libcc1.cc names.cc names.hh $(shared_source)
-libcc1_la_LIBADD = $(libiberty)
+libcc1_la_LIBADD = \
+$(if $(wildcard $(libiberty_noasan)),, \
+$(if $(wildcard $(libiberty_pic
I'm seeing a different bootstrap failure from those already discussed:
In file included from
/scratch/jmyers/fsf/gcc-mainline/libcc1/../gcc/gcc-plugin.h:28:0,
from
/scratch/jmyers/fsf/gcc-mainline/libcc1/plugin.cc:34:
/scratch/jmyers/fsf/gcc-mainline/libcc1/../gcc/system.
On 28/10/14 13:19, Joseph S. Myers wrote:
> I'm seeing a different bootstrap failure from those already discussed:
>
> In file included from
> /scratch/jmyers/fsf/gcc-mainline/libcc1/../gcc/gcc-plugin.h:28:0,
> from
> /scratch/jmyers/fsf/gcc-mainl
To get the failure you need not to have GMP installed somewhere the
bootstrap compiler would otherwise find (e.g. uninstall your system GMP
package before testing). The failure is building stage 1.
> I am actually not totally sure how to respect the -with-gmp argument
> in libcc1. auto* to
On Tue, Oct 28, 2014 at 05:36:50PM +, Phil Muldoon wrote:
> On 28/10/14 13:19, Joseph S. Myers wrote:
> > I'm seeing a different bootstrap failure from those already discussed:
> >
> > In file included from
> > /scratch/jmyers/fsf/gcc-mainline
okay, though I'd have to look at the whole thread to
understand what libcc1 is. :)
Just two questions:
1) what's the issue that you need to disable asan for?
2) why is GMPLIB not handled in the same way?
Paolo
02936.html
> > patch ok too (that one already tested; another bootstrap issue)?
>
> Both seem okay, though I'd have to look at the whole thread to
> understand what libcc1 is. :)
It is a library for communication between the debugger and
a GCC plugin (and the plugin itself)
es)? Is the
>>> https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02936.html
>>> patch ok too (that one already tested; another bootstrap issue)?
>>
>> Both seem okay, though I'd have to look at the whole thread to
>> understand what libcc1 is. :)
>
> It
On Wed, Oct 29, 2014 at 11:53:28AM +0100, Paolo Bonzini wrote:
> >> 2) why is GMPLIB not handled in the same way?
> >
> > The only problem is that system.h includes gmp.h, so we need a way
> > to find that header. I think libcc1 doesn't use any functions from gm
On 29/10/14 10:53, Paolo Bonzini wrote:
>>> 2) why is GMPLIB not handled in the same way?
>>
>> The only problem is that system.h includes gmp.h, so we need a way
>> to find that header. I think libcc1 doesn't use any functions from gmp
>> itself, so if gmp.
strap/regtest, is it ok for trunk (should fix
>>>> two bootstrap issues)? Is the
>>>> https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02936.html
>>>> patch ok too (that one already tested; another bootstrap issue)?
>>>
>>> Both seem okay, though I
s, e.g. because of #pragma GCC poison at the end of system.h,
> I believe some gmp.h versions were using some poisoned symbols.
> system.h doesn't include gmp.h if -DGENERATOR_FILE, but libcc1 is not a
> generator, so that is not appropriate, it can use various other GCC headers
> t
tested my patch on
i686-linux (--with-build-config=bootstrap-ubsan), that was build without
ada, on x86_64-linux the build failed because of some recent ada vs.
bootstrap-ubsan incompatibilities unrelated to libcc1 (but libcc1 built
fine).
So I'm proposing my patch (which is modeled after l
On 10/29/14 04:28, Jakub Jelinek wrote:
On Tue, Oct 28, 2014 at 05:36:50PM +, Phil Muldoon wrote:
On 28/10/14 13:19, Joseph S. Myers wrote:
I'm seeing a different bootstrap failure from those already discussed:
In file included from
/scratch/jmyers/fsf/gcc-mainline/libcc1/../gc
n_la_LINK,
> libcc1_la_DEPENDENCIES, libcc1_la_LINK, LTLDFLAGS): New variables.
> * Makefile.in: Regenerated.
;-) To re-use your words: »That is insufficient«, d) in a configuration
where there is no lto-plugin built, we now try to link the shared libcc1
against a static libiberty:
/bin/b
On Thu, Oct 30, 2014 at 09:33:08AM +0100, Thomas Schwinge wrote:
> Here is a patch that I'm testing; OK? I didn't understand what the
> conditions are that libcc1 might not be built as a shared library: is it
> always built as one -- but is that really supported on all syst
Hi!
On Thu, 30 Oct 2014 09:51:59 +0100, Jakub Jelinek wrote:
> On Thu, Oct 30, 2014 at 09:33:08AM +0100, Thomas Schwinge wrote:
> > Here is a patch that I'm testing; OK? I didn't understand what the
> > conditions are that libcc1 might not be built as a shared library:
This started as a patch to fix the libcc1 failure pointed out in
PR libcc1/113977. However, investigating that pointed out some other
issues, which are also fixed in this series.
I tested this on x86-64 Fedora 38 against two versions of gdb: one
patched to fix the gdb side of the bug, and one
As found by Tom Tromey in
https://gcc.gnu.org/pipermail/gcc-patches/2024-February/646807.html
libcc1 is not listed as bug component even though it is there in bugzilla.
This fixes that oversight.
Committed as obvious after testing using git gcc-verify on a patch.
contrib/ChangeLog
On 11/14/23 22:30, Tom Tromey wrote:
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
This changes libcc1 to use "override" where appropriate.
libcc1/ChangeLog
2021-01-03 Tom Tromey
* libcp1.cc (class compiler_triplet_regexp)
(class compiler_driver_filename, class libcp1_connection): Use
"override".
* libcc1.cc (class com
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
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
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
> Tested on powerpc64-linux, --enable-languages=all,ada,go,obj-c++ ,
> followed by "make distclean". Is this okay for trunk?
>
>
> Segher
>
>
> 2016-04-04 Segher Boessenkool
>
> libcc1/
> PR bootstrap/70173
> * Makefile.am (MOSTL
On Sun, Apr 10, 2016 at 08:44:20PM -0500, Segher Boessenkool wrote:
> Ping?
Ok for stage4.
> > 2016-04-04 Segher Boessenkool
> >
> > libcc1/
> > PR bootstrap/70173
> > * Makefile.am (MOSTLYCLEANFILES): New, add compiler-name.h .
> > (comp
Olivier,
During highly parallel builds on fast hosts, we have experienced
sporadic bootstrap failures on libquadmath like
I have encountered such a bootstrap problem too. I guessed dependency
race condition, but -j21 was a simpler fix :)
I'm happy to try the patch.
nathan
--
Nathan Sidwel
efix+][+module+]: maybe-all-gcc
@endif gcc-no-bootstrap
to all "all" targets after the dependency to stage_current
@if gcc-bootstrap (in Makefile.tpl).
The "depgcc" boolean is simply a mechanism to do that
only for cases where we were adding a extra explicit dependency
to maybe-all-gcc before, that is, only for libcc1.
Olivier
On 06/14/2017 01:24 PM, Olivier Hainque wrote:
I'm happy to try the patch.
That would bring useful extra datapoints, Thanks!
I now seem unable to trigger the race with an unpatched source. Sorry
--
Nathan Sidwell
urrent
dependencies.
Our understanding is that it is incorrect to have libcc1 depend on
maybe-all-gcc in a bootstrapping setup because it can trigger rebuilds of gcc/
components in parallel with ongoing processing of target components (with
pre-requisites on stage_current only).
On Jun 13, 2017, Olivier Hainque wrote:
> 2017-06-13 Olivier Hainque
> * Makefile.def (host_modules): Set depgcc to true for libcc1,
> meaning need of a dep on stage_current if gcc-bootstrap and on
> maybe-all-gcc otherwise.
> (dependencies) Remov
es): Set depgcc to true for libcc1,
>> meaning need of a dep on stage_current if gcc-bootstrap and on
>> maybe-all-gcc otherwise.
>> (dependencies) Remove unconditional dependency on all-gcc.
>
>> * Makefile.tpl ("all" targets): Handle depgcc.
of discussions we tracked, the understanding
of the dependency issue was that we *had* (before the patch),
possibilities to have stage_current and maybe-all-gcc targets
built concurrently, via
> configure-target-libquadmath: stage_current
> all-target-libquadmath: configure-target-libquadmath
&
On Jun 26, 2017, Olivier Hainque wrote:
> On Jun 22, 2017, at 14:12 , Alexandre Oliva wrote:
>> Your patch takes care of the build dependencies of libcc1, which should
>> avoid some scenarios that might lead to concurrency between staged and
>> non-staged builds. However
-configure*-target-libgcc depend on maybe-all*-gcc (see above
> those comments). The precise deps vary per bootstrap level, or
> non-bootstrap.
>
> But after the proposed patch there are no such deps for libcc1 in the
> bootstrap case, so we might very well attempt to build libcc1 in
&
This is the libcc1 change. When creating a clone, it needs to fiddle with
TYPE_FIELDS now.
nathan
--
Nathan Sidwell
2017-07-14 Nathan Sidwell
libcc1/
* libcp1plugin.cc (plugin_build_decl): Member fns are on TYPE_FIELDS.
Index: libcc1/libcp1plugin.cc
On Tue, Oct 28, 2014 at 12:24:39PM +, Phil Muldoon wrote:
> 2014-10-28 Phil Muldoon
>
> * configure.ac: Remove -Werror.
> * configure: Regenerate.
> * Makefile.am: Remove -Werror. Link correct libiberty.
> * Makefile.in: Regenerate.
As for -Werror, doesn't your patch complet
On 28/10/14 12:24, Phil Muldoon wrote:
> Hi
>
> A few issues came to light this morning on some systems with
> bootstrapping and libiberty linking issues. We erroneously specified
> -Werror in stage one builds. This patch removes that flag. We also
> unconditionally linked with the PIC version o
On 28/10/14 12:34, Jakub Jelinek wrote:
> On Tue, Oct 28, 2014 at 12:24:39PM +, Phil Muldoon wrote:
>> 2014-10-28 Phil Muldoon
>>
>> * configure.ac: Remove -Werror.
>> * configure: Regenerate.
>> * Makefile.am: Remove -Werror. Link correct libiberty.
>> * Makefile.in: Regenera
Hi!
On Thu, 30 Oct 2014 11:10:51 +0100, I wrote:
> Build a shared host libiberty also for libcc1's benefit.
Backported to gomp-4_0-branch in r216918:
commit 595db85c7323b08d29bf344911a7bd709d68685b
Author: tschwinge
Date: Thu Oct 30 11:09:14 2014 +
Build a shared host l
PR libcc1/113977 points out a case where a simple expression is
rejected with a compiler error message. The bug here is that gdb does
not inform the plugin of the correct alignment -- in fact, there is no
way to do that.
This patch adds a new method to allow the alignment to be set, and
bumps
On Jun 3, 2018, Alexandre Oliva wrote:
> On Jun 27, 2017, Alexandre Oliva wrote:
>> configuration, because the current Makefile would only do that with
>> all-host, after bootstrap is complete.
> I have extensively studied the dependencies, and I still don't see ho
sis, this was indeed the case.
Yes, indeed. I intended to convey this in the
opening message of this thread by referring to concurrency
between libcc1 and libquadmath. That was admittedly
too implicit :)
> I still don't see how any
> staging or unstaging might have taken place, but I c
On 06/11/2018 08:50 PM, Alexandre Oliva wrote:
> So I see two possible ways to go from now:
>
> 1. address the previously-mentioned fragility in the patch I posted, to
> catch all cases of postbootstrap targets and their deps on
> non-postbootstrap targets.
>
>
> 2. revamp the bootstrap/non-boot
12 +56038,8 @@ all-stagetrain-lto-plugin:
maybe-all-stagetrain-libiberty-linker-plugin
all-stagefeedback-lto-plugin: maybe-all-stagefeedback-libiberty-linker-plugin
all-stageautoprofile-lto-plugin:
maybe-all-stageautoprofile-libiberty-linker-plugin
all-stageautofeedback-lto-plugin:
maybe-all-sta
> On 26 Jun 2018, at 07:38, Alexandre Oliva wrote:
>
> Here's the patch I'll install if nobody objects in the next few days.
> Tested on x86_64-linux-gnu with a gcc bootstrap tree, a gcc
> non-bootstrap tree, and a binutils+gdb tree.
Thanks a lot for this Alex!
This adds deleter objects for various kinds of protocol pointers to
libcc1. Existing specializations of argument_wrapper are then
replaced with a single specialization that handles all pointer types
via the appropriate deleter. The result here is a bit nicer because
the argument_wrapper
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
On Jun 27, 2017, Alexandre Oliva wrote:
> On Jun 26, 2017, Olivier Hainque wrote:
>> On Jun 22, 2017, at 14:12 , Alexandre Oliva wrote:
>>> Your patch takes care of the build dependencies of libcc1, which should
>>> avoid some scenarios that might lead to concurrency
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
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
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
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
patch does not change the libcc1 API as it overloads the triplet_regexp
parameter of GCC's set_arguments according to:
+ if (access (triplet_regexp, X_OK) == 0)
GDB counterpart:
[PATCH 4/4] compile: Add 'set compile-gcc'
https://sourceware.org/ml/gdb-
On 04/23/2015 02:38 PM, Jan Kratochvil wrote:
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
On 04/17/2015 09:17 AM, Jan Kratochvil wrote:
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
Sorry this has taken so lon
the @
> operator in libcc1. So perhaps starting with a justification for
> wanting/needed that capability would be helpful.
It is not a simple /@[0-9]+$/ regex, the expression can be for example
(*vararray@(3+1))
Parentheses still could be parsed by GDB, though.
But a statemen
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
wanting/needed that capability would be helpful.
It is not a simple /@[0-9]+$/ regex, the expression c
>> I did not realize that myself before. I do not think there is an
>> easy fix for the GCC patch, is it?
It seems like a VLA would work.
Jeff> 99% of the time I've used a constant with the @ syntax in gdb.
I use a non-constant argument to @ quite a bit.
It's common to have something like the
On 06/03/2015 09:29 AM, Tom Tromey wrote:
I did not realize that myself before. I do not think there is an
easy fix for the GCC patch, is it?
It seems like a VLA would work.
Right. It doesn't seem like a big stretch to me either.
Jeff> 99% of the time I've used a constant with the @ synta
On 03/06/15 18:30, Jeff Law wrote:
It's common to have something like the struct hack where the length of
the array is stored in the struct. Then when scripting gdb one can
write:
print s.array[0] @ s.length
Which is case that I've had use for a non-constant RHS as well. I just
haven't
Manuel> It should be possible to arrange the inferior code in
Manuel> such a way that GCC parses each side of @ independently and gives the
Manuel> info necessary to GDB such that it can interpret what @ means or give
Manuel> a reasonable error.
Only if this can be done without requiring gdb to le
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
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+"a@c"[1]+'@'+'\''@(*array1@10)[5])[2]
>
Is this a real case? I cannot understand what this means, but it could
simply be
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+"a@c"[1]+'@'+'\''@(*array1@10)[5])[2]
> >
>
>
On 4 June 2015 at 09:36, Jan Kratochvil wrote:
> 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:
> These two expressions are equivalent for all operations except of sizeof():
> pointer
> (*pointer@ANYTHING)
>
Sure,
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, Jun 04, 2015 at 10:36:46AM +0200, Manuel López-Ibáñez wrote:
> On 4 June 2015 at 09:36, Jan Kratochvil wrote:
> > 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:
> > These two expressions are equivalent for all operations
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 06/04/2015 01:36 AM, Jan Kratochvil wrote:
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+"a@c"[1]+'@'+
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 06/04/2015 08:27 AM, Jan Kratochvil wrote:
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 case
defines
may already contain the triplets.
The GCC patch improves the libcc1::compiler_triplet_regexp::find and
libcp1::compiler_triplet_regexp::find methods by first trying to match
the triplet in the compiler name and correctly discarding the triplet
part of the regexp if the matching succeeds.
The attached patch replaces the uses of TREE_NO_WARNING in libc11.
Add support for per-location warning groups.
libcc1/ChangeLog:
* libcp1plugin.cc (record_decl_address): Replace a direct use
of TREE_NO_WARNING with set_no_warning.
diff --git a/libcc1/libcp1plugin.cc b/libcc1/libcp1plugin.cc
This changes libcc1 to inline a trivial method and to use the default
constructor.
libcc1/ChangeLog
2021-01-03 Tom Tromey
* connection.hh (~connection): Use default.
(print): Inline.
* connection.cc (cc1_plugin::connection::~connection)
(cc1_plugin::connection
This adds deleter objects for various kinds of protocol pointers to
libcc1. Existing specializations of argument_wrapper are then
replaced with a single specialization that handles all pointer types
via the appropriate deleter. The result here is a bit nicer because
the argument_wrapper
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
Both libcc1 plugins have nearly identical copies of code to find the
underlying compiler. This seemed wasteful to me, so this patch
unifies the copies.
Two minor API changes were needed.
First, the old code used a back-link from the compiler object to the
plugin object to check the 've
On 4/27/2021 7:01 PM, Tom Tromey wrote:
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
On 4/27/2021 7:01 PM, Tom Tromey wrote:
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.
OK
jeff
On 4/27/2021 7:01 PM, Tom Tromey wrote:
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.
OK
jeff
Hi!
I've committed the following patch (which Iain tested - at least
libiberty part). The issue is that while Darwin is PIC by default, for
performance reasons it uses -mdynamic-no-pic and that makes code compiled
that way not suitable for shared libraries.
Committed to trunk as obvious.
2015-0
vide new option 'set compile-gcc'.
This patch does not change the libcc1 API as it overloads the triplet_regexp
parameter of GCC's set_arguments according to:
+ if (access (triplet_regexp, X_OK) == 0)
GDB counterpart:
[PATCH 4/4] compile: Add 'set compile-gcc'
/usr/bin/ARCH-OS-gcc and chooses one but one cannot
override which one. GDB would provide new option 'set compile-gcc'.
This patch does not change the libcc1 API as it overloads the triplet_regexp
parameter of GCC's set_arguments according to:
+ if (access (triplet_regex
omment for
GCC_FE_VERSION_1.
(struct gcc_base_vtable): Rename set_arguments to set_arguments_v0.
Add set_arguments, set_triplet_regexp and set_driver_filename.
libcc1/ChangeLog
2015-05-24 Jan Kratochvil
* libcc1.cc (libcc1): Add class compiler with field compil
101 - 200 of 328 matches
Mail list logo
