| Message ID | 20210428010119.806184-8-tom@tromey.com |
|---|---|
| State | New |
| Headers | show |
| Series | C++11-based improvements for libcc1 | expand |
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 <tom@tromey.com> > > * libcp1plugin.cc (plugin_build_function_type): Use std::vector. > * libcc1plugin.cc (plugin_build_function_type): Use std::vector. Does this really work? In general we can't stuff GC'd objects into something like std::vector. Though I guess in this instance the lifetime is limited and we don't have to worry about the GC system? Jeff
>>>>> "Jeff" == Jeff Law <jeffreyalaw@gmail.com> 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-27 Tom Tromey <tom@tromey.com> >> >> * libcp1plugin.cc (plugin_build_function_type): Use std::vector. >> * libcc1plugin.cc (plugin_build_function_type): Use std::vector. Jeff> Does this really work? In general we can't stuff GC'd objects into Jeff> something like std::vector. Though I guess in this instance the Jeff> lifetime is limited and we don't have to worry about the GC system? It's the latter. The patch doesn't really change whether or not the elements of the array are visible to the GC. It just changes how the vector is managed -- from manual use of new/delete to automatic via vector. The plugins do need to interface with the GC, but this is done by registering GC'able objects in a global hash table that is manually marked; see the 'preserve' and 'mark' methods on the plugin context objects. thanks, Tom
On 4/28/2021 1:56 PM, Tom Tromey wrote: >>>>>> "Jeff" == Jeff Law <jeffreyalaw@gmail.com> 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-27 Tom Tromey <tom@tromey.com> >>> >>> * libcp1plugin.cc (plugin_build_function_type): Use std::vector. >>> * libcc1plugin.cc (plugin_build_function_type): Use std::vector. > Jeff> Does this really work? In general we can't stuff GC'd objects into > Jeff> something like std::vector. Though I guess in this instance the > Jeff> lifetime is limited and we don't have to worry about the GC system? > > It's the latter. > > The patch doesn't really change whether or not the elements of the array > are visible to the GC. It just changes how the vector is managed -- > from manual use of new/delete to automatic via vector. > > The plugins do need to interface with the GC, but this is done by > registering GC'able objects in a global hash table that is manually > marked; see the 'preserve' and 'mark' methods on the plugin context > objects. OK. Then let's go with the patch as-is. jeff
diff --git a/libcc1/libcc1plugin.cc b/libcc1/libcc1plugin.cc index 59e4851064a2..65e748258f40 100644 --- a/libcc1/libcc1plugin.cc +++ b/libcc1/libcc1plugin.cc @@ -67,6 +67,8 @@ #include "rpc.hh" #include "gcc-c-interface.h" +#include <vector> + #ifdef __GNUC__ #pragma GCC visibility push(default) #endif @@ -672,24 +674,21 @@ plugin_build_function_type (cc1_plugin::connection *self, const struct gcc_type_array *argument_types_in, int is_varargs) { - tree *argument_types; tree return_type = convert_in (return_type_in); tree result; - argument_types = new tree[argument_types_in->n_elements]; + std::vector<tree> argument_types (argument_types_in->n_elements); for (int i = 0; i < argument_types_in->n_elements; ++i) argument_types[i] = convert_in (argument_types_in->elements[i]); if (is_varargs) result = build_varargs_function_type_array (return_type, argument_types_in->n_elements, - argument_types); + argument_types.data ()); else result = build_function_type_array (return_type, argument_types_in->n_elements, - argument_types); - - delete[] argument_types; + argument_types.data ()); plugin_context *ctx = static_cast<plugin_context *> (self); return convert_out (ctx->preserve (result)); diff --git a/libcc1/libcp1plugin.cc b/libcc1/libcp1plugin.cc index 27a6175e34e6..1fc8e269f075 100644 --- a/libcc1/libcp1plugin.cc +++ b/libcc1/libcp1plugin.cc @@ -70,6 +70,8 @@ #include "marshall-cp.hh" #include "rpc.hh" +#include <vector> + #ifdef __GNUC__ #pragma GCC visibility push(default) #endif @@ -1980,24 +1982,21 @@ plugin_build_function_type (cc1_plugin::connection *self, const struct gcc_type_array *argument_types_in, int is_varargs) { - tree *argument_types; tree return_type = convert_in (return_type_in); tree result; - argument_types = new tree[argument_types_in->n_elements]; + std::vector<tree> argument_types (argument_types_in->n_elements); for (int i = 0; i < argument_types_in->n_elements; ++i) argument_types[i] = convert_in (argument_types_in->elements[i]); if (is_varargs) result = build_varargs_function_type_array (return_type, argument_types_in->n_elements, - argument_types); + argument_types.data ()); else result = build_function_type_array (return_type, argument_types_in->n_elements, - argument_types); - - delete[] argument_types; + argument_types.data ()); plugin_context *ctx = static_cast<plugin_context *> (self); return convert_out (ctx->preserve (result));