From patchwork Tue Nov 9 12:25:22 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Thomas Schwinge X-Patchwork-Id: 1552956 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=8.43.85.97; helo=sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4HpRzG6pzRz9sCD for ; Tue, 9 Nov 2021 23:26:02 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 896CD3858012 for ; Tue, 9 Nov 2021 12:26:00 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id D57C43858D39 for ; Tue, 9 Nov 2021 12:25:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D57C43858D39 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: uybtOkRCDNnRXYpxXaTID8GKnMoXMlsn+MtXLaReapjQ2sA8nNVPxixr6SbPlVROdWQRvZYVG/ GHFf4hu5JufQ6pRB6lxvdgGCLwQ33WJ9RHuiEWvVyLJDCeveE3eKFDCNXN3yYG2xmma3W4Iyvu xVT1DT+5RuI1AhN3Xv/NeTF9X7soeDawKGbvSGRZU+Mb8jd9qWdOvAbw6pcnxAUYo19QTnLNP5 yuCDxKhfDggrU9sfnXW+6FCX5hF32LJFtUM5NTm2304vpeRUh4TKtvsRuxfZvQYDlUpLQOi7FY m45ENARe2ky3XDXUIVQd/2pc X-IronPort-AV: E=Sophos;i="5.87,220,1631606400"; d="scan'208,223";a="68253775" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa4.mentor.iphmx.com with ESMTP; 09 Nov 2021 04:25:35 -0800 IronPort-SDR: LCvw8VFyOM/6GIeH+DLgexY2GoTHIzu3KukE8T8sl1XyCY6AEzNnyuGcacjLfazJf58GJotbfV iINxzuKD8Fbh6b77mfRv+i70IbU0x+SDvgxjAKJntMci2Q84ao+ZWkNpdmFvBKE1Fqk53AJqJm 19z0bVlbGMy/Bwsykwc1fLvxYtSqZCA8oVmJ94QDtuSPks3m6Leumhy2IXOlw12UOrOeyEk5HR JvjbX3dm4aR/485HuMA19xDp1lOWCcM0CvyyHXWvpk5yYxAxaLsLn9q1q3L48ZpSaBP7zkkjem WEI= From: Thomas Schwinge To: Richard Biener , Subject: Get rid of infinite recursion for 'typedef' used with GTY-marked 'gcc/diagnostic-spec.h:nowarn_map' [PR101204, PR103157] In-Reply-To: References: <92db3776-af59-fa20-483b-aa67b17d0751@gmail.com> <47d06c821a53f5bd2246f0fca2c9a693bff6b882.camel@redhat.com> <3a5ea83c-0d91-d123-f537-f8f1223df890@gmail.com> <4514e92d166a007cdfd6b971a69a295a4d8b6891.camel@redhat.com> <015d6a49-d4d8-3ed8-d2b9-2999b466da55@gmail.com> <87y28gm6lt.fsf@euler.schwinge.homeip.net> <87k0hh7hdn.fsf@euler.schwinge.homeip.net> User-Agent: Notmuch/0.29.3+94~g74c3f1b (https://notmuchmail.org) Emacs/27.1 (x86_64-pc-linux-gnu) Date: Tue, 9 Nov 2021 13:25:22 +0100 Message-ID: <87ee7p7byl.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-09.mgc.mentorg.com (139.181.222.9) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-12.1 required=5.0 tests=BAYES_00, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_SHORT, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org Sender: "Gcc-patches" Hi! On 2021-11-09T11:54:04+0100, Richard Biener wrote: > On Tue, Nov 9, 2021 at 11:28 AM Thomas Schwinge wrote: >> On 2021-09-01T18:14:46-0600, Martin Sebor wrote: >> > On 9/1/21 1:35 PM, Thomas Schwinge wrote: >> >> On 2021-06-23T13:47:08-0600, Martin Sebor via Gcc-patches wrote: >> >>> --- /dev/null >> >>> +++ b/gcc/diagnostic-spec.h >> >> >> >>> +typedef location_t key_type_t; >> >>> +typedef int_hash xint_hash_t; >> >>> +typedef hash_map xint_hash_map_t; >> >>> + >> >>> +/* A mapping from the location of an expression to the warning spec >> >>> + set for it. */ >> >>> +extern GTY(()) xint_hash_map_t *nowarn_map; >> >> >> Oh, and one of [my pending changes] actually (unintentially so) happens to resolve >> >> "[12 Regression] infinite recursion in >> >> gtype-desc.c since r12-1801-g7036e9ef462fde8181bece4ac4e03f3aa27204dc", >> >> so unless you've done any work on that, may I take over that PR? >> > >> > I haven't. Thanks for offering to take it on! I'm curious to >> > hear how your change fixes that problem. >> >> So, instead of my earlier drive-by fix, I've since distilled what it >> actually is that is causing/fixing this (strange...) problem. OK to push >> the attached "Get rid of infinite recursion for 'typedef' used with >> GTY-marked 'gcc/diagnostic-spec.h:nowarn_map' [PR101204]"? (This, of >> course, only fixes the symptom but not the actual underlying problem. >> But I'm not going to dig deep into 'gengtype' at this time.) ;-) > > Did you try if > > typedef hash_map, nowarn_spec_t> > xint_hash_map_t; > > works? First, that would be in conflict with my goal of settling on a *single* 'location_hash' type, but also: no, 'gengtype' doesn't grok that either: In file included from config.h:8:0, from gtype-desc.c:21: [...]/source-gcc/gcc/../include/ansidecl.h:148:55: error: wrong number of template arguments (1, should be at least 2) # define ATTRIBUTE_UNUSED __attribute__ ((__unused__)) ^ gtype-desc.c:3014:37: note: in expansion of macro 'ATTRIBUTE_UNUSED' gt_ggc_mx (int_hash Usually a typedef is needed so that gengtype can grok struct > members but it > might very well be confused about two levels of typedefs here? > > That said ... I guess this kind of fix is OK - but can you please put > a big fat comment > about this in the actual code I had thought about that, but then decided not to do that, as the problem is general, not specific to this particular code. Instead, I had put something into 'gcc/doc/gty.texi'. Anyway, I've now put something into that place, too. > and open a bugreport tracking this > gengtype defect? "'gengtype': 'typedef' causing infinite-recursion code to be generated". Pushed to master branch commit c71cb26a9e841888f52e4bfcaad94c8f8ecb4fdb "Get rid of infinite recursion for 'typedef' used with GTY-marked 'gcc/diagnostic-spec.h:nowarn_map' [PR101204, PR103157]", see attached. Grüße Thomas ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 From c71cb26a9e841888f52e4bfcaad94c8f8ecb4fdb Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 9 Nov 2021 10:55:15 +0100 Subject: [PATCH] Get rid of infinite recursion for 'typedef' used with GTY-marked 'gcc/diagnostic-spec.h:nowarn_map' [PR101204, PR103157] Reproduced with clang version 10.0.0-4ubuntu1: gtype-desc.c:11333:1: warning: all paths through this function will call itself [-Winfinite-recursion] ... as well as some GCC's '-O2 -fdump-tree-optimized': void gt_pch_nx(int_hash*, gt_pointer_operator, void*) ([...]) { : : goto ; } That three-arguments 'gt_pch_nx' function as well as two one-argument 'gt_ggc_mx', 'gt_pch_nx' functions now turn empty: [...] void -gt_ggc_mx (int_hash& x_r ATTRIBUTE_UNUSED) +gt_ggc_mx (struct xint_hash_t& x_r ATTRIBUTE_UNUSED) { - int_hash * ATTRIBUTE_UNUSED x = &x_r; - gt_ggc_mx (&((*x))); + struct xint_hash_t * ATTRIBUTE_UNUSED x = &x_r; } [...] void -gt_pch_nx (int_hash& x_r ATTRIBUTE_UNUSED) +gt_pch_nx (struct xint_hash_t& x_r ATTRIBUTE_UNUSED) { - int_hash * ATTRIBUTE_UNUSED x = &x_r; - gt_pch_nx (&((*x))); + struct xint_hash_t * ATTRIBUTE_UNUSED x = &x_r; } [...] void -gt_pch_nx (int_hash* x ATTRIBUTE_UNUSED, +gt_pch_nx (struct xint_hash_t* x ATTRIBUTE_UNUSED, ATTRIBUTE_UNUSED gt_pointer_operator op, ATTRIBUTE_UNUSED void *cookie) { - gt_pch_nx (&((*x)), op, cookie); } [...] gcc/ PR middle-end/101204 PR other/103157 * diagnostic-spec.h (typedef xint_hash_t): Turn into... (struct xint_hash_t): ... this. * doc/gty.texi: Update. --- gcc/diagnostic-spec.h | 6 +++++- gcc/doc/gty.texi | 8 ++++++++ 2 files changed, 13 insertions(+), 1 deletion(-) diff --git a/gcc/diagnostic-spec.h b/gcc/diagnostic-spec.h index 9b3aaaa3ce6..e54e9e3ddbe 100644 --- a/gcc/diagnostic-spec.h +++ b/gcc/diagnostic-spec.h @@ -130,7 +130,11 @@ operator!= (const nowarn_spec_t &lhs, const nowarn_spec_t &rhs) return !(lhs == rhs); } -typedef int_hash xint_hash_t; +/* Per PR103157 "'gengtype': 'typedef' causing infinite-recursion code to be + generated", don't use + typedef int_hash xint_hash_t; + here. */ +struct xint_hash_t : int_hash {}; typedef hash_map xint_hash_map_t; /* A mapping from a 'location_t' to the warning spec set for it. */ diff --git a/gcc/doc/gty.texi b/gcc/doc/gty.texi index 2ad7793191b..b996ff2c44e 100644 --- a/gcc/doc/gty.texi +++ b/gcc/doc/gty.texi @@ -64,6 +64,14 @@ The parser understands simple typedefs such as @code{typedef int @var{name};}. These don't need to be marked. +However, in combination with GTY, avoid using typedefs such as +@code{typedef int_hash<@dots{}> @var{name};} +for these generate infinite-recursion code. +See @uref{https://gcc.gnu.org/PR103157,PR103157}. +Instead, you may use +@code{struct @var{name} : int_hash<@dots{}> @{@};}, +for example. + Since @code{gengtype}'s understanding of C++ is limited, there are several constructs and declarations that are not supported inside classes/structures marked for automatic GC code generation. The -- 2.33.0