Message ID | 20230313201512.151814-1-jason@redhat.com |
---|---|
State | Accepted |
Headers |
Return-Path: <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:5915:0:0:0:0:0 with SMTP id v21csp1385798wrd; Mon, 13 Mar 2023 13:16:06 -0700 (PDT) X-Google-Smtp-Source: AK7set8a9o82jMq/QP+0bNJ1z9I3vzlGFb8XkqpsHsPVfQmyQnFF0a4SKuCxNR58+pEGNwl4N9rg X-Received: by 2002:a17:906:db0c:b0:909:3c55:a1b3 with SMTP id xj12-20020a170906db0c00b009093c55a1b3mr47987849ejb.38.1678738566508; Mon, 13 Mar 2023 13:16:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1678738566; cv=none; d=google.com; s=arc-20160816; b=ePLnshCsd6bclkx2YQpeQc8q6FksaeM2UbUmnJBe5mnOLzy+LA1GHBzs44zJG3CqCy IT6ZujX3neVKcUub/qvBY9ytD9MWKdGHMa0PL6N1fWBAGQ5oZD4l2B2vCx9TWt32XRyL okpzgFkKB3T2Fu6L2xD/LgZzupoOnfpHnhFJm0MtyS9gam/rSNSEiWgZdFszMSebhH3Q Ai8UfzFKXicU07+VET/NaHQU6HGPAUh8oemujOz1k2WOaojwx72/jVN50znCdNmVyjGc eh+EXeQ107ABVywLrlAzo4408lvoVMjO+iE1VOilXk/bJN+i9amdMoXovLMBaiypnkKA potg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:reply-to:from:list-subscribe:list-help:list-post :list-archive:list-unsubscribe:list-id:precedence :content-transfer-encoding:mime-version:message-id:date:subject:cc :to:dmarc-filter:delivered-to:dkim-signature:dkim-filter; bh=6vWRSz5YnTP2bWTqTR4B7kWiuBHn7oznHayYWR5DAVY=; b=IXsAXWV3L5XPrA7Qgc74RX5W6jkXRvFgRQerscI4tB4BEJaSZ1U1XCzxpL6x/lnJMK F1n8BKenvreGCFcybHyeRtGCpxh7ZZTQdHEXnVVsgpIFKVSxVTTc9OgYzz/2MBdQyO2v UVUyXHNlj3dueoPy3Zi6S7OonRVjLBwILLMHuiQBBFajPu5JZwwww6sOF7AmMalHOP0c mcqnn8HZqyi+4kTwTNgTY2PtkFEYGhakxnBKyi3ryhUviZxZ2NXny9ke1OLgTteZ6Kw3 BkHdJDLr5Dt3k7eR+fkdI4d5zi5x37Gv5j5ahDIl/t9laiEF9TbBwClIEwlnKqmkV16u vDmA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=XkbxFap6; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from sourceware.org (server2.sourceware.org. [8.43.85.97]) by mx.google.com with ESMTPS id u23-20020a170906781700b009287477c339si430240ejm.538.2023.03.13.13.16.06 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Mar 2023 13:16:06 -0700 (PDT) Received-SPF: pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) client-ip=8.43.85.97; Authentication-Results: mx.google.com; dkim=pass header.i=@gcc.gnu.org header.s=default header.b=XkbxFap6; spf=pass (google.com: domain of gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=gnu.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 79DEC385840A for <ouuuleilei@gmail.com>; Mon, 13 Mar 2023 20:16:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 79DEC385840A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1678738565; bh=6vWRSz5YnTP2bWTqTR4B7kWiuBHn7oznHayYWR5DAVY=; h=To:Cc:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=XkbxFap6MnZLm3UIaomP2ssuO7z/fhKekLcEVi+1rl/iIN9SBivXbkru6V0jK2GIW ViB8Qaa9WUCaMTuduLRBbBPFRr8RowmBw27Ufhvry6GjLRdNNX25aPCikpB9ckrGxW xMxu5oxkubh87Ao39TB9HvVXBVeg4rF+9P8GxlEg= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id 787613858D1E for <gcc-patches@gcc.gnu.org>; Mon, 13 Mar 2023 20:15:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 787613858D1E Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-461-RafrcUIWMh6zNt6jyMaWAg-1; Mon, 13 Mar 2023 16:15:18 -0400 X-MC-Unique: RafrcUIWMh6zNt6jyMaWAg-1 Received: by mail-qk1-f200.google.com with SMTP id d10-20020a05620a240a00b0073baf1de8ebso7213713qkn.19 for <gcc-patches@gcc.gnu.org>; Mon, 13 Mar 2023 13:15:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678738518; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=6vWRSz5YnTP2bWTqTR4B7kWiuBHn7oznHayYWR5DAVY=; b=SWn8gT0cpdsizvRCyLFHgC9tJPso+3ot7egbfZB9hfSA9jJaAwi4HbhIVdMIK3wl9Y Gcywh4bctcmDkeyOugCr9bDkq8wQqCE7IFbCBcAtcJXs1C/mUnHyh17CWbN2fhA1n4Ke r+ueIZQVlK8x8Iv0ZJTEwmgk5gV6LuOvr2adJMLNISB3ailefXzCL8IFhCwAOu60gGtt sttWcNmLyACXEtT2qCkNcwGIssAncrmgZRbS4xAZT7p+oHwEQeZ2cdyPNGqFCRjvd3DV vlfoYMO46wiV4XxNXLC+Ou+K2R0QlU+fvpod1vwOklHFh+ucjIJzGEh6JwyyK3Fe4fjW ai0Q== X-Gm-Message-State: AO0yUKXAVGxRGpCeZNosuvTb9SVKt+RLGY4JvlAIcLiURiQzHEIfN63I b5WkVhjYRwnERNGNIXH8bOk12VkuEuvzbbX7AOjtAekYIxsOPOXqMiTIjyBhvH+nMnCYJFsYKe2 xvkBjFe98COKjvjoSMMVnNt0cUapjXKoy3ltHKI83v3RgC/Eas9dW0uXjG0WVquR1YuSzXrwx9Q == X-Received: by 2002:a05:622a:292:b0:3bf:c346:a743 with SMTP id z18-20020a05622a029200b003bfc346a743mr29729560qtw.39.1678738517970; Mon, 13 Mar 2023 13:15:17 -0700 (PDT) X-Received: by 2002:a05:622a:292:b0:3bf:c346:a743 with SMTP id z18-20020a05622a029200b003bfc346a743mr29729512qtw.39.1678738517467; Mon, 13 Mar 2023 13:15:17 -0700 (PDT) Received: from jason.com (130-44-159-43.s15913.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.159.43]) by smtp.gmail.com with ESMTPSA id dt5-20020a05620a478500b007456e020846sm383810qkb.13.2023.03.13.13.15.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Mar 2023 13:15:17 -0700 (PDT) To: gcc-patches@gcc.gnu.org Cc: Jakub Jelinek <jakub@redhat.com> Subject: [PATCH RFA] tree: define tree_code_type in C++11/14 [PR108634] Date: Mon, 13 Mar 2023 16:15:12 -0400 Message-Id: <20230313201512.151814-1-jason@redhat.com> X-Mailer: git-send-email 2.31.1 MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII"; x-default=true X-Spam-Status: No, score=-12.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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 <gcc-patches.gcc.gnu.org> List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=unsubscribe> List-Archive: <https://gcc.gnu.org/pipermail/gcc-patches/> List-Post: <mailto:gcc-patches@gcc.gnu.org> List-Help: <mailto:gcc-patches-request@gcc.gnu.org?subject=help> List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-patches>, <mailto:gcc-patches-request@gcc.gnu.org?subject=subscribe> From: Jason Merrill via Gcc-patches <gcc-patches@gcc.gnu.org> Reply-To: Jason Merrill <jason@redhat.com> Errors-To: gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org Sender: "Gcc-patches" <gcc-patches-bounces+ouuuleilei=gmail.com@gcc.gnu.org> X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1760284970750543952?= X-GMAIL-MSGID: =?utf-8?q?1760284970750543952?= |
Series |
[RFA] tree: define tree_code_type in C++11/14 [PR108634]
|
|
Checks
Context | Check | Description |
---|---|---|
snail/gcc-patch-check | success | Github commit url |
Commit Message
Jason Merrill
March 13, 2023, 8:15 p.m. UTC
Tested x86_64-pc-linux-gnu, OK for trunk? -- 8< -- The r13-6577 change to use tree_code_type_tmpl in earlier C++ dialects broke gdbhooks, which expects tree_code_type to always be available. I considered trying to make gdbhooks more robust, but it seemed simpler to define tree_code_type as a reference to the template. This still ends up with a definition of the reference in each translation unit, but that's allowed by the ODR because it always refers to the same entity, and is much smaller than having the whole table in each TU. PR plugins/108634 gcc/ChangeLog: * tree-core.h (tree_code_type, tree_code_length): Define even without inline variable support. * tree.h (TREE_CODE_CLASS, TREE_CODE_LENGTH): Only one definition. --- gcc/tree-core.h | 3 +++ gcc/tree.h | 10 ---------- 2 files changed, 3 insertions(+), 10 deletions(-) base-commit: c227508d06a63f9b8fede3fd88813accb447060e
Comments
On 3/13/23 16:15, Jason Merrill wrote: > Tested x86_64-pc-linux-gnu, OK for trunk? > > -- 8< -- > > The r13-6577 change to use tree_code_type_tmpl in earlier C++ dialects broke > gdbhooks, which expects tree_code_type to always be available. I considered > trying to make gdbhooks more robust, but it seemed simpler to define > tree_code_type as a reference to the template. This still ends up with a > definition of the reference in each translation unit, but that's allowed by the > ODR because it always refers to the same entity, and is much smaller than > having the whole table in each TU. ...or I could build with a newer bootstrap compiler, I suppose. > PR plugins/108634 > > gcc/ChangeLog: > > * tree-core.h (tree_code_type, tree_code_length): > Define even without inline variable support. > * tree.h (TREE_CODE_CLASS, TREE_CODE_LENGTH): > Only one definition. > --- > gcc/tree-core.h | 3 +++ > gcc/tree.h | 10 ---------- > 2 files changed, 3 insertions(+), 10 deletions(-) > > diff --git a/gcc/tree-core.h b/gcc/tree-core.h > index fd2be57b78c..545dfd30114 100644 > --- a/gcc/tree-core.h > +++ b/gcc/tree-core.h > @@ -2298,6 +2298,7 @@ struct tree_code_type_tmpl { > > template <int N> > constexpr enum tree_code_class tree_code_type_tmpl<N>::tree_code_type[]; > +static constexpr auto &tree_code_type = tree_code_type_tmpl<0>::tree_code_type; > #else > constexpr inline enum tree_code_class tree_code_type[] = { > #include "all-tree.def" > @@ -2326,6 +2327,8 @@ struct tree_code_length_tmpl { > > template <int N> > constexpr unsigned char tree_code_length_tmpl<N>::tree_code_length[]; > +static constexpr auto &tree_code_length > += tree_code_length_tmpl<0>::tree_code_length; > #else > constexpr inline unsigned char tree_code_length[] = { > #include "all-tree.def" > diff --git a/gcc/tree.h b/gcc/tree.h > index 91375f9652f..92ac0e6a214 100644 > --- a/gcc/tree.h > +++ b/gcc/tree.h > @@ -177,12 +177,7 @@ code_helper::is_builtin_fn () const > #define TREE_CODE_CLASS_STRING(CLASS)\ > tree_code_class_strings[(int) (CLASS)] > > -#if __cpp_inline_variables < 201606L > -#define TREE_CODE_CLASS(CODE) \ > - tree_code_type_tmpl <0>::tree_code_type[(int) (CODE)] > -#else > #define TREE_CODE_CLASS(CODE) tree_code_type[(int) (CODE)] > -#endif > > /* Nonzero if NODE represents an exceptional code. */ > > @@ -276,12 +271,7 @@ code_helper::is_builtin_fn () const > > #define EXPR_P(NODE) IS_EXPR_CODE_CLASS (TREE_CODE_CLASS (TREE_CODE (NODE))) > > -#if __cpp_inline_variables < 201606L > -#define TREE_CODE_LENGTH(CODE) \ > - tree_code_length_tmpl <0>::tree_code_length[(int) (CODE)] > -#else > #define TREE_CODE_LENGTH(CODE) tree_code_length[(int) (CODE)] > -#endif > > > /* Helper macros for math builtins. */ > > base-commit: c227508d06a63f9b8fede3fd88813accb447060e
On Mon, Mar 13, 2023 at 04:15:12PM -0400, Jason Merrill wrote: > The r13-6577 change to use tree_code_type_tmpl in earlier C++ dialects broke > gdbhooks, which expects tree_code_type to always be available. I considered > trying to make gdbhooks more robust, but it seemed simpler to define > tree_code_type as a reference to the template. This still ends up with a > definition of the reference in each translation unit, but that's allowed by the > ODR because it always refers to the same entity, and is much smaller than > having the whole table in each TU. > > PR plugins/108634 > > gcc/ChangeLog: > > * tree-core.h (tree_code_type, tree_code_length): > Define even without inline variable support. > * tree.h (TREE_CODE_CLASS, TREE_CODE_LENGTH): > Only one definition. I think it would be better to change gdbhooks.py to match what the code does. We should adjust the # extern const enum tree_code_class tree_code_type[]; # #define TREE_CODE_CLASS(CODE) tree_code_type[(int) (CODE)] comment because that isn't true even for new bootstrap compiler. And, I just wonder if val_tree_code_type = gdb.parse_and_eval('tree_code_type') couldn't be replaced with try: val_tree_code_type = gdb.parse_and_eval('tree_code_type') except; val_tree_code_type = gdb.parse_and_eval('tree_code_type_tmpl<0>::tree_code_type') or so. Jakub
On Mon, Mar 13, 2023 at 10:02:41PM +0100, Jakub Jelinek wrote: > On Mon, Mar 13, 2023 at 04:15:12PM -0400, Jason Merrill wrote: > > The r13-6577 change to use tree_code_type_tmpl in earlier C++ dialects broke > > gdbhooks, which expects tree_code_type to always be available. I considered > > trying to make gdbhooks more robust, but it seemed simpler to define > > tree_code_type as a reference to the template. This still ends up with a > > definition of the reference in each translation unit, but that's allowed by the > > ODR because it always refers to the same entity, and is much smaller than > > having the whole table in each TU. > > > > PR plugins/108634 > > > > gcc/ChangeLog: > > > > * tree-core.h (tree_code_type, tree_code_length): > > Define even without inline variable support. > > * tree.h (TREE_CODE_CLASS, TREE_CODE_LENGTH): > > Only one definition. > > I think it would be better to change gdbhooks.py to match what the code > does. > We should adjust the > # extern const enum tree_code_class tree_code_type[]; > # #define TREE_CODE_CLASS(CODE) tree_code_type[(int) (CODE)] > comment because that isn't true even for new bootstrap compiler. > And, I just wonder if > val_tree_code_type = gdb.parse_and_eval('tree_code_type') > couldn't be replaced with > try: > val_tree_code_type = gdb.parse_and_eval('tree_code_type') > except; > val_tree_code_type = gdb.parse_and_eval('tree_code_type_tmpl<0>::tree_code_type') > or so. Or val_tree_code_type = gdb.parse_and_eval('tree_code_type') if val_tree_code_type == 0: val_tree_code_type = gdb.parse_and_eval('tree_code_type_tmpl<0>::tree_code_type') Whatever works. Jakub
diff --git a/gcc/tree-core.h b/gcc/tree-core.h index fd2be57b78c..545dfd30114 100644 --- a/gcc/tree-core.h +++ b/gcc/tree-core.h @@ -2298,6 +2298,7 @@ struct tree_code_type_tmpl { template <int N> constexpr enum tree_code_class tree_code_type_tmpl<N>::tree_code_type[]; +static constexpr auto &tree_code_type = tree_code_type_tmpl<0>::tree_code_type; #else constexpr inline enum tree_code_class tree_code_type[] = { #include "all-tree.def" @@ -2326,6 +2327,8 @@ struct tree_code_length_tmpl { template <int N> constexpr unsigned char tree_code_length_tmpl<N>::tree_code_length[]; +static constexpr auto &tree_code_length += tree_code_length_tmpl<0>::tree_code_length; #else constexpr inline unsigned char tree_code_length[] = { #include "all-tree.def" diff --git a/gcc/tree.h b/gcc/tree.h index 91375f9652f..92ac0e6a214 100644 --- a/gcc/tree.h +++ b/gcc/tree.h @@ -177,12 +177,7 @@ code_helper::is_builtin_fn () const #define TREE_CODE_CLASS_STRING(CLASS)\ tree_code_class_strings[(int) (CLASS)] -#if __cpp_inline_variables < 201606L -#define TREE_CODE_CLASS(CODE) \ - tree_code_type_tmpl <0>::tree_code_type[(int) (CODE)] -#else #define TREE_CODE_CLASS(CODE) tree_code_type[(int) (CODE)] -#endif /* Nonzero if NODE represents an exceptional code. */ @@ -276,12 +271,7 @@ code_helper::is_builtin_fn () const #define EXPR_P(NODE) IS_EXPR_CODE_CLASS (TREE_CODE_CLASS (TREE_CODE (NODE))) -#if __cpp_inline_variables < 201606L -#define TREE_CODE_LENGTH(CODE) \ - tree_code_length_tmpl <0>::tree_code_length[(int) (CODE)] -#else #define TREE_CODE_LENGTH(CODE) tree_code_length[(int) (CODE)] -#endif /* Helper macros for math builtins. */