public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug analyzer/113923] New: Segfault in gcc/gcc/tree-diagnostic.cc:265
@ 2024-02-14 20:59 bouanto at zoho dot com
  2024-02-14 21:17 ` [Bug analyzer/113923] " dmalcolm at gcc dot gnu.org
                   ` (8 more replies)
  0 siblings, 9 replies; 10+ messages in thread
From: bouanto at zoho dot com @ 2024-02-14 20:59 UTC (permalink / raw)
  To: gcc-bugs

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)]
0x000077ae3edea93d 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  0x000077ae3edea93d 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  0x000077ae408a8ab2 in pp_format (pp=0x77a86437ea10, text=0x77add5bf5540,
urlifier=0x0) at ../../../gcc/gcc/pretty-print.cc:1704
#2  0x000077ae407a6503 in make_label_text (can_colorize=false,
fmt=0x77ae40edd909 "inlined call to %qE from %qE") at
../../../gcc/gcc/analyzer/analyzer.cc:494
#3  0x000077ae407bbf30 in ana::inlined_call_event::get_desc
(this=0x77a85fde16a0, can_colorize=false) at
../../../gcc/gcc/analyzer/checker-event.cc:1018
#4  0x000077ae407b9d1a in ana::checker_event::prepare_for_emission
(this=0x77a85fde16a0, pd=0x77a88c2e07a0, emission_id=...)
    at ../../../gcc/gcc/analyzer/checker-event.cc:230
#5  0x000077ae407d83da in ana::checker_path::prepare_for_emission
(this=0x77add5bf5900, pd=0x77a88c2e07a0) at
../../../gcc/gcc/analyzer/checker-path.h:108
#6  0x000077ae407d40ac in ana::diagnostic_manager::emit_saved_diagnostic
(this=0x77add5bf6210, eg=..., sd=...) at
../../../gcc/gcc/analyzer/diagnostic-manager.cc:1601
#7  0x000077ae407d9742 in ana::dedupe_winners::emit_best (this=0x77add5bf5b40,
dm=0x77add5bf6210, eg=...) at
../../../gcc/gcc/analyzer/diagnostic-manager.cc:1472
#8  0x000077ae407d3cf0 in ana::diagnostic_manager::emit_saved_diagnostics
(this=0x77add5bf6210, eg=...) at
../../../gcc/gcc/analyzer/diagnostic-manager.cc:1524
#9  0x000077ae3f2031e9 in ana::impl_run_checkers (logger=0x0) at
../../../gcc/gcc/analyzer/engine.cc:6226
#10 0x000077ae3f203582 in ana::run_checkers () at
../../../gcc/gcc/analyzer/engine.cc:6300
#11 0x000077ae3f1f47bb in (anonymous namespace)::pass_analyzer::execute
(this=0x77add5201000) at ../../../gcc/gcc/analyzer/analyzer-pass.cc:87
#12 0x000077ae3ec00e1f in execute_one_pass (pass=0x77add5201000) at
../../../gcc/gcc/passes.cc:2646
#13 0x000077ae3ec02074 in execute_ipa_pass_list (pass=0x77add5201000) at
../../../gcc/gcc/passes.cc:3095
#14 0x000077ae3e6f4c62 in ipa_passes () at ../../../gcc/gcc/cgraphunit.cc:2270
#15 0x000077ae3e6f4e82 in symbol_table::compile (this=0x77a90e2ccf00) at
../../../gcc/gcc/cgraphunit.cc:2333
#16 0x000077ae3e6f54f8 in symbol_table::finalize_compilation_unit
(this=0x77a90e2ccf00) at ../../../gcc/gcc/cgraphunit.cc:2585
#17 0x000077ae3ed73932 in compile_file () at ../../../gcc/gcc/toplev.cc:474
#18 0x000077ae3ed77568 in do_compile () at ../../../gcc/gcc/toplev.cc:2152
#19 0x000077ae3ed77a1e in toplev::main (this=0x77add5bfb256, argc=20,
argv=0x77add520f1c8) at ../../../gcc/gcc/toplev.cc:2308
#20 0x000077ae3e5ccecb in gcc::jit::playback::context::compile
(this=0x77add5bfb2f0) at ../../../gcc/gcc/jit/jit-playback.cc:2851
#21 0x000077ae3e59f1e7 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 0x000077ae3e5963fb 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 0x000077ae41b291eb 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 0x000077ae41dee137 in rustc_codegen_gcc::back::write::codegen
(cgcx=0x77add5bfdd38, diag_handler=0x77add5bfc7c0, module=...,
config=0x77ae0f1df1f0)
    at src/back/write.rs:124
#25 0x000077ae41e25dc0 in rustc_codegen_gcc::{impl#8}::codegen
(cgcx=0x77add5bfdd38, diag_handler=0x77add5bfc7c0,
    module=<error reading variable: Cannot access memory at address 0x48>,
config=0x77ae0f1df1f0) at src/lib.rs:352
#26 0x000077ae41d5fe34 in
rustc_codegen_ssa::back::write::finish_intra_module_work<rustc_codegen_gcc::GccCodegenBackend>
(cgcx=0x77add5bfdd38, module=...,
    module_config=0x77ae0f1df1f0) at
/rustc/a57770440f1ebe5b992551d3bcc489ae211908d4/compiler/rustc_codegen_ssa/src/back/write.rs:959
#27 0x000077ae41d6046a in
rustc_codegen_ssa::back::write::execute_optimize_work_item<rustc_codegen_gcc::GccCodegenBackend>
(cgcx=0x77add5bfdd38, module=...,
    module_config=0x77ae0f1df1f0) at
/rustc/a57770440f1ebe5b992551d3bcc489ae211908d4/compiler/rustc_codegen_ssa/src/back/write.rs:862
#28 0x000077ae41d56439 in
rustc_codegen_ssa::back::write::spawn_work::{closure#0}<rustc_codegen_gcc::GccCodegenBackend>
()
    at
/rustc/a57770440f1ebe5b992551d3bcc489ae211908d4/compiler/rustc_codegen_ssa/src/back/write.rs:1748
#29 0x000077ae41e0b2b7 in
std::sys_common::backtrace::__rust_begin_short_backtrace<rustc_codegen_ssa::back::write::spawn_work::{closure_env#0}<rustc_codegen_gcc::GccCodegenBackend>,
()> (f=...) at
/rustc/a57770440f1ebe5b992551d3bcc489ae211908d4/library/std/src/sys_common/backtrace.rs:154
--Type <RET> for more, q to quit, c to continue without paging--c
#30 0x000077ae41b5ed64 in
std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure#0}<rustc_codegen_ssa::back::write::spawn_work::{closure_env#0}<rustc_codegen_gcc::GccCodegenBackend>,
()> () at
/rustc/a57770440f1ebe5b992551d3bcc489ae211908d4/library/std/src/thread/mod.rs:529
#31 0x000077ae41e35084 in core::panic::unwind_safe::{impl#23}::call_once<(),
std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<rustc_codegen_ssa::back::write::spawn_work::{closure_env#0}<rustc_codegen_gcc::GccCodegenBackend>,
()>> (self=...)
    at
/rustc/a57770440f1ebe5b992551d3bcc489ae211908d4/library/core/src/panic/unwind_safe.rs:272
#32 0x000077ae41a9f0a0 in
std::panicking::try::do_call<core::panic::unwind_safe::AssertUnwindSafe<std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<rustc_codegen_ssa::back::write::spawn_work::{closure_env#0}<rustc_codegen_gcc::GccCodegenBackend>,
()>>, ()> (data=0x77add5bfe260)
    at
/rustc/a57770440f1ebe5b992551d3bcc489ae211908d4/library/std/src/panicking.rs:552
#33 0x000077ae41aa000b in __rust_try () from
/home/user/rustc_codegen_gcc/target/debug/librustc_codegen_gcc.so
#34 0x000077ae41a9ebb8 in std::panicking::try<(),
core::panic::unwind_safe::AssertUnwindSafe<std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<rustc_codegen_ssa::back::write::spawn_work::{closure_env#0}<rustc_codegen_gcc::GccCodegenBackend>,
()>>> (f=...)
    at
/rustc/a57770440f1ebe5b992551d3bcc489ae211908d4/library/std/src/panicking.rs:516
#35 0x000077ae41b5eb76 in
std::panic::catch_unwind<core::panic::unwind_safe::AssertUnwindSafe<std::thread::{impl#0}::spawn_unchecked_::{closure#1}::{closure_env#0}<rustc_codegen_ssa::back::write::spawn_work::{closure_env#0}<rustc_codegen_gcc::GccCodegenBackend>,
()>>, ()> (f=<error reading variable: Cannot access memory at address 0x20>)
    at
/rustc/a57770440f1ebe5b992551d3bcc489ae211908d4/library/std/src/panic.rs:142
#36
std::thread::{impl#0}::spawn_unchecked_::{closure#1}<rustc_codegen_ssa::back::write::spawn_work::{closure_env#0}<rustc_codegen_gcc::GccCodegenBackend>,
()> ()
    at
/rustc/a57770440f1ebe5b992551d3bcc489ae211908d4/library/std/src/thread/mod.rs:528
#37 0x000077ae41bdaf0f in
core::ops::function::FnOnce::call_once<std::thread::{impl#0}::spawn_unchecked_::{closure_env#1}<rustc_codegen_ssa::back::write::spawn_work::{closure_env#0}<rustc_codegen_gcc::GccCodegenBackend>,
()>, ()> () at
/rustc/a57770440f1ebe5b992551d3bcc489ae211908d4/library/core/src/ops/function.rs:250
#38 0x000077ae522b2915 in alloc::boxed::{impl#47}::call_once<(), dyn
core::ops::function::FnOnce<(), Output=()>, alloc::alloc::Global> () at
library/alloc/src/boxed.rs:2007
#39 alloc::boxed::{impl#47}::call_once<(), alloc::boxed::Box<dyn
core::ops::function::FnOnce<(), Output=()>, alloc::alloc::Global>,
alloc::alloc::Global> ()
    at library/alloc/src/boxed.rs:2007
#40 std::sys::unix::thread::{impl#2}::new::thread_start () at
library/std/src/sys/unix/thread.rs:108
#41 0x000077ae4c0a955a in ?? () from /usr/lib/libc.so.6
#42 0x000077ae4c126a3c in ?? () from /usr/lib/libc.so.6

From what I can see in gdb, in frame 3, m_apparent_caller_fndecl is NULL which
I guess is the cause of the segfault.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug analyzer/113923] Segfault in gcc/gcc/tree-diagnostic.cc:265
  2024-02-14 20:59 [Bug analyzer/113923] New: Segfault in gcc/gcc/tree-diagnostic.cc:265 bouanto at zoho dot com
@ 2024-02-14 21:17 ` dmalcolm at gcc dot gnu.org
  2024-02-14 21:20 ` dmalcolm at gcc dot gnu.org
                   ` (7 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2024-02-14 21:17 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113923

--- Comment #1 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
Reproducing that is going to be a challenge.

FWIW you can probably work around it via -fno-analyzer-undo-inlining.

For an inlined_call_event's m_apparent_caller_fndecl to be NULL, then when it
was created in checker_path::inject_any_inlined_call_events, cd.m_fndecl would
have to be NULL here:

   310                const chain_element &ce = elements[element_idx];
   311                int stack_depth_adjustment
   312                  = (blocks_in_curr_event.elements () - element_idx) - 1;
   313                if (location_t callsite = BLOCK_SOURCE_LOCATION
(ce.m_block))
   314                  updated_events.safe_push
   315                    (new inlined_call_event (callsite,
   316                                             elements[element_idx -
1].m_fndecl,
   317                                             ce.m_fndecl,
   318                                             orig_stack_depth,
   319                                             stack_depth_adjustment));

which comes from iter.get_fndecl () earlier in that function:

   292        for (inlining_iterator iter (curr_loc); !iter.done_p ();
iter.next ())
   293          {
   294            chain_element ce;
   295            ce.m_block = iter.get_block ();
   296            ce.m_fndecl = iter.get_fndecl ();
   297  
   298            if (!blocks_in_prev_event.contains (ce.m_block))
   299              elements.safe_push (ce);
   300            blocks_in_curr_event.add (ce.m_block);
   301          }

inlining-iterator.h looks at FUNCTION_DECL, so maybe if you're using a
different code that could confuse it.  But this is from libgccjit, so I'm not
sure.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug analyzer/113923] Segfault in gcc/gcc/tree-diagnostic.cc:265
  2024-02-14 20:59 [Bug analyzer/113923] New: Segfault in gcc/gcc/tree-diagnostic.cc:265 bouanto at zoho dot com
  2024-02-14 21:17 ` [Bug analyzer/113923] " dmalcolm at gcc dot gnu.org
@ 2024-02-14 21:20 ` dmalcolm at gcc dot gnu.org
  2024-02-14 21:20 ` dmalcolm at gcc dot gnu.org
                   ` (6 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2024-02-14 21:20 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113923

--- Comment #2 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
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.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug analyzer/113923] Segfault in gcc/gcc/tree-diagnostic.cc:265
  2024-02-14 20:59 [Bug analyzer/113923] New: Segfault in gcc/gcc/tree-diagnostic.cc:265 bouanto at zoho dot com
  2024-02-14 21:17 ` [Bug analyzer/113923] " dmalcolm at gcc dot gnu.org
  2024-02-14 21:20 ` dmalcolm at gcc dot gnu.org
@ 2024-02-14 21:20 ` dmalcolm at gcc dot gnu.org
  2024-02-15 22:35 ` bouanto at zoho dot com
                   ` (5 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: dmalcolm at gcc dot gnu.org @ 2024-02-14 21:20 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113923

--- Comment #3 from David Malcolm <dmalcolm at gcc dot gnu.org> ---
(In reply to David Malcolm from comment #2)
> are both non-NULL, which might catch the issue slightly early.
                                                          ^^^^^
                                                          earlier

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug analyzer/113923] Segfault in gcc/gcc/tree-diagnostic.cc:265
  2024-02-14 20:59 [Bug analyzer/113923] New: Segfault in gcc/gcc/tree-diagnostic.cc:265 bouanto at zoho dot com
                   ` (2 preceding siblings ...)
  2024-02-14 21:20 ` dmalcolm at gcc dot gnu.org
@ 2024-02-15 22:35 ` bouanto at zoho dot com
  2024-02-16 17:43 ` bouanto at zoho dot com
                   ` (4 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: bouanto at zoho dot com @ 2024-02-15 22:35 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113923

--- Comment #4 from Antoni <bouanto at zoho dot com> ---
I might be able to soon create a reproducer, but for now, I can say it might be
related to __attribute__  ((always_inline)).

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug analyzer/113923] Segfault in gcc/gcc/tree-diagnostic.cc:265
  2024-02-14 20:59 [Bug analyzer/113923] New: Segfault in gcc/gcc/tree-diagnostic.cc:265 bouanto at zoho dot com
                   ` (3 preceding siblings ...)
  2024-02-15 22:35 ` bouanto at zoho dot com
@ 2024-02-16 17:43 ` bouanto at zoho dot com
  2024-02-16 17:44 ` bouanto at zoho dot com
                   ` (3 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: bouanto at zoho dot com @ 2024-02-16 17:43 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113923

--- Comment #5 from Antoni <bouanto at zoho dot com> ---
Created attachment 57438
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57438&action=edit
GIMPLE for the Rust reproducer

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug analyzer/113923] Segfault in gcc/gcc/tree-diagnostic.cc:265
  2024-02-14 20:59 [Bug analyzer/113923] New: Segfault in gcc/gcc/tree-diagnostic.cc:265 bouanto at zoho dot com
                   ` (4 preceding siblings ...)
  2024-02-16 17:43 ` bouanto at zoho dot com
@ 2024-02-16 17:44 ` bouanto at zoho dot com
  2024-02-16 17:45 ` bouanto at zoho dot com
                   ` (2 subsequent siblings)
  8 siblings, 0 replies; 10+ messages in thread
From: bouanto at zoho dot com @ 2024-02-16 17:44 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113923

--- Comment #6 from Antoni <bouanto at zoho dot com> ---
Created attachment 57439
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57439&action=edit
Rust reproducer

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug analyzer/113923] Segfault in gcc/gcc/tree-diagnostic.cc:265
  2024-02-14 20:59 [Bug analyzer/113923] New: Segfault in gcc/gcc/tree-diagnostic.cc:265 bouanto at zoho dot com
                   ` (5 preceding siblings ...)
  2024-02-16 17:44 ` bouanto at zoho dot com
@ 2024-02-16 17:45 ` bouanto at zoho dot com
  2024-02-16 18:41 ` bouanto at zoho dot com
  2024-03-25 14:17 ` bouanto at zoho dot com
  8 siblings, 0 replies; 10+ messages in thread
From: bouanto at zoho dot com @ 2024-02-16 17:45 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113923

--- Comment #7 from Antoni <bouanto at zoho dot com> ---
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.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug analyzer/113923] Segfault in gcc/gcc/tree-diagnostic.cc:265
  2024-02-14 20:59 [Bug analyzer/113923] New: Segfault in gcc/gcc/tree-diagnostic.cc:265 bouanto at zoho dot com
                   ` (6 preceding siblings ...)
  2024-02-16 17:45 ` bouanto at zoho dot com
@ 2024-02-16 18:41 ` bouanto at zoho dot com
  2024-03-25 14:17 ` bouanto at zoho dot com
  8 siblings, 0 replies; 10+ messages in thread
From: bouanto at zoho dot com @ 2024-02-16 18:41 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113923

--- Comment #8 from Antoni <bouanto at zoho dot com> ---
(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(_: &core::panic::PanicInfo<'_>) -> ! {
    core::intrinsics::abort();
}

#[lang="eh_personality"]
fn eh_personality(){}

#[derive(Clone, Copy)]
#[repr(transparent)]
pub union MaybeUninit<T> {
    uninit: (),
    value: ManuallyDrop<T>,
}

impl<T> MaybeUninit<T> {
    // NOTE: there are no segfaults when removing the next line.
    #[inline(always)]
    pub const fn uninit() -> MaybeUninit<T> {
        MaybeUninit { uninit: () }
    }
}

#[start]
fn main(_argc: isize, _argv: *const *const u8) -> isize {
    let mut x = MaybeUninit::<&i32>::uninit();
    0
}

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [Bug analyzer/113923] Segfault in gcc/gcc/tree-diagnostic.cc:265
  2024-02-14 20:59 [Bug analyzer/113923] New: Segfault in gcc/gcc/tree-diagnostic.cc:265 bouanto at zoho dot com
                   ` (7 preceding siblings ...)
  2024-02-16 18:41 ` bouanto at zoho dot com
@ 2024-03-25 14:17 ` bouanto at zoho dot com
  8 siblings, 0 replies; 10+ messages in thread
From: bouanto at zoho dot com @ 2024-03-25 14:17 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113923

--- Comment #9 from Antoni <bouanto at zoho dot com> ---
Created attachment 57810
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57810&action=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?

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2024-03-25 14:17 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-02-14 20:59 [Bug analyzer/113923] New: Segfault in gcc/gcc/tree-diagnostic.cc:265 bouanto at zoho dot com
2024-02-14 21:17 ` [Bug analyzer/113923] " dmalcolm at gcc dot gnu.org
2024-02-14 21:20 ` dmalcolm at gcc dot gnu.org
2024-02-14 21:20 ` dmalcolm at gcc dot gnu.org
2024-02-15 22:35 ` bouanto at zoho dot com
2024-02-16 17:43 ` bouanto at zoho dot com
2024-02-16 17:44 ` bouanto at zoho dot com
2024-02-16 17:45 ` bouanto at zoho dot com
2024-02-16 18:41 ` bouanto at zoho dot com
2024-03-25 14:17 ` bouanto at zoho dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).