[PATCH] JIT: Update docs v2
Please disregard the prior patch I sent some minute ago. I spotted an copy-paste error, corrected bellow: >From 7f1d849319318a4cfd304279840899f928f9b86d Mon Sep 17 00:00:00 2001 From: Petter Tomner Date: Sat, 19 Feb 2022 16:01:54 +0100 Subject: [PATCH] jit: Update docs Update docs concerning linking and fix formatting errors. 'make html' looks fine. /gcc/jit/docs/topics: * compatibility.rst: Add 19 tag * compilation.rst: Linking * contexts.rst: Linking example * expressions.rst: Fix formatting and dropped 's' Signed-off-by: Petter Tomner 2022-02-19 --- gcc/jit/docs/topics/compatibility.rst | 12 gcc/jit/docs/topics/compilation.rst | 8 ++-- gcc/jit/docs/topics/contexts.rst | 5 + gcc/jit/docs/topics/expressions.rst | 15 ++- 4 files changed, 29 insertions(+), 11 deletions(-) diff --git a/gcc/jit/docs/topics/compatibility.rst b/gcc/jit/docs/topics/compatibility.rst index 16cebe31a10..03e3f3402a1 100644 --- a/gcc/jit/docs/topics/compatibility.rst +++ b/gcc/jit/docs/topics/compatibility.rst @@ -302,3 +302,15 @@ thread-local storage model of a variable: section of a variable: * :func:`gcc_jit_lvalue_set_link_section` + +.. _LIBGCCJIT_ABI_19: + +``LIBGCCJIT_ABI_19`` +--- +``LIBGCCJIT_ABI_19`` covers the addition of API entrypoints to set the initial value +of a global with an rvalue and to use constructors: + + * :func:`gcc_jit_context_new_array_constructor` + * :func:`gcc_jit_context_new_struct_constructor` + * :func:`gcc_jit_context_new_union_constructor` + * :func:`gcc_jit_global_set_initializer_rvalue` diff --git a/gcc/jit/docs/topics/compilation.rst b/gcc/jit/docs/topics/compilation.rst index 0f90db3b70e..9b1eed2dede 100644 --- a/gcc/jit/docs/topics/compilation.rst +++ b/gcc/jit/docs/topics/compilation.rst @@ -146,6 +146,8 @@ can also be used for implementing more traditional ahead-of-time compilers, via the :c:func:`gcc_jit_context_compile_to_file` API entrypoint. +For linking in object files, use :c:func:`gcc_jit_context_add_driver_option`. + .. function:: void \ gcc_jit_context_compile_to_file (gcc_jit_context *ctxt, \ enum gcc_jit_output_kind output_kind,\ @@ -188,12 +190,6 @@ Output kind Typical suffix Compile the context to a dynamic library. - There is currently no support for specifying other libraries to link - against. - .. c:macro:: GCC_JIT_OUTPUT_KIND_EXECUTABLE Compile the context to an executable. - - There is currently no support for specifying libraries to link - against. diff --git a/gcc/jit/docs/topics/contexts.rst b/gcc/jit/docs/topics/contexts.rst index 68ab7ab1321..14ee57e2e54 100644 --- a/gcc/jit/docs/topics/contexts.rst +++ b/gcc/jit/docs/topics/contexts.rst @@ -569,6 +569,11 @@ Additional command-line options gcc_jit_context_add_driver_option (ctxt, "-lm"); gcc_jit_context_add_driver_option (ctxt, "-fuse-linker-plugin"); + gcc_jit_context_add_driver_option (ctxt, "obj.o"); + + gcc_jit_context_add_driver_option (ctxt, "-L."); + gcc_jit_context_add_driver_option (ctxt, "-lwhatever"); + Note that only some options are likely to be meaningful; there is no "frontend" within libgccjit, so typically only those affecting assembler and linker are likely to be useful. diff --git a/gcc/jit/docs/topics/expressions.rst b/gcc/jit/docs/topics/expressions.rst index 791a20398ca..9267b6d2ad6 100644 --- a/gcc/jit/docs/topics/expressions.rst +++ b/gcc/jit/docs/topics/expressions.rst @@ -152,6 +152,7 @@ Constructor expressions their presence using: .. code-block:: c + #ifdef LIBGCCJIT_HAVE_CTORS .. function:: gcc_jit_rvalue *\ @@ -186,6 +187,7 @@ Constructor expressions presence using: .. code-block:: c + #ifdef LIBGCCJIT_HAVE_CTORS .. function:: gcc_jit_rvalue *\ @@ -194,7 +196,7 @@ Constructor expressions gcc_jit_type *type,\ size_t num_values,\ gcc_jit_field **fields,\ - gcc_jit_rvalue **value) + gcc_jit_rvalue **values) Create a constructor for a struct as an rvalue. @@ -235,6 +237,7 @@ Constructor expressions presence using: .. code-block:: c + #ifdef LIBGCCJIT_HAVE_CTORS .. function:: gcc_jit_rvalue *\ @@ -265,6 +268,7 @@ Constructor expressions presence using: .. code-block:: c + #ifdef LIBGCCJIT_HAVE_CTORS Vector expressions @@ -803,14 +807,14 @@ Global variables #ifdef LIBGCCJIT_HAVE_gcc_jit_global_set_initializer .. function:: gcc_jit_lvalue *\ - gcc_jit_global_set_initializer_rvalue (gcc_jit_lvalue *global, +
JIT: Update docs
Hi! I messed up some formatting in the doc rts-files in the constructor commit. Here is a patch fixing that, adding the ABI key in compability, and also changing a comment about linking not being possible, that is not true since drive options were added. I built the docs to verify it looks nice. The patch only touches docs. Regards, Petter >From 450c90fce5b6c5a9522345b65a53057d3d7201b3 Mon Sep 17 00:00:00 2001 From: Petter Tomner Date: Sat, 19 Feb 2022 16:01:54 +0100 Subject: [PATCH] jit: Update docs Update docs concerning linking and fix formating errors. gcc/jit/docs/topics/ * compatibility.rst: Add 19 tag * compilation.rst: Linking * contexts.rst: Linking example * expressions.rst: Fix formating and dropped 's' Signed-off-by: 2022-02-19 Petter Tomner --- gcc/jit/docs/topics/compatibility.rst | 12 gcc/jit/docs/topics/compilation.rst | 8 ++-- gcc/jit/docs/topics/contexts.rst | 5 + gcc/jit/docs/topics/expressions.rst | 15 ++- 4 files changed, 29 insertions(+), 11 deletions(-) diff --git a/gcc/jit/docs/topics/compatibility.rst b/gcc/jit/docs/topics/compatibility.rst index 16cebe31a10..030e72165b7 100644 --- a/gcc/jit/docs/topics/compatibility.rst +++ b/gcc/jit/docs/topics/compatibility.rst @@ -302,3 +302,15 @@ thread-local storage model of a variable: section of a variable: * :func:`gcc_jit_lvalue_set_link_section` + +.. _LIBGCCJIT_ABI_19: + +``LIBGCCJIT_ABI_19`` +--- +``LIBGCCJIT_ABI_19`` covers the addition of an API entrypoint to set the link +section of a variable: + + * :func:`gcc_jit_context_new_array_constructor` + * :func:`gcc_jit_context_new_struct_constructor` + * :func:`gcc_jit_context_new_union_constructor` + * :func:`gcc_jit_global_set_initializer_rvalue` diff --git a/gcc/jit/docs/topics/compilation.rst b/gcc/jit/docs/topics/compilation.rst index 0f90db3b70e..9b1eed2dede 100644 --- a/gcc/jit/docs/topics/compilation.rst +++ b/gcc/jit/docs/topics/compilation.rst @@ -146,6 +146,8 @@ can also be used for implementing more traditional ahead-of-time compilers, via the :c:func:`gcc_jit_context_compile_to_file` API entrypoint. +For linking in object files, use :c:func:`gcc_jit_context_add_driver_option`. + .. function:: void \ gcc_jit_context_compile_to_file (gcc_jit_context *ctxt, \ enum gcc_jit_output_kind output_kind,\ @@ -188,12 +190,6 @@ Output kind Typical suffix Compile the context to a dynamic library. - There is currently no support for specifying other libraries to link - against. - .. c:macro:: GCC_JIT_OUTPUT_KIND_EXECUTABLE Compile the context to an executable. - - There is currently no support for specifying libraries to link - against. diff --git a/gcc/jit/docs/topics/contexts.rst b/gcc/jit/docs/topics/contexts.rst index 68ab7ab1321..14ee57e2e54 100644 --- a/gcc/jit/docs/topics/contexts.rst +++ b/gcc/jit/docs/topics/contexts.rst @@ -569,6 +569,11 @@ Additional command-line options gcc_jit_context_add_driver_option (ctxt, "-lm"); gcc_jit_context_add_driver_option (ctxt, "-fuse-linker-plugin"); + gcc_jit_context_add_driver_option (ctxt, "obj.o"); + + gcc_jit_context_add_driver_option (ctxt, "-L."); + gcc_jit_context_add_driver_option (ctxt, "-lwhatever"); + Note that only some options are likely to be meaningful; there is no "frontend" within libgccjit, so typically only those affecting assembler and linker are likely to be useful. diff --git a/gcc/jit/docs/topics/expressions.rst b/gcc/jit/docs/topics/expressions.rst index 791a20398ca..9267b6d2ad6 100644 --- a/gcc/jit/docs/topics/expressions.rst +++ b/gcc/jit/docs/topics/expressions.rst @@ -152,6 +152,7 @@ Constructor expressions their presence using: .. code-block:: c + #ifdef LIBGCCJIT_HAVE_CTORS .. function:: gcc_jit_rvalue *\ @@ -186,6 +187,7 @@ Constructor expressions presence using: .. code-block:: c + #ifdef LIBGCCJIT_HAVE_CTORS .. function:: gcc_jit_rvalue *\ @@ -194,7 +196,7 @@ Constructor expressions gcc_jit_type *type,\ size_t num_values,\ gcc_jit_field **fields,\ - gcc_jit_rvalue **value) + gcc_jit_rvalue **values) Create a constructor for a struct as an rvalue. @@ -235,6 +237,7 @@ Constructor expressions presence using: .. code-block:: c + #ifdef LIBGCCJIT_HAVE_CTORS .. function:: gcc_jit_rvalue *\ @@ -265,6 +268,7 @@ Constructor expressions presence using: .. code-block:: c + #ifdef LIBGCCJIT_HAVE_CTORS Vector expressions @@ -803,14 +807,14 @@ Global variables #ifdef
SV: SV: [commited] jit: Support for global rvalue initialization and constructors
Oh ye no it is probably terrible missuse trying to write into the constructor.
=)
Maybe I should look into barring that entrypoint for constructors. Kinda
overlooked
that rvalue arrays could be used as lvalues.
/Petter
Från: Antoni Boucher
Skickat: den 30 december 2021 02:40
Till: Petter Tomner; David Malcolm; j...@gcc.gnu.org; gcc-patches@gcc.gnu.org
Ämne: Re: SV: [commited] jit: Support for global rvalue initialization and
constructors
Oh, sorry, I meant when you have an array not in a local variable, and
you try to assign to an index of this array.
Something like:
gcc_jit_rvalue *ctor = gcc_jit_context_new_array_constructor
(ctxt,0,int50arr_type,6,values);
gcc_jit_block_add_assignment (block, 0,
gcc_jit_context_new_array_access(NULL, ctor,
gcc_jit_context_zero(int_type)), some_value);
Le jeudi 30 décembre 2021 à 01:16 +, Petter Tomner a écrit :
> Could you be more specific? I tried the equivalent of:
>
> /* int [50] foobar = {1,2,3,4};
> int [50] foo() { int arr[50];
> arr = (int [50]){-1,-2,-3,-4,-5,-6};
> arr = foobar;
> arr = (int [50]){1,2,3,4,5,6};
> arr[6] = 1234;
> return arr;}
>
> N.B: Not a typo, returning an array.
> */
>
> in test-local-init-rvalue.c with a global and local "arr" and it ran
> fine. (See attachment).
>
> Regards, Petter
>
>
> Från: Antoni Boucher
> Skickat: den 29 december 2021 23:45
> Till: Petter Tomner; David Malcolm; j...@gcc.gnu.org;
> gcc-patches@gcc.gnu.org
> Ämne: Re: [commited] jit: Support for global rvalue initialization
> and constructors
>
> I realized that trying to do an assignment to an array created by the
> new array constructor API will result in a "gimplification failed"
> error:
>
> libgccjit.so: error: gimplification failed
> 0x7fa3a441e5d3 gimplify_expr(tree_node**, gimple**, gimple**, bool
> (*)(tree_node*), int)
> ../../../gcc/gcc/gimplify.c:15964
> 0x7fa3a442b1ab gimplify_modify_expr
> ../../../gcc/gcc/gimplify.c:5975
> 0x7fa3a441ac4c gimplify_expr(tree_node**, gimple**, gimple**, bool
> (*)(tree_node*), int)
> ../../../gcc/gcc/gimplify.c:14951
> 0x7fa3a441e63c gimplify_stmt(tree_node**, gimple**)
> ../../../gcc/gcc/gimplify.c:7026
> 0x7fa3a441bca3 gimplify_statement_list
> ../../../gcc/gcc/gimplify.c:2014
> 0x7fa3a441bca3 gimplify_expr(tree_node**, gimple**, gimple**, bool
> (*)(tree_node*), int)
> ../../../gcc/gcc/gimplify.c:15396
> 0x7fa3a441e63c gimplify_stmt(tree_node**, gimple**)
> ../../../gcc/gcc/gimplify.c:7026
> 0x7fa3a441f000 gimplify_bind_expr
> ../../../gcc/gcc/gimplify.c:1427
> 0x7fa3a441adc6 gimplify_expr(tree_node**, gimple**, gimple**, bool
> (*)(tree_node*), int)
> ../../../gcc/gcc/gimplify.c:15152
> 0x7fa3a441e63c gimplify_stmt(tree_node**, gimple**)
> ../../../gcc/gcc/gimplify.c:7026
> 0x7fa3a4420671 gimplify_body(tree_node*, bool)
> ../../../gcc/gcc/gimplify.c:16197
> 0x7fa3a4420b3c gimplify_function_tree(tree_node*)
> ../../../gcc/gcc/gimplify.c:16351
> 0x7fa3a419fe5e gcc::jit::playback::function::postprocess()
> ../../../gcc/gcc/jit/jit-playback.c:1909
> 0x7fa3a41a13dc gcc::jit::playback::context::replay()
> ../../../gcc/gcc/jit/jit-playback.c:3250
>
>
> Should an assignment to such a value be supported?
>
> Le mercredi 15 décembre 2021 à 19:19 +, Petter Tomner a écrit :
> > Oh ye I accidentally dropped that in the merge thank you.
> >
> > I believe there is an implicit "global:" in the top of each version
> > scope, so it shouldn't
> > matter other than looking a bit deviant.
> >
> > Regards,
> > Petter
> >
> > Från: Antoni Boucher
> > Skickat: den 15 december 2021 15:19
> > Till: Petter Tomner; David Malcolm; j...@gcc.gnu.org;
> > gcc-patches@gcc.gnu.org
> > Ämne: Re: [commited] jit: Support for global rvalue initialization
> > and constructors
> >
> > Hi Petter.
> > I believe you have forgotten the line `global:` in the file
> > `gcc/jit/libgccjit.map`.
> > I'm not sure what this line does, but it is there for all other
> > ABI.
> > David: What do you think?
> > Regards.
> >
> > Le mardi 14 décembre 2021 à 17:22 +, Petter Tomner via Jit a
> > écrit :
> > > Hi!
> > >
> > > I have pushed the patch for rvalue initialization and ctors for
> > > libgccjit, for ABI 19.
> > >
> > > Please see attached patch.
> > >
> > > Regards,
> > > Petter
> > >
> >
> >
>
>
SV: [commited] jit: Support for global rvalue initialization and constructors
Could you be more specific? I tried the equivalent of:
/*int [50] foobar = {1,2,3,4};
int [50] foo() { int arr[50];
arr = (int [50]){-1,-2,-3,-4,-5,-6};
arr = foobar;
arr = (int [50]){1,2,3,4,5,6};
arr[6] = 1234;
return arr;}
N.B: Not a typo, returning an array.
*/
in test-local-init-rvalue.c with a global and local "arr" and it ran fine. (See
attachment).
Regards, Petter
Från: Antoni Boucher
Skickat: den 29 december 2021 23:45
Till: Petter Tomner; David Malcolm; j...@gcc.gnu.org; gcc-patches@gcc.gnu.org
Ämne: Re: [commited] jit: Support for global rvalue initialization and
constructors
I realized that trying to do an assignment to an array created by the
new array constructor API will result in a "gimplification failed"
error:
libgccjit.so: error: gimplification failed
0x7fa3a441e5d3 gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int)
../../../gcc/gcc/gimplify.c:15964
0x7fa3a442b1ab gimplify_modify_expr
../../../gcc/gcc/gimplify.c:5975
0x7fa3a441ac4c gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int)
../../../gcc/gcc/gimplify.c:14951
0x7fa3a441e63c gimplify_stmt(tree_node**, gimple**)
../../../gcc/gcc/gimplify.c:7026
0x7fa3a441bca3 gimplify_statement_list
../../../gcc/gcc/gimplify.c:2014
0x7fa3a441bca3 gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int)
../../../gcc/gcc/gimplify.c:15396
0x7fa3a441e63c gimplify_stmt(tree_node**, gimple**)
../../../gcc/gcc/gimplify.c:7026
0x7fa3a441f000 gimplify_bind_expr
../../../gcc/gcc/gimplify.c:1427
0x7fa3a441adc6 gimplify_expr(tree_node**, gimple**, gimple**, bool
(*)(tree_node*), int)
../../../gcc/gcc/gimplify.c:15152
0x7fa3a441e63c gimplify_stmt(tree_node**, gimple**)
../../../gcc/gcc/gimplify.c:7026
0x7fa3a4420671 gimplify_body(tree_node*, bool)
../../../gcc/gcc/gimplify.c:16197
0x7fa3a4420b3c gimplify_function_tree(tree_node*)
../../../gcc/gcc/gimplify.c:16351
0x7fa3a419fe5e gcc::jit::playback::function::postprocess()
../../../gcc/gcc/jit/jit-playback.c:1909
0x7fa3a41a13dc gcc::jit::playback::context::replay()
../../../gcc/gcc/jit/jit-playback.c:3250
Should an assignment to such a value be supported?
Le mercredi 15 décembre 2021 à 19:19 +, Petter Tomner a écrit :
> Oh ye I accidentally dropped that in the merge thank you.
>
> I believe there is an implicit "global:" in the top of each version
> scope, so it shouldn't
> matter other than looking a bit deviant.
>
> Regards,
> Petter
>
> Från: Antoni Boucher
> Skickat: den 15 december 2021 15:19
> Till: Petter Tomner; David Malcolm; j...@gcc.gnu.org;
> gcc-patches@gcc.gnu.org
> Ämne: Re: [commited] jit: Support for global rvalue initialization
> and constructors
>
> Hi Petter.
> I believe you have forgotten the line `global:` in the file
> `gcc/jit/libgccjit.map`.
> I'm not sure what this line does, but it is there for all other ABI.
> David: What do you think?
> Regards.
>
> Le mardi 14 décembre 2021 à 17:22 +, Petter Tomner via Jit a
> écrit :
> > Hi!
> >
> > I have pushed the patch for rvalue initialization and ctors for
> > libgccjit, for ABI 19.
> >
> > Please see attached patch.
> >
> > Regards,
> > Petter
> >
>
>
diff --git a/gcc/testsuite/jit.dg/test-local-init-rvalue.c b/gcc/testsuite/jit.dg/test-local-init-rvalue.c
index 1d74679c07c..308f5c39538 100644
--- a/gcc/testsuite/jit.dg/test-local-init-rvalue.c
+++ b/gcc/testsuite/jit.dg/test-local-init-rvalue.c
@@ -456,12 +456,42 @@ create_code (gcc_jit_context *ctxt, void *user_data)
0,
gcc_jit_lvalue_as_rvalue(local));
}
- { /* int[50] foo() { int arr[50];
+ { /* int [50] foobar = {1,2,3,4};
+ int[50] foo() { int arr[50];
+ arr = (int [50]){-1,-2,-3,-4,-5,-6};
+ arr = foobar;
arr = (int [50]){1,2,3,4,5,6};
+ arr[6] = 1234;
return arr;}
N.B: Not a typo, returning an array.
*/
+
+gcc_jit_rvalue *rval_1 = gcc_jit_context_new_rvalue_from_int (
+ ctxt, int_type, 1);
+gcc_jit_rvalue *rval_2 = gcc_jit_context_new_rvalue_from_int (
+ ctxt, int_type, 2);
+gcc_jit_rvalue *rval_3 = gcc_jit_context_new_rvalue_from_int (
+ ctxt, int_type, 3);
+gcc_jit_rvalue *rval_4 = gcc_jit_context_new_rvalue_from_int (
+ ctxt, int_type, 4);
+
+gcc_jit_rvalue *values4[] = {rval_1, rval_2, rval_3, rval_4};
+
+gcc_jit_rvalue *ctor3 =
+ gcc_jit_context_new_array_constructor (ctxt,
+ 0,
+ int50arr_type,
+ 4,
+ values4);
+gcc_jit_lvalue *global_intarr_1234 =
+ gcc_jit_context_new_global (ctxt, NULL,
+ GCC_JIT_GLOBAL_EXPORTED,
+ int50arr_type,
+ "foobar");
+
+gcc_jit_global_set_initializer_rvalue (global_intarr_1234, ctor3);
+
SV: [commited] jit: Support for global rvalue initialization and constructors
Oh ye I accidentally dropped that in the merge thank you. I believe there is an implicit "global:" in the top of each version scope, so it shouldn't matter other than looking a bit deviant. Regards, Petter Från: Antoni Boucher Skickat: den 15 december 2021 15:19 Till: Petter Tomner; David Malcolm; j...@gcc.gnu.org; gcc-patches@gcc.gnu.org Ämne: Re: [commited] jit: Support for global rvalue initialization and constructors Hi Petter. I believe you have forgotten the line `global:` in the file `gcc/jit/libgccjit.map`. I'm not sure what this line does, but it is there for all other ABI. David: What do you think? Regards. Le mardi 14 décembre 2021 à 17:22 +, Petter Tomner via Jit a écrit : > Hi! > > I have pushed the patch for rvalue initialization and ctors for > libgccjit, for ABI 19. > > Please see attached patch. > > Regards, > Petter >
SV: SV: [PATCH v2] jit: Add support for global rvalue initialization and ctors
Hi! Thanks for the review. Having proper grammar in user facing text is important so I in no way feel it is overzealous. I'll push the patch once I fixed the points mentioned in the review. Regards, Petter Från: David Malcolm Skickat: den 13 december 2021 20:22 Till: Antoni Boucher; Petter Tomner; gcc-patches@gcc.gnu.org; j...@gcc.gnu.org Ämne: Re: SV: [PATCH v2] jit: Add support for global rvalue initialization and ctors On Sun, 2021-12-12 at 20:39 -0500, Antoni Boucher wrote: > Yes, this patch works for rustc_codegen_gcc perfectly. > It even fixes one issue that was in my patch, so that's nice! Excellent - thanks Antoni. > > Le samedi 11 décembre 2021 à 15:35 +, Petter Tomner a écrit : > > Hi! > > > > > s/an union/a union/ > > > s/a rvalue/an rvalue/ > > > > Heh no way ... and I though I knew English grammar :) I apologize for the non-regularity of English :) [and it's somewhat unfair for me to nit-pick, given that it's my first language - sorry; we may as well get this stuff correct] > > > > Had to look that up to see what the deal was but it makes sense. > > > > yunion, arevalue. Exactly. English spelling is a mess. > > > > > s/wrong-field-name/wrong-field-obj/ > > > > > > to match the struct example (given that the issue being tested > > > for > > > is > > > that it's the wrong object, rather than the wrong name). > > > > Initially, before submitting to the list, I made the code such that > > the field > > objects did not have to be the ones that were used when creating > > the > > struct or union, and forgot changing the test names. > > > > I figured it required too much string compares for the field names > > and > > pointer compares for the field object were more appropriate. To > > create > > dummy field objects were also kinda heavy. > > > > I'll address the points. Petter, you can go ahead and commit this, once you address the various points from my earlier review, and from Antoni's observation that "flags" should be "m_flags" when it's a member. Antoni has committed at least one ABI version bump since you posted this, so you'll need to rebase your work on top of his and adjust accordingly. Please re-test the patch before pushing it. Thanks for all your great work on this. Dave
SV: [PATCH v2] jit: Add support for global rvalue initialization and ctors
Hi! > s/an union/a union/ > s/a rvalue/an rvalue/ Heh no way ... and I though I knew English grammar :) Had to look that up to see what the deal was but it makes sense. yunion, arevalue. > s/wrong-field-name/wrong-field-obj/ > > to match the struct example (given that the issue being tested for is > that it's the wrong object, rather than the wrong name). Initially, before submitting to the list, I made the code such that the field objects did not have to be the ones that were used when creating the struct or union, and forgot changing the test names. I figured it required too much string compares for the field names and pointer compares for the field object were more appropriate. To create dummy field objects were also kinda heavy. I'll address the points. Regards, Petter Från: David Malcolm Skickat: den 9 december 2021 20:39 Till: Petter Tomner; gcc-patches@gcc.gnu.org; j...@gcc.gnu.org; Antoni Boucher Ämne: Re: [PATCH v2] jit: Add support for global rvalue initialization and ctors On Mon, 2021-12-06 at 10:47 +0000, Petter Tomner via Gcc-patches wrote: > Hi! > > Attached is a patch with changes in line with the review of the prior > patch. > The patch adds support for initialization of global variables with > rvalues as well > as rvalue constructors for structs, arrays and unions. Thanks for the updated patch. Antoni: does this patch work for you for your rustc plugin? > > Review: https://gcc.gnu.org/pipermail/jit/2021q4/001400.html > > The points have been addressed, except: > > > Can the type be made const? > > I started to make types_kinda_same_internal () taking const args, but I > felt the > patch was ballooning because some spread out methods needed a const > signature too. I could submit that in a separate patch. Fair enough; fixing that isn't a blocker; it's already a big patch. > > I also addressed a problem Antoni found: > https://gcc.gnu.org/pipermail/jit/2021q4/001399.html > > , where you could not initialize global pointer variables to point to > uninitialized variables. I did that by > removing a redundant check with validate_var_has_init (), since that > walking function would > have to be quite complex to allow pointers to uninitialized variables. > > Any: > const int foo; > int bar = foo; > > will instead be reported as "not compile time constant" instead of a > nice error message with names. > > make check-jit runs fine on gnu-linux-x64 Debian. Various review comments inline below, which are mostly just nits: > From a4fef1308eaa72ce4ec51dbe5efcfbbf032e9870 Mon Sep 17 00:00:00 2001 > From: Petter Tomner > Date: Mon, 29 Nov 2021 20:44:07 +0100 > Subject: [PATCH] Add support for global rvalue initialization and constructors > > This patch adds support for initialization of global variables > with rvalues and creating constructors for array, struct and > union types which can be used as rvalues. > > Signed-off-by: > 2021-12-06 Petter Tomner [...snip...] > diff --git a/gcc/jit/docs/topics/expressions.rst > b/gcc/jit/docs/topics/expressions.rst > index 396259ef07e..5f64ca68595 100644 > --- a/gcc/jit/docs/topics/expressions.rst > +++ b/gcc/jit/docs/topics/expressions.rst > @@ -126,6 +126,147 @@ Simple expressions > underlying string, so it is valid to pass in a pointer to an on-stack > buffer. > > +Constructor expressions > +*** > + > + The following functions make constructors for array, struct and union > + types. > + > + The constructor rvalue can be used for assignment to locals. > + It can be used to initialize global variables with > + :func:`gcc_jit_global_set_initializer_rvalue`. It can also be used as a > + temporary value for function calls and return values, but its address > + can't be taken. > + > + Note that arrays in libgccjit does not collapse to pointers like in s/does not/do not/ > + C. I.e. if an array constructor is used as e.g. a return value, the whole > + array would be returned by value - array constructors can be assigned to > + array variables. > + > + The constructor can contain nested constructors. > + > + Note that a string literal rvalue can't be used to construct a char array. > + It need one rvalue for each char. s/char array. It need one rvalue/char array; the latter needs one rvalue/ > + > + These entrypoints were added in :ref:`LIBGCCJIT_ABI_16`; you can test for > its s/16/17/ I believe. s/its/their/ > + presense using: s/presense/presence/ (and in various other places below) > + .. code-block:: c > + #ifdef LIBGCCJIT_HAVE_CTORS > + > +.. function:: gcc_jit_rvalue *\ > +
[commited] jit: Change printf specifiers for size_t to %zu
Hi! I've pushed a fix for %ld as printf specifiers for size_t which made 32bit builds sad, as per Gerald Pfeifers mail to the list: https://gcc.gnu.org/pipermail/jit/2021q4/001395.html %ld changed to %zu in four places in libgccjit.c. Please note that I considered this patch a "free for all" since it is trivial and rather annoying on 32bit computers and I pushed without prior approval from the jit maintainer (D. Malcolm). make check-jit runs cleanly on gnu-linux-debian x64 and in a x86 VM. Regards, PetterFrom 1e53408452448cdfa5481e25e470946c2c472539 Mon Sep 17 00:00:00 2001 From: Petter Tomner Date: Sat, 27 Nov 2021 15:52:15 +0100 Subject: [PATCH] jit: Change printf specifiers for size_t to %zu Change four occurances of %ld specifier for size_t to %zu for clean 32bit builds. Signed-off-by 2021-11-27 Petter Tomner gcc/jit/ * libgccjit.c: %ld -> %zu --- gcc/jit/libgccjit.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gcc/jit/libgccjit.c b/gcc/jit/libgccjit.c index c744b634f4b..5d051e43e1e 100644 --- a/gcc/jit/libgccjit.c +++ b/gcc/jit/libgccjit.c @@ -707,7 +707,7 @@ gcc_jit_function_type_get_param_type (gcc_jit_function_type *function_type, gcc::jit::recording::context *ctxt = function_type->m_ctxt; RETURN_NULL_IF_FAIL_PRINTF3 (index < num_params, ctxt, NULL, - "index of %ld is too large (%s has %ld params)", + "index of %zu is too large (%s has %zu params)", index, function_type->get_debug_string (), num_params); @@ -951,7 +951,7 @@ gcc_jit_struct_get_field (gcc_jit_struct *struct_type, size_t num_fields = struct_type->get_fields ()->length (); RETURN_NULL_IF_FAIL_PRINTF3 (index < num_fields, NULL, NULL, - "index of %ld is too large (%s has %ld fields)", + "index of %zu is too large (%s has %zu fields)", index, struct_type->get_debug_string (), num_fields); -- 2.30.2
SV: [PATCH] libgccjit: add some reflection functions in the jit C api
Hi!
+gcc_jit_type *
+gcc_jit_type_unqualified (gcc_jit_type *type)
+{
+ RETURN_NULL_IF_FAIL (type, NULL, NULL, "NULL type");
+
+ return (gcc_jit_type *)type->unqualified ();
+}
I think there is a problem with the current implementation of unqualified()
that might be kinda surprising to
users, since it only removes one qualifier and also not "pointed to" qualifiers.
Unrelated to this patch that behavior should probably be documented, since it
effects many entry-points
and makes cast to base type kinda mandatory when qualified types are mixed.
Casts uses a recursive
check of types and is happy to cast any pointer to any pointer (no matter the
level of pointerness) so
they work.
I guess the casts should get some shortcircuit for casts between same base
types really,
to not bloat the GENERIC tree.
I made a utility function in another patch for comparing types that do full
stripping (see bellow).
Maybe something like that could be usefull?
jit-recording.h:
+/* Strip all qualifiers and count pointer depth, returning true
+ if the types and pointer depth are the same, otherwise false. */
+static inline bool
+types_kinda_same (recording::type *a, recording::type *b)
+{
+ /* Handle trivial case here, to allow for inlining. */
+ return a == b || types_kinda_same_internal (a, b);
+}
jit-recording.c:
+/* Strip qualifiers and count pointer depth, returning true
+ if the types' base type and pointer depth are
+ the same, otherwise false.
+
+ Do not call this directly. Call 'types_kinda_same' */
+bool
+types_kinda_same_internal (recording::type *a, recording::type *b)
+{
+ int ptr_depth[2] = {};
+ recording::type *base_types[2];
+ recording::type *types[2] = {a, b};
+
+ /* Strip qualifiers and count pointerness */
+ for (int i = 0; i < 2; i++)
+{
+ recording::type *t = types[i];
+ while (true)
+ {
+ if (!t)
+ return false; /* Should only happen on bad input */
+
+ recording::type *pointed_to_type = t->is_pointer();
+ if (pointed_to_type != NULL)
+ {
+ ptr_depth[i]++;
+ t = pointed_to_type;
+ continue;
+ }
+
+ /* unqualified() returns 'this' on base types */
+ recording::type *next = t->unqualified ();
+ if (next == t)
+ {
+ base_types[i] = t;
+ break;
+ }
+ t = next;
+ }
+}
+
+ return base_types[0] == base_types[1] &&
+(ptr_depth[0] == ptr_depth[1]);
+}
Från: Jit för Antoni Boucher via Jit
Skickat: den 13 oktober 2021 04:09
Till: David Malcolm
Kopia: Antoni Boucher via Jit; gcc-patches@gcc.gnu.org
Ämne: Re: [PATCH] libgccjit: add some reflection functions in the jit C api
David: PING
Le lundi 27 septembre 2021 à 20:53 -0400, Antoni Boucher a écrit :
> I fixed an issue (it would show an error message when
> gcc_jit_type_dyncast_function_ptr_type was called on a type different
> than a function pointer type).
>
> Here's the updated patch.
>
> Le vendredi 18 juin 2021 à 16:37 -0400, David Malcolm a écrit :
> > On Fri, 2021-06-18 at 15:41 -0400, Antoni Boucher wrote:
> > > I have write access now.
> >
> > Great.
> >
> > > I'm not sure how I'm supposed to send my patches:
> > > should I put it in personal branches and you'll merge them?
> >
> > Please send them to this mailing list for review; once they're
> > approved
> > you can merge them.
> >
> > >
> > > And for the MAINTAINERS file, should I just push to master right
> > > away,
> > > after sending it to the mailing list?
> >
> > I think people just push the MAINTAINERS change and then let the
> > list
> > know, since it makes a good test that write access is working
> > correctly.
> >
> > Dave
> >
> > >
> > > Thanks for your help!
> > >
> > > Le vendredi 18 juin 2021 à 12:09 -0400, David Malcolm a écrit :
> > > > On Fri, 2021-06-18 at 11:55 -0400, Antoni Boucher wrote:
> > > > > Le vendredi 11 juin 2021 à 14:00 -0400, David Malcolm a
> > > > > écrit :
> > > > > > On Fri, 2021-06-11 at 08:15 -0400, Antoni Boucher wrote:
> > > > > > > Thank you for your answer.
> > > > > > > I attached the updated patch.
> > > > > >
> > > > > > BTW you (or possibly me) dropped the mailing lists; was
> > > > > > that
> > > > > > deliberate?
> > > > >
> > > > > Oh, my bad.
> > > > >
> > > >
> > > > [...]
> > > >
> > > >
> > > > > >
> > > > > >
> > > > > > > I have signed the FSF copyright attribution.
> > > > > >
> > > > > > I can push changes on your behalf, but I'd prefer it if you
> > > > > > did
> > > > > > it,
> > > > > > especially given that you have various other patches you
> > > > > > want
> > > > > > to
> > > > > > get
> > > > > > in.
> > > > > >
> > > > > > Instructions on how to get push rights to the git repo are
> > > > > > here:
> > > > > > https://gcc.gnu.org/gitwrite.html
> > > > > >
> > > > > > I can sponsor you.
> > > > >
> > > > > Thanks.
> > > > > I did sign up to get push rights.
> > > > > Have you
[PATCH 2/2] jit: Complex types and loong constants
This patch adds the possibility to make the following constants: * long long * long double * complex long double The long long one is needed for 32bit systems. The new entrypoints are: gcc_jit_context_new_rvalue_from_long_long gcc_jit_context_new_rvalue_from_long_double gcc_jit_context_new_rvalue_from_complex_long_double The patch also fixes a issue with the reproducer's debug c-file writer, which does not handle floating point numbers very well. I.e. infs, NaN and losing precision on doubles. make check-jit runs fine with the patch series on Debian 64x. See attachment.From f49cea6830b08a019958ef3f6a1ced1e416f80b3 Mon Sep 17 00:00:00 2001 From: Petter Tomner Date: Sat, 16 Oct 2021 21:55:20 +0200 Subject: [PATCH 2/3] long long Add long long, long double and complex long double constants This patch adds entrypoints to make constants (literals) for long long, long double and complex long double types. Also, it fixes problems with all floating point numbers in write_reproducer. I.e. support NAN and INF values, aswell as proper precision for double and long double. Which is needed for testing this patch. Signed-off-by: 2021-10-21 Petter Tomner gcc/jit/ * jit-playback.c : (new_rvalue_from_const ): New (new_rvalue_from_const ): Uses long long instead (new_rvalue_from_const ): New (new_rvalue_from_const <_Complex long double>) : New * jit-recording.c : (dump_reproducer_to_file) : Type punning NANs (reproducer_write_arr) : arr -> "char array literal"-string (memento_of_new_rvalue_from_const ) : New (memento_of_new_rvalue_from_const ) : New (memento_of_new_rvalue_from_const <_Complex long double>) : New (memento_of_new_rvalue_from_const ::make_debug_string): %g instead of %f (memento_of_new_rvalue_from_const ::write_reproducer): %a instead of %f, handle NAN and INF (memento_of_new_rvalue_from_const <_Complex double>::write_reproducer): %a instead of %f, handle NAN and INF. Use CMPLX macro. * libgccjit.c : * libgccjit.h : (LIBGCCJIT_HAVE_LONGLONG_CONSTANTS) : New (gcc_jit_context_new_rvalue_from_long_long) : New (gcc_jit_context_new_rvalue_from_long_double) : New (gcc_jit_context_new_rvalue_from_complex_long_double) : New * libgccjit++.h : New entrypoints * libgccjit.map: New entrypoints added to ABI 16 gcc/testsuite/ * jit.dg/all-non-failing-tests.h: Added test-long-literals.c * jit.dg/test-long-literals.c: New gcc/jit/docs/topics/ * expressions.rst : Updated docks --- gcc/jit/docs/topics/expressions.rst | 43 +- gcc/jit/jit-playback.c | 143 +- gcc/jit/jit-recording.c | 442 ++- gcc/jit/libgccjit++.h| 39 ++ gcc/jit/libgccjit.c | 46 ++ gcc/jit/libgccjit.h | 33 +- gcc/jit/libgccjit.map| 3 + gcc/testsuite/jit.dg/all-non-failing-tests.h | 7 + gcc/testsuite/jit.dg/test-long-literals.c| 283 9 files changed, 1017 insertions(+), 22 deletions(-) create mode 100644 gcc/testsuite/jit.dg/test-long-literals.c diff --git a/gcc/jit/docs/topics/expressions.rst b/gcc/jit/docs/topics/expressions.rst index a98f35572b4..30a3b9780f9 100644 --- a/gcc/jit/docs/topics/expressions.rst +++ b/gcc/jit/docs/topics/expressions.rst @@ -70,6 +70,18 @@ Simple expressions Given a numeric type (integer or floating point), build an rvalue for the given constant :c:type:`long` value. +.. function:: gcc_jit_rvalue *\ + gcc_jit_context_new_rvalue_from_long_long (gcc_jit_context *ctxt, \ + gcc_jit_type *numeric_type, \ + long long value) + + Given a numeric type (integer or floating point), build an rvalue for + the given constant :c:type:`long long` value. + + This function was added in :ref:`LIBGCCJIT_ABI_16`; + you can test for its presence using + `#ifdef LIBGCCJIT_HAVE_LONGLONG_CONSTANTS` + .. function:: gcc_jit_rvalue *gcc_jit_context_zero (gcc_jit_context *ctxt, \ gcc_jit_type *numeric_type) @@ -98,6 +110,18 @@ Simple expressions Given a numeric type (integer or floating point), build an rvalue for the given constant :c:type:`double` value. +.. function:: gcc_jit_rvalue *\ + gcc_jit_context_new_rvalue_from_long_double (gcc_jit_context *ctxt, \ + gcc_jit_type *numeric_type, \ + long double value) + + Given a floating point type, build an rvalue for + the given constant :c:type:`long double`. + + This function was added in :ref:`LIBGCCJIT_ABI_16`; + you can test for its presence using + `#ifdef LIBGCCJIT_HAVE_LONGLONG_CONSTANTS` + .. function:: gcc_jit_rvalue *\ gcc_jit_context_new_rvalue_from_complex_double (gcc_jit_context *ctxt, \
[PATCH 1/2] jit: Complex types and loong constants
This patch fixes support for complex types. It adds the entrypoints: gcc_jit_context_new_rvalue_from_complex_double gcc_jit_context_set_bool_enable_complex_types Aswell as the binary operator GCC_JIT_BINARY_OP_COMPLEX, to make complex numbers from two real number rvalues. Note that the complex types already are in the type enum, so I thought the cleanest solution is to enable them, rather than to have a "get_complex_type" function. See attachement.From 6d5d7ce40f9bb84a7943e5113c8954ae4b941905 Mon Sep 17 00:00:00 2001 From: Petter Tomner Date: Fri, 15 Oct 2021 20:16:54 +0200 Subject: [PATCH 1/3] Complex Fix support for complex types The patch adds support of complex floating point types to libgccjit. A new binary operator 'COMPLEX' is added to create complex values from real values. Aswell as a function to create a complex double literal. To notify users if a binary linking to libgccjit depends on complex types, complex type support most be enabled with a new option function since they allready are in the types enum. Signed-off-by: 2021-10-21 Petter Tomner gcc/jit/ * jit-common.h : (INNER_BOOL_OPTION_ENABLE_COMPLEX_TYPES): New * jit-playback.c : Create imaginary literals, conversions (complex_real_to_real) : New (new_rvalue_from_const<...>) : Also build complex constants (new_rvalue_from_const <_Complex double>) : New (new_binary_op) : Add COMPLEX operator (build_cast) : Casts to complex (memento_of_new_rvalue_from_const <_Complex double>) : New (binary_op::make_debug_string) : Handle complex operator * jit-recording.c : Reproducer, debug strings, forwarding * jit-recording.h : (float_size_qual) : Poll size qualifier of float types (is_complex) : Poll if type is complex * libgccjit++.h : New entrypoints, see below * libgccjit.c : Implementation of new entry points, see .h (gcc_jit_context_get_type) : Extend range check, validation (valid_binary_op_p) : Extend range check (gcc_jit_context_new_binary_op) : Validation (gcc_jit_context_new_unary_op) : Validation (gcc_jit_context_new_comparison) : Validation * libgccjit.h : (gcc_jit_context_new_rvalue_from_complex_double) : New (GCC_JIT_BINARY_OP_COMPLEX) : New (LIBGCCJIT_HAVE_COMPLEX) : New (gcc_jit_context_set_bool_enable_complex_types) : New * libgccjit.map : Added new entrypoints (LIBGCCJIT_ABI_16) : New gcc/testsuite/ * jit.dg/test-complex-builtins.c : New * jit.dg/test-complex-literals.c : New * jit.dg/test-complex-misc.c : New * jit.dg/test-complex-operators.c : New * jit.dg/test-complex-types.c : New * jit.dg/test-error-complex-noenable.c : New gcc/jit/docs/topics/ * contexts.rst : Update docs * expressions.rst * types.rst --- gcc/jit/docs/topics/contexts.rst | 20 + gcc/jit/docs/topics/expressions.rst | 89 ++- gcc/jit/docs/topics/types.rst | 12 +- gcc/jit/jit-common.h | 1 + gcc/jit/jit-playback.c| 165 - gcc/jit/jit-recording.c | 126 +++- gcc/jit/jit-recording.h | 28 + gcc/jit/libgccjit++.h | 21 + gcc/jit/libgccjit.c | 97 ++- gcc/jit/libgccjit.h | 44 +- gcc/jit/libgccjit.map | 6 + gcc/testsuite/jit.dg/all-non-failing-tests.h | 30 + gcc/testsuite/jit.dg/test-complex-builtins.c | 217 ++ gcc/testsuite/jit.dg/test-complex-literals.c | 145 gcc/testsuite/jit.dg/test-complex-misc.c | 204 ++ gcc/testsuite/jit.dg/test-complex-operators.c | 353 + gcc/testsuite/jit.dg/test-complex-types.c | 677 ++ .../jit.dg/test-error-complex-noenable.c | 31 + 18 files changed, 2221 insertions(+), 45 deletions(-) create mode 100644 gcc/testsuite/jit.dg/test-complex-builtins.c create mode 100644 gcc/testsuite/jit.dg/test-complex-literals.c create mode 100644 gcc/testsuite/jit.dg/test-complex-misc.c create mode 100644 gcc/testsuite/jit.dg/test-complex-operators.c create mode 100644 gcc/testsuite/jit.dg/test-complex-types.c create mode 100644 gcc/testsuite/jit.dg/test-error-complex-noenable.c diff --git a/gcc/jit/docs/topics/contexts.rst b/gcc/jit/docs/topics/contexts.rst index 00fb17e155d..d8689407cc6 100644 --- a/gcc/jit/docs/topics/contexts.rst +++ b/gcc/jit/docs/topics/contexts.rst @@ -489,6 +489,26 @@ Boolean options #ifdef LIBGCCJIT_HAVE_gcc_jit_context_set_bool_use_external_driver +.. function:: void\ + gcc_jit_context_set_bool_enable_complex_types (gcc_jit_context *ctxt,\ + int bool_value); + + This option can enable complex type support in libgccjit. By default, + no complex types can be used. + + If you use complex types, it is recommended to use builtin functions + `creal`, `cimag` and `conj` etc. with the correct type suffix, since + those are inlined into the code,
[PATCH 0/2] jit: Complex types and loong constants
Hi, These two patches fixes support for complex types and adds the possibility to make long long, long double and complex long double constants. Please see follow up mails. Regards,
[PATCH 2/2] jit: Add support for complex types
>From a833639e6dfe9ff44b1084b5a5cbbf477d023cf5 Mon Sep 17 00:00:00 2001 From: Petter Tomner Date: Tue, 14 Sep 2021 23:52:06 +0200 Subject: [PATCH 2/2] jit: Testcases and documentation for complex types Will squash with path 1 Signed-off-by: 2021-09-15 Petter Tomner gcc/jit/docs/topics/ * gcc/jit/docs/topics/contexts.rst Updated docs * gcc/jit/docs/topics/expressions.rst * gcc/jit/docs/topics/types.rst * test-complex-builtins.c New * test-complex-literals.c New * test-complex-misc.c New * test-complex-operators.c New * test-complex-types.c New --- gcc/jit/docs/topics/contexts.rst | 20 + gcc/jit/docs/topics/expressions.rst | 89 ++- gcc/jit/docs/topics/types.rst | 12 +- gcc/testsuite/jit.dg/all-non-failing-tests.h | 30 + gcc/testsuite/jit.dg/test-complex-builtins.c | 217 ++ gcc/testsuite/jit.dg/test-complex-literals.c | 145 gcc/testsuite/jit.dg/test-complex-misc.c | 206 ++ gcc/testsuite/jit.dg/test-complex-operators.c | 353 + gcc/testsuite/jit.dg/test-complex-types.c | 677 ++ 9 files changed, 1720 insertions(+), 29 deletions(-) create mode 100644 gcc/testsuite/jit.dg/test-complex-builtins.c create mode 100644 gcc/testsuite/jit.dg/test-complex-literals.c create mode 100644 gcc/testsuite/jit.dg/test-complex-misc.c create mode 100644 gcc/testsuite/jit.dg/test-complex-operators.c create mode 100644 gcc/testsuite/jit.dg/test-complex-types.c diff --git a/gcc/jit/docs/topics/contexts.rst b/gcc/jit/docs/topics/contexts.rst index 00fb17e155d..42fdef7c654 100644 --- a/gcc/jit/docs/topics/contexts.rst +++ b/gcc/jit/docs/topics/contexts.rst @@ -489,6 +489,26 @@ Boolean options #ifdef LIBGCCJIT_HAVE_gcc_jit_context_set_bool_use_external_driver +.. function:: void\ + gcc_jit_context_set_bool_enable_complex_types (gcc_jit_context *ctxt, \ + int bool_value); + + This option can enable complex type support in libgccjit. By default, + no complex types can be used. + + If you use complex types, it is recommended to use builtin functions + `creal`, `cimag` and `conj` etc. with the correct type suffix, since + those are inlined into the code, rather then imported functions from + the math lib which are not. See :ref:`gcc_jit_context_get_builtin_function`. + + This entrypoint was added in :ref:`LIBGCCJIT_ABI_16`; you can test for + its presence using + + .. code-block:: c + + #ifdef LIBGCCJIT_HAVE_COMPLEX + + Integer options *** diff --git a/gcc/jit/docs/topics/expressions.rst b/gcc/jit/docs/topics/expressions.rst index 396259ef07e..fc0345c3e1d 100644 --- a/gcc/jit/docs/topics/expressions.rst +++ b/gcc/jit/docs/topics/expressions.rst @@ -98,6 +98,15 @@ Simple expressions Given a numeric type (integer or floating point), build an rvalue for the given constant :c:type:`double` value. +.. function:: gcc_jit_rvalue *\ + gcc_jit_context_new_rvalue_from_complex_double (gcc_jit_context *ctxt, \ + gcc_jit_type *numeric_type, \ + _Complex double value) + + Given a floating point type, build an rvalue for + the given constant :c:type:`_Complex double`. When the result type is + non-complex, the imaginary part is discarded. + .. function:: gcc_jit_rvalue *\ gcc_jit_context_new_rvalue_from_ptr (gcc_jit_context *ctxt, \ gcc_jit_type *pointer_type, \ @@ -168,14 +177,14 @@ Unary Operations The available unary operations are: -== -Unary Operation C equivalent -== -:c:macro:`GCC_JIT_UNARY_OP_MINUS` `-(EXPR)` -:c:macro:`GCC_JIT_UNARY_OP_BITWISE_NEGATE` `~(EXPR)` -:c:macro:`GCC_JIT_UNARY_OP_LOGICAL_NEGATE` `!(EXPR)` -:c:macro:`GCC_JIT_UNARY_OP_ABS` `abs (EXPR)` -== +== == +Unary Operation C equivalent Supported types +== == +:c:macro:`GCC_JIT_UNARY_OP_MINUS` `-(EXPR)` integer, real, complex +:c:macro:`GCC_JIT_UNARY_OP_BITWISE_NEGATE` `~(EXPR)` integer +:c:macro:`GCC_JIT_UNARY_OP_LOGICAL_NEGATE` `!(EXPR)` integer +:c:macro:`GCC_JIT_UNARY_OP_ABS` `abs (EXPR)` integer, real +== == .. c:macro:: GCC_JIT_UNARY_OP_MINUS @@ -235,22 +244,23 @@ Binary Operations The available binary operations
[PATCH 1/2] jit: Add support for complex types
>From ff47bbec5a833b4470cae7cb636a5fbf31c6432e Mon Sep 17 00:00:00 2001
From: Petter Tomner
Date: Tue, 14 Sep 2021 23:51:41 +0200
Subject: [PATCH 1/2] jit: Support for complex types
The patch adds support of complex floating point types to libgccjit.
A new binary operator 'COMPLEX' is added to create complex values
from real values. Aswell as a function to create a complex double
literal.
To notify users if a binary linking to libgccjit depends on complex
types, complex type support most be enabled with a new option function.
Signed-off-by:
2021-09-15 Petter Tomner
gcc/jit/
* jit-common.h (INNER_BOOL_OPTION_ENABLE_COMPLEX_TYPES): new
* jit-playback.c Create imaginary literals, conversions
* jit-recording.c Reproducer, debug strings, forwarding
* jit-recording.h
(float_size_qual): Poll size qualifier of float types
(is_complex): Poll if type is complex
* libgccjit++.h New entrypoints, see below
* libgccjit.c Implementation of new entry points
(gcc_jit_context_get_type): Extend range check, validation
(valid_binary_op_p): Extend range check
(gcc_jit_context_new_binary_op): Validation
(gcc_jit_context_new_unary_op): Validation
(gcc_jit_context_new_comparison): Validation
* libgccjit.h
(gcc_jit_context_new_rvalue_from_complex_double): New
(GCC_JIT_BINARY_OP_COMPLEX): New
(LIBGCCJIT_HAVE_COMPLEX): New
(gcc_jit_context_set_bool_enable_complex_types): New
* libgccjit.map Added new entrypoints
(LIBGCCJIT_ABI_16): New
---
gcc/jit/jit-common.h| 1 +
gcc/jit/jit-playback.c | 165 ++--
gcc/jit/jit-recording.c | 116 +++-
gcc/jit/jit-recording.h | 28 +++
gcc/jit/libgccjit++.h | 23 +-
gcc/jit/libgccjit.c | 97 ++-
gcc/jit/libgccjit.h | 45 ++-
gcc/jit/libgccjit.map | 6 ++
8 files changed, 468 insertions(+), 13 deletions(-)
diff --git a/gcc/jit/jit-common.h b/gcc/jit/jit-common.h
index f88e6755b00..bc0453fba05 100644
--- a/gcc/jit/jit-common.h
+++ b/gcc/jit/jit-common.h
@@ -198,6 +198,7 @@ enum inner_bool_option
{
INNER_BOOL_OPTION_ALLOW_UNREACHABLE_BLOCKS,
INNER_BOOL_OPTION_USE_EXTERNAL_DRIVER,
+ INNER_BOOL_OPTION_ENABLE_COMPLEX_TYPES,
NUM_INNER_BOOL_OPTIONS
};
diff --git a/gcc/jit/jit-playback.c b/gcc/jit/jit-playback.c
index 59399dee251..8e4971958c3 100644
--- a/gcc/jit/jit-playback.c
+++ b/gcc/jit/jit-playback.c
@@ -40,6 +40,7 @@ along with GCC; see the file COPYING3. If not see
#include "gcc.h"
#include "diagnostic.h"
#include "stmt.h"
+#include "complex.h"
#include
@@ -78,6 +79,8 @@ convert (tree dst_type, tree expr)
case INTEGER_TYPE:
case ENUMERAL_TYPE:
return fold (convert_to_integer (dst_type, expr));
+case REAL_TYPE:
+ return fold (convert_to_real (dst_type, expr));
default:
gcc_assert (gcc::jit::active_playback_ctxt);
@@ -679,6 +682,24 @@ new_global_initialized (location *loc,
namespace playback
{
+/* Return the corrensponding not complex float type of a
+ float type. I.e. complex float -> float */
+static tree
+complex_real_to_real (tree complex_type)
+{
+ if (TYPE_CANONICAL (complex_type) ==
+TYPE_CANONICAL (complex_float_type_node))
+return float_type_node;
+ else if (TYPE_CANONICAL (complex_type) ==
+ TYPE_CANONICAL (complex_double_type_node))
+return double_type_node;
+ else if (TYPE_CANONICAL (complex_type) ==
+ TYPE_CANONICAL (complex_long_double_type_node))
+return long_double_type_node;
+ else
+gcc_unreachable();
+}
+
/* Specialization of making an rvalue from a const, for host . */
template <>
@@ -694,6 +715,25 @@ new_rvalue_from_const (type *type,
tree inner = build_int_cst (inner_type, value);
return new rvalue (this, inner);
}
+ else if (COMPLEX_FLOAT_TYPE_P (inner_type))
+{
+ tree tree_real;
+ tree tree_imag;
+ tree real_type;
+ REAL_VALUE_TYPE real_value;
+ REAL_VALUE_TYPE imag_value;
+
+ real_type = complex_real_to_real (inner_type);
+
+ real_from_integer (_value, VOIDmode, value, SIGNED);
+ real_from_integer (_value, VOIDmode, 0, SIGNED);
+
+ tree_real = build_real (real_type, real_value);
+ tree_imag = build_real (real_type, imag_value);
+
+ tree inner = build_complex (inner_type, tree_real, tree_imag);
+ return new rvalue (this, inner);
+}
else
{
REAL_VALUE_TYPE real_value;
@@ -718,6 +758,25 @@ new_rvalue_from_const (type *type,
tree inner = build_int_cst (inner_type, value);
return new rvalue (this, inner);
}
+ else if (COMPLEX_FLOAT_TYPE_P (inner_type))
+{
+ tree tree_real;
+ tree tree_imag;
+ tree real_type;
+ REAL_VALUE_TYPE real_value;
+ REAL_VALUE_TYPE imag_value;
+
+ real_type =
[PATCH 0/2] jit: Add support for complex types
Hi! The following two patches adds support for complex types in libgccjit. The complex types already are in the types enum, however they are not usable. In the patch, to use complex types, the user need to call a option function enabling support. In this way, there will be a linking error if someone tries to use complex types and a too old libgccjit.so, instead of a cryptic out of range enum error message at runtime. Since the types already are in the enum, I saw no better way that wouldn't be confusing. Patch 1 is implementation and patch 2 is docs and testcases. check-jit runs fine on x64 Debian. Regards, Petter
[PATCH] MAINTAINERS: Adding myself to to DCO and write after approval
>From f75e52427846bc453544833b1d167f8568e7cfd8 Mon Sep 17 00:00:00 2001 From: Petter Tomner Date: Fri, 10 Sep 2021 21:37:00 +0200 Subject: [PATCH] MAINTAINERS: Adding myself to to DCO and write after approval 2020-09-10 Petter Tomner ChangeLog: * MAINTAINERS: Me added to DCO and write after approval --- MAINTAINERS | 2 ++ 1 file changed, 2 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index 6a1589c4705..1c2f3a1d830 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -635,6 +635,7 @@ Dinar Temirbulatov Kresten Krab Thorup Kai Tietz Ilya Tocar +Petter Tomner Philipp Tomsich Daniel Towner Konrad Trifunovic @@ -709,3 +710,4 @@ information. Jeff Law Gaius Mulley Trevor Saunders + Petter Tomner \ No newline at end of file -- 2.30.2
Sv: Sv: [PATCH 1/2 v2] jit : Generate debug info for variables
Hi,
I tested it on another machine over ssh and newer gdb:s (8.3+) clobbers the
output with color escapes so I had to disable colors
for the gdb session in jit.exp for the regex matching to work properly:
+verbose "Disable color styling in GDB newer then 8.3 (errors on older)"
+send "set style enabled off\n"
On pre 8.3 gdb:s that will be an ignored syntax error.
With that change it passes the check-jit test on that machine too.
=== jit Summary ===
# of expected passes12073
I squashed the patches and attached it to this mail (with the above change).
No, I don't have push rights to the GCC repo. Should I request it?
Regards,
Petter
-Ursprungligt meddelande-
Från: David Malcolm
Skickat: den 8 september 2021 14:49
Till: Petter Tomner ; gcc-patches@gcc.gnu.org; j...@gcc.gnu.org
Ämne: Re: Sv: [PATCH 1/2 v2] jit : Generate debug info for variables
On Tue, 2021-09-07 at 16:18 +0000, Petter Tomner via Gcc-patches wrote:
> I realized I still managed to mess up some WS. I have attached a patch
> that is the same, except fixes the WS issue underneath.
>
> Regards, Petter
>
> + FOR_EACH_VEC_ELT (m_globals, i, global)
> + rest_of_decl_compilation (global, true, true);
Thanks for the updated patch.
Looks good to me, assuming it's been tested successfully. It should be
combined with the testcase into a single commit when pushed.
Do you have push rights to the GCC git repo?
Dave
From ef4c2885f0d693254b9ba4a6c8eca6e2f1c4fc62 Mon Sep 17 00:00:00 2001
From: Petter Tomner
Date: Thu, 9 Sep 2021 00:50:06 +0200
Subject: [PATCH] libgccjit: Generate debug info for variables
Finalize declares via available helpers after location is set. Set
TYPE_NAME of primitives and friends to "int" etc. Debug info is now
set properly for variables.
Signed-off-by:
2021-09-09 Petter Tomner
gcc/jit/
* jit-playback.c: Moved global var processing to after loc handling.
Setting TYPE_NAME for fundamental types.
Using common functions for finalizing globals.
* jit-playback.h: New method init_types().
Changed get_tree_node_for_type() to method.
gcc/testsuite/jit.dg/
* test-error-array-bounds.c: Array is not unsigned
* jit.exp: Helper function
* test-debuginfo.c: New testcase
---
gcc/jit/jit-playback.c| 70 ++
gcc/jit/jit-playback.h| 5 ++
gcc/testsuite/jit.dg/jit.exp | 28
gcc/testsuite/jit.dg/test-debuginfo.c | 72 +++
.../jit.dg/test-error-array-bounds.c | 2 +-
5 files changed, 162 insertions(+), 15 deletions(-)
create mode 100644 gcc/testsuite/jit.dg/test-debuginfo.c
diff --git a/gcc/jit/jit-playback.c b/gcc/jit/jit-playback.c
index 79ac525e5df..59399dee251 100644
--- a/gcc/jit/jit-playback.c
+++ b/gcc/jit/jit-playback.c
@@ -165,7 +165,8 @@ gt_ggc_mx ()
/* Given an enum gcc_jit_types value, get a "tree" type. */
-static tree
+tree
+playback::context::
get_tree_node_for_type (enum gcc_jit_types type_)
{
switch (type_)
@@ -192,11 +193,7 @@ get_tree_node_for_type (enum gcc_jit_types type_)
return short_unsigned_type_node;
case GCC_JIT_TYPE_CONST_CHAR_PTR:
- {
- tree const_char = build_qualified_type (char_type_node,
- TYPE_QUAL_CONST);
- return build_pointer_type (const_char);
- }
+ return m_const_char_ptr;
case GCC_JIT_TYPE_INT:
return integer_type_node;
@@ -579,10 +576,6 @@ playback::lvalue *
playback::context::
global_finalize_lvalue (tree inner)
{
- varpool_node::get_create (inner);
-
- varpool_node::finalize_decl (inner);
-
m_globals.safe_push (inner);
return new lvalue (this, inner);
@@ -2952,9 +2945,7 @@ replay ()
{
JIT_LOG_SCOPE (get_logger ());
- m_const_char_ptr
-= build_pointer_type (build_qualified_type (char_type_node,
- TYPE_QUAL_CONST));
+ init_types ();
/* Replay the recorded events: */
timevar_push (TV_JIT_REPLAY);
@@ -2984,10 +2975,17 @@ replay ()
{
int i;
function *func;
-
+ tree global;
/* No GC can happen yet; process the cached source locations. */
handle_locations ();
+ /* Finalize globals. See how FORTRAN 95 does it in gfc_be_parse_file()
+ for a simple reference. */
+ FOR_EACH_VEC_ELT (m_globals, i, global)
+rest_of_decl_compilation (global, true, true);
+
+ wrapup_global_declarations (m_globals.address(), m_globals.length());
+
/* We've now created tree nodes for the stmts in the various blocks
in each function, but we haven't built each function's single stmt
list yet. Do so now. */
@@ -3081,6 +3079,50 @@ location_comparator (const void *lhs, const void *rhs)
return loc_lhs->get_column_num () - loc_rhs->get_column_num ();
}
+/* Initialize the NAME_TYPE of the primitive types as well as some
+ others. */
+void
+playback::context::
+init_types (
Sv: [PATCH 1/2 v2] jit : Generate debug info for variables
I realized I still managed to mess up some WS. I have attached a patch that is the same, except fixes the WS issue underneath. Regards, Petter + FOR_EACH_VEC_ELT (m_globals, i, global) +rest_of_decl_compilation (global, true, true); 0001-libgccjit-Generate-debug-info-for-variables-WS-fix.patch Description: 0001-libgccjit-Generate-debug-info-for-variables-WS-fix.patch
[PATCH 2/2 v2] jit : Generate debug info for variables, testcase
>From 87d081f6b4233446f8a45f76dfd674f1e0b6aafe Mon Sep 17 00:00:00 2001
From: Petter Tomner
Date: Sun, 5 Sep 2021 00:18:10 +0200
Subject: [PATCH 2/2] libgccjit: Test cases for debug info
Assure that debug info is available for a local and global variable and a
function
with GDB.
Signed-off-by:
2021-09-05 Petter Tomner
gcc/testsuite/jit.dg/
* jit.exp: Helper function
* test-debuginfo.c: New file
---
gcc/testsuite/jit.dg/jit.exp | 25 ++
gcc/testsuite/jit.dg/test-debuginfo.c | 72 +++
2 files changed, 97 insertions(+)
create mode 100644 gcc/testsuite/jit.dg/test-debuginfo.c
diff --git a/gcc/testsuite/jit.dg/jit.exp b/gcc/testsuite/jit.dg/jit.exp
index 005ba01601a..905ebe62fbd 100644
--- a/gcc/testsuite/jit.dg/jit.exp
+++ b/gcc/testsuite/jit.dg/jit.exp
@@ -377,6 +377,31 @@ proc dg-jit-set-exe-params { args } {
}
}
+# For test-debuginfo.c. Starts gdb, does cmds and checks the output against
match
+proc jit-check-debug-info { obj_file cmds match } {
+verbose "Checking debug info for $obj_file with match: $match"
+
+if { [catch {exec gdb -v} fid] } {
+verbose "No gdb seems to be in path. Can't check debug info. Reporting
'unsupported'."
+unsupported "No gdb seems to be in path. Can't check debug info"
+return
+}
+
+spawn gdb $obj_file
+
+foreach cmd $cmds {
+send $cmd
+}
+expect {
+-re $match { pass OK }
+default { fail FAIL }
+}
+
+# Quit gdb
+send "set confirm off\n"
+send "q\n"
+}
+
proc jit-dg-test { prog do_what extra_tool_flags } {
verbose "within jit-dg-test..."
verbose " prog: $prog"
diff --git a/gcc/testsuite/jit.dg/test-debuginfo.c
b/gcc/testsuite/jit.dg/test-debuginfo.c
new file mode 100644
index 000..49e8834a0ba
--- /dev/null
+++ b/gcc/testsuite/jit.dg/test-debuginfo.c
@@ -0,0 +1,72 @@
+/* Essentially this test checks that debug info are generated for globals
+ locals and functions, including type info. The comment bellow is used
+ as fake code (does not affect the test, use for manual debugging). */
+/*
+int a_global_for_test_debuginfo;
+int main (int argc, char **argv)
+{
+int a_local_for_test_debuginfo = 2;
+return a_global_for_test_debuginfo + a_local_for_test_debuginfo;
+}
+*/
+#include "libgccjit.h"
+
+/* We don't want set_options() in harness.h to set -O3 so our little local
+ is optimized away. */
+#define TEST_ESCHEWS_SET_OPTIONS
+static void set_options (gcc_jit_context *ctxt, const char *argv0)
+{
+gcc_jit_context_set_bool_option(ctxt, GCC_JIT_BOOL_OPTION_DEBUGINFO, 1);
+}
+
+#define TEST_COMPILING_TO_FILE
+#define OUTPUT_KIND GCC_JIT_OUTPUT_KIND_EXECUTABLE
+#define OUTPUT_FILENAME "jit-debuginfo.o"
+#include "harness.h"
+
+#define LOC(row, col) gcc_jit_context_new_location(ctxt, "test-debuginfo.c",
row, col)
+
+void
+create_code (gcc_jit_context *ctxt, void* p)
+{
+ gcc_jit_type *int_type = gcc_jit_context_get_type(ctxt, GCC_JIT_TYPE_INT);
+
+ gcc_jit_lvalue *bar = gcc_jit_context_new_global(ctxt,
+LOC(5,1), GCC_JIT_GLOBAL_EXPORTED,
+int_type, "a_global_for_test_debuginfo");
+
+ gcc_jit_param *argc_para = gcc_jit_context_new_param(ctxt, LOC(6,15),
+int_type, "argc");
+ gcc_jit_param *argv_para = gcc_jit_context_new_param(ctxt, LOC(6,28),
+gcc_jit_type_get_pointer(
+ gcc_jit_type_get_pointer(
+gcc_jit_context_get_type(ctxt, GCC_JIT_TYPE_CHAR))),
+"argc");
+
+ gcc_jit_param *params[] = {argc_para, argv_para};
+
+ gcc_jit_function *foo_fn = gcc_jit_context_new_function(ctxt, LOC(6,5),
+GCC_JIT_FUNCTION_EXPORTED, int_type, "main", 2, params, 0);
+ gcc_jit_block *start_block = gcc_jit_function_new_block(foo_fn,
+"start_block");
+
+ gcc_jit_lvalue *a = gcc_jit_function_new_local(foo_fn, LOC(8,5),
+int_type, "a_local_for_test_debuginfo");
+ gcc_jit_block_add_assignment(start_block, LOC(8,36), a,
+gcc_jit_context_new_rvalue_from_int(ctxt, int_type, 2));
+ gcc_jit_rvalue *add = gcc_jit_context_new_binary_op(ctxt, LOC(9,40),
+GCC_JIT_BINARY_OP_PLUS, int_type,
+gcc_jit_lvalue_as_rvalue(a), gcc_jit_lvalue_as_rvalue(bar));
+
+ gcc_jit_block_end_with_return(start_block, LOC(9,5), add);
+}
+
+#undef LOC
+
+/* jit-check-debug-info fires up gdb and checks that the variables have
+ debug info */
+
+/* { dg-final { jit-check-debug-info "jit-debuginfo.o" {"info variables\n"}
"int\\s+a_global_for_test_debuginfo;" } } */
+/* { dg-final { jit-check-debug-info "jit-debuginfo.o" {"pt main\n"}
"int\\s*\\(\\s*int\\s*,\\s*char\\s*\\*\\*\\s*\\)"} } */
+/* { dg-final { jit-check-debug-info "jit-debuginfo.o" {"start\n" "info
locals\n"} "a_local_for_test_debuginfo"} } */
+/* { dg-final { jit-check-debug-info "jit-debuginfo.o" {"start\n" "pt
a_local_for_test_debuginfo\n"} "int"} } */
\ No newline at end of file
--
2.20.1
[PATCH 1/2 v2] jit : Generate debug info for variables
>From 521349806136bef9096d094f4785f5868854a19d Mon Sep 17 00:00:00 2001
From: Petter Tomner
Date: Sat, 4 Sep 2021 23:55:34 +0200
Subject: [PATCH 1/2] libgccjit: Generate debug info for variables
Finalize declares via available helpers after location is set. Set
TYPE_NAME of primitives and friends to "int" etc. Debug info is now
set properly for variables.
Signed-off-by:
2021-09-05 Petter Tomner
gcc/jit/
* jit-playback.c: Moved global var processing to after loc handling.
Setting TYPE_NAME for fundamental types.
Using common functions for finalizing globals.
* jit-playback.h: New method init_types().
Changed get_tree_node_for_type() to method.
gcc/testsuite/jit.dg/
* test-error-array-bounds.c: Array is not unsigned
---
gcc/jit/jit-playback.c| 70 +++
gcc/jit/jit-playback.h| 5 ++
.../jit.dg/test-error-array-bounds.c | 2 +-
3 files changed, 62 insertions(+), 15 deletions(-)
diff --git a/gcc/jit/jit-playback.c b/gcc/jit/jit-playback.c
index 79ac525e5df..bf1bd10dedd 100644
--- a/gcc/jit/jit-playback.c
+++ b/gcc/jit/jit-playback.c
@@ -165,7 +165,8 @@ gt_ggc_mx ()
/* Given an enum gcc_jit_types value, get a "tree" type. */
-static tree
+tree
+playback::context::
get_tree_node_for_type (enum gcc_jit_types type_)
{
switch (type_)
@@ -192,11 +193,7 @@ get_tree_node_for_type (enum gcc_jit_types type_)
return short_unsigned_type_node;
case GCC_JIT_TYPE_CONST_CHAR_PTR:
- {
- tree const_char = build_qualified_type (char_type_node,
- TYPE_QUAL_CONST);
- return build_pointer_type (const_char);
- }
+ return m_const_char_ptr;
case GCC_JIT_TYPE_INT:
return integer_type_node;
@@ -579,10 +576,6 @@ playback::lvalue *
playback::context::
global_finalize_lvalue (tree inner)
{
- varpool_node::get_create (inner);
-
- varpool_node::finalize_decl (inner);
-
m_globals.safe_push (inner);
return new lvalue (this, inner);
@@ -2952,9 +2945,7 @@ replay ()
{
JIT_LOG_SCOPE (get_logger ());
- m_const_char_ptr
-= build_pointer_type (build_qualified_type (char_type_node,
- TYPE_QUAL_CONST));
+ init_types ();
/* Replay the recorded events: */
timevar_push (TV_JIT_REPLAY);
@@ -2984,10 +2975,17 @@ replay ()
{
int i;
function *func;
-
+ tree global;
/* No GC can happen yet; process the cached source locations. */
handle_locations ();
+ /* Finalize globals. See how FORTRAN 95 does it in gfc_be_parse_file()
+ for a simple reference. */
+ FOR_EACH_VEC_ELT (m_globals, i, global)
+rest_of_decl_compilation (global, true, true);
+
+ wrapup_global_declarations (m_globals.address(), m_globals.length());
+
/* We've now created tree nodes for the stmts in the various blocks
in each function, but we haven't built each function's single stmt
list yet. Do so now. */
@@ -3081,6 +3079,50 @@ location_comparator (const void *lhs, const void *rhs)
return loc_lhs->get_column_num () - loc_rhs->get_column_num ();
}
+/* Initialize the NAME_TYPE of the primitive types as well as some
+ others. */
+void
+playback::context::
+init_types ()
+{
+ /* See lto_init() in lto-lang.c or void visit (TypeBasic *t) in D's types.cc
+ for reference. If TYPE_NAME is not set, debug info will not contain types
*/
+#define NAME_TYPE(t,n) \
+if (t) \
+ TYPE_NAME (t) = build_decl (UNKNOWN_LOCATION, TYPE_DECL, \
+ get_identifier (n), t)
+
+ NAME_TYPE (integer_type_node, "int");
+ NAME_TYPE (char_type_node, "char");
+ NAME_TYPE (long_integer_type_node, "long int");
+ NAME_TYPE (unsigned_type_node, "unsigned int");
+ NAME_TYPE (long_unsigned_type_node, "long unsigned int");
+ NAME_TYPE (long_long_integer_type_node, "long long int");
+ NAME_TYPE (long_long_unsigned_type_node, "long long unsigned int");
+ NAME_TYPE (short_integer_type_node, "short int");
+ NAME_TYPE (short_unsigned_type_node, "short unsigned int");
+ if (signed_char_type_node != char_type_node)
+NAME_TYPE (signed_char_type_node, "signed char");
+ if (unsigned_char_type_node != char_type_node)
+NAME_TYPE (unsigned_char_type_node, "unsigned char");
+ NAME_TYPE (float_type_node, "float");
+ NAME_TYPE (double_type_node, "double");
+ NAME_TYPE (long_double_type_node, "long double");
+ NAME_TYPE (void_type_node, "void");
+ NAME_TYPE (boolean_type_node, "bool");
+ NAME_TYPE (complex_float_type_node, "complex float");
+ NAME_TYPE (complex_double_type_node, "complex double");
+ NAME_TYPE (complex_long_double_type_node, "complex long double");
+
+ m_const_char_ptr = build_pointer_type(
+build_qualified_type (char_type_node, TYPE_QUAL_CONST));
+
+ NAME_TYPE (m_const_char_ptr, "char");
+ NAME_TYPE (size_type_node, "size_t");
+ NAME_TYPE
[PATCH 0/2 v2] jit : Generate debug info for variables
Hi, This is a revision of my patch for debug info. The patches are posted as mails to this thread. Make check-jit runs fine on Debian x64. Below is the original mail and under it a rehash of the review comments. Regards, Petter - Hi, This is a patch to generate debug info for local variables as well as globals. With this, "ptype foo", "info variables", "info locals" etc works when debugging in GDB. Finalizing of global variable declares are moved to after locations are handled and done as Fortran, C, Go etc do it. Also, primitive types have their TYPE_NAME set for debug info on types to work. Below are the patch, and I attached a testcase. Since it requires GDB to run it might not be suitable? Make check-jit runs fine on Debian x64. Regards, - > Can you write non-empty ChangeLog entries please. Done. I think the python script chokes on asd/qwe/jit.db/ (the dot) though. > @@ -2984,15 +2975,22 @@ replay () > Looks like some whitespace churn above Fixed. > I don't see "Signed-off-by" tags in the patches. Added. > I think this should be "unsupported" rather than "xfail". Changed. > This is OK, but maybe using gcc_jit_context_dump_to_file with update_locations == 1 might be more sustainable in the long run? Ye I didn't remember that flag. Entering loc manually aint no fun.
Sv: Sv: [PATCH] jit : Generate debug info for variables
Thanks for the review. I will post a revision to the mailing list.
I have not filed a copyright assignment with the FSF, but if DCO is enough
I'll add it. I also read the mail about the testcase of this patch.
Regards, Petter
-Ursprungligt meddelande-
Från: David Malcolm
Skickat: den 2 september 2021 17:21
Till: Petter Tomner ; gcc-patches@gcc.gnu.org; j...@gcc.gnu.org
Ämne: Re: Sv: [PATCH] jit : Generate debug info for variables
On Tue, 2021-08-31 at 00:23 +, Petter Tomner via Gcc-patches wrote:
> Well I seemed to have attached the wrong testcase. Here is the proper
> one attached.
>
> Regards,
>
> -Ursprungligt meddelande-
> Från: Petter Tomner
> Skickat: den 31 augusti 2021 02:14
> Till: gcc-patches@gcc.gnu.org; j...@gcc.gnu.org
> Ämne: [PATCH] jit : Generate debug info for variables
>
> Hi,
>
> This is a patch to generate debug info for local variables as well as
> globals.
> With this, "ptype foo", "info variables", "info locals" etc works when
> debugging in GDB.
>
> Finalizing of global variable declares are moved to after locations
> are handled and done as Fortran, C, Go etc do it. Also, primitive
> types have their TYPE_NAME set for debug info on types to work.
>
> Below are the patch, and I attached a testcase. Since it requires GDB
> to run it might not be suitable? Make check-jit runs fine on Debian
> x64.
>
> Regards,
> From 6a5d24cbe80429d19042e643bd4c23940cd185fa Mon Sep 17 00:00:00 2001
> From: Petter Tomner
> Date: Mon, 30 Aug 2021 01:45:11 +0200
> Subject: [PATCH 2/2] libgccjit: Test cases for debug info
>
> Assure that debug info is available for variables.
>
> gcc/testsuite/jit.dg/
> jit.exp: Helper function
> test-debuginfo.c
Again, please provided non-empty ChangeLog entries.
You can use contrib/gcc-changelog/git_check_commit.py to validate them.
I don't see "Signed-off-by" tags in the patches. Have you either filed a
copyright assignment with the FSF, or can you please add the tags to certify
that you wrote the patches and can contribute them, see:
https://gcc.gnu.org/contribute.html#legal
https://gcc.gnu.org/dco.html
[...snip...]
> +proc jit-check-debug-info { obj_file cmds match } {
> +verbose "Checking debug info for $obj_file with match: $match"
> +
> +if { [catch {exec gdb -v} fid] } {
> +verbose "No gdb seems to be in path. Can't check debug info.
Reporting expected fail."
> +xfail "No gdb seems to be in path. Can't check debug info"
I think this should be "unsupported" rather than "xfail".
[...snip...]
> diff --git a/gcc/testsuite/jit.dg/test-debuginfo.c
b/gcc/testsuite/jit.dg/test-debuginfo.c
> new file mode 100644
> index 000..0af5779fdd1
> --- /dev/null
> +++ b/gcc/testsuite/jit.dg/test-debuginfo.c
> @@ -0,0 +1,72 @@
> +/* Essentially this test checks that debug info are generated for
globals
> + locals and functions, including type info. The comment bellow is
used
> + as fake code (does not affect the test, use for manual
debugging). */
> +/*
> +int a_global_for_test_debuginfo;
> +int main (int argc, char **argv)
> +{
> +int a_local_for_test_debuginfo = 2;
> +return a_global_for_test_debuginfo + a_local_for_test_debuginfo;
> +} */
This is OK, but maybe using gcc_jit_context_dump_to_file with update_locations
== 1 might be more sustainable in the long run? See:
https://gcc.gnu.org/onlinedocs/jit/topics/locations.html#faking-it
OK otherwise.
Thanks
Dave
Sv: [PATCH] jit : Generate debug info for variables
Well I seemed to have attached the wrong testcase. Here is the proper one attached. Regards, -Ursprungligt meddelande- Från: Petter Tomner Skickat: den 31 augusti 2021 02:14 Till: gcc-patches@gcc.gnu.org; j...@gcc.gnu.org Ämne: [PATCH] jit : Generate debug info for variables Hi, This is a patch to generate debug info for local variables as well as globals. With this, "ptype foo", "info variables", "info locals" etc works when debugging in GDB. Finalizing of global variable declares are moved to after locations are handled and done as Fortran, C, Go etc do it. Also, primitive types have their TYPE_NAME set for debug info on types to work. Below are the patch, and I attached a testcase. Since it requires GDB to run it might not be suitable? Make check-jit runs fine on Debian x64. Regards, 0002-libgccjit-Test-cases-for-debug-info.patch Description: 0002-libgccjit-Test-cases-for-debug-info.patch
[PATCH] jit : Generate debug info for variables
Hi,
This is a patch to generate debug info for local variables as well as globals.
With this, "ptype foo", "info variables", "info locals" etc works when
debugging in GDB.
Finalizing of global variable declares are moved to after locations are handled
and done
as Fortran, C, Go etc do it. Also, primitive types have their TYPE_NAME set for
debug info
on types to work.
Below are the patch, and I attached a testcase. Since it requires GDB to run it
might
not be suitable? Make check-jit runs fine on Debian x64.
Regards,
>From d77e77104024c7ae9ce31b419dad1f0a5801fda7 Mon Sep 17 00:00:00 2001
From: Petter Tomner
Date: Mon, 30 Aug 2021 01:44:07 +0200
Subject: [PATCH 1/2] libgccjit: Generate debug info for variables
Finalize declares via available helpers after location is set. Set
TYPE_NAME of primitives and friends to "int" etc. Debug info is now
set properly for variables.
2021-08-31 Petter Tomner
gcc/jit
jit-playback.c
jit-playback.h
gcc/testsuite/jit.dg/
test-error-array-bounds.c: Array is not unsigned
---
gcc/jit/jit-playback.c| 76 ++-
gcc/jit/jit-playback.h| 5 ++
.../jit.dg/test-error-array-bounds.c | 2 +-
3 files changed, 65 insertions(+), 18 deletions(-)
diff --git a/gcc/jit/jit-playback.c b/gcc/jit/jit-playback.c
index 79ac525e5df..74321b0946a 100644
--- a/gcc/jit/jit-playback.c
+++ b/gcc/jit/jit-playback.c
@@ -165,7 +165,8 @@ gt_ggc_mx ()
/* Given an enum gcc_jit_types value, get a "tree" type. */
-static tree
+tree
+playback::context::
get_tree_node_for_type (enum gcc_jit_types type_)
{
switch (type_)
@@ -192,11 +193,7 @@ get_tree_node_for_type (enum gcc_jit_types type_)
return short_unsigned_type_node;
case GCC_JIT_TYPE_CONST_CHAR_PTR:
- {
- tree const_char = build_qualified_type (char_type_node,
- TYPE_QUAL_CONST);
- return build_pointer_type (const_char);
- }
+ return m_const_char_ptr;
case GCC_JIT_TYPE_INT:
return integer_type_node;
@@ -579,10 +576,6 @@ playback::lvalue *
playback::context::
global_finalize_lvalue (tree inner)
{
- varpool_node::get_create (inner);
-
- varpool_node::finalize_decl (inner);
-
m_globals.safe_push (inner);
return new lvalue (this, inner);
@@ -2952,9 +2945,7 @@ replay ()
{
JIT_LOG_SCOPE (get_logger ());
- m_const_char_ptr
-= build_pointer_type (build_qualified_type (char_type_node,
- TYPE_QUAL_CONST));
+ init_types ();
/* Replay the recorded events: */
timevar_push (TV_JIT_REPLAY);
@@ -2984,15 +2975,22 @@ replay ()
{
int i;
function *func;
-
+ tree global;
/* No GC can happen yet; process the cached source locations. */
handle_locations ();
+ /* Finalize globals. See how FORTRAN 95 does it in gfc_be_parse_file()
+ for a simple reference. */
+ FOR_EACH_VEC_ELT (m_globals, i, global)
+rest_of_decl_compilation (global, true, true);
+
+ wrapup_global_declarations (m_globals.address(), m_globals.length());
+
/* We've now created tree nodes for the stmts in the various blocks
-in each function, but we haven't built each function's single stmt
-list yet. Do so now. */
+ in each function, but we haven't built each function's single
stmt
+ list yet. Do so now. */
FOR_EACH_VEC_ELT (m_functions, i, func)
- func->build_stmt_list ();
+ func->build_stmt_list ();
/* No GC can have happened yet. */
@@ -3081,6 +3079,50 @@ location_comparator (const void *lhs, const void *rhs)
return loc_lhs->get_column_num () - loc_rhs->get_column_num ();
}
+/* Initialize the NAME_TYPE of the primitive types as well as some
+ others. */
+void
+playback::context::
+init_types ()
+{
+ /* See lto_init() in lto-lang.c or void visit (TypeBasic *t) in D's types.cc
+ for reference. If TYPE_NAME is not set, debug info will not contain types
*/
+#define NAME_TYPE(t,n) \
+if (t) \
+ TYPE_NAME (t) = build_decl (UNKNOWN_LOCATION, TYPE_DECL, \
+ get_identifier (n), t)
+
+ NAME_TYPE (integer_type_node, "int");
+ NAME_TYPE (char_type_node, "char");
+ NAME_TYPE (long_integer_type_node, "long int");
+ NAME_TYPE (unsigned_type_node, "unsigned int");
+ NAME_TYPE (long_unsigned_type_node, "long unsigned int");
+ NAME_TYPE (long_long_integer_type_node, "long long int");
+ NAME_TYPE (long_long_unsigned_type_node, "long long unsigned int");
+ NAME_TYPE (short_integer_type_node, "short int");
+ NAME_TYPE (short_unsigned_type_node, "short unsigned int");
+ if (signed_char_type_node != char_type_node)
+NAME_TYPE (signed_char_type_node, "signed char");
+ if (unsigned_char_type_node != char_type_node)
+NAME_TYPE (unsigned_char_type_node, "unsigned char");
+ NAME_TYPE (float_type_node, "float");
+
[PATCH 3/3] jit: Add support for weak linkage
This patch updates the documentation concerning the addition of weak linkage for 'gcc_jit_context_new_function()' and 'gcc_jit_context_new_global()'. The documentation needs regeneration. gcc/jit/docs/topics/ * compilation.rst * expressions.rst * functions.rst --- gcc/jit/docs/topics/compilation.rst | 3 ++- gcc/jit/docs/topics/expressions.rst | 13 + gcc/jit/docs/topics/functions.rst | 20 +--- 3 files changed, 32 insertions(+), 4 deletions(-) diff --git a/gcc/jit/docs/topics/compilation.rst b/gcc/jit/docs/topics/compilation.rst index b6ace12120f..67c7ac5f7f3 100644 --- a/gcc/jit/docs/topics/compilation.rst +++ b/gcc/jit/docs/topics/compilation.rst @@ -57,7 +57,8 @@ In-memory compilation with a name matching `funcname` must have been created on `result`'s context (or a parent context) via a call to :func:`gcc_jit_context_new_function` with `kind` - :macro:`GCC_JIT_FUNCTION_EXPORTED`: + :macro:`GCC_JIT_FUNCTION_EXPORTED` or + :macro:`GCC_JIT_FUNCTION_EXPORTED_WEAK`: .. code-block:: c diff --git a/gcc/jit/docs/topics/expressions.rst b/gcc/jit/docs/topics/expressions.rst index 396259ef07e..e3a57264732 100644 --- a/gcc/jit/docs/topics/expressions.rst +++ b/gcc/jit/docs/topics/expressions.rst @@ -582,6 +582,19 @@ Global variables referring to it. Analogous to using an "extern" global from a header file. + .. c:macro:: GCC_JIT_GLOBAL_EXPORTED_WEAK + + Global is defined by the client code with weak linkage and is visible + by name outside of this JIT context via + :c:func:`gcc_jit_result_get_global`. Analogous to declaring a variable + with ``__attribute__((weak))``. + + When compiled to file weak linkage allow multiple definitions + of the same symbol name in different files all being linked + together. Note that child contexts include their parent and + can't have more than one variable with the same name no matter + if weak or not. + .. function:: gcc_jit_lvalue *\ gcc_jit_global_set_initializer (gcc_jit_lvalue *global,\ const void *blob,\ diff --git a/gcc/jit/docs/topics/functions.rst b/gcc/jit/docs/topics/functions.rst index b2d9239aa0a..31de2147e10 100644 --- a/gcc/jit/docs/topics/functions.rst +++ b/gcc/jit/docs/topics/functions.rst @@ -90,9 +90,8 @@ Functions Function is defined by the client code and visible by name outside of the JIT. - This value is required if you want to extract machine code - for this function from a :type:`gcc_jit_result` via - :func:`gcc_jit_result_get_code`. + With this value you can extract machine code for this function + from a :type:`gcc_jit_result` via :func:`gcc_jit_result_get_code`. .. macro:: GCC_JIT_FUNCTION_INTERNAL @@ -117,6 +116,21 @@ Functions above 0; when optimization is off, this is essentially the same as GCC_JIT_FUNCTION_INTERNAL. + .. macro:: GCC_JIT_FUNCTION_EXPORTED_WEAK + + Function is defined by the client code with weak linkage and + is visible by name outside of the JIT. Analogous to a function + with ``__attribute__((weak))``. + + When compiled to file weak linkage allow multiple definitions + of the same symbol name in different files all being linked + together. Note that child contexts include their parent and + can't have more than one function with the same name no matter + if weak or not. + + With this value you can extract machine code for this function + from a :type:`gcc_jit_result` via :func:`gcc_jit_result_get_code`. + The parameter ``name`` must be non-NULL. The call takes a copy of the underlying string, so it is valid to pass in a pointer to an on-stack buffer. -- 2.20.1
[PATCH 2/3] jit: Add support for weak linkage
This patch has a test case for weak linkage as well as modification of helper
functions. Essentially it produces two object files, one with weak and one with
normal symbols, and a main which prints the values of those two symbols and a
cehck to ensure that the normal symbols' values are printed.
2021-08-08 Petter Tomner
gcc/testsuite/
* all-non-failing-tests.h : "weak_symbols" added to test list
* harness.h : Macro flag to be able to provide own test_jit()
* jit.exp : Helper functions with support for 2+ outfiles
* test-compile-weak-symbols.c : New test case
* verify-weak-linkage.c : main function for linking to obj. files.
---
gcc/testsuite/jit.dg/all-non-failing-tests.h | 12 +-
gcc/testsuite/jit.dg/harness.h| 5 +
gcc/testsuite/jit.dg/jit.exp | 69 ++
.../jit.dg/test-compile-weak-symbols.c| 207 ++
gcc/testsuite/jit.dg/verify-weak-linkage.c| 21 ++
5 files changed, 313 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/jit.dg/test-compile-weak-symbols.c
create mode 100644 gcc/testsuite/jit.dg/verify-weak-linkage.c
diff --git a/gcc/testsuite/jit.dg/all-non-failing-tests.h
b/gcc/testsuite/jit.dg/all-non-failing-tests.h
index 84ef54a0386..4da34905a3d 100644
--- a/gcc/testsuite/jit.dg/all-non-failing-tests.h
+++ b/gcc/testsuite/jit.dg/all-non-failing-tests.h
@@ -105,6 +105,13 @@
#undef create_code
#undef verify_code
+/* test-compile-weak-symbols.c */
+#define create_code create_code_weak_symbols
+#define verify_code verify_code_weak_symbols
+#include "test-compile-weak-symbols.c"
+#undef create_code
+#undef verify_code
+
/* test-compound-assignment.c */
#define create_code create_code_compound_assignment
#define verify_code verify_code_compound_assignment
@@ -454,7 +461,10 @@ const struct testcase testcases[] = {
verify_code_version},
{"volatile",
create_code_volatile,
- verify_code_volatile}
+ verify_code_volatile},
+ {"weak_symbols",
+ create_code_weak_symbols,
+ verify_code_weak_symbols}
};
const int num_testcases = (sizeof (testcases) / sizeof (testcases[0]));
diff --git a/gcc/testsuite/jit.dg/harness.h b/gcc/testsuite/jit.dg/harness.h
index 6b59fb57aae..84c248303f4 100644
--- a/gcc/testsuite/jit.dg/harness.h
+++ b/gcc/testsuite/jit.dg/harness.h
@@ -331,6 +331,10 @@ dump_reproducer (gcc_jit_context *ctxt, const char *argv0)
free (reproducer_name);
}
+static void
+test_jit (const char *argv0, void *user_data);
+
+#ifndef TEST_PROVIDES_TEST_JIT
/* Run one iteration of the test. */
static void
test_jit (const char *argv0, void *user_data)
@@ -383,6 +387,7 @@ test_jit (const char *argv0, void *user_data)
if (logfile)
fclose (logfile);
}
+#endif /* #ifndef TEST_PROVIDES_TEST_JIT */
#endif /* #ifndef TEST_ESCHEWS_TEST_JIT */
/* We want to prefix all unit test results with the test, but dejagnu.exp's
diff --git a/gcc/testsuite/jit.dg/jit.exp b/gcc/testsuite/jit.dg/jit.exp
index 9af87f9c6ad..f26970a41e6 100644
--- a/gcc/testsuite/jit.dg/jit.exp
+++ b/gcc/testsuite/jit.dg/jit.exp
@@ -692,6 +692,19 @@ proc jit-verify-output-file-was-created { args } {
}
}
+proc jit-verify-output-files-were-created { args } {
+verbose "jit-verify-output-files-were-created: $args"
+
+foreach output_filename $args {
+# Verify that the expected files was written out
+if { [file exists $output_filename] == 1} {
+pass "$output_filename exists"
+} else {
+fail "$output_filename does not exist"
+}
+}
+}
+
# Verify that the given file exists, and is executable.
# Attempt to execute it, and verify that its stdout matches
# the given regex.
@@ -840,6 +853,62 @@ proc jit-verify-object { args } {
jit-run-executable ${executable_from_obj} ${dg-output-text}
}
+# Compile 'sources' and link in 'objects' and execute the program
+# and check that its output matches 'expected_output'.
+#
+# The path to the JIT test source folder is prepended to each
+# word in 'source'.
+#
+# For use with test-compile-weak-symbols.c testcase.
+proc jit-verify-sources-objects { expected_output sources objects } {
+global srcdir
+global subdir
+
+verbose "jit-verify-objects: $expected_output $sources $objects"
+set dg-output-text $expected_output
+
+# prepend the path to the folder with the JIT tests
+# to each source
+set rel_path "$srcdir/$subdir/"
+set srcs [lmap i $sources { string cat $rel_path $i }]
+verbose "sources full path: ${srcs}"
+
+upvar 2 name name
+verbose "name: $name"
+
+upvar 2 prog prog
+verbose "prog: $prog"
+
+# Name the linked executable as the first source
+# with ".exe" appended.
+set executable_from_obj [lindex $sources 0].exe
+verbose " executable_from_obj: ${executable_from_obj}"
+
+# Invoke the driver to link the .o file to the .exe
+set comp_output [gcc_target_compile \
+"${srcs}
[PATCH 1/3] jit: Add support for weak linkage
This patch adds support for weak linkage variables and functions in libgccjit.
'gcc_jit_context_new_function()' and 'gcc_jit_context_new_global()' gets one
new enum value each which specifies weak linkage. The macro
'LIBGCCJIT_HAVE_WEAK_SYMBOLS' indicates weak linkage support. Analogous to
declaring with "__attribute__((weak))".
2021-08-08 Petter Tomner
gcc/jit/
* libgccjit.c: Range check for enum
* libgccjit.h (LIBGCCJIT_HAVE_WEAK_SYMBOLS): Feuture macro
(enum gcc_jit_function_kind): New enum value
(enum gcc_jit_global_kind): New enum value
* jit-playback.c : Make nodes weak
* jit-recording.c : Reproduce and dump properly
---
gcc/jit/jit-playback.c | 11 ++
gcc/jit/jit-recording.c | 22 +++-
gcc/jit/libgccjit.c | 4 ++--
gcc/jit/libgccjit.h | 45 +
4 files changed, 71 insertions(+), 11 deletions(-)
diff --git a/gcc/jit/jit-playback.c b/gcc/jit/jit-playback.c
index 79ac525e5df..58ba23fa3b4 100644
--- a/gcc/jit/jit-playback.c
+++ b/gcc/jit/jit-playback.c
@@ -565,6 +565,11 @@ global_new_decl (location *loc,
case GCC_JIT_GLOBAL_IMPORTED:
DECL_EXTERNAL (inner) = 1;
break;
+
+case GCC_JIT_GLOBAL_EXPORTED_WEAK:
+ TREE_STATIC (inner) = 1;
+ DECL_WEAK (inner) = 1;
+ break;
}
if (loc)
@@ -1640,6 +1645,12 @@ postprocess ()
DECL_PRESERVE_P (m_inner_fndecl) = 1;
}
+ if (m_kind == GCC_JIT_FUNCTION_EXPORTED_WEAK)
+{
+ DECL_WEAK (m_inner_fndecl) = 1;
+ DECL_EXTERNAL (m_inner_fndecl) = 0;
+ DECL_PRESERVE_P (m_inner_fndecl) = 1;
+}
if (m_kind == GCC_JIT_FUNCTION_INTERNAL
||m_kind == GCC_JIT_FUNCTION_ALWAYS_INLINE)
{
diff --git a/gcc/jit/jit-recording.c b/gcc/jit/jit-recording.c
index 117ff70114c..77c069358ef 100644
--- a/gcc/jit/jit-recording.c
+++ b/gcc/jit/jit-recording.c
@@ -3902,6 +3902,7 @@ recording::function::write_to_dump (dump )
default: gcc_unreachable ();
case GCC_JIT_FUNCTION_EXPORTED:
case GCC_JIT_FUNCTION_IMPORTED:
+case GCC_JIT_FUNCTION_EXPORTED_WEAK:
d.write ("extern ");
break;
case GCC_JIT_FUNCTION_INTERNAL:
@@ -3913,6 +3914,9 @@ recording::function::write_to_dump (dump )
}
d.write ("%s\n", m_return_type->get_debug_string ());
+ if (m_kind == GCC_JIT_FUNCTION_EXPORTED_WEAK)
+d.write ("__attribute__((weak)) ");
+
if (d.update_locations ())
m_loc = d.make_location ();
@@ -4107,7 +4111,8 @@ static const char * const names_of_function_kinds[] = {
"GCC_JIT_FUNCTION_EXPORTED",
"GCC_JIT_FUNCTION_INTERNAL",
"GCC_JIT_FUNCTION_IMPORTED",
- "GCC_JIT_FUNCTION_ALWAYS_INLINE"
+ "GCC_JIT_FUNCTION_ALWAYS_INLINE",
+ "GCC_JIT_FUNCTION_EXPORTED_WEAK"
};
/* Implementation of recording::memento::write_reproducer for functions. */
@@ -4579,6 +4584,10 @@ recording::global::replay_into (replayer *r)
"extern TYPE NAME;"
e.g. "extern int foo;"
+ GCC_JIT_GLOBAL_EXPORTED_WEAK:
+ "TYPE __attribute__((weak)) NAME"
+ e.g. "int __attribute__((weak)) foo"
+
These are written to the top of the dump by
recording::context::dump_to_file. */
@@ -4594,6 +4603,7 @@ recording::global::write_to_dump (dump )
gcc_unreachable ();
case GCC_JIT_GLOBAL_EXPORTED:
+case GCC_JIT_GLOBAL_EXPORTED_WEAK:
break;
case GCC_JIT_GLOBAL_INTERNAL:
@@ -4605,9 +4615,10 @@ recording::global::write_to_dump (dump )
break;
}
- d.write ("%s %s",
- m_type->get_debug_string (),
- get_debug_string ());
+ d.write ("%s ", m_type->get_debug_string ());
+ if (m_kind == GCC_JIT_GLOBAL_EXPORTED_WEAK)
+d.write ("__attribute__((weak)) ");
+ d.write ("%s", get_debug_string ());
if (!m_initializer)
{
@@ -4632,7 +4643,8 @@ recording::global::write_to_dump (dump )
static const char * const global_kind_reproducer_strings[] = {
"GCC_JIT_GLOBAL_EXPORTED",
"GCC_JIT_GLOBAL_INTERNAL",
- "GCC_JIT_GLOBAL_IMPORTED"
+ "GCC_JIT_GLOBAL_IMPORTED",
+ "GCC_JIT_GLOBAL_EXPORTED_WEAK"
};
template
diff --git a/gcc/jit/libgccjit.c b/gcc/jit/libgccjit.c
index 7fa948007ad..d290f908774 100644
--- a/gcc/jit/libgccjit.c
+++ b/gcc/jit/libgccjit.c
@@ -902,7 +902,7 @@ gcc_jit_context_new_function (gcc_jit_context *ctxt,
/* LOC can be NULL. */
RETURN_NULL_IF_FAIL_PRINTF1 (
((kind >= GCC_JIT_FUNCTION_EXPORTED)
- && (kind <= GCC_JIT_FUNCTION_ALWAYS_INLINE)),
+ && (kind <= GCC_JIT_FUNCTION_EXPORTED_WEAK)),
ctxt, loc,
"unrecognized value for enum gcc_jit_function_kind: %i",
kind);
@@ -1101,7 +1101,7 @@ gcc_jit_context_new_global (gcc_jit_context *ctxt,
/* LOC can be NULL. */
RETURN_NULL_IF_FAIL_PRINTF1 (
((kind >= GCC_JIT_GLOBAL_EXPORTED)
- && (kind <= GCC_JIT_GLOBAL_IMPORTED)),
+ && (kind <= GCC_JIT_GLOBAL_EXPORTED_WEAK)),
ctxt, loc,
"unrecognized value for enum gcc_jit_global_kind: %i",
kind);
[PATCH 0/3] jit: Add support for weak linkage
Hi, To implement generics/C++ template-ish with libgccjit it would be very useful to have the possibility to declare functions and variables with weak linkage, to be able to have independent AOT compilation of object files without needing to keep track of what is "instantiated" where to prevent collisions. I implemented this by giving 'gcc_jit_context_new_function()' and 'gcc_jit_context_new_global()' one new enum value EXPORTED_WEAK each that specifies an exported symbol with weak linkage. The variable or function is accessible from a 'result' as would it be EXPORTED. I split the code up for it to be easier to read: Patch 1 is the implementation. Patch 2 is a test case. Patch 3 is documentation updates. I ran 'make check-jit' successfully on a x64-pc-gnu linux. I didn't make any ABI tag and the docs need regeneration in path 3. Regards, Petter Tomner
