From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 122229 invoked by alias); 27 Nov 2015 22:43:52 -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 122220 invoked by uid 89); 27 Nov 2015 22:43:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 27 Nov 2015 22:43:50 +0000 Received: from nat-ies.mentorg.com ([192.94.31.2] helo=SVR-IES-FEM-01.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1a2Rk1-0001gl-Ab from joseph_myers@mentor.com ; Fri, 27 Nov 2015 14:43:45 -0800 Received: from digraph.polyomino.org.uk (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.3.224.2; Fri, 27 Nov 2015 22:43:43 +0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.82) (envelope-from ) id 1a2Rjy-0008AN-DB; Fri, 27 Nov 2015 22:43:42 +0000 Date: Fri, 27 Nov 2015 23:56:00 -0000 From: Joseph Myers To: Marek Polacek CC: GCC Patches , Jakub Jelinek , Richard Biener Subject: Re: [PATCH] Add save_expr langhook (PR c/68513) In-Reply-To: <20151127185531.GA28072@redhat.com> Message-ID: References: <20151127185531.GA28072@redhat.com> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2015-11/txt/msg03402.txt.bz2 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). 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 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. 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.... -- Joseph S. Myers joseph@codesourcery.com