From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 76A5C3889830; Sat, 19 Mar 2022 07:42:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 76A5C3889830 From: "cvs-commit at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/101515] [11/12 Regression] ICE in pp_cxx_unqualified_id, at cp/cxx-pretty-print.c:128 since r11-6729-gadb520606ce3e1e1 Date: Sat, 19 Mar 2022 07:42:34 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: tree-optimization X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: diagnostic, ice-on-valid-code X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: qinzhao at gcc dot gnu.org X-Bugzilla-Target-Milestone: 11.3 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2022 07:42:34 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101515 --- Comment #8 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:2663d18356b0a62f5a800c7e5596d814cd3c2c41 commit r12-7720-g2663d18356b0a62f5a800c7e5596d814cd3c2c41 Author: Jakub Jelinek Date: Sat Mar 19 08:40:47 2022 +0100 c-family: Fix up ICE during pretty-printing of PMF related expression [PR101515] The intent of r11-6729 is that it prints something that helps user to figure out what exactly is being accessed. When we find a unique non-static data member that is being accessed, ev= en when we can't fold it nicely, IMNSHO it is better to print ((sometype *)&var)->field or (*(sometype *)&var).field instead of *(fieldtype *)((char *)&var + 56) because the user doesn't know what is at offset 56, we shouldn't ask us= er to decipher structure layout etc. One question is if we could return something better for the TYPE_PTRMEMFUNC_FLAG RECORD_TYPE members here (something that would print it more naturally/readably in a C++ way), though the fact that the routine is in c-family makes it harder. Another one is whether we shouldn't punt for FIELD_DECLs that don't have nicely printable name of its containing scope, something like: if (tree scope =3D get_containing_scope (field)) if (TYPE_P (scope) && TYPE_NAME (scope) =3D=3D NULL_T= REE) break; return cop; or so. This patch implements that. Note the returned cop is a COMPONENT_REF where the first argument has a nicely printable type name (x with type sp), but sp's TYPE_MAIN_VARIANT is the unnamed TYPE_PTRMEMFUNC_FLAG. So another possibility would be if we see such a problem for the FIELD_DECL's scope, check if TYPE_MAIN_VARIANT of the first COMPONENT_REF's argument is equal to that scope and in that case use TREE_TYPE of the first COMPONENT_REF's argument as the scope instead. 2022-03-19 Jakub Jelinek PR c++/101515 * c-pretty-print.cc (c_fold_indirect_ref_for_warn): For C++ don= 't return COMPONENT_REFs with FIELD_DECLs whose containing scope c= an't be printed. * g++.dg/warn/pr101515.C: New test.=