public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug analyzer/113505] [14 Regression] ICE: SIGSEGV in tree_class_check (tree.h:3766) with -O -fdump-analyzer -fanalyzer since r14-6239 Date: Tue, 19 Mar 2024 12:13:03 +0000 [thread overview] Message-ID: <bug-113505-4-87IA5QO8Nt@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-113505-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113505 --- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Seems this is because the analyzer creates invalid IL. MEM_REF second argument should be always INTEGER_CST, with value which is the offset from the base and pointer type used for TBAA purposes: /* Memory addressing. Operands are a pointer and a tree constant integer byte offset of the pointer type that when dereferenced yields the type of the base object the pointer points into and which is used for TBAA purposes. The type of the MEM_REF is the type the bytes at the memory location are interpreted as. MEM_REF <p, c> is equivalent to ((typeof(c))p)->x... where x... is a chain of component references offsetting p by c. */ DEFTREECODE (MEM_REF, "mem_ref", tcc_reference, 2) Now, analyzer in some cases creates MEM_REFs right: tree len_ptr = cd.get_arg_tree (2); tree star_len_ptr = build2 (MEM_REF, TREE_TYPE (TREE_TYPE (len_ptr)), len_ptr, build_int_cst (TREE_TYPE (len_ptr), 0)); in sm-fd.cc most likely has POINTER_TYPE, but static tree get_tree_for_byte_offset (tree ptr_expr, byte_offset_t byte_offset) { gcc_assert (ptr_expr); return fold_build2 (MEM_REF, char_type_node, ptr_expr, wide_int_to_tree (size_type_node, byte_offset)); } and tree offset_0 = build_int_cst (integer_type_node, 0); tree star_p = build2 (MEM_REF, integer_type_node, p, offset_0); and tree offset_0 = build_int_cst (integer_type_node, 0); tree mem_ref = build2 (MEM_REF, integer_type_node, pointer_plus_expr, offset_0); are definitely wrong, the two other spots in region-model.cc which create MEM_REFs not really sure about. Now, if such MEM_REFs will be around only during the pass and not actually emitted into the IL nor TBAA analyzed if they can or can't be aliased with some other reference, I'd suggest just to use something that can alias anything, so: build_pointer_type_for_mode (char_type_node, ptr_mode, true)
next prev parent reply other threads:[~2024-03-19 12:13 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-01-19 15:37 [Bug analyzer/113505] New: ICE: SIGSEGV in tree_class_check (tree.h:3766) with -O -fdump-analyzer -fanalyzer zsojka at seznam dot cz 2024-02-15 15:41 ` [Bug analyzer/113505] [14 Regression] " dmalcolm at gcc dot gnu.org 2024-03-04 13:08 ` rguenth at gcc dot gnu.org 2024-03-07 20:48 ` law at gcc dot gnu.org 2024-03-19 11:59 ` [Bug analyzer/113505] [14 Regression] ICE: SIGSEGV in tree_class_check (tree.h:3766) with -O -fdump-analyzer -fanalyzer since r14-6239 jakub at gcc dot gnu.org 2024-03-19 12:13 ` jakub at gcc dot gnu.org [this message] 2024-03-19 12:28 ` jakub at gcc dot gnu.org 2024-03-19 15:29 ` dmalcolm at gcc dot gnu.org 2024-03-19 20:08 ` cvs-commit at gcc dot gnu.org 2024-03-19 20:09 ` dmalcolm at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-113505-4-87IA5QO8Nt@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
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).