[COMMITTED] Add libcc1 to bug components

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

[PATCH 3/3] Fix PR libcc1/113977

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

[PATCH 2/3] Fix version negotiation in libcc1 plugins

This fixes version negotiation in the libcc1 plugins. It's done in a simple way: the version number from the context object is now passed to base_gdb_plugin. The idea behind this is that when the client (gdb) requests version N, the plugin should respond with the newest version that it knows

[PATCH 0/3] Fix libcc1 failure

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

Re: [PATCH] Fix crash in libcc1

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_type

[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

[pushed] Darwin, libcc1: Handle hosts with mdynamic-no-pic support.

Hi, The default for building host-side binaries for mdynamic-no-pic hosts is to enable this. However, it is not compatible with dynamic libraries, so must be switched off for libcc1. tested on i686-darwin9, x86_64-darwin, x86_64-linux, pushed to master, thanks, Iain Signed-off-by: Iain Sandoe

[PATCH] Darwin, libcc1: Handle hosts with mdynamic-no-pic support.

Hi, The default for building host-side binaries on Darwin hosts that support mdynamic-no-pic is to enable it. However, this is not compatible with dynamic libraries, so must be switched off for libcc1. OK for master? thanks Iain Signed-off-by: Iain Sandoe libcc1/ChangeLog

Re: [PATCH 8/13] v2 Use new per-location warning APIs in libcc1

On 6/23/21 11:04 PM, Jeff Law wrote: On 6/4/2021 3:42 PM, Martin Sebor via Gcc-patches wrote: The attached patch replaces the uses of TREE_NO_WARNING in libcc1 with the new suppress_warning() API. gcc-no-warning-libcc1.diff Add support for per-location warning groups. libcc1/ChangeLog

Re: [PATCH 8/13] v2 Use new per-location warning APIs in libcc1

On 6/4/2021 3:42 PM, Martin Sebor via Gcc-patches wrote: The attached patch replaces the uses of TREE_NO_WARNING in libcc1 with the new suppress_warning() API. gcc-no-warning-libcc1.diff Add support for per-location warning groups. libcc1/ChangeLog: * libcp1plugin.cc

[PATCH 8/13] v2 Use new per-location warning APIs in libcc1

The attached patch replaces the uses of TREE_NO_WARNING in libcc1 with the new suppress_warning() API. Add support for per-location warning groups. libcc1/ChangeLog: * libcp1plugin.cc (record_decl_address): Replace a direct use of TREE_NO_WARNING with suppress_warning. diff --git a/libcc1

[PATCH 10/11] use xxx_no_warning APIs in libcc1

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

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: [PATCH v2 19/21] libcc1: use variadic templates for callbacks

On 4/27/2021 7:01 PM, Tom Tromey wrote: This patch completes the transition of libcc1 from the use of separate template functions for different arities to the use of variadic functions. This is how I had wanted it to work from the very beginning, and is possible now with C++11. I had thought

Re: [PATCH v2 17/21] libcc1: share the GCC interface code

On 4/27/2021 7:01 PM, Tom Tromey wrote: Both the C and C++ side of the GDB plugin in libcc1 share a lot of code relating to the base GCC interface. It was all copy-and-pasted, but is essentially identical between the two. This is by design, as the base GCC API is intended to be shared

Re: [PATCH v2 15/21] libcc1: share GDB plugin code

On 4/27/2021 7:01 PM, Tom Tromey wrote: 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

Re: [PATCH v2 14/21] libcc1: share basic context code

On 4/27/2021 7:01 PM, Tom Tromey wrote: 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

Re: [PATCH v2 11/21] libcc1: unify compiler handling

On 4/27/2021 7:01 PM, Tom Tromey wrote: 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

Re: [PATCH v2 10/21] libcc1: use unique_ptr more

On 4/27/2021 7:01 PM, Tom Tromey wrote: 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

Re: [PATCH v2 09/21] libcc1: add more uses of 'deleter'

On 4/27/2021 7:01 PM, Tom Tromey wrote: This changes libcc1 to use the 'deleter' template in a few more places. The template and basic specializations are moved to a new header, then some unmarshall functions are changed to use this code. This change avoids the need to repeat cleanup code

Re: [PATCH v2 08/21] libcc1: add deleter objects

On 4/27/2021 7:01 PM, Tom Tromey wrote: 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

Re: [PATCH v2 07/21] libcc1: use std::vector when building function types

On 4/28/2021 1:56 PM, Tom Tromey wrote: "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 2021-04-2

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

Re: [PATCH v2 06/21] libcc1: use variadic templates for "rpc"

On 4/27/2021 7:01 PM, Tom Tromey wrote: This changes libcc1 to use variadic templates for the "rpc" functions. This simplifies the code and removes some possibility for mistakes. libcc1/ChangeLog 2021-04-27 Tom Tromey * libcp1.cc (rpc): Use variadic template. Remove

Re: [PATCH v2 05/21] libcc1: use variadic templates for "call"

On 4/27/2021 7:01 PM, Tom Tromey wrote: This changes libcc1 to use variadic templates for the "call" functions. The primary benefit is that this simplifies the code. libcc1/ChangeLog 2021-04-27 Tom Tromey * rpc.hh (call): Use variadic template. Remove

Re: [PATCH v2 01/21] libcc1: use templates to unmarshall enums

On 4/27/2021 7:00 PM, Tom Tromey wrote: Now that C++11 can be used in GCC, libcc1 can be changed to use templates and type traits to handle unmarshalling all kinds of enums. libcc1/ChangeLog 2021-04-27 Tom Tromey * marshall.hh (cc1_plugin::unmarshall): Use type traits

Re: [PATCH v2 21/21] libcc1: avoid a call to c_str

On 4/27/2021 7:01 PM, Tom Tromey wrote: 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

Re: [PATCH v2 20/21] libcc1: avoid extra string copies

On 4/27/2021 7:01 PM, Tom Tromey wrote: 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

Re: [PATCH v2 18/21] libcc1: fix a memory leak

On 4/27/2021 7:01 PM, Tom Tromey wrote: libcc1 has a memory leak when calling fork_exec -- it allocates a new vector of arguments, but then does not free it anywhere. This patch changes this code to use std::vector instead. Note that the previous code tried to avoid bad_alloc. I don't

Re: [PATCH v2 16/21] libcc1: use GCC_FE_VERSION_1 in C++ plugin

this version, so it should remain compatible. libcc1/ChangeLog 2021-04-27 Tom Tromey * libcp1.cc (vtable): Use GCC_FE_VERSION_1. OK Jeff

Re: [PATCH v2 13/21] libcc1: use static_assert

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

Re: [PATCH v2 12/21] libcc1: use foreach

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

Re: [PATCH v2 07/21] libcc1: use std::vector when building function types

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 2021-04-27 Tom Tromey * libcp1plugin.cc (plugin_build_function_type): Use std::vector

Re: [PATCH v2 04/21] libcc1: delete copy constructor and assignment operators

On 4/27/2021 7:01 PM, Tom Tromey wrote: Change libcc1 to use "= delete" for the copy constructor and assignment operator, rather than the old approach of private methods that are nowhere defined. libcc1/ChangeLog 2021-04-27 Tom Tromey * rpc.hh (argument_wrapper):

Re: [PATCH v2 03/21] libcc1: inline some simple methods

On 4/27/2021 7:01 PM, Tom Tromey wrote: This changes libcc1 to inline a trivial method and to use the default constructor. libcc1/ChangeLog 2021-04-27 Tom Tromey * connection.hh (~connection): Use default. (print): Inline. * connection.cc (cc1_plugin::connection

Re: [PATCH v2 02/21] libcc1: use "override"

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

[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

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

[PATCH v2 19/21] libcc1: use variadic templates for callbacks

This patch completes the transition of libcc1 from the use of separate template functions for different arities to the use of variadic functions. This is how I had wanted it to work from the very beginning, and is possible now with C++11. I had thought that variadic callbacks required C++17

[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

Both the C and C++ side of the GDB plugin in libcc1 share a lot of code relating to the base GCC interface. It was all copy-and-pasted, but is essentially identical between the two. This is by design, as the base GCC API is intended to be shared. This patch merges the implementations

[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

libcc1 has a memory leak when calling fork_exec -- it allocates a new vector of arguments, but then does not free it anywhere. This patch changes this code to use std::vector instead. Note that the previous code tried to avoid bad_alloc. I don't believe this is very important. For one thing

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

This changes libcc1 to use the 'deleter' template in a few more places. The template and basic specializations are moved to a new header, then some unmarshall functions are changed to use this code. This change avoids the need to repeat cleanup code in the unmarshallers. libcc1/ChangeLog 2021-04

[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

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

[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

[PATCH v2 05/21] libcc1: use variadic templates for "call"

This changes libcc1 to use variadic templates for the "call" functions. The primary benefit is that this simplifies the code. libcc1/ChangeLog 2021-04-27 Tom Tromey * rpc.hh (call): Use variadic template. Remove overloads. * marshall.hh (marshall): Add base over

[PATCH v2 06/21] libcc1: use variadic templates for "rpc"

This changes libcc1 to use variadic templates for the "rpc" functions. This simplifies the code and removes some possibility for mistakes. libcc1/ChangeLog 2021-04-27 Tom Tromey * libcp1.cc (rpc): Use variadic template. Remove overloads. * libcc1.cc (rpc): Us

[PATCH v2 04/21] libcc1: delete copy constructor and assignment operators

Change libcc1 to use "= delete" for the copy constructor and assignment operator, rather than the old approach of private methods that are nowhere defined. libcc1/ChangeLog 2021-04-27 Tom Tromey * rpc.hh (argument_wrapper): Use delete for copy constructor. * con

[PATCH v2 02/21] libcc1: use "override"

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

[PATCH v2 03/21] libcc1: inline some simple methods

This changes libcc1 to inline a trivial method and to use the default constructor. libcc1/ChangeLog 2021-04-27 Tom Tromey * connection.hh (~connection): Use default. (print): Inline. * connection.cc (cc1_plugin::connection::~connection) (cc1_plugin::connection

[PATCH v2 01/21] libcc1: use templates to unmarshall enums

Now that C++11 can be used in GCC, libcc1 can be changed to use templates and type traits to handle unmarshalling all kinds of enums. libcc1/ChangeLog 2021-04-27 Tom Tromey * marshall.hh (cc1_plugin::unmarshall): Use type traits. * marshall-cp.hh (cc1_plugin::unmarshall

[PATCH v2 00/21] C++11-based improvements for libcc1

Here is v2 of my series to simplify libcc1 through the use of C++11 constructs. v1 is here: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/562668.html I never pinged it because I'd sent it in the wrong stage. As with v1, this brings libcc1 much closer to how I originally wanted

Re: [PATCH 00/10] C++11-based improvements for libcc1

>>>>> "Tom" == Tom Tromey writes: Tom> This short series uses C++11 features to simplify libcc1. This brings Tom> the code closer to how I pictured it when I first wrote it. (It would Tom> be further improved by std::apply, but this isn't available until

[PATCH 10/10] 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-01-03 Tom Tromey * libcp1.cc (struct libcp1) : Use unique_ptr. (~libcp1): Remove. (libcp1_compile, libcp1_set_triplet_regexp

[PATCH 09/10] libcc1: add more uses of 'deleter'

This changes libcc1 to use the 'deleter' template in a few more places. The template and basic specializations are moved to a new header, then some unmarshall functions are changed to use this code. This change avoids the need to repeat cleanup code in the unmarshallers. libcc1/ChangeLog 2021-01

[PATCH 08/10] libcc1: add deleter objects

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

[PATCH 04/10] libcc1: delete copy constructor and assignment operators

Change libcc1 to use "= delete" for the copy constructor and assignment operator, rather than the old approach of private methods that are nowhere defined. libcc1/ChangeLog 2021-01-03 Tom Tromey * rpc.hh (argument_wrapper): Use delete for copy constructor. * con

[PATCH 06/10] libcc1: use variadic templates for "rpc"

This changes libcc1 to use variadic templates for the "rpc" functions. This simplifies the code and removes some possibility for mistakes. libcc1/ChangeLog 2021-01-03 Tom Tromey * libcp1.cc (rpc): Use variadic template. Remove overloads. * libcc1.cc (rpc): Us

[PATCH 07/10] 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-01-03 Tom Tromey * libcp1plugin.cc (plugin_build_function_type): Use std::vector. * libcc1plugin.cc (plugin_build_function_type

[PATCH 05/10] libcc1: use variadic templates for "call"

This changes libcc1 to use variadic templates for the "call" functions. The primary benefit is that this simplifies the code. libcc1/ChangeLog 2021-01-03 Tom Tromey * rpc.hh (call): Use variadic template. Remove overloads. * marshall.hh (marshall): Add base over

[PATCH 01/10] libcc1: use templates to unmarshall enums

Now that C++11 can be used in GCC, libcc1 can be changed to use templates and type traits to handle unmarshalling all kinds of enums. libcc1/ChangeLog 2021-01-03 Tom Tromey * marshall.hh (cc1_plugin::unmarshall): Use type traits. * marshall-cp.hh (cc1_plugin::unmarshall

[PATCH 03/10] libcc1: inline some simple methods

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

[PATCH 02/10] libcc1: use "override"

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

[PATCH 00/10] C++11-based improvements for libcc1

This short series uses C++11 features to simplify libcc1. This brings the code closer to how I pictured it when I first wrote it. (It would be further improved by std::apply, but this isn't available until C++17.) I built and tested this against git GDB on x86-64 Fedora 32. Note that the C

[committed] libcc1: Fix up libcc1 configure [PR98330]

On Wed, Dec 02, 2020 at 04:11:24PM +, Iain Sandoe wrote: > > > --- a/libcc1/configure.ac > > > +++ b/libcc1/configure.ac > > > @@ -104,6 +104,12 @@ AC_CACHE_CHECK([for socket libraries], > > > libcc1_cv_lib_sockets, > > > ]) > > > LIBS=&q

Re: [PATCH 1/5] libcc1: Enable Intel CET on Intel CET enabled host

On Sat, 2020-05-09 at 08:43 -0700, H.J. Lu wrote: > Since on Intel CET enabled host, dlopen in Intel CET enabled applications > fails on shared libraries which aren't Intel CET enabled, enable Intel > CET in libcc1 on Intel CET enabled host. > > * Makefile.am (AM

[PATCH 1/5] libcc1: Enable Intel CET on Intel CET enabled host

Since on Intel CET enabled host, dlopen in Intel CET enabled applications fails on shared libraries which aren't Intel CET enabled, enable Intel CET in libcc1 on Intel CET enabled host. * Makefile.am (AM_CXXFLAGS): Add $(CET_HOST_FLAGS). * configure.ac: Add GCC_CET_HOST_FLAGS

[PATCH 0/5] Add CET host support to libcc1

This patch set adds CET host support to libcc1 by enabling CET host support in gcc, libcpp, libdecnumber and libbacktrace. OK for master? H.J. Lu (5): libcc1: Enable Intel CET on Intel CET enabled host gcc: Enable Intel CET on Intel CET enabled host for jit libcpp: Enable Intel CET

Re: fix libcc1 dependencies in toplevel Makefile

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

Re: fix libcc1 dependencies in toplevel Makefile

ybe-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-stageautofeedback-libiberty-linker-plugin -confi

Re: fix libcc1 dependencies in toplevel Makefile

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

Re: fix libcc1 dependencies in toplevel Makefile

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 can now see

Re: fix libcc1 dependencies in toplevel Makefile

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 se

Re: fix libcc1 dependencies in toplevel Makefile

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

Re: [PATCH v2] [libcc1] Rename C{,P}_COMPILER_NAME and remove triplet from them

ing^3. >>> >>> I'm sending the updated ChangeLog/patch. I'm also removing gdb-patches >>> from the Cc list. >>> >>> libcc1/ChangeLog: >>> 2017-09-01 Sergio Durigan Junior <sergi...@redhat.com> >>> Pedro Alves <pal..

Re: [PATCH v2] [libcc1] Rename C{,P}_COMPILER_NAME and remove triplet from them

On Wednesday, November 15 2017, Jim Wilson wrote: > On 11/13/2017 01:10 PM, Sergio Durigan Junior wrote: >> On Tuesday, September 26 2017, I wrote: >> >>> Ping^2. >> >> Ping^3. >> >> I'm sending the updated ChangeLog/patch. I'm also removi

Re: [PATCH v2] [libcc1] Rename C{,P}_COMPILER_NAME and remove triplet from them

On 11/13/2017 01:10 PM, Sergio Durigan Junior wrote: On Tuesday, September 26 2017, I wrote: Ping^2. Ping^3. I'm sending the updated ChangeLog/patch. I'm also removing gdb-patches from the Cc list. libcc1/ChangeLog: 2017-09-01 Sergio Durigan Junior <sergi...@redhat.

Re: [PATCH v2] [libcc1] Rename C{,P}_COMPILER_NAME and remove triplet from them

On Nov 13, 2017, Sergio Durigan Junior <sergi...@redhat.com> wrote: > On Tuesday, September 26 2017, I wrote: >> Ping^2. > Ping^3. > I'm sending the updated ChangeLog/patch. I'm also removing gdb-patches > from the Cc list. > libcc1/ChangeLog: > 2017-09-01

Re: [PATCH v2] [libcc1] Rename C{,P}_COMPILER_NAME and remove triplet from them

On Tuesday, September 26 2017, I wrote: > Ping^2. Ping^3. I'm sending the updated ChangeLog/patch. I'm also removing gdb-patches from the Cc list. libcc1/ChangeLog: 2017-09-01 Sergio Durigan Junior <sergi...@redhat.com> Pedro Alves <pal...@redhat.com>

Re: [PATCH v2] [libcc1] Rename C{,P}_COMPILER_NAME and remove triplet from them

PILER_NAME defines with the specified prefix >>>> and suffix. Therefore, the regexp being used to match the compiler name >>>> is wrong because it doesn't take into account the fact that the defines >>>> may already contain the triplets. >>> >>> As discu

Re: [PATCH v2] [libcc1] Rename C{,P}_COMPILER_NAME and remove triplet from them

not merely >>> named "gcc", but e.g. "x86_64-linux-gnu-gcc-7"), which end up naming the >>> C_COMPILER_NAME and CP_COMPILER_NAME defines with the specified prefix >>> and suffix. Therefore, the regexp being used to match the compiler name >>> i

[PATCH v2] [libcc1] Rename C{,P}_COMPILER_NAME and remove triplet from them

g the >> C_COMPILER_NAME and CP_COMPILER_NAME defines with the specified prefix >> and suffix. Therefore, the regexp being used to match the compiler name >> is wrong because it doesn't take into account the fact that the defines >> may already contain the trip

Re: [libcc1] Improve detection of triplet on compiler names

g the >> C_COMPILER_NAME and CP_COMPILER_NAME defines with the specified prefix >> and suffix. Therefore, the regexp being used to match the compiler name >> is wrong because it doesn't take into account the fact that the defines >> may already contain the trip

Re: [libcc1] Improve detection of triplet on compiler names

e, the regexp being used to match the compiler name > is wrong because it doesn't take into account the fact that the defines > may already contain the triplets. As discussed on IRC, I think the problem is that C_COMPILER_NAME in libcc1 includes the full triplet in the first place. I thin

Re: [libcc1] Improve detection of triplet on compiler names

On Wednesday, August 23 2017, Pedro Alves wrote: > On 08/23/2017 02:07 PM, Sergio Durigan Junior wrote: >> On Wednesday, August 23 2017, Pedro Alves wrote: >> >>> On 08/23/2017 05:17 AM, Sergio Durigan Junior wrote: >>>> The GCC patch improves the l

Re: [libcc1] Improve detection of triplet on compiler names

On 08/23/2017 02:07 PM, Sergio Durigan Junior wrote: > On Wednesday, August 23 2017, Pedro Alves wrote: > >> On 08/23/2017 05:17 AM, Sergio Durigan Junior wrote: >>> The GCC patch improves the libcc1::compiler_triplet_regexp::find and >>> libcp1::compiler_triplet

Re: [libcc1] Improve detection of triplet on compiler names

On Wednesday, August 23 2017, Pedro Alves wrote: > On 08/23/2017 05:17 AM, Sergio Durigan Junior wrote: >> The GCC patch improves the libcc1::compiler_triplet_regexp::find and >> libcp1::compiler_triplet_regexp::find methods by first trying to match >> the triplet

Re: [libcc1] Improve detection of triplet on compiler names

On 08/23/2017 05:17 AM, Sergio Durigan Junior wrote: > 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 o

[libcc1] Improve detection of triplet on compiler names

ready 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. I've had

Re: [PATCH] Kill TYPE_METHODS libcc1 6/9

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 <nat...@acm.org> libcc1/ * libcp1plugin.cc (plugin_build_decl): Member fns are on TYPE_FIELDS. Index: libcc1/libcp1plu

Use SET_DECL_MODE in libcc1

Applied as obvious after testing on aarch64-linux-gnu and x86_64-linux-gnu. Richard 2017-07-05 Richard Sandiford <richard.sandif...@linaro.org> libcc1/ * libcp1plugin.cc (plugin_build_field): Use SET_DECL_MODE. Index: libcc1/libcp1plu

Re: fix libcc1 dependencies in toplevel Makefile

; > plus, maybe-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 wel

Re: fix libcc1 dependencies in toplevel Makefile

On Jun 26, 2017, Olivier Hainque <hain...@adacore.com> wrote: > On Jun 22, 2017, at 14:12 , Alexandre Oliva <aol...@redhat.com> wrote: >> Your patch takes care of the build dependencies of libcc1, which should >> avoid some scenarios that might lead to concurrency betwe

Re: fix libcc1 dependencies in toplevel Makefile

quadmath: all-target-libquadmath > all-target: maybe-all-target-libquadmath on the one hand, > all-libcc1: maybe-all-gcc > maybe-all-libcc1: all-libcc1 > all-host: maybe-all-libcc1 on the other hand. Does that make sense ? Thanks for your feedback! (Note that I'll be away from tomorrow to Monday) Olivier

  1   2   3   4   >