From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15162 invoked by alias); 31 Jul 2015 20:38:02 -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 15153 invoked by uid 89); 31 Jul 2015 20:38:02 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.2 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mx3-phx2.redhat.com Received: from mx3-phx2.redhat.com (HELO mx3-phx2.redhat.com) (209.132.183.24) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Fri, 31 Jul 2015 20:38:01 +0000 Received: from zmail14.collab.prod.int.phx2.redhat.com (zmail14.collab.prod.int.phx2.redhat.com [10.5.83.16]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id t6VKbxbr017982; Fri, 31 Jul 2015 16:37:59 -0400 Date: Fri, 31 Jul 2015 21:31:00 -0000 From: Kai Tietz To: Jason Merrill Cc: Jakub Jelinek , Kai Tietz , Jeff Law , gcc-patches List Message-ID: <785212094.4313048.1438375078670.JavaMail.zimbra@redhat.com> In-Reply-To: <55BBA6C1.4000105@redhat.com> References: <557BAE5A.7030309@redhat.com> <55BA5667.9040200@redhat.com> <55BAE20A.1070400@redhat.com> <55BB9EDB.8030305@redhat.com> <20150731164638.GH1780@tucnak.redhat.com> <55BBA6C1.4000105@redhat.com> Subject: Re: C++ delayed folding branch review MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-07/txt/msg02715.txt.bz2 ----- Urspr=C3=BCngliche Mail ----- > On 07/31/2015 12:46 PM, Jakub Jelinek wrote: > > On Fri, Jul 31, 2015 at 06:25:57PM +0200, Kai Tietz wrote: > >> 2015-07-31 18:14 GMT+02:00 Jason Merrill : > >>> On 07/30/2015 10:48 PM, Jeff Law wrote: > >>>> > >>>> Note, anything outside of the C/C++ front-ends depending on that > >>>> canonicalization done by shorten_compare is, IMHO, broken. > >>> > >>> I think the OMP code isn't relying on it being done by shorten_compar= e; > >>> it's > >>> trying to do it itself in c_finish_omp_for but is somehow thwarted by > >>> delayed folding. > >> > >> Well, this seems to be reasoned by finish_omp_for (), which gets > >> invoked in parser.c cp_parser_omp_for_loop, and/or pt.c: tsubst_expr. > >> In all those cases arguments aren't folded anymore. So > >> c_finish_omp_for's patterns don't match anymore. I guess we might > >> want to do this cannonical form in genericize-pass? > > > > Or just fold in finish_omp_for before calling c_finish_omp_for, so that= it > > is in the expected form? >=20 > That certainly sounds simpler. >=20 > Jason Well, it sounds easier. We need to do here this special COND-folding (means= operands only), and pass this into c_finish_omp. Of course we should just= fold OMP_FOR's COND part. I will try a patch for this- Kai