[Bug rtl-optimization/114768] New: Volatile reads can be optimized away
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114768
Bug ID: 114768
Summary: Volatile reads can be optimized away
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: bouanto at zoho dot com
Target Milestone: ---
In the following code:
void test(int *ptr) {
*ptr = *(volatile int *)ptr;
}
The volatile read is optimized away and GCC produces the following asm:
test(int*):
ret
Godbolt link: https://gcc.godbolt.org/z/rabToGfqj
Clang produces the following code:
test(int*): # @test(int*)
mov eax, dword ptr [rdi]
ret
which is likely to be the expected behavior.
[Bug analyzer/113923] Segfault in gcc/gcc/tree-diagnostic.cc:265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113923 --- Comment #9 from Antoni --- Created attachment 57810 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57810=edit Patch to fix the issue I was unable to create a reproducer in C for the tests. It seems the problem was actually in libgccjit because it was not setting BLOCK_SUPERCONTEXT. I'm not sure how best to test it, though. The only idea I have would be to attempt to create a libgccjit test that adds -fanalyzer to its arguments. Do you have a better idea?
[Bug analyzer/114285] Use of uninitialized value when copying a struct field by field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114285 --- Comment #8 from Antoni --- Created attachment 57726 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57726=edit Reproducer using union I tried switching to a union and I still get the same error. A union is used by std::optional, so I would assume that this should work. Or is copying uninitialized memory via a union also UB?
[Bug analyzer/114285] Use of uninitialized value when copying a struct field by field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114285 --- Comment #5 from Antoni --- (In reply to Andrew Pinski from comment #3) > >Rust will sometimes copy uninitialized memory and I'd like to avoid > >disabling this specific warning. > > > Note in C, there are specific rules about copying unitialized memory. Most > is it is undefined. It is kinda of odd a "security" language like Rust > allows copying unitialized memory at all since a copy should be considered > an use ... So, if it is UB in C, it makes sense that the analyzer stays that way. However, I would need another solution to copy undefined memory using a different GIMPLE construct or something.
[Bug analyzer/114285] Use of uninitialized value when copying a struct field by field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114285 --- Comment #4 from Antoni --- (In reply to Andrew Pinski from comment #3) > >Rust will sometimes copy uninitialized memory and I'd like to avoid > >disabling this specific warning. > > > Note in C, there are specific rules about copying unitialized memory. Most > is it is undefined. It is kinda of odd a "security" language like Rust > allows copying unitialized memory at all since a copy should be considered > an use ... A load in LLVM returns undef, so it is not UB. The problem is in rustc_codegen_gcc itself.
[Bug analyzer/114285] New: Use of uninitialized value when copying a struct field by field
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114285 Bug ID: 114285 Summary: Use of uninitialized value when copying a struct field by field 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: --- Created attachment 57655 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57655=edit Reproducer for the bug Hi. Not sure if it's the same case as the other issues related to -Wanalyzer-use-of-uninitialized-value and I wanted to discuss this anyway. In rustc_codegen_gcc, I can get "use of uninitialized value" when using the Option type, which contains a value and whether there's a value or not. I tried to reproduce in C and I attached the reproducer. Not sure what we should do here. Copying the whole struct doesn't trigger any warning (should it?) and using memcpy doesn't fix the warning. Rust will sometimes copy uninitialized memory and I'd like to avoid disabling this specific warning. Should there be a dinstinction between copying uninitialized memory and using it? What are your thoughts on this? Thanks.
[Bug analyzer/113923] Segfault in gcc/gcc/tree-diagnostic.cc:265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113923
--- Comment #8 from Antoni ---
(In reply to David Malcolm from comment #2)
> inlined_call_event's ctor should probably assert that params
> tree apparent_callee_fndecl,
> tree apparent_caller_fndecl,
> are both non-NULL, which might catch the issue slightly early.
I added an assert and here's the stacktrace:
during IPA pass: analyzer
libgccjit.so: internal compiler error: : in inlined_call_event, at
analyzer/checker-event.h:578
0x73d4eafbf076 ana::inlined_call_event::inlined_call_event(unsigned int,
tree_node*, tree_node*, int, int)
../../../gcc/gcc/analyzer/checker-event.h:578
0x73d4eafbe7dd ana::checker_path::inject_any_inlined_call_events(ana::logger*)
../../../gcc/gcc/analyzer/checker-path.cc:319
0x73d4eafd415f
ana::diagnostic_manager::emit_saved_diagnostic(ana::exploded_graph const&,
ana::saved_diagnostic&)
../../../gcc/gcc/analyzer/diagnostic-manager.cc:1599
0x73d4eafd981d ana::dedupe_winners::emit_best(ana::diagnostic_manager*,
ana::exploded_graph const&)
../../../gcc/gcc/analyzer/diagnostic-manager.cc:1472
0x73d4eafd3dcb
ana::diagnostic_manager::emit_saved_diagnostics(ana::exploded_graph const&)
../../../gcc/gcc/analyzer/diagnostic-manager.cc:1524
0x73d4e9a0327a ana::impl_run_checkers(ana::logger*)
../../../gcc/gcc/analyzer/engine.cc:6226
0x73d4e9a03613 ana::run_checkers()
../../../gcc/gcc/analyzer/engine.cc:6300
0x73d4e99f484c execute
../../../gcc/gcc/analyzer/analyzer-pass.cc:87
I can also confirm that this is related to always_inline as there are no
segfaults when removing the #[inline(always)] in the following example (see
comment):
#![no_std]
#![allow(internal_features)]
#![feature(core_intrinsics, lang_items, start)]
#![feature(transparent_unions)]
use core::mem::ManuallyDrop;
#[panic_handler]
fn panic_handler(_: ::panic::PanicInfo<'_>) -> ! {
core::intrinsics::abort();
}
#[lang="eh_personality"]
fn eh_personality(){}
#[derive(Clone, Copy)]
#[repr(transparent)]
pub union MaybeUninit {
uninit: (),
value: ManuallyDrop,
}
impl MaybeUninit {
// NOTE: there are no segfaults when removing the next line.
#[inline(always)]
pub const fn uninit() -> MaybeUninit {
MaybeUninit { uninit: () }
}
}
#[start]
fn main(_argc: isize, _argv: *const *const u8) -> isize {
let mut x = MaybeUninit::<>::uninit();
0
}
[Bug analyzer/113923] Segfault in gcc/gcc/tree-diagnostic.cc:265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113923 --- Comment #7 from Antoni --- I don't know if this helps, but I added a small Rust reproducer that can trigger the segfault when compiled with rustc_codegen_gcc and the corresponding GIMPLE for this Rust reproducer.
[Bug analyzer/113923] Segfault in gcc/gcc/tree-diagnostic.cc:265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113923 --- Comment #6 from Antoni --- Created attachment 57439 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57439=edit Rust reproducer
[Bug analyzer/113923] Segfault in gcc/gcc/tree-diagnostic.cc:265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113923 --- Comment #5 from Antoni --- Created attachment 57438 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57438=edit GIMPLE for the Rust reproducer
[Bug analyzer/113923] Segfault in gcc/gcc/tree-diagnostic.cc:265
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113923 --- Comment #4 from Antoni --- I might be able to soon create a reproducer, but for now, I can say it might be related to __attribute__ ((always_inline)).
[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"
[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<>
(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 src/back/write.rs:124
#25 0x77ae41e25dc0 in rustc_codegen_gcc::{impl#8}::codegen
[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 regression/113722] New: Folding of __builtin_bswap128 doesn't work anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113722
Bug ID: 113722
Summary: Folding of __builtin_bswap128 doesn't work anymore
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
Assignee: unassigned at gcc dot gnu.org
Reporter: bouanto at zoho dot com
Target Milestone: ---
With the following code:
#include
int main(int argc, char* argv[]) {
__uint128_t res = __builtin_bswap128 (2);
printf("Value: %ld\n", res >> 64);
res = __builtin_bswap128 (argc + 1);
printf("Value: %ld\n", res >> 64);
}
it gives the following output in gcc 13.2.1:
Value: 144115188075855872
Value: 144115188075855872
while it gives the following output in the master branch, commit
2c27aa8d75113f404bf9cd39364611af386d9719:
Value: 0
Value: 144115188075855872
So it seems to be a regression in the folding of wide_int::bswap.
[Bug jit/113343] New: Float values are not correct when cross-compiling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113343 Bug ID: 113343 Summary: Float values are not correct when cross-compiling Product: gcc Version: 13.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- Values created by gcc_jit_context_new_rvalue_from_double are wrong when cross-compiling to an arch where the encoding of floats is different than the host. I'll soon post a patch for to fix this.
[Bug jit/112910] Getting the size of the type size_t returns the wrong value on some platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112910 --- Comment #3 from Antoni --- Yes, but it isn't available in recording. Perhaps I could use it with another solution that is in the work, though.
[Bug jit/112910] Getting the size of the type size_t returns the wrong value on some platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112910 --- Comment #1 from Antoni --- Created attachment 56831 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56831=edit Patch fixing this bug
[Bug jit/112910] New: Getting the size of the type size_t returns the wrong value on some platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112910 Bug ID: 112910 Summary: Getting the size of the type size_t returns the wrong value on some platforms Product: gcc Version: 13.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: jit Assignee: dmalcolm at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- It seems that MAX_BITS_PER_WORD is not the same as the size of size_t on some platforms.
[Bug jit/108762] Add support for target-dependent builtins in libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108762 Antoni changed: What|Removed |Added Attachment #54452|0 |1 is obsolete|| --- Comment #2 from Antoni --- Created attachment 56678 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56678=edit Patch v2
[Bug jit/112603] Allow setting the personality function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112603 --- Comment #1 from Antoni --- Created attachment 56628 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56628=edit Patch
[Bug jit/112603] New: Allow setting the personality function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112603 Bug ID: 112603 Summary: Allow setting the personality function Product: gcc Version: 13.1.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 send a patch for this.
[Bug jit/112602] Support vector permutation and access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112602 --- Comment #1 from Antoni --- Created attachment 56627 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56627=edit Patch
[Bug jit/112602] New: Support vector permutation and access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112602 Bug ID: 112602 Summary: Support vector permutation and access Product: gcc Version: 13.1.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 send a patch for this feature request.
[Bug target/112576] "unrecognizable insn" in libgccjit when using some target-specific builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112576 --- Comment #1 from Antoni --- Created attachment 56611 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56611=edit Patch
[Bug target/112576] New: "unrecognizable insn" in libgccjit when using some target-specific builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112576 Bug ID: 112576 Summary: "unrecognizable insn" in libgccjit when using some target-specific builtins Product: gcc Version: 13.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- I'll soon post a patch that fixes this.
[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 --- Comment #1 from Antoni --- Created attachment 56610 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56610=edit Patch
[Bug jit/112574] Add support for bfloat16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112574 --- Comment #1 from Antoni --- Created attachment 56609 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56609=edit Patch
[Bug target/112575] New: Segfault in libgccjit due to not cleaning up some target specific cache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112575 Bug ID: 112575 Summary: Segfault in libgccjit due to not cleaning up some target specific cache Product: gcc Version: 13.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: bouanto at zoho dot com Target Milestone: --- I'll soon post a patch to fix this.
[Bug jit/112574] New: Add support for bfloat16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112574 Bug ID: 112574 Summary: Add support for bfloat16 Product: gcc Version: 13.1.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/111396] Segfault when using -flto with libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111396 --- Comment #2 from Antoni --- Created attachment 56554 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56554=edit Patch fixing the issue
[Bug jit/112466] Add support for getting the supported CPU features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112466 --- Comment #1 from Antoni --- Created attachment 56547 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56547=edit Patch implementing this feature
[Bug jit/112466] New: Add support for getting the supported CPU features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112466 Bug ID: 112466 Summary: Add support for getting the supported CPU features Product: gcc Version: 13.1.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 have an incoming patch for this that I'll post soon.
[Bug jit/111396] New: Segfault when using -flto with libgccjit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111396 Bug ID: 111396 Summary: Segfault when using -flto with libgccjit Product: gcc Version: 13.1.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 55888 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55888=edit Reproducer for part of the bug Hi. There's a bug when compiling multiple times with -flto. I attached a reproducer for a part of the bug. (The other part of the bug should be fixed by https://gcc.gnu.org/pipermail/jit/2023q3/001668.html.)
[Bug lto/109854] New: Error: junk `(%rip)' after expression when using -flto on files compiled with and without -masm=intel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109854
Bug ID: 109854
Summary: Error: junk `(%rip)' after expression when using -flto
on files compiled with and without -masm=intel
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Assignee: unassigned at gcc dot gnu.org
Reporter: bouanto at zoho dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Hi.
With those two source files:
a.c:
#include
void a(void) {
puts("A");
}
main.c:
void a(void);
int main(void) {
a();
return 0;
}
and by running the following commands:
gcc -c -flto a.c # Note the absence of -masm=intel
gcc -masm=intel -O3 -flto a.o main.c -o main
I get the following error:
/tmp/cca9LQNs.s: Assembler messages:
/tmp/cca9LQNs.s:17: Error: junk `(%rip)' after expression
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/bin/ld: error: lto-wrapper failed
collect2: error: ld returned 1 exit status
Compiling the a.c file with -masm=intel solves the issue.
(Doing the opposite, that is compiling a.c with -masm=intel and main.c without
gives a different error: /usr/bin/ld: /tmp/ccMwJTwN.ltrans0.ltrans.o:
relocation R_X86_64_32S against undefined symbol `$8' can not be used when
making a PIE object; recompile with -fPIE
Please tell me if you want me to open a different issue for this case.)
Thanks to fix this issue.
[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=edit Add support for machine-dependant builtins
[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/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/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/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/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/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/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 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/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/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/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 --- Comment #1 from Antoni --- Created attachment 53212 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53212=edit patch fixing the bug
[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 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 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=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/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=edit First 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/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=edit Patch
[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/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/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/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/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/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/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/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/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/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/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/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/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=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/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/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 #1 from Antoni --- Created attachment 50847 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50847=edit Patch adding support for setting the link section
[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/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=edit Patch to add this feature I created a patch to add TLS variables.
[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=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/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/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/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=edit Patch to fix the issues with using atomic builtins I implemented the missing types and fixed the type checking.
[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/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/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 #2 from Antoni --- Created attachment 50731 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50731=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 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=edit Fixed reproducer
[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=edit Reproducer for the bug Hi. The attached example produce a segfault when trying to compile code using inline assembly. Thanks.
[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=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/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=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 #1 from Antoni --- Created attachment 50665 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50665=edit Second part of the reproducer
[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=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.
