From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72552 invoked by alias); 28 Mar 2018 06:19:10 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 71855 invoked by uid 89); 28 Mar 2018 06:19:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=arising, free!, H*f:CADzB, H*o:Group X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 28 Mar 2018 06:19:07 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6B1687F6A1; Wed, 28 Mar 2018 06:19:06 +0000 (UTC) Received: from free.home (ovpn04.gateway.prod.ext.phx2.redhat.com [10.5.9.4]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 60A6D600C0; Wed, 28 Mar 2018 06:19:02 +0000 (UTC) Received: from livre (livre.home [172.31.160.2]) by free.home (8.15.2/8.15.2) with ESMTP id w2S6IgjT229824; Wed, 28 Mar 2018 03:18:42 -0300 From: Alexandre Oliva To: Jason Merrill Cc: gcc-patches List , Nathan Sidwell Subject: Re: [PATCH] [PR c++/84943] allow folding of array indexing indirect_ref References: Date: Wed, 28 Mar 2018 06:31:00 -0000 In-Reply-To: (Jason Merrill's message of "Fri, 23 Mar 2018 16:59:33 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2018-03/txt/msg01481.txt.bz2 On Mar 23, 2018, Jason Merrill wrote: > On Fri, Mar 23, 2018 at 4:55 PM, Jason Merrill wrote: >> On Fri, Mar 23, 2018 at 12:44 PM, Jason Merrill wrote: >>> Seems like cp_fold should update CALL_EXPR_FN with "callee" if non-null. >> >> Did you try this? That should avoid it being ADDR_EXPR of a decl. > Oh, I was assuming the ICE was in the middle-end, but it's in > build_call_a. And it looks like the problem isn't that it's an > ADDR_EXPR of a decl, but that the function isn't marked TREE_USED. Well, yeah. cp_build_function_call_vec marks the function as used when function is a FUNCTION_DECL. In this testcase, it's INDIRECT_REF of ADDR_EXPR of FUNCTION_DECL. Since the idea of bypassing cancelling-out pairs of INDIRECT_REF and ADDR_EXPR, that would have allowed cp_build_function_call_vec to get to the FUNCTION_DECL and mark it as used was not accepted, the alternative was to stop build_call_a from getting to the FUNCTION_DECL, which was very much in line of what you'd said about preserving source constructs and allowing the significant differences for some language rules to remain in place. Now, to me, it is clear that if we are to preserve source level constructs because they could make some significant different WRT certain language rules, and to that end we don't want to simplify the INDIRECT_REF arising from the array indexing with the ADDR_EXPR of the function-to-pointer decay, then it should follow that we also don't want to simplify the ADDR_EXPR that build_addr_func would introduce with that INDIRECT_REF. That's what the latest patch I proposed does, and it also solves the potential inconsistency between cp_build_function_call_vec and build_call_a, in which one of them does not find the FUNCTION_DECL because it's too deeply hidden within INDIRECT_REFs/ADDR_EXPRs pairs and so it fails to mark the decl as used, but then the other finds it because build_addr_func peeled an INDIRECT_REF, and then complains that the decl is not marked as used. Now, I don't know what the rules are that could make a difference in this case, but I must confess that I'm a bit surprised that the following constructs could possibly be interpreted differently under C++ rules: f(); (&f)(); (*f)(); f[0](); (*&f)(); (*&*&*&f)(); Maybe they aren't when we get to cp_build_function_call_vec (any differences WRT overload resolution would have been taken care of), and we should use get_callee_fndecl in cp_build_function_call_vec, and arrange for get_callee_fndecl to peel as many layers of INDIRECT_REF and ADDR_EXPR as it finds when searching for a FUNCTION_DECL. Anyway, given the accumulated constraints I've been given WRT to this bug, I'm afraid I've run out of ideas. I welcome suggestions as to how to proceed. -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer