From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id CF19738438A3 for ; Fri, 8 Jan 2021 19:23:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org CF19738438A3 Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-497-DXhIrlvKNryRZN4WvOZJTw-1; Fri, 08 Jan 2021 14:23:02 -0500 X-MC-Unique: DXhIrlvKNryRZN4WvOZJTw-1 Received: by mail-qt1-f200.google.com with SMTP id l7so9006885qth.15 for ; Fri, 08 Jan 2021 11:23:02 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=YCRI7sNK/jdqBjIcIkms9UCE8M9TiyC1RF2AKW++hBI=; b=dAKvjGdNjYo42kxXntQ/WBLNnkWzTon4RZLVMNYsYvfbf7E9k3g+bV5MLT12E653L6 F9KV7JKAUJVDqj0+BhYZeV1kKN3BYReb7J034xmZJOmbXzRFliOyyIlXtUNUtnmQt//n SFfdn88f2qyhFYbYqgRvPo/3OBfrITr52JniaTi4fYT/b2gg2TmJV4BwXFbyBlFoKiht MoXJh71z/XoZdeu5ZCfbQhOlxDcv/NF1lCwTfNNfMU6YZ4zYrRzbt242tCMupIw3e1iH iWOmRn3+nVVDlljx5Ltk5+5Ls0Crk61uh/hAeXhj0hZp4i2hAvI0TFwDFvtkfrT2pP5q 5oGA== X-Gm-Message-State: AOAM533rLL9vEj0f7VPukyEthSIH4KL2wxODj89YJptVdkEB/bGOOODR iXOmdDfYqdqt/z3wLCDlKtV1hWj8PJAvlJozstH3bVuBAb86EfXdbPjYsckvs/TZ+tSe5rw3XM9 IKpUyFHH80GNyfkdiRnuAlCDVnc06eqSu7Ps1Im3XoxrFBCU+XSweeS+k6mJHX8BqlQ== X-Received: by 2002:a37:57c7:: with SMTP id l190mr5438703qkb.487.1610133781602; Fri, 08 Jan 2021 11:23:01 -0800 (PST) X-Google-Smtp-Source: ABdhPJyDh8qnbby86kxTL2aVXPZevo1ggi5Ec4h72uuRRdhdRs46munfgcTQwYgWpDZRjrU8dwX51A== X-Received: by 2002:a37:57c7:: with SMTP id l190mr5438662qkb.487.1610133781125; Fri, 08 Jan 2021 11:23:01 -0800 (PST) Received: from [192.168.1.148] (209-6-216-142.s141.c3-0.smr-cbr1.sbo-smr.ma.cable.rcncustomer.com. [209.6.216.142]) by smtp.gmail.com with ESMTPSA id o21sm5377460qko.9.2021.01.08.11.22.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 08 Jan 2021 11:23:00 -0800 (PST) Subject: Re: [PATCH] c++, abi: Fix abi_tag attribute handling [PR98481] To: Jakub Jelinek Cc: gcc-patches@gcc.gnu.org References: <20210107164718.GP725145@tucnak> From: Jason Merrill Message-ID: <07f1435c-44ce-4b00-5491-a9f07a547148@redhat.com> Date: Fri, 8 Jan 2021 14:22:59 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 MIME-Version: 1.0 In-Reply-To: <20210107164718.GP725145@tucnak> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/mixed; boundary="------------D2A84C1A468530C234D5BB53" Content-Language: en-US X-Spam-Status: No, score=-16.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: , X-List-Received-Date: Fri, 08 Jan 2021 19:23:06 -0000 This is a multi-part message in MIME format. --------------D2A84C1A468530C234D5BB53 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 1/7/21 11:47 AM, Jakub Jelinek wrote: > In GCC10 cp_walk_subtrees has been changed to walk template arguments. > As the following testcase, that changed the mangling of some functions. Argh. > I believe the previous behavior that find_abi_tags_r doesn't recurse into > template args has been the correct one, but setting *walk_subtrees = 0 > for the types and handling the types subtree walking manually in > find_abi_tags_r looks too hard, there are a lot of subtrees and details what > should and shouldn't be walked, both in tree.c (walk_type_fields there, > which is static) and in cp_walk_subtrees itself. > > The following patch abuses the fact that *walk_subtrees is an int to > tell cp_walk_subtrees it shouldn't walk the template args. > > Another option would be to have two separate cp_walk_subtrees-like > callbacks, one that wouldn't walk into template args and the other > that would and then would tail call the other one, and > cp_walk_tree_without_duplicates but call walk_tree_1 directly or use > some other macro. I like the idea to use *walk_subtrees to distinguish between walking syntactic subtrees and walking type-identity subtrees. But it should be more general; how does this look to you? Jason --------------D2A84C1A468530C234D5BB53 Content-Type: text/x-patch; charset=UTF-8; name="98481.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="98481.diff" diff --git a/gcc/cp/class.c b/gcc/cp/class.c index c41ac7deefe..00c0dba0a55 100644 --- a/gcc/cp/class.c +++ b/gcc/cp/class.c @@ -1507,6 +1507,10 @@ mark_or_check_tags (tree t, tree *tp, abi_tag_data *p, bool val) static tree find_abi_tags_r (tree *tp, int *walk_subtrees, void *data) { + if (TYPE_P (*tp) && *walk_subtrees == 1) + /* Tell cp_walk_subtrees to look though typedefs. */ + *walk_subtrees = 2; + if (!OVERLOAD_TYPE_P (*tp)) return NULL_TREE; @@ -1527,6 +1531,10 @@ find_abi_tags_r (tree *tp, int *walk_subtrees, void *data) static tree mark_abi_tags_r (tree *tp, int *walk_subtrees, void *data) { + if (TYPE_P (*tp) && *walk_subtrees == 1) + /* Tell cp_walk_subtrees to look though typedefs. */ + *walk_subtrees = 2; + if (!OVERLOAD_TYPE_P (*tp)) return NULL_TREE; diff --git a/gcc/cp/decl2.c b/gcc/cp/decl2.c index b10671091b5..b087753cfba 100644 --- a/gcc/cp/decl2.c +++ b/gcc/cp/decl2.c @@ -2358,9 +2358,6 @@ min_vis_r (tree *tp, int *walk_subtrees, void *data) int this_vis = VISIBILITY_DEFAULT; if (! TYPE_P (*tp)) *walk_subtrees = 0; - else if (typedef_variant_p (*tp)) - /* Look through typedefs despite cp_walk_subtrees. */ - this_vis = type_visibility (DECL_ORIGINAL_TYPE (TYPE_NAME (*tp))); else if (OVERLOAD_TYPE_P (*tp) && !TREE_PUBLIC (TYPE_MAIN_DECL (*tp))) { @@ -2379,6 +2376,10 @@ min_vis_r (tree *tp, int *walk_subtrees, void *data) if (this_vis > *vis_p) *vis_p = this_vis; + /* Tell cp_walk_subtrees to look through typedefs. */ + if (*walk_subtrees == 1) + *walk_subtrees = 2; + return NULL; } diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c index 82027cc9abf..c536eb581a7 100644 --- a/gcc/cp/tree.c +++ b/gcc/cp/tree.c @@ -5146,16 +5146,26 @@ cp_walk_subtrees (tree *tp, int *walk_subtrees_p, walk_tree_fn func, if (TYPE_P (*tp)) { - /* Walk into template args without looking through typedefs. */ - if (tree ti = TYPE_TEMPLATE_INFO_MAYBE_ALIAS (*tp)) - WALK_SUBTREE (TI_ARGS (ti)); - /* Don't look through typedefs; walk_tree_fns that want to look through - typedefs (like min_vis_r) need to do that themselves. */ - if (typedef_variant_p (*tp)) + /* If *WALK_SUBTREES_P is 1, we're interested in the syntactic form of + the argument, so don't look through typedefs, but do walk into + template arguments for alias templates (and non-typedefed classes). + + If *WALK_SUBTREES_P > 1, we're interested in type identity or + equivalence, so look through typedefs, ignoring template arguments for + alias templates, and walk into template args of classes. + + See find_abi_tags_r for an example of setting *WALK_SUBTREES_P to 2 + when that's the behavior the walk_tree_fn wants. */ + if (*walk_subtrees_p == 1 && typedef_variant_p (*tp)) { + if (tree ti = TYPE_ALIAS_TEMPLATE_INFO (*tp)) + WALK_SUBTREE (TI_ARGS (ti)); *walk_subtrees_p = 0; return NULL_TREE; } + + if (tree ti = TYPE_TEMPLATE_INFO (*tp)) + WALK_SUBTREE (TI_ARGS (ti)); } /* Not one of the easy cases. We must explicitly go through the --------------D2A84C1A468530C234D5BB53--