From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 0BD9A3858417; Tue, 19 Mar 2024 12:13:04 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0BD9A3858417 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1710850384; bh=8Qfx8iuB/NcoPCOPJ1mniLNPqUxJD9WODi4t/mKebSs=; h=From:To:Subject:Date:In-Reply-To:References:From; b=H4VASOFQjaLA4fPDjMeeNNFGNRIjBNYU7cw9/G1Zyi3m+skC4axo+TmWr9za53vzE M897tz2YiBvzXHgS41PJtt5d3o1ix3J1++7bBhgFcu6J7tEuZybenC/FcSp4QEM6rZ cUERYcUFV6+2GTBT25VdRbYuZJ2zVm/QFyoLV/f4= From: "jakub at gcc dot 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 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: analyzer X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: jakub at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: dmalcolm at gcc dot gnu.org X-Bugzilla-Target-Milestone: 14.0 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D113505 --- Comment #3 from Jakub Jelinek --- Seems this is because the analyzer creates invalid IL. MEM_REF second argument should be always INTEGER_CST, with value which is t= he 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 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 =3D cd.get_arg_tree (2); tree star_len_ptr =3D 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 =3D build_int_cst (integer_type_node, 0); tree star_p =3D build2 (MEM_REF, integer_type_node, p, offset_0); and tree offset_0 =3D build_int_cst (integer_type_node, 0); tree mem_ref =3D 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 oth= er reference, I'd suggest just to use something that can alias anything, so: build_pointer_type_for_mode (char_type_node, ptr_mode, true)=