gfortran calling convention

You wrote:

The NIST F77 test suite doesn't seem to be compatible with gfortran at
all,

Actually, the entire suite compiles flawlessly with gfortran.
See http://gcc.gnu.org/wiki/GFortranResults

Gr.
Steven

Was that true of GCC 4.0.1?

-Chris

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).

Gr.
Steven

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.
What are the plans for moving to a newer gcc for the llvm branch? I
suspect it isn't planned too soon, right?

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...

Any ideas from those more familiar with the situation?

Thanks,
-mike

I'm actually trying this while I wait for some other things to
complete, but as it stands, it seems like a bad idea. It certainly
seems more complicated than just dropping in new sources.

What I did was simply to copy over the libgfortran/ and gcc/fortran/
directories from the GCC SVN (4.2) from last friday into an llvm-gcc
tree, re-apply my changes from the previous patches, and try
compiling.

What I got was a bunch of link errors in gtype-desc.c, and I'm not
sure I want to make any changes outside of the gfortran subdirs, since
that would make merging changes back in a real pain.

Am I missing another option, or am I out of luck until llvm-gcc updates to 4.1?

Thanks,
-mike

Another option might be g95 instead of gfortran. I haven't used it for
a while, but I seem to recall it working fine in gcc 4.0.1.

I'm specifically interested in compiling fortran to LLVM, so I expect
that the changes necessary to get g95 to output LLVM would be
prohibitive.

I'm not 100% familiar with the situation, but g95 is apparently a
one-man project and is not part of gcc, while gfortran was forked from
g95 at some point and is officially part of gcc. At least for my
purposes, g95 is a non-starter.

Thanks,
-mike

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.

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.

-Chris

>> 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.

Ok.

> 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.

-mike

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

>> 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

I'd only do the LLVM changes. The non-llvm apple changes include a bunch of stuff you almost certainly don't care about. :slight_smile:

-Chris

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.

Long ago (4.1 was on trunk) I tried to do it because the apple branch
didn't worked on Linux.

The only big change that I know is that in newer GCC the gimple trees
are already broken up in basic blocks. This may actually make the
conversion simpler, but it requires some work.

-Chris

Rafael