fortran 90 compiler for linux
Steve....@libero.it
I'm searching for a free F90 compiler that run under linux (suse 9.0)
I have googled on the web, but got lost. Does anyone know some link
where to find a good one (also a trial version is fine) ??
Thanks! Cheers, Steve
Chris Hulbert
Try gfortran or g95
Herman D. Knoble
http://www.personal.psu.edu/hdk/fortran.html#Linux
Skip Knoble
On 13 Jul 2005 08:09:38 -0700, Steve....@libero.it wrote:
-|hi there,
-|
-|I'm searching for a free F90 compiler that run under linux (suse 9.0)
-|
-|I have googled on the web, but got lost. Does anyone know some link
-|where to find a good one (also a trial version is fine) ??
-|
-|Thanks! Cheers, Steve
Kamaraju Kusumanchi
Try gfortran
http://www.gnu.org/software/gcc/fortran/
gfortran is included in gcc-4.0 and later versions. I dont know whether
it has been packaged already for suse 9.0 . But you should be able to
figure it out once you know the name of the compiler.
Another free compiler for Linux is g95.
http://g95.sourceforge.net/
Both are very good and very responsive to bugs you report and are under
active development.
hth
raju
Steve Lionel
>I'm searching for a free F90 compiler that run under linux (suse 9.0)
The Intel Fortran Compiler for Linux is free for personal/non-commercial use.
See http://www.intel.com/cd/software/products/asmo-na/eng/compilers/flin Note
that, until sometime in August, version 8.1 is what is offered for
non-commercial use. You can also download a free 30-day trial of the 9.0
compiler.
Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH
User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://developer.intel.com/software/products/support/
Greg Lindahl
Steve Lionel <Steve....@REMOVEintelME.com> wrote:
>On 13 Jul 2005 08:09:38 -0700, Steve....@libero.it wrote:
>
>>I'm searching for a free F90 compiler that run under linux (suse 9.0)
>
>The Intel Fortran Compiler for Linux is free for personal/non-commercial use.
Instead of a separate posting from each commercial vendor, how about let's point
him at Skip Knoble's summary webpage, that lists them all? Both PathScale
and PGI offer free trials, perhaps some other compilers do, too.
-- greg
(employed by, not speaking for, PathScale.)
Steve....@libero.it
it looks like working, but return me quite a lot of errors. I'm
currently runnig some f90 programs that a guy gave to me. The program
is supposed to work fine, but the compiler doesn't like some syntax,
like the simbol '&' to continue into a new line, or the 'c' to comment.
The real problem, however comes out when I try to link some Numerical
Recipes (fortran 77) routines. The compiler really doesn't like them :(
Is there any way to make the compiler more tolerant so I can use it
with the routine I have at my disposal?
Another question. I have tryed to install also the Absoft compiler with
a temporary license (2 month ahead). Installation procedure work fine,
but then when I try to run the compiler the following message is
returned
Unable to obtain license: license server not found
Does anyone know what should I do to prevent this to happen?
Thanks&Cheers!
S.
Duane Bozarth
>
> I have tried the Intel compiler.
>
> it looks like working, but return me quite a lot of errors. I'm
> currently runnig some f90 programs that a guy gave to me. The program
> is supposed to work fine, but the compiler doesn't like some syntax,
> like the simbol '&' to continue into a new line, or the 'c' to comment.
> The real problem, however comes out when I try to link some Numerical
> Recipes (fortran 77) routines. The compiler really doesn't like them :(
> Is there any way to make the compiler more tolerant so I can use it
> with the routine I have at my disposal?
What did you name the files? Sounds sorta' like the compiler is trying
to compile free format files as fixed format, maybe? The "&" a "c" are
standard-conforming (although it's possible they're somehow not being
used in a conforming manner, of course) so I'd be quite certain that
isn't a problem w/ the Intel compiler.
Perhaps you could post a problem section and others could comment more
fully. If there's anything unique Steve L will undoubtedly kick in...
> Another question. I have tryed to install also the Absoft compiler with
> a temporary license (2 month ahead). Installation procedure work fine,
> but then when I try to run the compiler the following message is
> returned
> Unable to obtain license: license server not found
> Does anyone know what should I do to prevent this to happen?
Ask Absoft, maybe???
Chris Hulbert
> > like the simbol '&' to continue into a new line, or the 'c' to comment.
> > The real problem, however comes out when I try to link some Numerical
> > Recipes (fortran 77) routines. The compiler really doesn't like them :(
> > Is there any way to make the compiler more tolerant so I can use it
> > with the routine I have at my disposal?
I know compilers like gfortran and g95 seem to rely on file extensions.
if they're named just .f, it will try to compile it as f77 files (i.e.
with > and ! to your symbols earlier).
gfortran:
try -x f95. See
http://www.gnu.org/software/gcc/fortran/usage.html#fname for more
details
g95;
Try the -std option
Ken Plotkin
<cchgro...@gmail.com> wrote:
>Try gfortran or g95
Are they complete and standard-conforming?
Walt Brainerd
There is no complete and standard-conforming
Fortran compiler :-).
From what I have seen, g95 is very good.
gfortran is coming along, but not quite
up to g95 yet.
--
Walt Brainerd +1-877-355-6640 (voice & fax)
The Fortran Company +1-520-760-1397 (outside USA)
6025 N. Wilmot Road wa...@fortran.com
Tucson, AZ 85750 USA http://www.fortran.com
Steve Kargl
With a recent change to the mainline cvs sources,
gfortran passes all NIST Forrtan 77 testsuite programs
with the exception of 1 test. AFAIK, g95 will never meet
the requirements of the Fortran 77 standard. Gfortran is
probably 90 to 95% complaint with the Fortran 95 standard.
Unfortunately, that last 5 to 10% is the complicated details.
You can get cygwyn or MingW gfortran binaries from
www.gfortran.org.
--
steve
Steve Kargl
With a recent change to the mainline cvs sources,
Ken Plotkin
wrote:
>There is no complete and standard-conforming
>Fortran compiler :-).
Not even the commercial compilers?
Or did I phrase the question with a giant hole...I meant with respect
to the F95 standard. I've lost track as to whether F2003 is now the
official standard - but I know we're a long way from anyone satisfying
that.
Joost
> >There is no complete and standard-conforming
> >Fortran compiler :-).
>
> Not even the commercial compilers?
>
No, I've never seen one.
At best, they need to be described as 'complete and standard-conforming
apart from bugs'. Given the complexity of these programs there is no
way of formally proving a compiler bug free (and in reality they all
have known, open bugs). Furthermore, given the complexity of the
Fortran standard, it is impossible (just guessing, but getting some
feeling for the topic) to provide a finite list of e.g. testcases that
a compiler has to pass in order to be standard conforming. E.g. there
is no way to define the meaning of 'the standard has been implemented
for 90% (or 99.99%)'. You can just find out, after the fact, that a
compiler is not quite standard conforming. Furthermore, a good compiler
is much more than just standard conforming, i.e. much of the errors
reported by compilers (for non-standard/buggy source code) are not
required to be diagnosed by the compiler.
Cheers,
Joost
Dieter Britz
> I have tried the Intel compiler.
>
> it looks like working, but return me quite a lot of errors. I'm
> currently runnig some f90 programs that a guy gave to me. The program
> is supposed to work fine, but the compiler doesn't like some syntax,
> like the simbol '&' to continue into a new line, or the 'c' to comment.
> The real problem, however comes out when I try to link some Numerical
> Recipes (fortran 77) routines. The compiler really doesn't like them :(
> Is there any way to make the compiler more tolerant so I can use it
> with the routine I have at my disposal?
I installed Intel's f90/95 compiler years ago and it works like
a charm. The source files should be called *.f90. The compiler is
less tolerant of some kinds of errors than some other compilers. E.g.
I had to edit programs in which I had a comma between WRITE and
the list to be written. Good for me to be reminded. It also gives me
annoying Warnings about page feeds I like to put in for a better
legible print-out of programs with subroutines, but I can suppress these
warnings.
--
Dieter Britz, Kemisk Institut, Aarhus Universitet, Danmark.
beli...@aol.com
> I installed Intel's f90/95 compiler years ago and it works like
> a charm. The source files should be called *.f90.
The Intel compiler, like most other compilers,
(1) treats *.f90 files by default as having free source form
(2) treats *.f and *.for files as having fixed source form
(3) has compiler options to override these rules and force a file to be
treated as free or fixed.
beli...@aol.com
> Ken Plotkin wrote:
>
> > On 13 Jul 2005 13:46:33 -0700, "Chris Hulbert"
> > <cchgro...@gmail.com> wrote:
> >
> >
> >>Try gfortran or g95
> >
> >
> > Are they complete and standard-conforming?
>
> There is no complete and standard-conforming
> Fortran compiler :-).
I don't know of any outstanding bugs in the Lahey/Fujitsu Fortran 95
compiler for Windows, version 7.1 in implementing the Fortran 95
standard. The few complaints I have seen about LF95 in this newsgroup
concern some Technical Reports that followed the F95 standard. I wonder
if anyone has a counterexample.
Steve....@libero.it
I had installed it on a remote machine previously, and that gave the
problems I already mentioned...
I have installed on my desktop now, and it's working fine :)))
It that due to the fact I was working remotely?!?
It compiles without errors and warning, but still it doesn't run....
I'm quite a newby, but here is what I do :
1) I declare the arrays to be dynamically allocated:
integer n
real, dimension(:), allocatable :: cz,apm
real*8, dimension(:), allocatable :: al8,del8
2) I read a file (input.in) where I set a lot of parameters and also
the name of the file I want to open
open(20,file='input.in',status='old',form='formatted')
read(20,'(a)') slicein ! input file
read(20,*) ah1,am1,as1 ! various parameter I set
....
where the file input.in has the following form
table.ascii
8 0 0
....
3) Then I read the file table.ascii where the data are stored
open (20,file=slicein,status='old',form='unformatted')
read (20) n
allocate (cz(ngal),apm(ngal))
allocate (al8(ngal),del8(ngal)
read (20) al8, del8, cz, apm
close(20)
However, the program encounter a problem exactly before the point
read (20) n above and return me this strange list
forrtl: severe (39): error during read, unit 20, file
/home/myfold/table.ascii
Image PC Routine Line Source
red 080A6F18 Unknown Unknown Unknown
red 080A6A10 Unknown Unknown Unknown
red 0807B081 Unknown Unknown Unknown
red 0805AE20 Unknown Unknown Unknown
red 0805B2C3 Unknown Unknown Unknown
red 08067F98 Unknown Unknown Unknown
red 0804B317 Unknown Unknown Unknown
red 0804A3C8 Unknown Unknown Unknown
Unknown 40090D17 Unknown Unknown Unknown
red 0804A281 Unknown Unknown Unknown
(red is the name of the executable file)
I'm quite sure the error is something very obvious, but I cannot figure
it out. Any help?
Thanks a lot!
S.
Tim Prince
would work with a text editor, nor be portable in general even among
Fortran compilers. 'unformatted' is not the same as the more recent
(since 30 years ago) list directed formatted, which you may have meant
to use.
Herman D. Knoble
First, It is not possible to prove that a non-trivial program
is correct. It's undecidable. Therefore there are bugs in every
non-trivial program; and a compiler surely fills the definition
of a non-trivial program.
So all compilers have bugs. Some are known, some are not.
Some could reflect Standard misinterpretations, although
I too am not aware of any.
In the case of commercial compilers like Lahey LF95, PathScale PATHF90
and Intel IFORT,and Silverfrost (formally Salford) FTN95, it has been
my experience that reported (well documented) bugs,
Standards related or not, are taken quite seriously,
acknowledged and fixed, if possible without introducing more
bugs, in reasonably short order (typically next release or
via a "fixed" module that the development team often offers
to send to the bug originator).
This said, at this point in history, again I agree with you.
That is, for the most part most Fotran compilers are reasonably
stable and usable most often without running into bugs, and less
often running into bugs related to Fortran 90 Standards, and probably
even less often related to Fortran 95 Standards.
For the sake of Fortran application integrity, we still need
to work with compiler developers so that when we use their
compilers to generate applicatons (all applicatoins are
"mission critical" in my opinion), those applications
have as much integrity ("soundness") as humanly possible.
(That's why good debugging options like Salford and Lahey's
uninitialized variables, subscript/string ranges, etc.
are so important.
Skip Knoble
On 15 Jul 2005 04:11:58 -0700, beli...@aol.com wrote:
-|Walt Brainerd wrote:
-|> Ken Plotkin wrote:
-|>
-|> > On 13 Jul 2005 13:46:33 -0700, "Chris Hulbert"
-|> > <cchgro...@gmail.com> wrote:
-|> >
-|> >
-|> >>Try gfortran or g95
-|> >
-|> >
-|> > Are they complete and standard-conforming?
-|>
-|> There is no complete and standard-conforming
-|> Fortran compiler :-).
-|
-|I don't know of any outstanding bugs in the Lahey/Fujitsu Fortran 95
-|compiler for Windows, version 7.1 in implementing the Fortran 95
-|standard. The few complaints I have seen about LF95 in this newsgroup
-|concern some Technical Reports that followed the F95 standard. I wonder
-|if anyone has a counterexample.
James Van Buskirk
news:1121425918....@g49g2000cwa.googlegroups.com...
> I don't know of any outstanding bugs in the Lahey/Fujitsu Fortran 95
> compiler for Windows, version 7.1 in implementing the Fortran 95
> standard. The few complaints I have seen about LF95 in this newsgroup
> concern some Technical Reports that followed the F95 standard. I wonder
> if anyone has a counterexample.
I have seen sufficient bugs in previous versions to be fairly sure
that the bugs must be there in the current version. What does LF95 7.1
do about
http://home.comcast.net/~kmbtib/Fortran_stuff/elem_assign.f90
for example? If you use any compiler as your primary development
compiler for a while you are going to encounter bugs. The f95
standard itself has bugs and internal contradictions and I have
no idea how you could create a standard for which this would not
be the case. How can you write a bug-free compiler to an
inconsistent standard?
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
Paul Van Delst
> <beli...@aol.com> wrote in message
> news:1121425918....@g49g2000cwa.googlegroups.com...
>
>
>>I don't know of any outstanding bugs in the Lahey/Fujitsu Fortran 95
>>compiler for Windows, version 7.1 in implementing the Fortran 95
>>standard. The few complaints I have seen about LF95 in this newsgroup
>>concern some Technical Reports that followed the F95 standard. I wonder
>>if anyone has a counterexample.
>
>
> I have seen sufficient bugs in previous versions to be fairly sure
> that the bugs must be there in the current version. What does LF95 7.1
> do about
>
> http://home.comcast.net/~kmbtib/Fortran_stuff/elem_assign.f90
Dunno about the windows 7.1, but the unix 6.2c does the following:
lnx:scratch : lf95 blah.f90
Encountered 0 errors, 0 warnings in file blah.f90.
lnx:scratch : a.out
original x = 7 11 13
permuted x = 11 13 7
new x = 11 13 11
And v8.1 intel:
lnx:scratch : ifort -static-libcxa blah.f90
lnx:scratch : a.out
original x = 7 11 13
permuted x = 11 13 7
new x = 11 13 11
g95 seems to get it right though (at least I think so):
lnx:scratch : g95 blah.f90
lnx:scratch : a.out
original x = 7 11 13
permuted x = 11 13 7
new x = 11 13 7
cheers,
paulv
--
Paul van Delst
CIMSS @ NOAA/NCEP/EMC
James Van Buskirk
news:db8q2t$hna$1...@news.nems.noaa.gov...
> g95 seems to get it right though (at least I think so):
Yes, Andy wrote me a note a while back to let me know that
he had fixed this bug. It is so amusing that both LF95 and
ifort have the same error here. Even surrounding the dexter
of the assignment with parentheses doesn't help these
compilers out!
Steve Lionel
<not_...@comcast.net> wrote:
>"Paul Van Delst" <paul.v...@noaa.gov> wrote in message
>news:db8q2t$hna$1...@news.nems.noaa.gov...
>
>> g95 seems to get it right though (at least I think so):
>
>Yes, Andy wrote me a note a while back to let me know that
>he had fixed this bug. It is so amusing that both LF95 and
>ifort have the same error here. Even surrounding the dexter
>of the assignment with parentheses doesn't help these
>compilers out!
Now that it has been brought to our attention, we'll fix it too.
Steve....@libero.it
I have tried to write a short program in order to just read the file.
Here is what I do:
program hello
integer ngal
real, dimension(:), allocatable :: cz,apm
real*8, dimension(:), allocatable :: al8,del8
open(unit=20,file='table.ascii',status='old',action='read')
read (20) ngal
allocate (al8(ngal),del8(ngal),cz(ngal),apm(ngal))
read (20) al8, del8, cz, apm
end
The compiler do its job, but the when I run it I get that long list of
errors as I told before
forrtl: No such file or directory
forrtl: severe (29): file not found, unit 20, file
/home/mydir/table.ascii
Image PC Routine Line Source
a.out 080859D4 Unknown Unknown Unknown
a.out 080854CC Unknown Unknown Unknown
a.out 08067659 Unknown Unknown Unknown
a.out 0805D5F8 Unknown Unknown Unknown
a.out 0805DA9B Unknown Unknown Unknown
a.out 0804D559 Unknown Unknown Unknown
a.out 0804A1E2 Unknown Unknown Unknown
a.out 0804A168 Unknown Unknown Unknown
Unknown 40090D17 Unknown Unknown Unknown
a.out 0804A021 Unknown Unknown Unknown
How can I open and read a file?? I really feel stupid...
Consider that the file I'm trying to open has this form
2.09832233 0.7039494427 12360. 15.0
2.09919478 0.7042403265 12330. 14.6
2.10268538 0.6562437721 10016. 15.3
2.10355824 0.6579891413 10024. 15.2
...........
Thanks!
Joost
you seem to read table.ascii in the wrong way. It is an ascii file, so
try to read it with
read(20,*) ngal
read(20,*) al8, del8, cz, apm
however from the values, it seems like it is more like this
DO i=1,ngal
read(20,*) al8(i), del8(i), cz(i), apm(i)
ENDDO
Joost
Joost
with the options
'-O0 -g -traceback'.
I also notice that the error message is that file is not found. Are you
sure it is the same directory as you run the program, with exactly the
same name (including capital letters)...
Joost
Abdul Qat
"Herman D. Knoble" <SkipKno...@SPAMpsu.DOT.edu> wrote in message
news:euefd1lv2uulo7nh8...@4ax.com...
[...]
> So all compilers have bugs.
>
Agreed, they have lots of them.
[...]
> In the case of commercial compilers ... bugs, are taken ... seriously,
> acknowledged and fixed, if possible without introducing more
> bugs, in reasonably short order (typically next release or
> via a "fixed" module that the development team often offers
> to send to the bug originator).
>
Disagree, for example: Intel via Microsoft via Digital via Compaq via HP
haven't learned squat about accommodating customer concerns anymore than
they did in the case of their divide fault denial: just how many niggers
lurk in Intel's inners?, not that I'd have one in the house!
>
> For the sake of Fortran application integrity, we still need
> to work with compiler developers so that when we use their
> compilers to generate applications (all applications are
> "mission critical" in my opinion), those applications
> have as much integrity ("soundness") as humanly possible.
I could give a fig about FORTRAN compilers, whose users aren't responsible
for the cutups of their developers and the QA of their misartistry. You
clearly have the luxury of sole exposure to academic software whose bugs
and flaws are of no consequence to anyone and don't lay claim to being
"mission critical" to anyone other than their author(s) and their useless
'papers' (sic highfalutin litter). In the real world, software without
validation is to pornography without sex. May the given hand never falter!
--
You're Welcome,
Gerry T.
______
"Science is the belief in the ignorance of experts." -- Feynman, in The
Pleasure of Finding Things Out.