On Mon, 11 Sep 2006, Michael McCracken wrote:>> be though. > > I'm thinking that effort on 4.0.1 gfortran is not worthwhile, since > 4.0.1 fails to compile some pretty basic examples, and there are some > pretty extensive changes between then and 4.2.ok>> comperable) to merge the LLVM changes into 4.1. I'm personally not >> interested in doing the work, but if you wanted to tackle it I'd be happy >> to answer questions that arise from it if I can. > > Yes, it did turn out to be a big change. > So are you also saying that it'd be simpler to merge the LLVM changes > into 4.1 than it would be to merge them into 4.2?Sorry, I'm suggesting that merging the LLVM changes into 4.1 might be easier than merging the gfortran changes into 4.0.> Maybe it's unwise, but my first impulse if I'm going to tackle merging > so many changes is to not merge with a branch. However, I'm not really > sure right now how much work we're talking about here.I really don't know how hard it will be either. A nice aspect of the LLVM changes is that their interface to the rest of the compiler (trees) are relatively stable. -Chris -- http://nondot.org/sabre/ http://llvm.org/
On 9/11/06, Chris Lattner <sabre at nondot.org> wrote:> On Mon, 11 Sep 2006, Michael McCracken wrote: > >> be though. > > > > I'm thinking that effort on 4.0.1 gfortran is not worthwhile, since > > 4.0.1 fails to compile some pretty basic examples, and there are some > > pretty extensive changes between then and 4.2. > > ok > > >> comperable) to merge the LLVM changes into 4.1. I'm personally not > >> interested in doing the work, but if you wanted to tackle it I'd be happy > >> to answer questions that arise from it if I can. > > > > Yes, it did turn out to be a big change. > > So are you also saying that it'd be simpler to merge the LLVM changes > > into 4.1 than it would be to merge them into 4.2? > > Sorry, I'm suggesting that merging the LLVM changes into 4.1 might be > easier than merging the gfortran changes into 4.0.ok> > Maybe it's unwise, but my first impulse if I'm going to tackle merging > > so many changes is to not merge with a branch. However, I'm not really > > sure right now how much work we're talking about here. > > I really don't know how hard it will be either. A nice aspect of the LLVM > changes is that their interface to the rest of the compiler (trees) are > relatively stable.What about their interactions with the other Apple changes? Could I get a working compiler out of only merging the "APPLE LOCAL LLVM" changes into gcc, or would I have to merge all the Apple changes also? As a quick count, I grepped for "APPLE LOCAL" and "APPLE LOCAL LLVM": "APPLE LOCAL" : ~6000 "APPLE LOCAL*LLVM": 176 (includes "APPLE LOCAL LLVM" and "APPLE LOCAL begin LLVM", and one instance of "APPLE LOCAL LLVM begin") I might try the second, but I don't think I have the time for the first. -mike -- Michael McCracken UCSD CSE PhD Candidate research: http://www.cse.ucsd.edu/~mmccrack/ misc: http://michael-mccracken.net/wp/
On Mon, 11 Sep 2006, Michael McCracken wrote:>> I really don't know how hard it will be either. A nice aspect of the LLVM >> changes is that their interface to the rest of the compiler (trees) are >> relatively stable. > > What about their interactions with the other Apple changes? > Could I get a working compiler out of only merging the "APPLE LOCAL > LLVM" changes into gcc, or would I have to merge all the Apple changes > also? > > As a quick count, I grepped for "APPLE LOCAL" and "APPLE LOCAL LLVM": > "APPLE LOCAL" : ~6000 > "APPLE LOCAL*LLVM": 176 (includes "APPLE LOCAL LLVM" and "APPLE LOCAL > begin LLVM", and one instance of "APPLE LOCAL LLVM begin") > > I might try the second, but I don't think I have the time for the first.I'd only do the LLVM changes. The non-llvm apple changes include a bunch of stuff you almost certainly don't care about. :) -Chris -- http://nondot.org/sabre/ http://llvm.org/