* C++ API: Vector arguments / error detection @ 2022-01-30 15:35 Marc Nieper-Wißkirchen 2022-01-31 14:49 ` David Malcolm 0 siblings, 1 reply; 7+ messages in thread From: Marc Nieper-Wißkirchen @ 2022-01-30 15:35 UTC (permalink / raw) To: Marc Nieper-Wißkirchen via Jit This is about two unrelated issues regarding the C++ API: (1) At the moment, a lot of API functions like new_function take non-const referenced to vectors, e.g. std::vector <param> ¶ms; Can we change this into const references? This way, one can write auto param1 = ctxt.new_param (...); auto param2 = ctxt.new_param (...); auto func = new_function (..., {param1, param2}, ...); instead of the more complicated and less convenient auto param1 = ...; auto param2 = ...; auto params = std::vector {param1, param2}; auto func = new_function (..., params, ...); (2) When using gccjit::context::compile_to_file, how can I check whether the compilation succeeded without errors or not? In libgccjit++.h no error is checked and no exception thrown. Thanks, Marc ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: C++ API: Vector arguments / error detection 2022-01-30 15:35 C++ API: Vector arguments / error detection Marc Nieper-Wißkirchen @ 2022-01-31 14:49 ` David Malcolm 2022-01-31 15:08 ` Marc Nieper-Wißkirchen 0 siblings, 1 reply; 7+ messages in thread From: David Malcolm @ 2022-01-31 14:49 UTC (permalink / raw) To: Marc Nieper-Wißkirchen, Marc Nieper-Wißkirchen via Jit On Sun, 2022-01-30 at 16:35 +0100, Marc Nieper-Wißkirchen via Jit wrote: > This is about two unrelated issues regarding the C++ API: > > (1) At the moment, a lot of API functions like new_function take non- > const > referenced to vectors, e.g. std::vector <param> ¶ms; > > Can we change this into const references? This way, one can write > > auto param1 = ctxt.new_param (...); > auto param2 = ctxt.new_param (...); > auto func = new_function (..., {param1, param2}, ...); > > instead of the more complicated and less convenient > > auto param1 = ...; > auto param2 = ...; > auto params = std::vector {param1, param2}; > auto func = new_function (..., params, ...); I wonder why they're not const already - maybe I just forgot? Making the refs const sounds like a good idea to me. > > (2) When using gccjit::context::compile_to_file, how can I check > whether > the compilation succeeded without errors or not? In libgccjit++.h no > error > is checked and no exception thrown. Looks like I forgot to: (a) give a return value to gcc_jit_context_compile_to_file, and (b) add C++ bindings for gcc_jit_context_get_first_error and gcc_jit_context_get_last_error. Looks like fixing (a) would be an ABI break, bother (perhaps we could add a revised gcc_jit_context_compile_to_file symbol and do it with symbol versioning) With those in place, it looks like either the client code needs to check gcc::jit::context::get_last_error on failure, or, better, it should probably change to look something like this (untested): inline void context::compile_to_file (enum gcc_jit_output_kind output_kind, const char *output_path) { if (gcc_jit_context_compile_to_file (m_inner_ctxt, output_kind, output_path)) throw error (m_inner_ctxt); } where error's ctor should call gcc::jit::context::get_last_error on the ctxt, or something similar to this. Sorry about the C++ API being much less polished that the C API. Dave ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: C++ API: Vector arguments / error detection 2022-01-31 14:49 ` David Malcolm @ 2022-01-31 15:08 ` Marc Nieper-Wißkirchen 2022-01-31 15:19 ` David Malcolm 0 siblings, 1 reply; 7+ messages in thread From: Marc Nieper-Wißkirchen @ 2022-01-31 15:08 UTC (permalink / raw) To: David Malcolm Cc: Marc Nieper-Wißkirchen, Marc Nieper-Wißkirchen via Jit Am Mo., 31. Jan. 2022 um 15:49 Uhr schrieb David Malcolm < dmalcolm@redhat.com>: > On Sun, 2022-01-30 at 16:35 +0100, Marc Nieper-Wißkirchen via Jit > wrote: > > This is about two unrelated issues regarding the C++ API: > > > > (1) At the moment, a lot of API functions like new_function take non- > > const > > referenced to vectors, e.g. std::vector <param> ¶ms; > > > > Can we change this into const references? This way, one can write > > > > auto param1 = ctxt.new_param (...); > > auto param2 = ctxt.new_param (...); > > auto func = new_function (..., {param1, param2}, ...); > > > > instead of the more complicated and less convenient > > > > auto param1 = ...; > > auto param2 = ...; > > auto params = std::vector {param1, param2}; > > auto func = new_function (..., params, ...); > > I wonder why they're not const already - maybe I just forgot? > > Making the refs const sounds like a good idea to me. > The reason why you didn't make them const may be that the C API that is called takes non-const arrays of pointers. The latter is probably a good idea because of the const model in C and the const-cast restrictions. But when the C API doesn't change the arrays, all that is needed is a const_cast <...> (...) in the C++ API implementation. If you can confirm the former, I can do the latter. > > > > (2) When using gccjit::context::compile_to_file, how can I check > > whether > > the compilation succeeded without errors or not? In libgccjit++.h no > > error > > is checked and no exception thrown. > > Looks like I forgot to: > (a) give a return value to gcc_jit_context_compile_to_file, and > (b) add C++ bindings for gcc_jit_context_get_first_error and > gcc_jit_context_get_last_error. > > Looks like fixing (a) would be an ABI break, bother (perhaps we could > add a revised gcc_jit_context_compile_to_file symbol and do it with > symbol versioning) > A workaround would be to check that the context is without an error before the context to gcc_jit_context_compile_to_file and then to check afterward again, right? If this is true, a return value (while nice) is not absolutely necessary and an ABI break would not be needed. (By the way, is changing the return type from void to int, say, an ABI break on any platform? The C++ API could throw an error whenever there is an error in the context after compiling. > With those in place, it looks like either the client code needs to > check gcc::jit::context::get_last_error on failure, or, better, it > should probably change to look something like this (untested): > > inline void > context::compile_to_file (enum gcc_jit_output_kind output_kind, > const char *output_path) > { > if (gcc_jit_context_compile_to_file (m_inner_ctxt, > output_kind, > output_path)) > throw error (m_inner_ctxt); > } > > where error's ctor should call gcc::jit::context::get_last_error on the > ctxt, or something similar to this. > > > Sorry about the C++ API being much less polished that the C API. > There absolutely no need to excuse :). libgccjit is a great idea and piece of software. That's the nice thing about free software that people who need a more polished API can contribute. Marc ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: C++ API: Vector arguments / error detection 2022-01-31 15:08 ` Marc Nieper-Wißkirchen @ 2022-01-31 15:19 ` David Malcolm 2022-01-31 15:32 ` Marc Nieper-Wißkirchen 0 siblings, 1 reply; 7+ messages in thread From: David Malcolm @ 2022-01-31 15:19 UTC (permalink / raw) To: Marc Nieper-Wißkirchen; +Cc: Marc Nieper-Wißkirchen via Jit On Mon, 2022-01-31 at 16:08 +0100, Marc Nieper-Wißkirchen wrote: > Am Mo., 31. Jan. 2022 um 15:49 Uhr schrieb David Malcolm < > dmalcolm@redhat.com>: > > > On Sun, 2022-01-30 at 16:35 +0100, Marc Nieper-Wißkirchen via Jit > > wrote: > > > This is about two unrelated issues regarding the C++ API: > > > > > > (1) At the moment, a lot of API functions like new_function take > > > non- > > > const > > > referenced to vectors, e.g. std::vector <param> ¶ms; > > > > > > Can we change this into const references? This way, one can write > > > > > > auto param1 = ctxt.new_param (...); > > > auto param2 = ctxt.new_param (...); > > > auto func = new_function (..., {param1, param2}, ...); > > > > > > instead of the more complicated and less convenient > > > > > > auto param1 = ...; > > > auto param2 = ...; > > > auto params = std::vector {param1, param2}; > > > auto func = new_function (..., params, ...); > > > > I wonder why they're not const already - maybe I just forgot? > > > > Making the refs const sounds like a good idea to me. > > > > The reason why you didn't make them const may be that the C API that is > called takes non-const arrays of pointers. The latter is probably a > good > idea because of the const model in C and the const-cast restrictions. Yeah, that was probably it. > > But when the C API doesn't change the arrays, all that is needed is a > const_cast <...> (...) in the C++ API implementation. If you can > confirm > the former, I can do the latter. Sounds like a good idea to me. > > > > > (2) When using gccjit::context::compile_to_file, how can I check > > > whether > > > the compilation succeeded without errors or not? In libgccjit++.h > > > no > > > error > > > is checked and no exception thrown. > > > > Looks like I forgot to: > > (a) give a return value to gcc_jit_context_compile_to_file, and > > (b) add C++ bindings for gcc_jit_context_get_first_error and > > gcc_jit_context_get_last_error. > > > > Looks like fixing (a) would be an ABI break, bother (perhaps we could > > add a revised gcc_jit_context_compile_to_file symbol and do it with > > symbol versioning) > > > > A workaround would be to check that the context is without an error > before > the context to gcc_jit_context_compile_to_file and then to check > afterward > again, right? That could work. > If this is true, a return value (while nice) is not > absolutely necessary and an ABI break would not be needed. (By the > way, is > changing the return type from void to int, say, an ABI break on any > platform? I'm not sure; I think I'm erring on the side of caution. > > The C++ API could throw an error whenever there is an error in the > context > after compiling. Sounds good. > > > > With those in place, it looks like either the client code needs to > > check gcc::jit::context::get_last_error on failure, or, better, it > > should probably change to look something like this (untested): > > > > inline void > > context::compile_to_file (enum gcc_jit_output_kind output_kind, > > const char *output_path) > > { > > if (gcc_jit_context_compile_to_file (m_inner_ctxt, > > output_kind, > > output_path)) > > throw error (m_inner_ctxt); > > } > > > > where error's ctor should call gcc::jit::context::get_last_error on > > the > > ctxt, or something similar to this. > > > > > > Sorry about the C++ API being much less polished that the C API. > > > > There absolutely no need to excuse :). libgccjit is a great idea and > piece > of software. That's the nice thing about free software that people who > need a more polished API can contribute. > Marc Indeed. I was tempted to say "patches welcome", but that can come across as rather passive-aggressive :) Out of curiosity, are you using the C++ API for something, and would you like it on the "Who's using this code?" section on https://gcc.gnu.org/wiki/JIT ? Thanks Dave ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: C++ API: Vector arguments / error detection 2022-01-31 15:19 ` David Malcolm @ 2022-01-31 15:32 ` Marc Nieper-Wißkirchen 2022-01-31 15:39 ` Marc Nieper-Wißkirchen 0 siblings, 1 reply; 7+ messages in thread From: Marc Nieper-Wißkirchen @ 2022-01-31 15:32 UTC (permalink / raw) To: David Malcolm Cc: Marc Nieper-Wißkirchen, Marc Nieper-Wißkirchen via Jit Am Mo., 31. Jan. 2022 um 16:20 Uhr schrieb David Malcolm < dmalcolm@redhat.com>: > On Mon, 2022-01-31 at 16:08 +0100, Marc Nieper-Wißkirchen wrote: > > Am Mo., 31. Jan. 2022 um 15:49 Uhr schrieb David Malcolm < > > dmalcolm@redhat.com>: > > > > > On Sun, 2022-01-30 at 16:35 +0100, Marc Nieper-Wißkirchen via Jit > > > wrote: > > > > This is about two unrelated issues regarding the C++ API: > > > > > > > > (1) At the moment, a lot of API functions like new_function take > > > > non- > > > > const > > > > referenced to vectors, e.g. std::vector <param> ¶ms; > > > > > > > > Can we change this into const references? This way, one can write > > > > > > > > auto param1 = ctxt.new_param (...); > > > > auto param2 = ctxt.new_param (...); > > > > auto func = new_function (..., {param1, param2}, ...); > > > > > > > > instead of the more complicated and less convenient > > > > > > > > auto param1 = ...; > > > > auto param2 = ...; > > > > auto params = std::vector {param1, param2}; > > > > auto func = new_function (..., params, ...); > > > > > > I wonder why they're not const already - maybe I just forgot? > > > > > > Making the refs const sounds like a good idea to me. > > > > > > > The reason why you didn't make them const may be that the C API that is > > called takes non-const arrays of pointers. The latter is probably a > > good > > idea because of the const model in C and the const-cast restrictions. > > Yeah, that was probably it. > > > > > But when the C API doesn't change the arrays, all that is needed is a > > const_cast <...> (...) in the C++ API implementation. If you can > > confirm > > the former, I can do the latter. > > Sounds like a good idea to me. > > > > > > > > > (2) When using gccjit::context::compile_to_file, how can I check > > > > whether > > > > the compilation succeeded without errors or not? In libgccjit++.h > > > > no > > > > error > > > > is checked and no exception thrown. > > > > > > Looks like I forgot to: > > > (a) give a return value to gcc_jit_context_compile_to_file, and > > > (b) add C++ bindings for gcc_jit_context_get_first_error and > > > gcc_jit_context_get_last_error. > > > > > > Looks like fixing (a) would be an ABI break, bother (perhaps we could > > > add a revised gcc_jit_context_compile_to_file symbol and do it with > > > symbol versioning) > > > > > > > A workaround would be to check that the context is without an error > > before > > the context to gcc_jit_context_compile_to_file and then to check > > afterward > > again, right? > > That could work. > > > If this is true, a return value (while nice) is not > > absolutely necessary and an ABI break would not be needed. (By the > > way, is > > changing the return type from void to int, say, an ABI break on any > > platform? > > I'm not sure; I think I'm erring on the side of caution. > > > > > > The C++ API could throw an error whenever there is an error in the > > context > > after compiling. > > Sounds good. > Thanks for all these prompt responses. You can expect some patches during the next few days. :) > > > > > > > > With those in place, it looks like either the client code needs to > > > check gcc::jit::context::get_last_error on failure, or, better, it > > > should probably change to look something like this (untested): > > > > > > inline void > > > context::compile_to_file (enum gcc_jit_output_kind output_kind, > > > const char *output_path) > > > { > > > if (gcc_jit_context_compile_to_file (m_inner_ctxt, > > > output_kind, > > > output_path)) > > > throw error (m_inner_ctxt); > > > } > > > > > > where error's ctor should call gcc::jit::context::get_last_error on > > > the > > > ctxt, or something similar to this. > > > > > > > > > Sorry about the C++ API being much less polished that the C API. > > > > > > > There absolutely no need to excuse :). libgccjit is a great idea and > > piece > > of software. That's the nice thing about free software that people who > > need a more polished API can contribute. > > Marc > > Indeed. I was tempted to say "patches welcome", but that can come > across as rather passive-aggressive :) > :) "Welcome" is a nice and friendly word, isn't it? > Out of curiosity, are you using the C++ API for something, and would > you like it on the "Who's using this code?" section on > https://gcc.gnu.org/wiki/JIT ? > My "something" is far from finished. But I will come back to you when I have something to show. What I can say so far is that the C++ API really saves a lot of typing. Marc ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: C++ API: Vector arguments / error detection 2022-01-31 15:32 ` Marc Nieper-Wißkirchen @ 2022-01-31 15:39 ` Marc Nieper-Wißkirchen 2022-02-01 14:41 ` Marc Nieper-Wißkirchen 0 siblings, 1 reply; 7+ messages in thread From: Marc Nieper-Wißkirchen @ 2022-01-31 15:39 UTC (permalink / raw) To: Marc Nieper-Wißkirchen Cc: David Malcolm, Marc Nieper-Wißkirchen via Jit Probably more important than changing std::vector <...> &args to const std::vector <...> &args is to offer an extra set of methods that take a std::initializer_list instead of a vector. These should be allocated on the stack and not on the heap, improving efficiency when the argument lists are known ahead. Am Mo., 31. Jan. 2022 um 16:32 Uhr schrieb Marc Nieper-Wißkirchen < marc.nieper+gnu@gmail.com>: > Am Mo., 31. Jan. 2022 um 16:20 Uhr schrieb David Malcolm < > dmalcolm@redhat.com>: > >> On Mon, 2022-01-31 at 16:08 +0100, Marc Nieper-Wißkirchen wrote: >> > Am Mo., 31. Jan. 2022 um 15:49 Uhr schrieb David Malcolm < >> > dmalcolm@redhat.com>: >> > >> > > On Sun, 2022-01-30 at 16:35 +0100, Marc Nieper-Wißkirchen via Jit >> > > wrote: >> > > > This is about two unrelated issues regarding the C++ API: >> > > > >> > > > (1) At the moment, a lot of API functions like new_function take >> > > > non- >> > > > const >> > > > referenced to vectors, e.g. std::vector <param> ¶ms; >> > > > >> > > > Can we change this into const references? This way, one can write >> > > > >> > > > auto param1 = ctxt.new_param (...); >> > > > auto param2 = ctxt.new_param (...); >> > > > auto func = new_function (..., {param1, param2}, ...); >> > > > >> > > > instead of the more complicated and less convenient >> > > > >> > > > auto param1 = ...; >> > > > auto param2 = ...; >> > > > auto params = std::vector {param1, param2}; >> > > > auto func = new_function (..., params, ...); >> > > >> > > I wonder why they're not const already - maybe I just forgot? >> > > >> > > Making the refs const sounds like a good idea to me. >> > > >> > >> > The reason why you didn't make them const may be that the C API that is >> > called takes non-const arrays of pointers. The latter is probably a >> > good >> > idea because of the const model in C and the const-cast restrictions. >> >> Yeah, that was probably it. >> >> > >> > But when the C API doesn't change the arrays, all that is needed is a >> > const_cast <...> (...) in the C++ API implementation. If you can >> > confirm >> > the former, I can do the latter. >> >> Sounds like a good idea to me. >> >> > > >> >> > > > (2) When using gccjit::context::compile_to_file, how can I check >> > > > whether >> > > > the compilation succeeded without errors or not? In libgccjit++.h >> > > > no >> > > > error >> > > > is checked and no exception thrown. >> > > >> > > Looks like I forgot to: >> > > (a) give a return value to gcc_jit_context_compile_to_file, and >> > > (b) add C++ bindings for gcc_jit_context_get_first_error and >> > > gcc_jit_context_get_last_error. >> > > >> > > Looks like fixing (a) would be an ABI break, bother (perhaps we could >> > > add a revised gcc_jit_context_compile_to_file symbol and do it with >> > > symbol versioning) >> > > >> > >> > A workaround would be to check that the context is without an error >> > before >> > the context to gcc_jit_context_compile_to_file and then to check >> > afterward >> > again, right? >> >> That could work. >> >> > If this is true, a return value (while nice) is not >> > absolutely necessary and an ABI break would not be needed. (By the >> > way, is >> > changing the return type from void to int, say, an ABI break on any >> > platform? >> >> I'm not sure; I think I'm erring on the side of caution. >> >> >> > >> > The C++ API could throw an error whenever there is an error in the >> > context >> > after compiling. >> >> Sounds good. >> > > Thanks for all these prompt responses. You can expect some patches during > the next few days. :) > > > >> >> > >> > >> > > With those in place, it looks like either the client code needs to >> > > check gcc::jit::context::get_last_error on failure, or, better, it >> > > should probably change to look something like this (untested): >> > > >> > > inline void >> > > context::compile_to_file (enum gcc_jit_output_kind output_kind, >> > > const char *output_path) >> > > { >> > > if (gcc_jit_context_compile_to_file (m_inner_ctxt, >> > > output_kind, >> > > output_path)) >> > > throw error (m_inner_ctxt); >> > > } >> > > >> > > where error's ctor should call gcc::jit::context::get_last_error on >> > > the >> > > ctxt, or something similar to this. >> > > >> > > >> > > Sorry about the C++ API being much less polished that the C API. >> > > >> > >> > There absolutely no need to excuse :). libgccjit is a great idea and >> > piece >> > of software. That's the nice thing about free software that people who >> > need a more polished API can contribute. >> > Marc >> >> Indeed. I was tempted to say "patches welcome", but that can come >> across as rather passive-aggressive :) >> > > :) "Welcome" is a nice and friendly word, isn't it? > > >> Out of curiosity, are you using the C++ API for something, and would >> you like it on the "Who's using this code?" section on >> https://gcc.gnu.org/wiki/JIT ? >> > > My "something" is far from finished. But I will come back to you when I > have something to show. What I can say so far is that the C++ API really > saves a lot of typing. > > Marc > > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: C++ API: Vector arguments / error detection 2022-01-31 15:39 ` Marc Nieper-Wißkirchen @ 2022-02-01 14:41 ` Marc Nieper-Wißkirchen 0 siblings, 0 replies; 7+ messages in thread From: Marc Nieper-Wißkirchen @ 2022-02-01 14:41 UTC (permalink / raw) To: Marc Nieper-Wißkirchen Cc: David Malcolm, Marc Nieper-Wißkirchen via Jit Actually, we should use C++ templating mechanism here: For example, gccjit::struct_ gccjit::context::new_struct_type (const std::string &name, std::vector<field> &fields, gccjit::location loc) should become template <typename T> gccjit::struct_ gccjit::context::new_struct_type (const std::string &name, T &&fields, gccjit::location loc) gccjit::struct_ gccjit::context::new_struct_type (const std::string &name, std::initializer_list <field>, gccjit::location loc) The implementation would then be as follows: template <typename T> gccjit::struct_ gccjit::context:: new_struct_type (const std::string &name, T &&fields, gccjit::location loc) { field *as_array_of_wrappers = const_cast <field *> (std::data (std::forward <T> (fields))); gcc_jit_field **as_array_of_ptrs = reinterpret_cast <gcc_jit_field **> (as_array_of_wrappers); return struct_ (gcc_jit_context_new_struct_type (m_inner_ctxt, loc.get_inner_location (), name.c_str (), std::size (std::forward <T> (fields)), as_array_of_ptrs)); } gccjit::struct_ gccjit::context:: new_struct_type (const std::string &name, std::initializer_list <field> fields, gccjit::location loc) { return new_struct_type <> (fields); } With it, all the following initializations are possible: std::vector <field> fields {field1, field2}; new_struct_type ("name", fields); std::array <field, 2> fields {field1, field2}; new_struct_type ("name", fields); field fields[2] {field1, field2}; new_struct_type ("name", fields); new_struct_type ("name", {field1, field2}); // initializer list Note that the above implementation uses std::data and std::size, which is only available from C++17 onward, for clarity, but both template functions can be easily provided by libgccjit++.h when used with C++11 or C++14. } Am Mo., 31. Jan. 2022 um 16:39 Uhr schrieb Marc Nieper-Wißkirchen <marc.nieper+gnu@gmail.com>: > > Probably more important than changing std::vector <...> &args to const std::vector <...> &args is to offer an extra set of methods that take a std::initializer_list instead of a vector. These should be allocated on the stack and not on the heap, improving efficiency when the argument lists are known ahead. > > > Am Mo., 31. Jan. 2022 um 16:32 Uhr schrieb Marc Nieper-Wißkirchen <marc.nieper+gnu@gmail.com>: >> >> Am Mo., 31. Jan. 2022 um 16:20 Uhr schrieb David Malcolm <dmalcolm@redhat.com>: >>> >>> On Mon, 2022-01-31 at 16:08 +0100, Marc Nieper-Wißkirchen wrote: >>> > Am Mo., 31. Jan. 2022 um 15:49 Uhr schrieb David Malcolm < >>> > dmalcolm@redhat.com>: >>> > >>> > > On Sun, 2022-01-30 at 16:35 +0100, Marc Nieper-Wißkirchen via Jit >>> > > wrote: >>> > > > This is about two unrelated issues regarding the C++ API: >>> > > > >>> > > > (1) At the moment, a lot of API functions like new_function take >>> > > > non- >>> > > > const >>> > > > referenced to vectors, e.g. std::vector <param> ¶ms; >>> > > > >>> > > > Can we change this into const references? This way, one can write >>> > > > >>> > > > auto param1 = ctxt.new_param (...); >>> > > > auto param2 = ctxt.new_param (...); >>> > > > auto func = new_function (..., {param1, param2}, ...); >>> > > > >>> > > > instead of the more complicated and less convenient >>> > > > >>> > > > auto param1 = ...; >>> > > > auto param2 = ...; >>> > > > auto params = std::vector {param1, param2}; >>> > > > auto func = new_function (..., params, ...); >>> > > >>> > > I wonder why they're not const already - maybe I just forgot? >>> > > >>> > > Making the refs const sounds like a good idea to me. >>> > > >>> > >>> > The reason why you didn't make them const may be that the C API that is >>> > called takes non-const arrays of pointers. The latter is probably a >>> > good >>> > idea because of the const model in C and the const-cast restrictions. >>> >>> Yeah, that was probably it. >>> >>> > >>> > But when the C API doesn't change the arrays, all that is needed is a >>> > const_cast <...> (...) in the C++ API implementation. If you can >>> > confirm >>> > the former, I can do the latter. >>> >>> Sounds like a good idea to me. >>> >>> > > >>> >>> > > > (2) When using gccjit::context::compile_to_file, how can I check >>> > > > whether >>> > > > the compilation succeeded without errors or not? In libgccjit++.h >>> > > > no >>> > > > error >>> > > > is checked and no exception thrown. >>> > > >>> > > Looks like I forgot to: >>> > > (a) give a return value to gcc_jit_context_compile_to_file, and >>> > > (b) add C++ bindings for gcc_jit_context_get_first_error and >>> > > gcc_jit_context_get_last_error. >>> > > >>> > > Looks like fixing (a) would be an ABI break, bother (perhaps we could >>> > > add a revised gcc_jit_context_compile_to_file symbol and do it with >>> > > symbol versioning) >>> > > >>> > >>> > A workaround would be to check that the context is without an error >>> > before >>> > the context to gcc_jit_context_compile_to_file and then to check >>> > afterward >>> > again, right? >>> >>> That could work. >>> >>> > If this is true, a return value (while nice) is not >>> > absolutely necessary and an ABI break would not be needed. (By the >>> > way, is >>> > changing the return type from void to int, say, an ABI break on any >>> > platform? >>> >>> I'm not sure; I think I'm erring on the side of caution. >>> >>> >>> > >>> > The C++ API could throw an error whenever there is an error in the >>> > context >>> > after compiling. >>> >>> Sounds good. >> >> >> Thanks for all these prompt responses. You can expect some patches during the next few days. :) >> >> >>> >>> >>> > >>> > >>> > > With those in place, it looks like either the client code needs to >>> > > check gcc::jit::context::get_last_error on failure, or, better, it >>> > > should probably change to look something like this (untested): >>> > > >>> > > inline void >>> > > context::compile_to_file (enum gcc_jit_output_kind output_kind, >>> > > const char *output_path) >>> > > { >>> > > if (gcc_jit_context_compile_to_file (m_inner_ctxt, >>> > > output_kind, >>> > > output_path)) >>> > > throw error (m_inner_ctxt); >>> > > } >>> > > >>> > > where error's ctor should call gcc::jit::context::get_last_error on >>> > > the >>> > > ctxt, or something similar to this. >>> > > >>> > > >>> > > Sorry about the C++ API being much less polished that the C API. >>> > > >>> > >>> > There absolutely no need to excuse :). libgccjit is a great idea and >>> > piece >>> > of software. That's the nice thing about free software that people who >>> > need a more polished API can contribute. >>> > Marc >>> >>> Indeed. I was tempted to say "patches welcome", but that can come >>> across as rather passive-aggressive :) >> >> >> :) "Welcome" is a nice and friendly word, isn't it? >> >>> >>> Out of curiosity, are you using the C++ API for something, and would >>> you like it on the "Who's using this code?" section on >>> https://gcc.gnu.org/wiki/JIT ? >> >> >> My "something" is far from finished. But I will come back to you when I have something to show. What I can say so far is that the C++ API really saves a lot of typing. >> >> Marc >> ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-02-01 14:41 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-01-30 15:35 C++ API: Vector arguments / error detection Marc Nieper-Wißkirchen 2022-01-31 14:49 ` David Malcolm 2022-01-31 15:08 ` Marc Nieper-Wißkirchen 2022-01-31 15:19 ` David Malcolm 2022-01-31 15:32 ` Marc Nieper-Wißkirchen 2022-01-31 15:39 ` Marc Nieper-Wißkirchen 2022-02-01 14:41 ` Marc Nieper-Wißkirchen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).