[LLVMdev] gfortran calling convention
michael.mccracken at gmail.com
Mon Sep 11 15:40:02 PDT 2006
On 9/11/06, Chris Lattner <sabre at nondot.org> wrote:
> On Sat, 9 Sep 2006, Michael McCracken wrote:
> >> No, gfortran in gcc 4.0 is, ehm, highly experimental (read: a piece of
> >> junk). Gfortran in gcc 4.1 was the first one that worked for NIST (and
> >> for SPEC).
> > Hm. I had noticed a bunch of changes in the current sources, but had
> > hoped 4.0.1 wasn't too far behind. This is discouraging. So, it sounds
> > like it might be a waste of effort to work on the 4.0.1 llvm-gfortran.
> I think that any porting work you do now will still be valuable in the
> future... so it's not wasted effort. I don't know how useful 4.0.1 will
> 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.
> > What are the plans for moving to a newer gcc for the llvm branch? I
> > suspect it isn't planned too soon, right?
> Not soon. We are likely to skip 4.1 and go right to 4.2, but 4.2 has to
> get more solid first.
> > What about just updating the fortran-related sources in the llvm
> > branch to their current state in gcc svn and going from there, does
> > anyone have a good idea how difficult that would be? From my limited
> > experience, it seems like the interface between gfortran and the rest
> > of the gcc tree doesn't need to change much.
> > I'm not clear on how hard that would be to manage merging later, but I
> > would like to be able to keep moving on this without running over old
> > bugs...
> No idea, but that sounds like a pretty big change. It may be simpler (or
> 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?
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.
UCSD CSE PhD Candidate
More information about the llvm-dev