From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 13010384514B; Thu, 27 Jun 2024 17:53:43 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 13010384514B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1719510823; bh=GHneZjGq+otsABwXGt9//FyFtJ88v8UcnSDx51zwYew=; h=From:To:Subject:Date:In-Reply-To:References:From; b=Rin9lKLwkJ/cvhjXcJdtAx55R9RiovUT1ScWn2F9Za88HuM89ZfSVkzqMfIDSniTi LN7VlMcoIZFAz0F4xaxZBt/ZvhoC/D+ZE6ADSGWQFYu09VNb5Oi2ff/ZBMSD9dt8qv hv+fFz8lTm1WWXtovr3AznHhsQgG+Ip1QX1F+sOs= From: "mpolacek at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: =?UTF-8?B?W0J1ZyBjKysvMTA5NTIxXSBbMTEvMTIvMTMvMTQvMTUgUmVncmVz?= =?UTF-8?B?c2lvbl0gQ2hlY2tpbmcgSUNFIHdpdGggY2Fub25pY2FsIHR5cGVzIGRpZmZl?= =?UTF-8?B?ciBmb3IgaWRlbnRpY2FsIHR5cGVzIOKAmFVCWVRFIFs3XeKAmSB7YWthIA==?= =?UTF-8?B?4oCYdW5zaWduZWQgY2hhciBbN13igJl9IGFuZCDigJh1bnNpZ25lZCBjaGFy?= =?UTF-8?B?IFs3XeKAmSBzaW5jZSByMTEtNjUwOC1nYWJiMWI2MDU4YzA5YTc=?= Date: Thu, 27 Jun 2024 17:53:42 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 13.0 X-Bugzilla-Keywords: diagnostic, ice-checking, ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: mpolacek at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.5 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc 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=3D109521 Marek Polacek changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mpolacek at gcc dot gnu.org --- Comment #6 from Marek Polacek --- So we have two "unsigned char [7]" types. They are the same except that one has TYPE_DEPENDENT_P_VALID set. One of them comes from the C++ FE: grokfield -> grokdeclarator -> create_array_type_for_decl etc. This has TYPE_DEPENDENT_P_VALID set. The other one is created in gimple_fold_builtin_memory_op: 1323 desttype =3D build_array_type_nelts (unsigned_char_type_node, 1324 tree_to_uhwi (len)); 1325 srctype =3D desttype; 1326 if (src_align > TYPE_ALIGN (srctype)) 1327 srctype =3D build_aligned_type (srctype, src_align); 1328 srcvar =3D fold_build2 (MEM_REF, srctype, src, off0); this also answers the question why the problem only happens with "unsigned char". Later, we warn in maybe_warn_operand: warning_at -> ... -> print_mem_ref wh= ich tries to display: MEM [(char * {ref-all})&D.2870 + 1B] print_mem_ref calls c_fold_indirect_ref_for_warn with this: 1961 tree cop =3D build3_loc (loc, COMPONENT_REF, TREE_TYPE (field), 1962 op, field, NULL_TREE); 1963 off =3D off - upos; 1964 if (tree ret =3D c_fold_indirect_ref_for_warn (loc, ty= pe, cop, 1965 off)) 1966 return ret; The type of the MEM_REF is the second type. But COP here is D.2870.pad, and its type is the first one. Comparing those two in same_type_ignoring_top_level_qualifiers_p will crash since they are the same types but their canonical types are not identical. I don't know what the fix would be.=