From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12386 invoked by alias); 13 Nov 2012 21:46:27 -0000 Received: (qmail 12373 invoked by uid 22791); 13 Nov 2012 21:46:27 -0000 X-SWARE-Spam-Status: No, hits=-7.0 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 13 Nov 2012 21:46:23 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qADLkMoZ031984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Nov 2012 16:46:22 -0500 Received: from anchor.twiddle.home (vpn-229-156.phx2.redhat.com [10.3.229.156]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id qADLkLA0009295; Tue, 13 Nov 2012 16:46:21 -0500 Message-ID: <50A2BFAC.8000102@redhat.com> Date: Tue, 13 Nov 2012 21:46:00 -0000 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121029 Thunderbird/16.0.2 MIME-Version: 1.0 To: Eric Botcazou CC: Richard Sandiford , gcc-patches@gcc.gnu.org Subject: Re: [4/8] Add bit_field_mode_iterator References: <87k3u3eybu.fsf@talisman.home> <87390rexub.fsf@talisman.home> <1899065.5XNjVddQ6H@polaris> In-Reply-To: <1899065.5XNjVddQ6H@polaris> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: 2012-11/txt/msg01035.txt.bz2 On 11/13/2012 04:41 AM, Eric Botcazou wrote: > I find the interface a bit awkward though. Can't we model it on the existing > iterators in basic-block.h or tree-flow.h? get_best_mode would be written: > > FOR_EACH_BITFIELD_MODE (mode, iter, bitsize, bitpos, > bitregion_start, bitregion_end, > align, volatilep) Now that we're in C++, I think we should be using iterators that are much more in the style of libstdc++. I agree that the .next interface used here is a bit confusing. I'd expect to see something like for (bit_field_mode_iterator i(x,y,z); i ; ++i) { enum machine_mode mode = *i; ... } For 4.9, I expect that someone can slowly purge our FOR_EACH_* macros... r~