reasons for failure
in [Fortran]
|
Prev: Clarify An Old Question: define a user data containing array with dimensions decided in running time
Next: Clarify An Old Question: define a user data containing array with ?dimensions decided in running time
From: Ken Fairfield on 19 May 2010 12:22 On May 18, 9:25 pm, Uno <merrilljen...(a)q.com> wrote: [...] > > I got the following when I tried to fire up the same program back here > on win32 xp: > > http://i48.tinypic.com/29d9pj.jpg > > E:\fortran_stuff> > Dir for this script: E:\fortran_stuff\ > E:\fortran_stuff> gfortran -Wall -Wextra test1.f90 -o out.exe > Access is denied. > > I did *not* get the same this roadblock on a windows7 64bit machine. Please don't mix up what gfortran may or may not do with your code, and the error message above: "Access is denied.". The "Access is denied" message sure sounds to me like there was an attempt to write out.exe to a location you didn't have write access to. Fix that, then try again. -Ken
From: James Van Buskirk on 19 May 2010 12:53 "steve" <kargls(a)comcast.net> wrote in message news:551fafec-c427-47a7-acec-7a063093ae9b(a)a2g2000prd.googlegroups.com... > Interpreting your vague "64-bit processing" to mean compiling > and run code on an X86_64 cpu, then no, you are not correct. > Read the Standard about the return values of selected_real_kind. > program my_kinds > implicit none > integer i > do i = 1, 20 > print '(A,I0,A,I0)', 'p = ', i, ', kind = ', > selected_real_kind(p=i) > end do > do i = 7, 20 > print '(A,I0,A,I0)', 'r = 1000, p = ', i, & > & ', kind = ', selected_real_kind(p=i, r=1000) > end do > end program my_kinds To simply answer the question about whether the Fortran processor is 64- or 32-bit, we could try something like: C:\gfortran\clf\64or32>type 64or32.f90 program sixty_four use ISO_C_BINDING, only: C_INTPTR_T implicit none write(*,'(a,i0,a)') 'This is a ',bit_size(0_C_INTPTR_T), & '-bit processor.' end program sixty_four C:\gfortran\clf\64or32>gfortran 64or32.f90 -o64or32 C:\gfortran\clf\64or32>64or32 This is a 64-bit processor. -- write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, & 6.0134700243160014d-154/),(/'x'/)); end
From: mecej4 on 19 May 2010 13:33 On 5/18/2010 11:25 PM, Uno wrote: > I've been trying to develop a 64-bit gfortran capability and was hopeful > that techniques I had been using would work on a friend's laptop, but I > think I failed. > > Am I correct to think that if I had 64-bit processing, then qp_preferred > would be positive: > > E:\fortran_stuff>type test1.f90 > implicit none > > integer, parameter :: sp = selected_real_kind(1,3) > integer, parameter :: dp = selected_real_kind(15,300) > integer, parameter :: qp_preferred = selected_real_kind(30,1000) > integer, parameter :: qp = (1+sign(1,qp_preferred))/2*qp_preferred+ & > (1-sign(1,qp_preferred))/2*dp > > > > real (kind=sp) w > real (kind=dp) y > real (kind=qp) z > > w = 4.0*atan(1.0) > y = 4.0*atan(1.0) > z = 4.0*atan(1.0) > > print *, sp,dp,qp_preferred,qp > print *, w,y,z > endprogram > > > ! gfortran -Wall -Wextra test1.f90 -o out.exe > > I'm not sure how related all this is, but there's the general notion > that when you're explaining what is not happening in your program, you > should explain it in terms of what you think is decreasingly relevant, > but keep on including things even when you don't understand the > implications yourself. > > I got the following when I tried to fire up the same program back here > on win32 xp: > > http://i48.tinypic.com/29d9pj.jpg > > E:\fortran_stuff> > Dir for this script: E:\fortran_stuff\ > E:\fortran_stuff> gfortran -Wall -Wextra test1.f90 -o out.exe > Access is denied. > > I did *not* get the same this roadblock on a windows7 64bit machine. That's understandable. The .jpg picture that you linked above shows that you were trying to run the Windows-X64 version of gfortran.exe on a 32-bit version of Windows. To run an x64 application, two prerequisites must be met: (i) a compatible x64 CPU (ii) a compatible OS that runs in 64bit mode If you are running Win-32 on an X64 CPU, that's not enough for running the X64 version of gfortran. There is nothing specific to gfortran in all this, either. > q1) Is 64-bit processing sufficient to get qp on gfortran? Depends on which version of gfortran you refer to, on which OS, and which CPU. > q2) What are other methods to determine aspects of 64-bit processing? Look at MyComputer->Properties. If it does not say 64 somewhere there, you are running a 32-bit version of Windows and you cannot run a version of gfortran (or any other program) targeted to an X64 CPU. It is quite possible that you can find a compiler that can promote reals to 10-byte or 16-byte floats, even with a 32-bit CPU with a 32-bit OS. After all, an 8-bit 8086, with or without an 8087, was capable of processing 32, 64 or 80 bit floats in the early 1980s. I state this since there seems to be some confusion as to pointer-size, integer-size and real-float-sizes. -- mecej4
From: steve on 19 May 2010 14:17 On May 19, 9:53 am, "James Van Buskirk" <not_va...(a)comcast.net> wrote: > "steve" <kar...(a)comcast.net> wrote in message > > news:551fafec-c427-47a7-acec-7a063093ae9b(a)a2g2000prd.googlegroups.com... > > > Interpreting your vague "64-bit processing" to mean compiling > > and run code on an X86_64 cpu, then no, you are not correct. > > Read the Standard about the return values of selected_real_kind. > > program my_kinds > > implicit none > > integer i > > do i = 1, 20 > > print '(A,I0,A,I0)', 'p = ', i, ', kind = ', > > selected_real_kind(p=i) > > end do > > do i = 7, 20 > > print '(A,I0,A,I0)', 'r = 1000, p = ', i, & > > & ', kind = ', selected_real_kind(p=i, r=1000) > > end do > > end program my_kinds > > To simply answer the question about whether the Fortran processor is > 64- or 32-bit, we could try something like: > > C:\gfortran\clf\64or32>type 64or32.f90 > program sixty_four > use ISO_C_BINDING, only: C_INTPTR_T > implicit none > > write(*,'(a,i0,a)') 'This is a ',bit_size(0_C_INTPTR_T), & > '-bit processor.' > end program sixty_four > > C:\gfortran\clf\64or32>gfortran 64or32.f90 -o64or32 > > C:\gfortran\clf\64or32>64or32 > This is a 64-bit processor. > Yes, of course. The issue is that Uno is confusing '64 bit processing' with the presences of a binary128 floating point type (look it up in IEEE 754), which has a 113 bit significand. The opteron processors that I use are widely considered to be 64-bit processors. An opteron does not support a native binary128 floating point type in hardware. -- steve
From: Uno on 20 May 2010 03:44
On 5/19/2010 12:17 PM, steve wrote: > Yes, of course. > > The issue is that Uno is confusing '64 bit processing' > with the presences of a binary128 floating point type > (look it up in IEEE 754), which has a 113 bit significand. > > The opteron processors that I use are widely considered to > be 64-bit processors. An opteron does not support a > native binary128 floating point type in hardware. Instead of talking about quad precision, I would rather discuss aspects of squaring away a 64-bit gfortran install. Dir for this script: E:\fortran_stuff\ E:\fortran_stuff>gfortran -Wall -Wextra test2.f90 -o out.exe E:\fortran_stuff>out This is a 64-bit processor. E:\fortran_stuff>type test2.f90 program sixty_four use ISO_C_BINDING, only: C_INTPTR_T implicit none write(*,'(a,i0,a)') 'This is a ',bit_size(0_C_INTPTR_T), & '-bit processor.' end program sixty_four ! gfortran -Wall -Wextra test2.f90 -o out.exe E:\fortran_stuff>type run2.bat @echo off Title Build environment for 64-bit gfortran equation solutions set dir=%~dp0 set path=%dir%\bin;^ %dir%\libexec\gcc\x86_64-pc-mingw32\4.5.0;^ %path% set EQ_LIBRARY_PATH=%dir%\x86_64-pc-mingw32\lib echo Dir for this script: %dir% cd %dir% E:\fortran_stuff> I see I'm missing a semicolon in the Eq_LIBRARY_PATH. How could I do a rudimentary test to see whether this is set correctly? I'm frankly a little fuzzy on why you want libraries in fortran as opposed to modules. This is computed and posted off a memory stick with thunderbird portable. -- Uno |