[Bug jit/95296] New: Segfault when trying to return a void value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95296 Bug ID: 95296 Summary: Segfault when trying to return a void value Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- Created attachment 48589 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48589&action=edit Complete example reproducing the segfault Hi. When trying to return a void value this way, this makes the code segfault: gcc_jit_type *void_type = gcc_jit_context_get_type (ctxt, GCC_JIT_TYPE_VOID); gcc_jit_lvalue *return_value = gcc_jit_function_new_local(func, NULL, void_type, "void"); gcc_jit_block_end_with_return (block, NULL, gcc_jit_lvalue_as_rvalue(return_value)); Could you please fix it so that it shows an error instead of segfaulting? Thanks.
[Bug jit/95306] New: Getting __builtin_saddl_overflow gives the error "unimplemented primitive type for builtin: 42"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95306 Bug ID: 95306 Summary: Getting __builtin_saddl_overflow gives the error "unimplemented primitive type for builtin: 42" Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- Created attachment 48592 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48592&action=edit Complete example reproducing this issue Hi. Getting the builtin __builtin_sadd_overflow like this: gcc_jit_function *sadd = gcc_jit_context_get_builtin_function(ctxt, "__builtin_sadd_overflow"); prints the following error at runtime: unimplemented primitive type for builtin: 42 Other builtins like __builtin_saddl_overflow works fine. Thanks to fix this issue.
[Bug jit/95314] New: Sharing a local reference to a global variable in multiple functions results in location references block not in block tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95314 Bug ID: 95314 Summary: Sharing a local reference to a global variable in multiple functions results in location references block not in block tree Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- Hi. If a create, in a function, a reference (with gcc_jit_lvalue_get_address) to a global and reuse this local reference in another function, it gives the following error: libgccjit.so: error: location references block not in block tree … during IPA pass: *free_lang_data libgccjit.so: error: verify_gimple failed 0x7f83924b35c9 verify_gimple_in_cfg(function*, bool) ../../gcc-10.1.0/gcc/tree-cfg.c:5462 0x7f839236a819 execute_function_todo ../../gcc-10.1.0/gcc/passes.c:1985 0x7f839236add7 do_per_function ../../gcc-10.1.0/gcc/passes.c:1647 0x7f839236b06b do_per_function ../../gcc-10.1.0/gcc/passes.c:2050 0x7f839236b06b execute_todo ../../gcc-10.1.0/gcc/passes.c:2039 I can try to make an example to reproduce this issue if needed. Is that the expected behavior or should libgccjit gives a proper error? (Recreating the reference in every function fix this issue.) Thanks.
[Bug jit/95314] Sharing a local reference to a global variable in multiple functions results in location references block not in block tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95314 --- Comment #5 from bouanto at zoho dot com --- The reproducer generates a file where the function create_code only contains this: /* Replay of API calls for ctxt_0x7f8079128680. */ So, no code is actually generated and thus, does not reproduce this issue.
[Bug jit/95325] New: Support 128-bit integers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95325 Bug ID: 95325 Summary: Support 128-bit integers Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- Hi. Would it be possible to add support for 128-bit integers in libgccjit? Thanks.
[Bug jit/95306] Getting __builtin_sadd_overflow gives the error "unimplemented primitive type for builtin: 42"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95306 --- Comment #1 from bouanto at zoho dot com --- A similar error happens for the builtin "memcpy": error: unimplemented primitive type for builtin: 38
[Bug jit/95314] Sharing a local reference to a global variable in multiple functions results in location references block not in block tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95314 --- Comment #8 from bouanto at zoho dot com --- Created attachment 48617 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48617&action=edit Small example to reproduce the bug
[Bug jit/95314] Sharing a local reference to a global variable in multiple functions results in location references block not in block tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95314 --- Comment #9 from bouanto at zoho dot com --- Actually, it seems I was wrong on the conditions to reproduce this issue. I managed to create a small example to reproduce the issue. I attached it to the bug report.
[Bug jit/95415] New: Add support for thread-local variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95415 Bug ID: 95415 Summary: Add support for thread-local variables Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- Hi. Would it be possible to add thread-local variables? Thanks.
[Bug jit/95426] New: libgccjit.so: error: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95426
Bug ID: 95426
Summary: libgccjit.so: error: RTL check: expected elt 2 type
'B', have '0' (rtx barrier) in BLOCK_FOR_INSN
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: jit
Assignee: dmalcolm at gcc dot gnu.org
Reporter: bouanto at zoho dot com
Target Milestone: ---
Hi.
I found this bug that happens when generating some code with libgccjit:
during RTL pass: expand
libgccjit.so: error: RTL check: expected elt 2 type 'B', have '0' (rtx barrier)
in BLOCK_FOR_INSN, at rtl.h:1485
0x7f2a2317d365 rtl_check_failed_type1(rtx_def const*, int, int, char const*,
int, char const*)
../../gcc/gcc/rtl.c:860
0x7f2a23091bf7 BLOCK_FOR_INSN(rtx_def*)
../../gcc/gcc/rtl.h:1485
0x7f2a23091f82 BLOCK_FOR_INSN(rtx_def*)
../../gcc/gcc/rtl.h:1469
0x7f2a23091f82 rtl_verify_bb_pointers
../../gcc/gcc/cfgrtl.c:2778
0x7f2a2359e6e6 rtl_verify_flow_info_1
../../gcc/gcc/cfgrtl.c:2832
0x7f2a2359e6e6 rtl_verify_flow_info
../../gcc/gcc/cfgrtl.c:3076
0x7f2a23582a06 verify_flow_info()
../../gcc/gcc/cfghooks.c:267
0x7f2a244a966d checking_verify_flow_info
../../gcc/gcc/cfghooks.h:212
0x7f2a244a966d try_optimize_cfg
../../gcc/gcc/cfgcleanup.c:3009
0x7f2a244a966d cleanup_cfg(int)
../../gcc/gcc/cfgcleanup.c:3174
0x7f2a2357f90a execute
../../gcc/gcc/cfgexpand.c:6732
I'm not sure what causes this issue and, again, dumping a reproducer dumps a
file with an empty create_code function.
Is there any compile-time option I need to enable to be able to create a
reproducer?
Thanks to fix this issue.
[Bug jit/95438] New: Cannot cast pointer to int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95438 Bug ID: 95438 Summary: Cannot cast pointer to int Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- Hi. It seems there's no way to cast a pointer to int. When I try a cast, I get: libgccjit.so: error: gcc_jit_context_new_cast: cannot cast param from type: unsigned char * * to type: unsigned long long Thanks to allow this.
[Bug jit/95438] Cannot cast pointer to int and vice versa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95438 --- Comment #1 from bouanto at zoho dot com --- The opposite does not work as well: libgccjit.so: error: gcc_jit_context_new_cast: cannot cast (long long)(unsigned long long)*&binopResult from type: long long to type: unsigned char * *
[Bug jit/95426] libgccjit.so: error: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95426 --- Comment #2 from bouanto at zoho dot com --- Created attachment 48648 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48648&action=edit Reproducer for the bug Oh, I see what I was doing wrong: I thought it was an option, so I was calling this function at the beginning. Also, I had to comment the line creating the type GCC_JIT_TYPE_COMPLEX_DOUBLE in order for this reproducer to reproduce the issue. With that line, it does another error: libgccjit.so: error: gcc_jit_context_get_type: unrecognized value for enum gcc_jit_types: 21 That's probably another bug, though.
[Bug jit/95462] New: Different int types for the same call to gcc_jit_context_get_int_type()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95462 Bug ID: 95462 Summary: Different int types for the same call to gcc_jit_context_get_int_type() Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- Hi. Sometimes, when I call gcc_jit_context_get_int_type(ctxt, 8, 1), I will get a long, and sometimes I will get a long long. On my platform, they are the same, but libgccjit will complain when giving a long where a long long was expected. What I suggest is to be able to get the sized type, like int64_t. Could you please add all sized integer types (like int64_t) in the enum gcc_jit_types? Thanks.
[Bug jit/95470] New: Type checking too rigid for shifts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95470 Bug ID: 95470 Summary: Type checking too rigid for shifts Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- Hi. It seems the type checking for gcc_jit_context_new_binary_op (GCC_JIT_BINARY_OP_LSHIFT) is too rigid. For instance, you cannot shift an unsigned number with a negative (signed number) because it wants both type to match. I think it would make sense to allow a negative shift for unsigned numbers. Thanks.
[Bug jit/95426] libgccjit.so: error: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95426 --- Comment #6 from bouanto at zoho dot com --- Any idea how I should change the generated code to make it work? Or will a patch not require changing the generated code? Thanks.
[Bug jit/95306] Getting __builtin_sadd_overflow gives the error "unimplemented primitive type for builtin: 42"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95306 --- Comment #4 from bouanto at zoho dot com --- Thanks for all your work. I'm now facing this issue with the builtin __atomic_load: libgccjit.so: error: unimplemented primitive type for builtin (type: BT_CONST_VOLATILE_PTR) Can you add support for this type as well, please?
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 bouanto at zoho dot com changed: What|Removed |Added CC||bouanto at zoho dot com --- Comment #2 from bouanto at zoho dot com --- I'd like to have inline asm support as well. I would see an API like this: For global asm: gcc_jit_context_add_module_asm(gcc_jit_context* ctxt, gcc_jit_location* loc, const char* asm) For local (in function) asm: gcc_jit_function* gcc_jit_block_add_inline_asm(gcc_jit_block* block, gcc_jit_location* loc, gcc_jit_type* return_type, int num_params, gcc_jit_params** params, const char* asm, const char* constraints, bool has_side_effects, bool align_stack, enum gcc_jit_asm_dialect dialect) This will return a function that can then be called as usual with gcc_jit_context_new_call. The return type of the function can either be void, a single value or a struct depending on the constraints. In my case I would need the asm dialects Intel and ATT. Maybe has_side_effects and align_stack could be rvalues: I'm not sure. Thanks.
[Bug jit/95498] New: unhandled conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95498 Bug ID: 95498 Summary: unhandled conversion Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- Created attachment 48667 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48667&action=edit Reproducer for the bug Hi. The attached reproducer fails with the following error: libgccjit.so: error: unhandled conversion input expression: constant visited 1> requested type: constant 32> unit-size constant 4> align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fd8f5a56d20 precision:32 min max > libgccjit.so: error: unhandled conversion input expression: unit-size align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fd8f591e888 precision:64 min max pointer_to_this > visited arg:0 visited arg:0 visited unsigned DI (null):0:0 size unit-size align:64 warn_if_not_align:0 context chain >> arg:1 readonly constant visited arg:0 arg:1 >> requested type: constant 32> unit-size constant 4> align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fd8f5a56d20 precision:32 min max > libgccjit.so: error: unhandled conversion input expression: requested type: constant 32> unit-size constant 4> align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type 0x7fd8f591e690 precision:32 min max pointer_to_this > gcc_jit_result_release: NULL result Sorry for the size of the reproducer. If you need to, I can try making it smaller. Thanks to fix this bug.
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291
--- Comment #4 from bouanto at zoho dot com ---
Oh, maybe it wasn't clear, but what I meant by constraints is: the output
operands, the input operands, and clobbers.
I guess we could make multiple parameters in the function for those.
For the things like (old) in "=r" (old), those would simply be sent as
arguments to the returned function.
So, an example like this:
```c
bool old;
__asm__ ("btsl %2,%1\n\t" // Turn on zero-based bit #Offset in Base.
"sbb %0,%0" // Use the CF to calculate old.
: "=r" (old), "+rm" (*Base)
: "Ir" (Offset)
: "cc");
```
would be created like this:
```c
gcc_jit_field *field_old = gcc_jit_context_new_field(ctxt, NULL, bool_type,
"old");
gcc_jit_field *field_base = …
gcc_jit_field *fields[2] = {field_bool, field_base};
gcc_jit_struct *return_type = gcc_jit_context_new_struct_type (ctxt, NULL,
"return_type", 2, fields);
gcc_jit_type *param_type = …
gcc_jit_param *param = gcc_jit_context_new_param(ctxt, NULL, param_type,
"param_offset")
bool is_volatile = false;
bool align_stack = false; // Does gcc have this option?
enum gcc_jit_asm_dialect dialect = GCC_JIT_ASM_DIALECT_INTEL;
gcc_jit_function* function = gcc_jit_block_add_extended_asm(block, NULL,
return_type, 1, ¶m,
"btsl %2,%1\n\t"
"sbb %0,%0", "=r,+rm" /* for "=r" and "+rm", it's comma-separated */, "Ir",
"cc", is_volatile, align_stack, dialect);
gcc_jit_context_new_call(ctxt, function, NULL, 1, &offset_rvalue); // This
returns the struct whose type was defined earlier.
```
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291
--- Comment #6 from bouanto at zoho dot com ---
(In reply to Andrew Pinski from comment #5)
> (In reply to bouanto from comment #4)
> > So, an example like this:
> >
> > ```c
> > bool old;
> > __asm__ ("btsl %2,%1\n\t" // Turn on zero-based bit #Offset in Base.
> > "sbb %0,%0" // Use the CF to calculate old.
> >: "=r" (old), "+rm" (*Base)
> >: "Ir" (Offset)
> >: "cc");
>
> Could we instead try to get this produced from normal gimple/C code?
I'm not sure I understand what you mean here? Does what you suggest change the
API in any way?
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 --- Comment #9 from bouanto at zoho dot com --- Ok, so you would go without a function-like API. I think you're missing a few parameters here, like the ASM dialect (intel vs ATT) unless that would be the string ".intel_syntax;" at the start of the asm_template. Also, the parameter location might be missing. Does gcc provide a way to specify whether the stack should be aligned properly, or is it done automatically, or should it be specified manually in asm_template with a string like ".align 32"? (In reply to David Malcolm from comment #8) > Reading the docs for extended asm, I think the API entrypoint would need to > look something like: > > extern void > gcc_jit_block_add_extended_asm (gcc_jit_block *block, > int is_volatile, > int is_inline, > const char *asm_template, > int num_output_operands, > gcc_jit_asm_operand **output_operands, > int num_input_operands, > gcc_jit_asm_operand **input_operands, > int num_clobbers, > const char **clobbers, > int num_goto_labels, > gcc_jit_block **goto_labels); > > which is a lot of arguments, and we'd also need a way to create > gcc_jit_asm_operand instances. > > If there are goto_labels, then the asm is implicitly "goto"-qualified; the > asm also is treated as potentially falling through to whatever is after it > in the block; it doesn't terminated its gcc_jit_block.
[Bug jit/95521] New: libgccjit.so: error: in build2, at tree.c:4743
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95521 Bug ID: 95521 Summary: libgccjit.so: error: in build2, at tree.c:4743 Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- Created attachment 48672 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48672&action=edit Reproducer for this bug Hi. I get the following error with the attached reproducer: libgccjit.so: error: in build2, at tree.c:4743 0x7faff2a7ca97 build2(tree_code, tree_node*, tree_node*, tree_node*) ../../gcc/gcc/tree.c:4743 0x7faff2d61116 gcc::jit::playback::context::new_binary_op(gcc::jit::playback::location*, gcc_jit_binary_op, gcc::jit::playback::type*, gcc::jit::playback::rvalue*, gcc::jit::playback::rvalue*) ../../gcc/gcc/jit/jit-playback.c:867 0x7faff2d4c9ba gcc::jit::recording::assignment_op::replay_into(gcc::jit::playback::context*) ../../gcc/gcc/jit/jit-recording.c:5948 0x7faff2d4d548 gcc::jit::recording::context::replay_into(gcc::jit::playback::context*) ../../gcc/gcc/jit/jit-recording.c:688 0x7faff2d5b6e4 gcc::jit::playback::context::replay() ../../gcc/gcc/jit/jit-playback.c:2734 The reproducer is very big, so tell me if you want me to try to make it smaller. Thanks.
[Bug jit/95522] New: error: builtin "__builtin_choose_expr" not found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95522 Bug ID: 95522 Summary: error: builtin "__builtin_choose_expr" not found Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- Hi. Trying to get the builtin __builtin_choose_expr gives the following error: libgccjit.so: error: builtin "__builtin_choose_expr" not found Thanks to add this builtin.
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 --- Comment #12 from bouanto at zoho dot com --- Since there would be many options, we could use a bitflags parameter instead of having multiple parameters for the options.
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 --- Comment #15 from bouanto at zoho dot com --- (In reply to David Malcolm from comment #14) > Or even move the flags to API calls: > > extern gcc_jit_extended_asm * > gcc_jit_block_add_extended_asm (gcc_jit_block *block, > const char *asm_template); > // location? > extern void > gcc_jit_extended_asm_set_volatile_flag (gcc_jit_extended_asm *ext_asm, > int flag); > extern void > gcc_jit_extended_asm_set_inline_flag (gcc_jit_extended_asm *ext_asm, > int flag); I'm okay with either way. For top-level assembly, I guess we can have a similar function, but without the parameters that would not be needed.
[Bug jit/95521] libgccjit.so: error: in build2, at tree.c:4743
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95521 --- Comment #4 from bouanto at zoho dot com --- Created attachment 48674 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48674&action=edit Smaller bug reproducer Here's a smaller bug reproducer.
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 --- Comment #18 from bouanto at zoho dot com --- See answers below. (In reply to David Malcolm from comment #16) > Created attachment 48677 [details] > Work-in-progress patch > > I had a go at implementing this; attached is a work-in-progress prototype. > > It works for simple cases (albeit with various TODO/FIXME items). > > See the test case at the end of the patch for two examples of usage. > > How does it look? This API looks good. > > Various issues that occurred to me while prototyping this: > > "gotos"/labels/control flow > > The new entrypoint "gcc_jit_block_add_extended_asm" in the patch assumes no > control flow, and libgccjit enforces a requirement that gcc_jit_blocks are > terminated. > > If there are to be conditional jumps, then I think we need a 2nd entrypoint > "gcc_jit_block_end_with_asm" or somesuch that takes an array of > gcc_jit_blocks and terminates the gcc_jit_block. Rather than having a jump > vs implicitly falling through, you'd have to specify both destination blocks. I'm fine with this gcc_jit_block_end_with_asm function, but does a compiler usually need that? I'm not sure it's needed. How would a compiler know what are the jumps from the inline asm? (Maybe I don't understand what's going on in this case.) > > "Basic" asm > > Do we actually need "basic" asm (as opposed to extended asm)? > In particular I'm wary about asm code that's outside of any given function. > Is that needed? That's something I use in my compiler, so that would be very appreciated if you could add this. > > asm dialects > > I'm ignoring this in the prototype. I would prefer not to expose > dialect-selection as a first-class entrypoint in the libgccjit API as it > touches the interaction with the driver, and libgccjit uses the driver code > in a weird way compared with the rest of GCC. Perhaps you'd be able to > affect it via e.g. gcc_jit_context_add_driver_option. It seems in inline assembly in gcc supports starting the template with ".intel_syntax;" to set the intel dialect. Would that work in this case? Thanks for your work.
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 --- Comment #20 from bouanto at zoho dot com --- Well, there's syntax for assembly at the top-level so the user can enter anything he wants, like in C. I can craft you an example if you need to, though. (In reply to David Malcolm from comment #19) > (In reply to bouanto from comment #18) > > (In reply to David Malcolm from comment #16) > > > Created attachment 48677 [details] > > This API looks good. > > Thanks. > > [...snip...] > > > > "Basic" asm > > > > > > Do we actually need "basic" asm (as opposed to extended asm)? > > > In particular I'm wary about asm code that's outside of any given > > > function. > > > Is that needed? > > > > That's something I use in my compiler, so that would be very appreciated if > > you could add this. > > Can you give concrete example(s) please? I'm having trouble thinking > through how this would work. > > [...snip...]
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 --- Comment #23 from bouanto at zoho dot com --- Created attachment 48685 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48685&action=edit Example of global assembly See answers below. (In reply to David Malcolm from comment #22) > Created attachment 48684 [details] > Updated work-in-progress patch which adds "asm goto" support > > Here's an updated version of the patch which adds "asm goto" support. grep > for test_i386_basic_asm_3a to see an example. > > Also uploaded to: > https://dmalcolm.fedorapeople.org/gcc/2020-06-05/0001-FIXME-WIP-on-extended- > asm-support-v2.patch > > Does this API make sense? Yes, now I understand what you meant. The API looks good. > I could use a concrete example of what you might use in C. > An issue is ordering: in C, these top-level statements presumably are ordered > relative to each other and the function bodies, based on the order they're > seen > by the parser (though I'm guessing here). Would something similar happen > based > on the order of calls to gcc_jit_context_new_function? I attached an example of global assembly. I don't understand the ordering issue. I also don't understand how gcc_jit_context_new_function is used here.
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 --- Comment #25 from bouanto at zoho dot com --- (In reply to David Malcolm from comment #24) > (In reply to bouanto from comment #23) > > Created attachment 48685 [details] > > Example of global assembly > > [...snip; thanks for the feedback] > > > I attached an example of global assembly. > > Thanks. > > > I don't understand the ordering issue. > > I also don't understand how gcc_jit_context_new_function is used here. > > I see that you have a balanced .pushsection/.popsection pair in your > example. Is it ever the case that people might want to have a .pushsection, > then some C code, then a .popsection? (and, by analogy, the same for > libgccjit rather than C). That's the ordering issue I'm concerned about, > since at that point it matters what order the hand-written asm is in > relative to the compiler-generated asm. I think we can assume that people won't try to mix top-level assembly and C code. So, we can assume the order won't matter and document this behavior.
[Bug jit/95498] unhandled conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95498 --- Comment #1 from bouanto at zoho dot com --- I'm trying to create a smaller reproducer by calling gcc_jit_context_dump_to_file, but I don't know where to stop in gdb in order to get the source info. How did you do it in https://gcc.gnu.org/bugzilla//show_bug.cgi?id=95521 ?
[Bug jit/95498] unhandled conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95498 --- Comment #3 from bouanto at zoho dot com --- (In reply to David Malcolm from comment #2) > Try putting a breakpoint on add_error (there are a few classes with > add_error methods; a sufficiently smart gdb ought to put the breakpoint on > all of them). I added the call to gcc_jit_context_dump_to_file (ctxt, "/tmp/something.c", 1 /* update_locations */); right after create_code(ctxt) but the parameter loc is NULL when I reach add_error in gdb so that I cannot print the line number. It was also null when I tried with the reproducer of this issue: https://gcc.gnu.org/bugzilla//show_bug.cgi?id=95521 Is there anything else to change in the reproducer so that it updates the locations accordingly?
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291
--- Comment #29 from bouanto at zoho dot com ---
This API looks fine.
Another test would be to create a simple function, the equivalent of this:
#include
asm(
"add:\n"
"movq %rdi, %rax\n"
"add %rsi, %rax\n"
"ret\n");
extern int add(int, int);
int main(void) {
assert(add(40, 2) == 42);
}
(In reply to David Malcolm from comment #27)
> Created attachment 48694 [details]
> v3 of the work-in-progress patch
>
> Here's an updated version of the patch; also uploaded to:
> https://dmalcolm.fedorapeople.org/gcc/2020-06-06/0001-FIXME-WIP-on-extended-
> asm-support-v3.patch
>
> In particular, this adds a new:
> gcc_jit_context_add_top_level_asm
> entrypoint. On implementing this, it hooks into the symbol table like the C
> frontend does, so it looks like it will respect ordering as much as the C
> frontend does.
>
> How does this look? The top-level asm code is barely tested though; I'd
> appreciate a way to verify it from the automated test case.
>
> Changes in v3:
> * added gcc_jit_context_add_top_level_asm
> * drop redundant gcc_jit_extended_asm_add_goto_label
> * added gcc_jit_extended_asm_as_object
> * started adding documentation
> * added comments to libgccjit.h
> * consolidated test-asm.c, grouping create/verify pairs
> * add test coverage for "volatile"
> * initial implementation of make_debug_string
> * added some error-checking
[Bug jit/87291] Add support for inline asm to libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87291 --- Comment #32 from Antoni --- Thanks; that looks really nice. The function gcc_jit_context_add_top_level_asm might be missing a location parameter. (In reply to David Malcolm from comment #31) > Created attachment 48704 [details] > v4 of the patch > > v4 patch, close to being finished (I hope) > > Also uploaded to: > > https://dmalcolm.fedorapeople.org/gcc/2020-06-08/0001-FIXME-WIP-on-extended- > asm-support-v4.patch > > C API docs: > > https://dmalcolm.fedorapeople.org/gcc/2020-06-08/jit-html-docs/topics/asm. > html > C++ API docs: > > https://dmalcolm.fedorapeople.org/gcc/2020-06-08/jit-html-docs/cp/topics/asm. > html
[Bug jit/95498] unhandled conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95498 --- Comment #4 from Antoni --- Created attachment 48829 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48829&action=edit Smaller reproducer for the bug I was able to reduce the size of the reproducer. I attached it.
[Bug jit/96066] New: Cannot use values from some builtins because they are of void type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96066 Bug ID: 96066 Summary: Cannot use values from some builtins because they are of void type Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- Hi. Some builtin functions, like __atomic_fetch_add, have a generic return type which libgccjit consider to be void. That makes it impossible to use this value. Thanks to fix this issue.
[Bug jit/96067] New: __atomic_compare_exchange_n should return bool instead of void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96067 Bug ID: 96067 Summary: __atomic_compare_exchange_n should return bool instead of void Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- Hi. The builtin __atomic_compare_exchange_n returns a void instead of bool. Thanks to fix this issue.
[Bug jit/96067] __atomic_compare_exchange_n should return bool instead of void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96067 --- Comment #2 from Antoni --- Created attachment 48835 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48835&action=edit Reproducer for thebug Here's a reproducer for the bug. The doc says it should return bool (https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html), but this reproducer shows the following error: libgccjit.so: error: gcc_jit_block_end_with_return: mismatching types: return of __atomic_compare_exchange_n ((&var), (&var), (int)0, (bool)0, (int)0, (int)0) (type: void) in function hello (return type: bool)
[Bug jit/96079] New: Unresolved atomic builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96079 Bug ID: 96079 Summary: Unresolved atomic builtins Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- Created attachment 48836 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48836&action=edit Reproducer Hi. When I try to use an atomic builtin, it gives an error like: libgccjit.so: error: /tmp/libgccjit-1VoggR/fake.so: undefined symbol: __atomic_store_n I tried setting the arch with: gcc_jit_context_add_command_line_option(ctxt, "-march=x86-64"); but it didn't change anything. >From inspecting the source code of gcc, it seems it does not support that yet because it does not call resolve_overloaded_builtin (I might be wrong, I don't have much knowledge of the gcc codebase). So, is there a way to do that currently or is it a bug? Thanks.
[Bug jit/96089] New: Support initializers for global variables.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96089 Bug ID: 96089 Summary: Support initializers for global variables. Product: gcc Version: 10.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- Hi. It would be nice to be able to set an initializer for global variables. There were some discussion about it there: https://gcc.gnu.org/pipermail/jit/2020q2/001215.html Thanks.
[Bug jit/96066] Cannot use values from some builtins because they are of void type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96066 --- Comment #2 from Antoni --- An attempt to use, let's say, __atomic_fetch_add_4, will result in a error like: libgccjit.so: error: unimplemented primitive type for builtin (type: BT_I4)
[Bug jit/95498] unhandled conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95498
--- Comment #6 from Antoni ---
(In reply to Alex Coplan from comment #5)
> Created attachment 48867 [details]
> Minimal reproducer
>
> I've done some exhaustive testing of which combinations of casts are
> allowed. It seems that any program of the following form is rejected with
> "unhandled conversion":
>
> T f(T x)
> {
> return (T)(U)x;
> }
>
> where T and U are integral types with U being strictly wider than T.
>
> I've attached a minimal handwritten testcase that reproduces the issue. You
> should be able to substitute the values passed to t_outer and t_inner for
> other types and still reproduce the issue, provided that t_outer is a
> strictly narrower type than t_inner.
Yeah, that's what I figured out.
I sent a patch:
https://gcc.gnu.org/pipermail/jit/2020q3/001228.html
I'd like to have a review of it.
[Bug jit/96889] New: Reflection API accessible from the jit C API
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96889 Bug ID: 96889 Summary: Reflection API accessible from the jit C API Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- Hi. There are some functions that would be useful to have in the C API of libgccjit like a function to get the number of parameters of a function or its return type. I'll send the patch very soon. There are probably other reflection functions that would be useful as well: I'll add them to the patch later.
[Bug jit/96889] Reflection API accessible from the jit C API
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96889 --- Comment #1 from Antoni --- Created attachment 49173 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49173&action=edit Patch with new functions
[Bug jit/100242] New: libgccjit.so: error: in expmed_mode_index, at expmed.h:249
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100242 Bug ID: 100242 Summary: libgccjit.so: error: in expmed_mode_index, at expmed.h:249 Product: gcc Version: 10.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- Created attachment 50664 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50664&action=edit First part of the compressed reproducer Hi. I get the following error for the attached reproducer: during RTL pass: expand libgccjit.so: error: in expmed_mode_index, at expmed.h:249 0x7f0da2e61a35 expmed_mode_index ../../../gcc/gcc/expmed.h:249 0x7f0da2e61aa4 expmed_op_cost_ptr ../../../gcc/gcc/expmed.h:271 0x7f0da2e620dc sdiv_cost_ptr ../../../gcc/gcc/expmed.h:540 0x7f0da2e62129 sdiv_cost ../../../gcc/gcc/expmed.h:558 0x7f0da2e73c12 expand_divmod(int, tree_code, machine_mode, rtx_def*, rtx_def*, rtx_def*, int) ../../../gcc/gcc/expmed.c:4335 0x7f0da2ea1423 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) ../../../gcc/gcc/expr.c:9240 0x7f0da2cd1a1e expand_gimple_stmt_1 ../../../gcc/gcc/cfgexpand.c:3796 0x7f0da2cd1c30 expand_gimple_stmt ../../../gcc/gcc/cfgexpand.c:3857 0x7f0da2cd90a9 expand_gimple_basic_block ../../../gcc/gcc/cfgexpand.c:5898 0x7f0da2cdade8 execute ../../../gcc/gcc/cfgexpand.c:6582 The reproducer was so big that I needed to compress it and split it in 3 files, so you'll have to cat the 3 files together and uncompress it. (If you could also explain to me how to find out where exactly is the issue in the reproducer in order to make it smaller and easier to debug, I'd appreciate.) Thanks to fix this issue.
[Bug jit/100242] libgccjit.so: error: in expmed_mode_index, at expmed.h:249
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100242 --- Comment #1 from Antoni --- Created attachment 50665 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50665&action=edit Second part of the reproducer
[Bug jit/100242] libgccjit.so: error: in expmed_mode_index, at expmed.h:249
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100242 --- Comment #2 from Antoni --- Created attachment 50666 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50666&action=edit Third part of the reproducer
[Bug jit/100242] libgccjit.so: error: in expmed_mode_index, at expmed.h:249
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100242 --- Comment #3 from Antoni --- Created attachment 50668 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50668&action=edit Smaller reproducer Ok, I figured out how to find the location of the error. In this case, it's caused by using the modulo operation on floats. I guess it should either be forbidden or use the `fmodf` intrinsics.
[Bug jit/100380] New: Segfault when using inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100380 Bug ID: 100380 Summary: Segfault when using inline asm Product: gcc Version: 10.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- Created attachment 50729 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50729&action=edit Reproducer for the bug Hi. The attached example produce a segfault when trying to compile code using inline assembly. Thanks.
[Bug jit/100380] Segfault when using inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100380 Antoni changed: What|Removed |Added Attachment #50729|0 |1 is obsolete|| --- Comment #1 from Antoni --- Created attachment 50730 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50730&action=edit Fixed reproducer
[Bug jit/100380] Segfault when using inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100380 --- Comment #2 from Antoni --- Created attachment 50731 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50731&action=edit Working code So, the segfault seems to happen when creating the variable after creating the extended asm expression. Here's a working version of the code.
[Bug jit/100380] Segfault when using inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100380 --- Comment #4 from Antoni --- I just had a similar issue when developing a new feature for libgccjit and it might be the same problem. If it is (I haven't checked in this case), here's what's happening: * The asm is replayed. * The asm tries to access the replayed variable (which wasn't replayed yet because it was created after the asm). * Segfault (the rest is not executed, but is shown to explain what's happening) * The variable is replayed (too late because it was NULL when accessed by the asm). Again it's to be verified, and I'm not sure what should be the solution to this problem because the mementos are replayed in the order they were created.
[Bug jit/100380] Segfault when using inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100380 --- Comment #5 from Antoni --- I can confirm that the problem is indeed what I described in my previous post. One solution would be to check if the rvalue was replayed (and if not, replay it now), but that involves adding this check everywhere, so that seems very invasive. Do you think there's a better solution?
[Bug jit/96079] Unresolved atomic builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96079 Antoni changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Antoni --- The actual call should be with a number instead of `n`, i.e. `__atomic_store_4`.
[Bug jit/96066] Cannot use values from some builtins because they are of void type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96066 --- Comment #3 from Antoni --- Created attachment 50832 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50832&action=edit Patch to fix the issues with using atomic builtins I implemented the missing types and fixed the type checking.
[Bug jit/96066] Cannot use values from some builtins because they are of void type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96066 --- Comment #4 from Antoni --- *** Bug 96067 has been marked as a duplicate of this bug. ***
[Bug jit/96067] __atomic_compare_exchange_n should return bool instead of void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96067 Antoni changed: What|Removed |Added Resolution|--- |DUPLICATE Status|ASSIGNED|RESOLVED --- Comment #4 from Antoni --- Closing in favor of 96066. That should be using a number instead of `n` as in `__atomic_compare_exchange_4`. *** This bug has been marked as a duplicate of bug 96066 ***
[Bug jit/95325] Support 128-bit integers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95325 --- Comment #1 from Antoni --- Created attachment 50835 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50835&action=edit Patch add support for sized integer types That patch not only add support for 128-bit integers, but also all other sized integers.
[Bug jit/95415] Add support for thread-local variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95415 --- Comment #3 from Antoni --- Created attachment 50842 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50842&action=edit Patch to add this feature I created a patch to add TLS variables.
[Bug jit/100688] New: Add support for link section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100688
Bug ID: 100688
Summary: Add support for link section
Product: gcc
Version: 10.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: jit
Assignee: dmalcolm at gcc dot gnu.org
Reporter: bouanto at zoho dot com
Target Milestone: ---
Hi.
I'd like support to set the link section (i.e.
`__attribute__((section(".section")))`) in libgccjit.
A patch will follow soon.
[Bug jit/100688] Add support for link section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100688 --- Comment #1 from Antoni --- Created attachment 50847 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50847&action=edit Patch adding support for setting the link section
[Bug jit/100688] Add support for link section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100688 --- Comment #3 from Antoni --- I develop a gcc codegen for the Rust compiler and it's a feature of Rust to be able to set the link section: https://github.com/antoyo/rustc_codegen_gcc/commit/999f768526d72e19e3eafdc963dcb6af8a1afe60#diff-6bbb01450b42befd6551add5fd3f53dd6a0ebd54f6f32c20cef02246521bd490R19 One of the use cases is in the standard library: https://github.com/rust-lang/rust/blob/7e11f3a8f3c1b2683125e7def0acb68a6d684f92/library/std/src/sys/unix/args.rs#L112
[Bug jit/100688] Add support for link section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100688 --- Comment #5 from Antoni --- This is much less work as I'm reusing the rustc front-end.
[Bug jit/96089] Support initializers for global variables.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96089 --- Comment #2 from Antoni --- Created attachment 50851 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50851&action=edit Add patch to set an arbitrary value to a global variable I made this patch to set an arbitrary value to a global variable. This patch suffers from the same issue as inline assembly (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100380), i.e. it segfaults if the `rvalue` is created after the global variable. It seems to be a design issue so I'm not sure what would be the fix for it and having it fixed would allow me to test this new function much more and see if things are missing (i.e. it might require a way to create a constant struct). See the link above for an explanation of this issue.
[Bug jit/96089] Support initializers for global variables.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96089 Antoni changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Antoni --- This can be closed as this was done in 3736837806fdb26daa51300bee1554bef89db9fe.
[Bug jit/107999] [13 Regression] jit.dg/test-error-array-bounds.c now fails because [-Warray-bounds] was updated to [-Warray-bounds=] in error messages after r13-4410-g7c01d029fca669263b9c2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107999 --- Comment #1 from Antoni --- Patch posted here: https://gcc.gnu.org/pipermail/jit/2022q4/001594.html
[Bug jit/108762] New: Add support for target-dependent builtins in libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108762 Bug ID: 108762 Summary: Add support for target-dependent builtins in libgccjit Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- I'll soon post a patch for this.
[Bug jit/108762] Add support for target-dependent builtins in libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108762 --- Comment #1 from Antoni --- Created attachment 54452 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54452&action=edit Add support for machine-dependant builtins
[Bug jit/104071] New: Add support for bitcast
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104071 Bug ID: 104071 Summary: Add support for bitcast Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- Hi. I'm opening this issue to track my upcoming patch to add support for bitcasts in libgccjit.
[Bug jit/104072] New: Register variables in libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104072 Bug ID: 104072 Summary: Register variables in libgccjit Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- Hi. I'm opening this issue to track my upcoming patch adding support for register variables in libgccjit.
[Bug jit/104073] New: Add option to hide stderr logging in libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104073 Bug ID: 104073 Summary: Add option to hide stderr logging in libgccjit Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- Hi. One issue I have for my work on adding support for 128-bit integers is that the way libgccjit works does not allow knowing before compiling whether those integers are supported on the target platform. As such, one workaround I have to know if they are supported is to create this type and compile using the JIT. If there is an error, I know the type is not supported. The problem is that this will show the error on stderr, which is problematic in rustc_codegen_gcc as rust expects no output there in some cases. Unless you have a better idea for checking if this type is supported, I could use my workaround if we add an option to hide stderr logging in libgccjit. I have an upcomming patch for this.
[Bug jit/104293] New: Add support for setting the alignment of variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104293 Bug ID: 104293 Summary: Add support for setting the alignment of variables Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- Hi. I'm opening this issue to track my upcoming patch adding support for setting the alignment of variables in libgccjit.
[Bug jit/95325] Support 128-bit integers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95325 --- Comment #3 from Antoni --- No. The only patch that is ready for review is "libgccjit: add some reflection functions in the jit C api".
[Bug jit/96889] Reflection API accessible from the jit C API
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96889 Antoni changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Antoni --- Fixed in master.
[Bug jit/96066] Cannot use values from some builtins because they are of void type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96066 Antoni changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #6 from Antoni --- Fixed in master.
[Bug jit/95415] Add support for thread-local variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95415 Antoni changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #6 from Antoni --- Merged in master.
[Bug jit/100688] Add support for link section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100688 Antoni changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #10 from Antoni --- Fixed in master.
[Bug jit/100380] Segfault when using inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100380 --- Comment #7 from Antoni --- Since then, I found a workaround to fix the similar segfault in my other feature. It might work for solving this and goes like this: instead of trying to access the rvalue when first replaying the asm, create an intermediate memento that does the work of add_output_operand (and most likely the other actions like add_input_operand). It works since this memento will necessarily be created after both the asm and the variable and thus, both will have been replayed when it's time to replay the new 'add_output_operand' memento.
[Bug jit/107770] New: Comparison of vectors of float doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107770 Bug ID: 107770 Summary: Comparison of vectors of float doesn't work Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- I'll soon post a patch to fix this.
[Bug target/107863] New: ICE with unrecognizable insn when using -funsigned-char with some AVX builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107863
Bug ID: 107863
Summary: ICE with unrecognizable insn when using
-funsigned-char with some AVX builtins
Product: gcc
Version: 12.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: bouanto at zoho dot com
Target Milestone: ---
Hi.
When I compile the following code:
#include
int main(int argc, char* argv[]) {
__m256i a = _mm256_set1_epi8(4);
__m256i b = _mm256_set1_epi8(2);
__m256i mask = _mm256_insert_epi8(_mm256_set1_epi8(0), -1, 2);
__m256i r = (__m256i) __builtin_ia32_pblendvb256 ((__v32qi)a, (__v32qi)b,
(__v32qi)mask);
return 0;
}
with the following command:
gcc main.c -o main -mavx512f -funsigned-char
I get the following error:
main.c: In function ‘main’:
main.c:9:1: error: unrecognizable insn:
9 | }
| ^
(insn 655 654 656 2 (set (reg:QI 607)
(const_int 255 [0xff])) "main.c":6:20 -1
(nil))
during RTL pass: vregs
main.c:9:1: internal compiler error: in extract_insn, at recog.cc:2791
0x1840d78 internal_error(char const*, ...)
???:0
0x62a3ac fancy_abort(char const*, int, char const*)
???:0
0x60555b _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
???:0
0x60557d _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
???:0
The code compiles when not using -funsigned-char.
I'm not sure what would be the fix for this. Would it make sense that builtins
never use the char type, but instead use either unsigned char or signed char?
[Bug jit/107999] New: test-error-array-bounds.c now fails because [-Warray-bounds] was updated to [-Warray-bounds=] in error messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107999 Bug ID: 107999 Summary: test-error-array-bounds.c now fails because [-Warray-bounds] was updated to [-Warray-bounds=] in error messages Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- The error message needs to be updated to make this test pass again.
[Bug jit/107770] Comparison of vectors of float doesn't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107770 Antoni changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #2 from Antoni --- Fixed by commit d2e782cb99c3116c389d6a9565678c4ffe26.
[Bug jit/108078] New: Canot compare vector types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108078 Bug ID: 108078 Summary: Canot compare vector types Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- I'll soon post a patch to fix this.
[Bug jit/108078] Canot compare vector types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108078 Antoni changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Antoni --- Fixed on master.
[Bug jit/105812] New: type mismatch in binary expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105812 Bug ID: 105812 Summary: type mismatch in binary expression Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- When using a combination of unary and binary expressions on a boolean value, we can trigger the error "type mismatch in binary expression". I'm about to post a patch for this issue.
[Bug jit/105812] type mismatch in binary expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105812 --- Comment #1 from Antoni --- Created attachment 53067 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53067&action=edit Patch
[Bug jit/105827] New: Infinite recursion in gt_ggc_mx_lang_tree_node
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105827 Bug ID: 105827 Summary: Infinite recursion in gt_ggc_mx_lang_tree_node Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- There's an infinite recursion in gt_ggc_mx_lang_tree_node. I'm not sure how exactly to reproduce it or to test it, so if you have any idea of tests I could add, please share. I'll post the patch for this soon.
[Bug jit/105827] Infinite recursion in gt_ggc_mx_lang_tree_node
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105827 --- Comment #1 from Antoni --- Created attachment 53074 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53074&action=edit First patch
[Bug jit/105829] New: Allow getting the size of floating-point types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105829 Bug ID: 105829 Summary: Allow getting the size of floating-point types Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- Currently, it's only possible to get the size of integer types. I'll soon post a patch that adds support of getting the size of floating-point types.
[Bug jit/105829] Allow getting the size of floating-point types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105829 --- Comment #1 from Antoni --- Created attachment 53075 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53075&action=edit First patch
[Bug jit/105829] Allow getting the size of floating-point types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105829 Antoni changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Antoni --- I pushed the updated patch to master.
[Bug target/106095] New: Some AVX builtins produce invalid asm with -masm=intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106095 Bug ID: 106095 Summary: Some AVX builtins produce invalid asm with -masm=intel Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- Some builtins don't produce valid asm when using the flag `-masm=intel`: * __builtin_ia32_pmovdw128mem_mask * __builtin_ia32_cvtss2sd_mask_round * __builtin_ia32_cvtsd2ss_mask_round * __builtin_ia32_pmovqw256mem_mask * __builtin_ia32_pmovqw128mem_mask I'll soon post a patch fixing this issue.
[Bug target/106095] Some AVX builtins produce invalid asm with -masm=intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106095 --- Comment #1 from Antoni --- Created attachment 53212 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53212&action=edit patch fixing the bug
[Bug jit/105812] type mismatch in binary expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105812 Antoni changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Antoni --- Fixed on master.
[Bug target/106095] Some AVX builtins produce invalid asm with -masm=intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106095 Antoni changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Antoni --- Fixed in master.
[Bug jit/95498] unhandled conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95498 Antoni changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #8 from Antoni --- Fixed in master.
[Bug jit/113842] New: Assertion failure in assemble_external_libcall due to a missing finalizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113842 Bug ID: 113842 Summary: Assertion failure in assemble_external_libcall due to a missing finalizer Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- This happens when compiling code with try/catch, so not yet possible to trigger on master. I'll soon post the patch to fix this issue.
[Bug analyzer/113923] New: Segfault in gcc/gcc/tree-diagnostic.cc:265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113923 Bug ID: 113923 Summary: Segfault in gcc/gcc/tree-diagnostic.cc:265 Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: analyzer Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- Hi. I cannot easily produce a reproducer for this since I got this when compiling a Rust project (librsvg) via rustc_codegen_gcc. The project was compiled with this command: path/to/rustc_codegen_gcc/y.sh cargo rustc -p librsvg -- -Cllvm-args=-fanalyzer Here's the complete stacktrace: Thread 8 "opt cgu.14" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x77add5c006c0 (LWP 7805)] 0x77ae3edea93d in default_tree_printer (pp=0x77a86437ea10, text=0x77add5bf5540, spec=0x77a8b09c4241 "E", precision=0, wide=false, set_locus=false, hash=false) at ../../../gcc/gcc/tree-diagnostic.cc:265 265 if (TREE_CODE (t) == IDENTIFIER_NODE) (gdb) bt #0 0x77ae3edea93d in default_tree_printer (pp=0x77a86437ea10, text=0x77add5bf5540, spec=0x77a8b09c4241 "E", precision=0, wide=false, set_locus=false, hash=false) at ../../../gcc/gcc/tree-diagnostic.cc:265 #1 0x77ae408a8ab2 in pp_format (pp=0x77a86437ea10, text=0x77add5bf5540, urlifier=0x0) at ../../../gcc/gcc/pretty-print.cc:1704 #2 0x77ae407a6503 in make_label_text (can_colorize=false, fmt=0x77ae40edd909 "inlined call to %qE from %qE") at ../../../gcc/gcc/analyzer/analyzer.cc:494 #3 0x77ae407bbf30 in ana::inlined_call_event::get_desc (this=0x77a85fde16a0, can_colorize=false) at ../../../gcc/gcc/analyzer/checker-event.cc:1018 #4 0x77ae407b9d1a in ana::checker_event::prepare_for_emission (this=0x77a85fde16a0, pd=0x77a88c2e07a0, emission_id=...) at ../../../gcc/gcc/analyzer/checker-event.cc:230 #5 0x77ae407d83da in ana::checker_path::prepare_for_emission (this=0x77add5bf5900, pd=0x77a88c2e07a0) at ../../../gcc/gcc/analyzer/checker-path.h:108 #6 0x77ae407d40ac in ana::diagnostic_manager::emit_saved_diagnostic (this=0x77add5bf6210, eg=..., sd=...) at ../../../gcc/gcc/analyzer/diagnostic-manager.cc:1601 #7 0x77ae407d9742 in ana::dedupe_winners::emit_best (this=0x77add5bf5b40, dm=0x77add5bf6210, eg=...) at ../../../gcc/gcc/analyzer/diagnostic-manager.cc:1472 #8 0x77ae407d3cf0 in ana::diagnostic_manager::emit_saved_diagnostics (this=0x77add5bf6210, eg=...) at ../../../gcc/gcc/analyzer/diagnostic-manager.cc:1524 #9 0x77ae3f2031e9 in ana::impl_run_checkers (logger=0x0) at ../../../gcc/gcc/analyzer/engine.cc:6226 #10 0x77ae3f203582 in ana::run_checkers () at ../../../gcc/gcc/analyzer/engine.cc:6300 #11 0x77ae3f1f47bb in (anonymous namespace)::pass_analyzer::execute (this=0x77add5201000) at ../../../gcc/gcc/analyzer/analyzer-pass.cc:87 #12 0x77ae3ec00e1f in execute_one_pass (pass=0x77add5201000) at ../../../gcc/gcc/passes.cc:2646 #13 0x77ae3ec02074 in execute_ipa_pass_list (pass=0x77add5201000) at ../../../gcc/gcc/passes.cc:3095 #14 0x77ae3e6f4c62 in ipa_passes () at ../../../gcc/gcc/cgraphunit.cc:2270 #15 0x77ae3e6f4e82 in symbol_table::compile (this=0x77a90e2ccf00) at ../../../gcc/gcc/cgraphunit.cc:2333 #16 0x77ae3e6f54f8 in symbol_table::finalize_compilation_unit (this=0x77a90e2ccf00) at ../../../gcc/gcc/cgraphunit.cc:2585 #17 0x77ae3ed73932 in compile_file () at ../../../gcc/gcc/toplev.cc:474 #18 0x77ae3ed77568 in do_compile () at ../../../gcc/gcc/toplev.cc:2152 #19 0x77ae3ed77a1e in toplev::main (this=0x77add5bfb256, argc=20, argv=0x77add520f1c8) at ../../../gcc/gcc/toplev.cc:2308 #20 0x77ae3e5ccecb in gcc::jit::playback::context::compile (this=0x77add5bfb2f0) at ../../../gcc/gcc/jit/jit-playback.cc:2851 #21 0x77ae3e59f1e7 in gcc::jit::recording::context::compile_to_file (this=0x77ae039f6080, output_kind=GCC_JIT_OUTPUT_KIND_OBJECT_FILE, output_path=0x77add5216000 "/home/user/rustc_codegen_gcc/projects/librsvg/target/debug/deps/rsvg-85e1285dcdc7222b.rsvg.d0bf5dc3489ec5bd-cgu.14.rcgu.o") at ../../../gcc/gcc/jit/jit-recording.cc:1650 #22 0x77ae3e5963fb in gcc_jit_context_compile_to_file (ctxt=0x77ae039f6080, output_kind=GCC_JIT_OUTPUT_KIND_OBJECT_FILE, output_path=0x77add5216000 "/home/user/rustc_codegen_gcc/projects/librsvg/target/debug/deps/rsvg-85e1285dcdc7222b.rsvg.d0bf5dc3489ec5bd-cgu.14.rcgu.o") at ../../../gcc/gcc/jit/libgccjit.cc:3938 #23 0x77ae41b291eb in gccjit::context::Context::compile_to_file<&str> (self=0x77add5bfca48, kind=gccjit::context::OutputKind::ObjectFile, file=...) at /home/user/.cargo/git/checkouts/gccjit.rs-13c2e290f2fb9e4d/e6109eb/src/context.rs:276 #24 0x77ae41dee137 in rustc_codegen_gcc::back::write::codegen (cgcx=0x77add5bfdd38, diag_handler=0x77add5bfc7c0, module=..., config=0x77ae0f1df1f0) at
[Bug target/112575] Segfault in libgccjit due to not cleaning up some target specific cache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112575 Antoni changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #2 from Antoni --- This patch is not necessary anymore, presumable due to this: "However, as of r14-4003-geaa8e8541349df ggc_common_finalize zeroes everything marked with GTY. The array target_attribute_cache does have a GTY marking, so perhaps as of that commit this patch isn't necessary"
