From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 120128 invoked by alias); 30 Nov 2015 12:38:04 -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 120115 invoked by uid 89); 30 Nov 2015 12:38:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Mon, 30 Nov 2015 12:38:02 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 184738E69C; Mon, 30 Nov 2015 12:38:01 +0000 (UTC) Received: from redhat.com (ovpn-204-104.brq.redhat.com [10.40.204.104]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id tAUCbuM3003482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 30 Nov 2015 07:37:59 -0500 Date: Mon, 30 Nov 2015 12:58:00 -0000 From: Marek Polacek To: Joseph Myers Cc: GCC Patches , Jakub Jelinek , Richard Biener Subject: Re: [PATCH] Add save_expr langhook (PR c/68513) Message-ID: <20151130123755.GD28072@redhat.com> References: <20151127185531.GA28072@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-SW-Source: 2015-11/txt/msg03474.txt.bz2 On Fri, Nov 27, 2015 at 10:43:42PM +0000, Joseph Myers wrote: > On Fri, 27 Nov 2015, Marek Polacek wrote: > > > I didn't know where to put setting of in_late_processing. With the current > > placement, we won't (for valid programs) call c_save_expr from c_genericize > > or c_gimplify_expr. > > Well, the placement in this patch (in c_parser_compound_statement) is > certainly wrong. It doesn't even save and restore, so after one compound > statement inside another, parsing would continue with in_late_processing > wrongly set. And c_save_expr is logically right for any parsing outside > compound statements as well (arbitrary expressions can occur in sizeof > outside functions and in VLA parameter sizes and should follow the normal > rules for what's a constant expression - there's a known bug that > statement expressions are wrongly rejected in such contexts). Indeed. I don't know what I was thinking. :/ > Starting from first principles: parsing takes place from within > c_parse_file as the sole external entry point to the parser. So you could > have a parsing_input variable that starts off as false, and where > c_parse_file saves it, sets to true, and restores the saved value at the > end. Then you'd use c_save_expr if parsing_input && !in_late_binary_op. > > If that doesn't work, it means there are cases where the hook gets called > from folding that takes place during parsing, on expressions that will not > subsequently go through c_fully_fold, but without in_late_binary_op set. > Knowing what those cases are might help work out any fix for them that is > needed. I'm not sanguine about doing this reliably in stage3. I think I'll try the other approach mentioned later in this thread. > > I suppose I should also modify save_expr in fold-const.c to call it via the > > langhook, if this approach is sane. Dunno. > > That's a complication. When the folding is taking place from within > c_fully_fold (and so the sub-expressions have already been folded, and had > their C_MAYBE_CONST_EXPRs removed, and the result of folding will not be > re-folded), it should be using save_expr not c_save_expr. So maybe the > hook needs to say: use c_save_expr, if parsing, not in_late_binary_op and > not folding from within c_fully_fold. Oh, I see :(. > Again long term we should aim for the representation during parsing not to > need SAVE_EXPRs and for the folding that creates them (and the other > folding for optimization in general) to happen only after parsing.... Yeah, let's strike that for gcc7. Thanks, Marek