From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10747 invoked by alias); 28 Apr 2008 17:22:55 -0000 Received: (qmail 10738 invoked by uid 22791); 28 Apr 2008 17:22:55 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 28 Apr 2008 17:22:27 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id m3SHKG3n013485; Mon, 28 Apr 2008 13:20:16 -0400 Received: from devserv.devel.redhat.com (devserv.devel.redhat.com [10.10.36.72]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id m3SHKFoo019700; Mon, 28 Apr 2008 13:20:16 -0400 Received: from devserv.devel.redhat.com (localhost.localdomain [127.0.0.1]) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id m3SHKFwL017850; Mon, 28 Apr 2008 13:20:15 -0400 Received: (from jakub@localhost) by devserv.devel.redhat.com (8.12.11.20060308/8.12.11/Submit) id m3SHKFci017848; Mon, 28 Apr 2008 13:20:15 -0400 Date: Mon, 28 Apr 2008 20:43:00 -0000 From: Jakub Jelinek To: Mark Mitchell Cc: Jason Merrill , gcc-patches@gcc.gnu.org Subject: Re: C++ patch ping Message-ID: <20080428172015.GW2255@devserv.devel.redhat.com> Reply-To: Jakub Jelinek References: <20080428162806.GV2255@devserv.devel.redhat.com> <4816041B.9060300@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4816041B.9060300@codesourcery.com> User-Agent: Mutt/1.4.1i X-IsSubscribed: yes 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 X-SW-Source: 2008-04/txt/msg02055.txt.bz2 On Mon, Apr 28, 2008 at 10:06:35AM -0700, Mark Mitchell wrote: > Jakub Jelinek wrote: > > >- http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01609.html PR c++/35650 > > I think this patch is OK. As you say, we could also change Thanks. > >- http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01559.html PR c++/35987 > > This is OK, too, though I would prefer using error_operand_p to the > direct comparision with error_mark_node. In this case, error_mark_node > is probably correct -- but using error_operand_p for expressions is more > mnemonic. cp_build_modify_expr starts with: /* Avoid duplicate error messages from operands that had errors. */ if (error_operand_p (lhs) || error_operand_p (rhs)) return error_mark_node; so it should turn many results res != error_mark_node && TREE_TYPE (res) == error_mark_node into error_mark_node. And the following cases also use direct error_mark_node comparison: /* Handle (a, b) used as an "lvalue". */ case COMPOUND_EXPR: newrhs = cp_build_modify_expr (TREE_OPERAND (lhs, 1), modifycode, rhs, complain); if (newrhs == error_mark_node) ^^^^ here return error_mark_node; return build2 (COMPOUND_EXPR, lhstype, TREE_OPERAND (lhs, 0), newrhs); case MODIFY_EXPR: if (TREE_SIDE_EFFECTS (TREE_OPERAND (lhs, 0))) lhs = build2 (TREE_CODE (lhs), TREE_TYPE (lhs), stabilize_reference (TREE_OPERAND (lhs, 0)), TREE_OPERAND (lhs, 1)); newrhs = cp_build_modify_expr (TREE_OPERAND (lhs, 0), modifycode, rhs, complain); if (newrhs == error_mark_node) ^^^^ and here return error_mark_node; return build2 (COMPOUND_EXPR, lhstype, lhs, newrhs); (and later code in the function does similarly). So, if I should use error_operand_p instead, I guess it should be changed consistently for all 3 cases, or none. Jakub