Can someone know the time for a oo implemented F2003 complier release under the window platform?
lles...@gmail.com
GaryScott
> It can be see it in this year?
Now taking wagers...vote for the compiler vendor (one of their
products on any platform) that will first achieve 100% compliance
(realize that some of these may not be in the race or for some
operating systems):
Absoft
Lahey/Fujitsu
Intel
Silverfrost/Salford
HP
IBM
NAG
PGI
SUN
Pathscale
G95
GFortran
Other
I should set up a voting web site...
Richard Maine
> Now taking wagers...vote for the compiler vendor (one of their
> products on any platform) that will first achieve 100% compliance...
Well, from the tables of implmented features I have seen, it looks like
IBM has been awful close for a while. I seem to recall that
parameterized derived types were the only major feature listed as
missing. I haven't had direct experience with the IBM compilers for
quite a few years now (last one I tried was the beta of XLF for OS X),
so I'm basing this just on the posted tables rather than on any kind of
actual first-hand (or even second-hand) tests. And, of course, the
operating system coverage is... limitted.
NAG has historically (for history starting with f90), been early. On the
other hand, it has seemed to me like NAG's progress slowed by about an
order of magnitude about the time that Malcolm went off for his stint in
Japan; this might not be a coincidence. Malcolm is about an order of
magnitude more productive than a lot of the rest of us humans, so that
figures.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
Gerry Ford
"GaryScott" <garyl...@sbcglobal.net> wrote in message
news:d1af1416-9ffd-4073...@t12g2000prg.googlegroups.com...
--->Can we come up with code snippets that would test incrementally-closer
compliance? I don't know what oo looks like in fortran. Does anyone have
any experience with it in fortran? I stumbled onto the topic some years
back when I wanted to have C functions that do the same thing with different
types.
As for my money, I'll bet against silverfrost and on sun. Of course, sun
isn't windows. I'm hoping that it can co-exist with windows, however. And
as long as we're betting, I'll take the Celtics over the Lakers.
--
"A belief in a supernatural source of evil is not necessary; men alone
are quite capable of every wickedness."
~~ Joseph Conrad (1857-1924), novelist
FX
Sun compilers run on linux, you know, you don't need to install Solaris
(which is what I think you're referring to) (although I had a year ago a
nice WinXP / DOS / Linux / Solaris / NetBSD system that earned me quite a
few points in most geek tests :)
--
FX
Richard Maine
> (although I had a year ago a
> nice WinXP / DOS / Linux / Solaris / NetBSD system that earned me quite a
> few points in most geek tests :)
Our Apple rep showed us something comparable one time a few years ago.
He was running OS X (of course), with several of those other options
running under Parallels. Of course, it had WinXP. I think I recall
Solaris, which I thought was pretty nifty for an Apple rep, and some
Linux distro. (Yes, NASA got Apple reps that could talk geek in addition
to the usual market-speak).
Damian
> "GaryScott" <garylsc...@sbcglobal.net> wrote in message
I try to avoid posting guesswork, but I have interacted with
developers of roughly seven Fortran compilers over the past 3 years,
so at least these are informed guesses:
My bet goes with IBM to be first and g95 to be last. Please don't take
that as a slam on g95. As the name of the compiler implies, 100%
compliance with Fortran 2003 is not a high priority. I respect that.
I like developers who prefer to do something (Fortran 95) really well
instead of constantly adding on the latest greatest features whether
or not they work. And there are things g95 does extremely well, e.g.
reporting memory leaks.
Without having any experience with Cray, it seems they are right on
IBM's heels, so I'd guess they'd be second (that guess is not based on
any personal experience though). NAG is not too far behind either, so
I'd guess they'd be third. I'll reserve comment on most of the others
except to say that gfortran is really raging forward. They are so
much further along today than they were even a year ago, that it's not
hard to imagine they could be there within about two years. It's just
a question of what time volunteers can find. It would be awesome if
some commercial vendor would do for gfortran what so many are doing
for Linux, but obviously the size of the respective user communities
differs by orders of magnitude.
I recently submitted a journal article with about 1200 lines of object-
oriented Fortran 2003 using the IBM compiler. Of the 7 or so compilers
I tried, IBM's was the only one that supported all of the features I
tried. I'm hesitant to distribute the code until the paper
(hopefully) survives peer review, but I'll be glad to post snippets
once it does. If I get a chance, I'll dig up some related snippets
that weren't in the paper and post those.
Damian
angelv
Richard Maine wrote:
> Well, from the tables of implmented features I have seen, it looks like
> IBM has been awful close for a while. I seem to recall that
> parameterized derived types were the only major feature listed as
> missing. I haven't had direct experience with the IBM compilers for
> quite a few years now (last one I tried was the beta of XLF for OS X),
> so I'm basing this just on the posted tables rather than on any kind of
> actual first-hand (or even second-hand) tests. And, of course, the
> operating system coverage is... limitted.
Do you know of any more or less up-to-date table describing the
implemented features of each compiler? For an application I'm
writting, I would very much like to use procedure pointers, but the
(little) search I've done in this group and in the PGI reference
manual didn't show up anything conclusive (there was an interesting
discussion about this a couple of years ago in this newsgroup, but I
wonder if things have chanced for the better since then).
Thanks,
Ángel de Vicente
Damian
See the December 2007 table in ACM Fortran Forum:
http://portal.acm.org/browse_dl.cfm?coll=portal&dl=ACM&idx=J286&linked=1&part=newsletter
I don't think PGI supports procedure pointers, but if you can get your
hands on a beta copy of their next release (7.2?), I believe it has
most of the C interoperability features of Fortran 2003. In that
case, you might be able to use C function pointers instead. I know
this works with gfortran 4.3.0.
Damian
James Van Buskirk
news:d94b1b92-9b69-4684...@m73g2000hsh.googlegroups.com...
On Apr 17, 6:24 am, angelv <txibi...@gmail.com> wrote:
> > Do you know of any more or less up-to-date table describing the
> > implemented features of each compiler? For an application I'm
> > writting, I would very much like to use procedure pointers, but the
> > (little) search I've done in this group and in the PGI reference
> > manual didn't show up anything conclusive (there was an interesting
> > discussion about this a couple of years ago in this newsgroup, but I
> > wonder if things have chanced for the better since then).
> I don't think PGI supports procedure pointers, but if you can get your
> hands on a beta copy of their next release (7.2?), I believe it has
> most of the C interoperability features of Fortran 2003. In that
> case, you might be able to use C function pointers instead. I know
> this works with gfortran 4.3.0.
He might be able to use C_FUNPTRs untils he feels the need to invoke
one of the procedures, at which time he will once again feel the
lack of procedure pointers in gfortran 4.0. It is possible to work
around this with cray pointers, and that's what I do at the present
time. Maybe it would be a good thing to write also the procedure
pointer code next to the cray pointer code and comment it out so
that when the time comes it will be relatively easy to change to
the standard syntax when gfortran catches up.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
Damian
Oops... I should have mentioned that my use of a C function pointer
was to take the location of a Fortran procedure, pass that location to
a C++ procedure (wrapped by 'extern C') and then invoke the procedure
from C++. In my case, that made sense because there was a pre-
existing C++ code I wanted to call a Fortran code. In other cases,
would it work to create an ad hoc C wrapper exclusively for invoking
the fortran procedure via a C_FUNPTR? I'm imagining the additional
coding would be pretty minimal and it would be standards-conforming
and therefore portable. On the one hand, the Fortran code would be
limited to receiving C types. On the other hand, one of those C types
could actually be a void * pointing to whatever you want, even a
derived type. I can post some demonstration code if so desired.
Damian
James Van Buskirk
> Oops... I should have mentioned that my use of a C function pointer
> was to take the location of a Fortran procedure, pass that location to
> a C++ procedure (wrapped by 'extern C') and then invoke the procedure
> from C++. In my case, that made sense because there was a pre-
> existing C++ code I wanted to call a Fortran code. In other cases,
> would it work to create an ad hoc C wrapper exclusively for invoking
> the fortran procedure via a C_FUNPTR? I'm imagining the additional
> coding would be pretty minimal and it would be standards-conforming
> and therefore portable. On the one hand, the Fortran code would be
> limited to receiving C types. On the other hand, one of those C types
> could actually be a void * pointing to whatever you want, even a
> derived type. I can post some demonstration code if so desired.
Spoken like a true C programmer. Why write a C wrapper to invoke a
Fortran procedure when Fortran can do so all by itself? Here is an
example with cray pointers, could be updated to use procedure
pointers if they ever come true:
C:\gfortran\clf\fptr>type fptr.f90
module funcs
implicit none
! Interface block for function program fptr will invoke
! to get the C_FUNPTR
interface
function get_proc(mess) bind(C,name='BlAh')
use ISO_C_BINDING
implicit none
character(kind=C_CHAR) mess(*)
type(C_FUNPTR) get_proc
end function get_proc
end interface
end module funcs
module other_fun
use ISO_C_BINDING
implicit none
private
! Message to be returned by procedure pointed to
! by the C_FUNPTR
character, allocatable, save :: my_message(:)
! Interface block for the procedure pointed to
! by the C_FUNPTR
public abstract_fun
abstract interface
function abstract_fun(x)
use ISO_C_BINDING
import my_message
implicit none
integer(C_INT) x(:)
character(size(my_message),C_CHAR) abstract_fun(size(x))
end function abstract_fun
end interface
contains
! Procedure to store the message and get the C_FUNPTR
function gp(message) bind(C,name='BlAh')
character(kind=C_CHAR) message(*)
type(C_FUNPTR) gp
integer(C_INT64_T) i
i = 1
do while(message(i) /= C_NULL_CHAR)
i = i+1
end do
my_message = message(int(1,kind(i)):i-1)
gp = get_funloc(make_mess,aux)
end function gp
! Intermediate procedure to pass the function and get
! back the C_FUNPTR
function get_funloc(x,y)
procedure(abstract_fun) x
type(C_FUNPTR) y
external y
type(C_FUNPTR) get_funloc
get_funloc = y(x)
end function get_funloc
! Procedure to convert the function to C_FUNPTR
function aux(x)
interface
subroutine x() bind(C)
end subroutine x
end interface
type(C_FUNPTR) aux
aux = C_FUNLOC(x)
end function aux
! Procedure pointed to by the C_FUNPTR
function make_mess(x)
integer(C_INT) x(:)
character(size(my_message),C_CHAR) make_mess(size(x))
make_mess = transfer(my_message,make_mess(1))
end function make_mess
end module other_fun
program fptr
use funcs
use other_fun
implicit none
interface
procedure(abstract_fun) fun
end interface
pointer(p,fun)
type(C_FUNPTR) fp
fp = get_proc('Hello, world'//achar(0))
p = transfer(fp,p)
write(*,'(a)') fun([1,2,3])
end program fptr
C:\gfortran\clf\fptr>C:\gcc_equation\bin\x86_64-pc-mingw32-gfortran
fptr.f90 -of
ptr
f951.exe: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
See, it works great and doesn't even need C++ to achieve the
desired result.
Richard Maine
> Spoken like a true C programmer. Why write a C wrapper to invoke a
> Fortran procedure when Fortran can do so all by itself? Here is an
> example with cray pointers...
Perhaps because Cray pointers aren't Fortran, but are an extension. In
particular, they are an extension that is not supported by the compilers
I use. In fact, Cray pointers to procedures are supported by very few
compilers. I suppose I should say "so-called Cray pointers to
procedures", insomuch as Cray compilers did not support that particular
variant. There was a time when I think that the set of compilers
supporting Cray pointers to procedures had one element; I think it might
have more now, but it still certainly isn't something to use if very
concerned about portability.
Note that Damian said
>> I'm imagining the additional
>> coding would be pretty minimal and it would be standards-conforming
>> and therefore portable.
I'm imagining that there is at least a chance that he meant exactly what
he said - that standard conformance and portability were factors he
considered.
....
> f951.exe: internal compiler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See <http://gcc.gnu.org/bugs.html> for instructions.
>
> See, it works great and doesn't even need C++ to achieve the
> desired result.
I find myself not entirely sure whether this was intended as a humorous
dig at gfortran or whether the wrong thing got pasted into the message.
I do find it a bit amusing so I'm leaning in that direction.
I suppose that if the message was intended as humor, I might have missed
a simillar humorous intent in the earlier part of the message as well.
James Van Buskirk
news:1ifkioo.1fxu9yez4rt14N%nos...@see.signature...
> Perhaps because Cray pointers aren't Fortran, but are an extension. In
> particular, they are an extension that is not supported by the compilers
> I use. In fact, Cray pointers to procedures are supported by very few
> compilers. I suppose I should say "so-called Cray pointers to
> procedures", insomuch as Cray compilers did not support that particular
> variant. There was a time when I think that the set of compilers
> supporting Cray pointers to procedures had one element; I think it might
> have more now, but it still certainly isn't something to use if very
> concerned about portability.
ifort and gfortran have cray pointers to procedures. gfortran doesn't
have procedure pointers yet and I'm not sure if ifort has them yet,
either. This example wouldn't work with procedure pointers in any
case, at least not without a further Fortran wrapper.
> Note that Damian said
>>> I'm imagining the additional
>>> coding would be pretty minimal and it would be standards-conforming
>>> and therefore portable.
> I'm imagining that there is at least a chance that he meant exactly what
> he said - that standard conformance and portability were factors he
> considered.
Since when is the body of a C function standard conforming Fortran?
It makes as much sense to me to fudge the standard a little while
sticking to pure Fortran as it does to throw the standard out
altogether with a C solution. In the [elided] example it may
prove difficult to invoke the function in question from C because
it requires access to a private allocatable array in a specification
statement, has an assumed-shape dummy argument and returns an array
of character variables with LEN > 1 in general. You can always
write a Fortran procedure with the bind(C) attribute that has the
same interface as the C wrapper would have had and do whatever
dirty deeds were intended for the C wrapper by fussing with the
type(C_PTR) and type(C_FUNPTR) dummy arguments your Fortran
wrapper received by value. I have posted several examples of
this technique.
>> See, it works great and doesn't even need C++ to achieve the
>> desired result.
> I find myself not entirely sure whether this was intended as a humorous
> dig at gfortran or whether the wrong thing got pasted into the message.
> I do find it a bit amusing so I'm leaning in that direction.
How about a dig @ C++? Have you ever tried to puzzle out the error
messages a C++ compiler spits out when it doesn't like your template
code for some undecipherable reason?
Damian
>
> Spoken like a true C programmer.
Funny line but I'm not an avid C programmer. In fact, I'm an avid
advocate of Fortran. But more than anything else, I advocate writing
standards-conforming, portable code. In the case I suggested, that
would mean writing standard Fortran and standard C.
> Why write a C wrapper to invoke a
> Fortran procedure when Fortran can do so all by itself?
.
Because, as you correctly pointed out, gfortran can't do it itself.
It can't yet invoke its own procedure pointer.
> Here is an
> example with cray pointers,
The word "Cray" does not appear anywhere in the Fortran 2003 standard,
so this approach violates the very principle that motivated it: "Why
write a C wrapper to invoke a Fortran procedure when Fortran can do so
all by itself?"
Damian
James Van Buskirk
> The word "Cray" does not appear anywhere in the Fortran 2003 standard,
> so this approach violates the very principle that motivated it: "Why
> write a C wrapper to invoke a Fortran procedure when Fortran can do so
> all by itself?"
OK, so you want me to rework the example with procedure pointers.
Fine.
C:\g95\gptr>type gptr.f90
module funcs
implicit none
! Interface block for function program gptr will invoke
module point_fun_mod
use other_fun
use ISO_C_BINDING
implicit none
private
public point_fun
contains
function point_fun(x)
type(C_FUNPTR) x
procedure(abstract_fun), pointer :: point_fun
point_fun => set_fun(x,aux)
end function point_fun
function set_fun(x,y)
interface
function y(x)
import abstract_fun
import C_FUNPTR
type(C_FUNPTR), value :: x
procedure(abstract_fun), pointer :: y
end function y
end interface
set_fun => y(x)
end function set_fun
function aux(x)
external x
external aux
pointer aux
aux => x
end function aux
end module point_fun_mod
program gptr
use funcs
use other_fun
use point_fun_mod
implicit none
procedure(abstract_fun), pointer :: fun
type(C_FUNPTR) fp
fp = get_proc('Hello, world'//achar(0))
fun => point_fun(fp)
write(*,'(a)') fun([1,2,3])
end program gptr
C:\g95\gptr>g95 gptr.f90 -ogptr
Internal error: procedure_decl()- Bad decl
g95: Internal error: Aborted (program f951)
Please submit a full bug report.
See http://www.g95.org or mail XX...@XXXXXXXXXX.XXX for instructions.
C:\g95\gptr>g95 -v
Using built-in specs.
Target:
Configured with:
/src/G95/gcc-4.1.2/configure --prefix=/mingw --enable-languages
=c --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --host=i386-pc-mingw32 --enab
le-threads --disable-nls --disable-win32-registry --enable-sjlj-exceptions --ena
ble-libgcj --without-x
Thread model: win32
gcc version 4.1.2 (g95 0.92!) Apr 17 2008
There. Are you happy now?
Simulate
> It can be see it in this year?
In my opinion, Intel compiler is a better one in windows platform.
However,I don't think it can release a full F2003 standard implemented
complier at the end of the year.
Simulate
Yes,the period of implimentation of f2003 standard seems to long!
Three years more from it releases....
angelv
On Apr 18, 8:48 am, "James Van Buskirk" <not_va...@comcast.net> wrote:
> Spoken like a true C programmer. Why write a C wrapper to invoke a
> Fortran procedure when Fortran can do so all by itself? Here is an
> example with cray pointers, could be updated to use procedure
> pointers if they ever come true:
[Code skipped]
Thanks for the replies. I decided to give a try to Cray pointers as a
temporary replacement for pointers to procedures, and I was about to
try out the code you provided, but given that apparently it gave a
segmentation fault when trying to compile it, I decided to go for
something simpler :-)
I read this about Cray pointers and gfortran
http://gcc.gnu.org/onlinedocs/gfortran/Cray-pointers.html#Cray-pointers
but I've never used this feature, neither external procedures, so be
gentle :-)
I got a minimal code to try the Cray pointers, as per the
documentation above:
[angelv@arce temp]$ cat temp.f90
PROGRAM test
IMPLICIT NONE
EXTERNAL sp
POINTER (subptr,subpte)
EXTERNAL subpte
subptr = LOC(sp)
CALL subpte
END PROGRAM test
SUBROUTINE sp
PRINT*, "HI"
END SUBROUTINE sp
But compilation is unsuccessfull:
[angelv@arce temp]$ gfortran -fcray-pointer -o temp temp.f90
In file temp.f90:6
EXTERNAL subpte
1
Error: CRAY POINTEE attribute conflicts with EXTERNAL attribute at (1)
In file temp.f90:10
CALL subpte
1
Error: CRAY POINTEE attribute conflicts with SUBROUTINE attribute in
'subpte' at (1)
In file temp.f90:5
POINTER (subptr,subpte)
1
Error: Symbol 'subpte' at (1) has no IMPLICIT type
[angelv@arce temp]$ gfortran --version
GNU Fortran (GCC) 4.1.2 20070925 (Red Hat 4.1.2-33)
Any help appreciated. Thanks,
Ángel de Vicente
James Van Buskirk
news:bd05f251-661e-44e0...@i76g2000hsf.googlegroups.com...
> [angelv@arce temp]$ gfortran --version
> GNU Fortran (GCC) 4.1.2 20070925 (Red Hat 4.1.2-33)
That's ancient. 4.4 nails this:
C:\gfortran\clf\cray_test>type temp.f90
PROGRAM test
IMPLICIT NONE
EXTERNAL sp
POINTER (subptr,subpte)
EXTERNAL subpte
subptr = LOC(sp)
CALL subpte
END PROGRAM test
SUBROUTINE sp
PRINT*, "HI"
END SUBROUTINE sp
C:\gfortran\clf\cray_test>gfortran -fcray-pointer temp.f90 -otemp
C:\gfortran\clf\cray_test>temp
HI
C:\gfortran\clf\cray_test>gfortran --version
GNU Fortran (GCC) 4.4.0 20080425 (experimental)
Copyright (C) 2008 Free Software Foundation, Inc.
GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
You may redistribute copies of GNU Fortran
under the terms of the GNU General Public License.
For more information about these matters, see the file named COPYING
I think that according to the Standard for Cray Pointers [:)]
the declarations for subpte should be completed before declaring
it as a Cray pointee, but for some reason gfortran lets you get
by with the order as given above.
gfortran has progressed at such a rate in the last year that it's
better to get the latest and risk regressions than to get old
stuff that was established never to work in the first place, at
least if you're planning on using advanced features.
angelv
On May 1, 12:29 am, "James Van Buskirk" <not_va...@comcast.net> wrote:
> > [angelv@arce temp]$ gfortran --version
> > GNU Fortran (GCC) 4.1.2 20070925 (Red Hat 4.1.2-33)
>
> That's ancient. 4.4 nails this:
Ah, OK, I will try to upgrade gfortran and will try as well with
ifort.
Thanks a lot,
Ángel de Vicente
Ron Ford
"GaryScott" <garyl...@sbcglobal.net> wrote in message
news:d1af1416-9ffd-4073...@t12g2000prg.googlegroups.com...
---> For reasons beyond my understanding, this newsreader fails to add '>'
in cases; I can't figure it out.
Another question for Bill's visitor: what does he hear about the other
vendors, to wit, the above?
--
"We wouldn't have a police department that had to show a profit every
year - or a fire department that had to show a profit every year. We
shouldn't do that with our health care system, either."
~~ Michael Moore
Black Barry
"Gerry Ford" <ge...@nowhere.ford> wrote in message
news:120838...@news.newsgroups.com...
>
> "GaryScott" <garyl...@sbcglobal.net> wrote in message
> news:d1af1416-9ffd-4073...@t12g2000prg.googlegroups.com...
> On Apr 16, 10:21 am, lleshu...@gmail.com wrote:
>> It can be see it in this year?
>
> Now taking wagers...vote for the compiler vendor (one of their
> products on any platform) that will first achieve 100% compliance
> (realize that some of these may not be in the race or for some
> operating systems):
>
> Absoft
> Lahey/Fujitsu
> Intel
> Silverfrost/Salford
> HP
> IBM
> NAG
> PGI
> SUN
> Pathscale
> G95
> GFortran
> Other
>
> I should set up a voting web site...
I think a person closer to the effort named NAG and IBM as frontrunners.
>
> --->Can we come up with code snippets that would test incrementally-closer
> compliance? I don't know what oo looks like in fortran. Does anyone have
> any experience with it in fortran? I stumbled onto the topic some years
> back when I wanted to have C functions that do the same thing with
> different types.
>
> As for my money, I'll bet against silverfrost and on sun. Of course, sun
> isn't windows. I'm hoping that it can co-exist with windows, however.
> And as long as we're betting, I'll take the Celtics over the Lakers.
This is the part I had to comment on. I can be wrong about fortran six days
a week, but when it comes down to classic hoops match-ups, it matters more.
The lakers bench is too tough for the Celts. It's one of those Phil Jackson
teams that has rested superstars in the fourth. Take the Lakers over the
Celtics, in six.
Ron Ford
"Black Barry" <black@barry ?? .liddy> wrote in message
news:6amf22F...@mid.individual.net...
Oops.
I didn't know Paul Pierce was a rested superstar. How about Tiger winning
without his left leg?
Good day for KG and Farragut.