gfortran calling convention

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

gfortran calling convention

Steven Bosscher-6
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


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: gfortran calling convention

Chris Lattner
On Sat, 9 Sep 2006, Steven Bosscher wrote:
> 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

Was that true of GCC 4.0.1?

-Chris

--
http://nondot.org/sabre/
http://llvm.org/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: gfortran calling convention

Steven Bosscher-6
On 9/9/06, Chris Lattner <[hidden email]> wrote:
> On Sat, 9 Sep 2006, Steven Bosscher wrote:
> > 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
>
> Was that true of GCC 4.0.1?

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
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: gfortran calling convention

Michael McCracken
On 9/9/06, Steven Bosscher <[hidden email]> wrote:

> On 9/9/06, Chris Lattner <[hidden email]> wrote:
> > On Sat, 9 Sep 2006, Steven Bosscher wrote:
> > > 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
> >
> > Was that true of GCC 4.0.1?
>
> 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.
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

--
Michael McCracken
UCSD CSE PhD Candidate
research: http://www.cse.ucsd.edu/~mmccrack/
misc: http://michael-mccracken.net/wp/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: gfortran calling convention

Michael McCracken
On 9/9/06, Michael McCracken <[hidden email]> wrote:

> On 9/9/06, Steven Bosscher <[hidden email]> wrote:
> > On 9/9/06, Chris Lattner <[hidden email]> wrote:
> > > On Sat, 9 Sep 2006, Steven Bosscher wrote:
> > > > 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
> > >
> > > Was that true of GCC 4.0.1?
> >
> > 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.
> 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?

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

--
Michael McCracken
UCSD CSE PhD Candidate
research: http://www.cse.ucsd.edu/~mmccrack/
misc: http://michael-mccracken.net/wp/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: gfortran calling convention

Ryan Brown-4
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.

On 9/11/06, Michael McCracken <[hidden email]> wrote:

> On 9/9/06, Michael McCracken <[hidden email]> wrote:
> > On 9/9/06, Steven Bosscher <[hidden email]> wrote:
> > > On 9/9/06, Chris Lattner <[hidden email]> wrote:
> > > > On Sat, 9 Sep 2006, Steven Bosscher wrote:
> > > > > 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
> > > >
> > > > Was that true of GCC 4.0.1?
> > >
> > > 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.
> > 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?
>
> 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
>
> --
> Michael McCracken
> UCSD CSE PhD Candidate
> research: http://www.cse.ucsd.edu/~mmccrack/
> misc: http://michael-mccracken.net/wp/
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: gfortran calling convention

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

On 9/11/06, Ryan Brown <[hidden email]> wrote:

> 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.
>
> On 9/11/06, Michael McCracken <[hidden email]> wrote:
> > On 9/9/06, Michael McCracken <[hidden email]> wrote:
> > > On 9/9/06, Steven Bosscher <[hidden email]> wrote:
> > > > On 9/9/06, Chris Lattner <[hidden email]> wrote:
> > > > > On Sat, 9 Sep 2006, Steven Bosscher wrote:
> > > > > > 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
> > > > >
> > > > > Was that true of GCC 4.0.1?
> > > >
> > > > 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.
> > > 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?
> >
> > 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
> >
> > --
> > Michael McCracken
> > UCSD CSE PhD Candidate
> > research: http://www.cse.ucsd.edu/~mmccrack/
> > misc: http://michael-mccracken.net/wp/
> > _______________________________________________
> > LLVM Developers mailing list
> > [hidden email]         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>


--
Michael McCracken
UCSD CSE PhD Candidate
research: http://www.cse.ucsd.edu/~mmccrack/
misc: http://michael-mccracken.net/wp/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: gfortran calling convention

Chris Lattner
In reply to this post by Michael McCracken
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.

> 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

--
http://nondot.org/sabre/
http://llvm.org/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: gfortran calling convention

Michael McCracken
On 9/11/06, Chris Lattner <[hidden email]> 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.

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

--
Michael McCracken
UCSD CSE PhD Candidate
research: http://www.cse.ucsd.edu/~mmccrack/
misc: http://michael-mccracken.net/wp/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: gfortran calling convention

Chris Lattner
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/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: gfortran calling convention

Michael McCracken
On 9/11/06, Chris Lattner <[hidden email]> 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/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: gfortran calling convention

Chris Lattner
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/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: gfortran calling convention

Rafael Espíndola
In reply to this post by Chris Lattner
> 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
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev