From patchwork Tue Nov 9 10:28:20 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Thomas Schwinge X-Patchwork-Id: 47269 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 14E223858012 for ; Tue, 9 Nov 2021 10:28:54 +0000 (GMT) X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from esa3.mentor.iphmx.com (esa3.mentor.iphmx.com [68.232.137.180]) by sourceware.org (Postfix) with ESMTPS id 4574E3858D39 for ; Tue, 9 Nov 2021 10:28:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4574E3858D39 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: bJrYH26fE1Ucd8wYkZS4Y2xT3nhv/s9spjixSa6DW7kxbnurWcSfJDm8q9xJB94UZI9P6+L4Nl +iPb8dDDsx3k1qaZtc5SUx+cBpK9p1YK6I8fph5cduPCGuO5dJM4jpsM+HcviVkObyHIniuSIh wuUfybApMjO5M7zaCSKsNKiLGTi6rkocy7xQ+Q3fVYeSkJCrz3AJ6Kze3qYorhE+kFPlm6ira2 x1NxflSbLSjg/zldi53u+P7J8KDV0B02FRzwP6FBUIFUk/dgzVaP0KeH51FVt05xVzwmhaavFR Eh2tooErJVylMwUbU1JKASyT X-IronPort-AV: E=Sophos;i="5.87,220,1631606400"; d="scan'208,223";a="68072728" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa3.mentor.iphmx.com with ESMTP; 09 Nov 2021 02:28:34 -0800 IronPort-SDR: dnepXH/X16Kf0+2D1rahHik8cCMlpHgDlfcSTMjUQ5pAweIAkcb4gAD1zo+BhZnXowzXzo7f59 8Z0FTy5zo3Tn5dQNpxBDqtELbz0T1FnCDVyke5x/L21Pi33jXgMU9v2Xmum3yQsOfNKlGDXwPK RRSa3mxxbX9oHEVFZHDoe7vPXga6FSQmItD2ql26KUv8xavBxQVs/ZexLw9CnA3McWBxnGJ9F/ jBz7Su+tyi5/jY8qLWH7uKz2KogjfG8DatILHFGmC3by07/4MMUTNezpRuVIZLHIjNfB6TaFZi fFY= From: Thomas Schwinge To: Martin Sebor , Subject: Get rid of infinite recursion for 'typedef' used with GTY-marked 'gcc/diagnostic-spec.h:nowarn_map' [PR101204] (was: [PATCH 1/13] v2 [PATCH 1/13] Add support for per-location warning groups (PR 74765)) 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> User-Agent: Notmuch/0.29.3+94~g74c3f1b (https://notmuchmail.org) Emacs/27.1 (x86_64-pc-linux-gnu) Date: Tue, 9 Nov 2021 11:28:20 +0100 Message-ID: <87k0hh7hdn.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+patchwork=sourceware.org@gcc.gnu.org Sender: "Gcc-patches" Hi! 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.) ;-) 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 4d691426a602f3179ef2847903e417fe473955c5 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] 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 * diagnostic-spec.h (typedef xint_hash_t): Turn into... (struct xint_hash_t): ... this. * doc/gty.texi: Update. --- gcc/diagnostic-spec.h | 2 +- gcc/doc/gty.texi | 8 ++++++++ 2 files changed, 9 insertions(+), 1 deletion(-) diff --git a/gcc/diagnostic-spec.h b/gcc/diagnostic-spec.h index 9b3aaaa3ce6..d29cdd46290 100644 --- a/gcc/diagnostic-spec.h +++ b/gcc/diagnostic-spec.h @@ -130,7 +130,7 @@ operator!= (const nowarn_spec_t &lhs, const nowarn_spec_t &rhs) return !(lhs == rhs); } -typedef int_hash xint_hash_t; +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..8900e082225 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/PR101204,PR101204}. +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