> -----Original Message-----
> From: Terry Guo [mailto:terry....@arm.com]
> Sent: Wednesday, July 04, 2012 15:12
> To: 'Andrew Pinski'; tob...@grosser.es
> Cc: gcc-patches@gcc.gnu.org; Joey Ye
> Subject: RE: [PATCH] Move Graphite from using PPL over to ISL
> 
> 
> 
> > -----Original Message-----
> > From: pins...@gmail.com [mailto:pins...@gmail.com] On Behalf Of
> Andrew
> > Pinski
> > Sent: Wednesday, July 04, 2012 2:58 PM
> > To: Terry Guo
> > Cc: Richard Guenther; gcc-patches@gcc.gnu.org; tob...@grosser.es;
> > seb...@gmail.com; Michael Matz; Diego Novillo; Joey Ye
> > Subject: Re: [PATCH] Move Graphite from using PPL over to ISL
> >
> > On Tue, Jul 3, 2012 at 11:51 PM, Terry Guo <terry....@arm.com> wrote:
> > > Hi Richard,
> > >
> > > What's the plan for 4.7 branch? Will you back port this patch to
> 4.7
> > and
> > > make it use ISL too? I am going to create a upstream GCC SVN branch
> > from 4.7
> > > for development on ARM embedded processors. If there will be some
> big
> > > changes for 4.7 in near future in terms of replacing PPL with ISL,
> I
> > will
> > > delay the creation of my branch. Thanks.
> >
> > GCC has a policy of not backporting new features to release branches.
> > This can be considered a new feature.  In fact what might happen is
> > disabling of the graphite support on the 4.7 branch instead.
> >
> > Is there a reason why you can't do development on the trunk?  And
> then
> > support a 4.7 for your own uses?  At Cavium, we try to do development
> > on an internal tree and then post them upstream.  Though in the
> future
> > we would like to do things upstream first and then backport features
> > to a release branch that we handle internally.
> >
> 
> Hi Tobi and Andrew,
> 
> Thanks for your timely answers. I just saw Sebastian's comments:
> 
> Yes, having GCC only depend on ISL and CLooG-ISL (and not depend
> anymore on PPL) is our plan for 4.7.
> 
> from http://gcc.gnu.org/ml/gcc-patches/2011-08/msg01161.html.
> 
> As for development model, we do work as Andrew said, upstream first and
> then backport features. The 4.7 branch I mentioned is mainly because we
> want to make a tool chain release based on 4.7 with some fixes
> backported from trunk.
Don't think it make sense backporting to 4.7 either. 

- Joey


Reply via email to