Problem with ALLOCATABLE scalar
in [Fortran]
|
Prev: minor typo in The Fortran 2003 Handbook?
Next: Questions on reuse of FORMAT statements and newer I/O options such as ACCESS='STREAM'
From: James Van Buskirk on 27 Dec 2009 03:32 In reading the gfortran manual, it says: > Description: > ALLOCATED(ARRAY) checks the status of whether X is allocated. Now, I can envision two problems with this: 1) It's probably checking whether ARRAY is allocated, not X. 2) There is no provision given for the SCALAR version. OK, so let's try a test program: C:\gfortran\clf\dimtest>type allocated_test.f90 program allocated_test implicit none integer, allocatable :: x integer, allocatable :: y(:) write(*,'(2a)') 'ALLOCATED(SCALAR=x) = ', & trim(merge('.TRUE. ','.FALSE.',allocated(scalar=x))) ! write(*,'(2a)') 'ALLOCATED(ARRAY=x) = ', & ! trim(merge('.TRUE. ','.FALSE.',allocated(array=x))) write(*,'(2a)') 'ALLOCATED(ARRAY=y) = ', & trim(merge('.TRUE. ','.FALSE.',allocated(array=y))) end program allocated_test C:\gfortran\clf\dimtest>gfortran allocated_test.f90 -oallocated_test allocated_test.f90:7.37: trim(merge('.TRUE. ','.FALSE.',allocated(scalar=x))) 1 Error: Can't find keyword named 'scalar' in call to 'allocated' at (1) So gfortran doesn't seem to have implemented a SCALAR version as yet. What if we try out the old version? C:\gfortran\clf\dimtest>type allocated_test.f90 program allocated_test implicit none integer, allocatable :: x integer, allocatable :: y(:) ! write(*,'(2a)') 'ALLOCATED(SCALAR=x) = ', & ! trim(merge('.TRUE. ','.FALSE.',allocated(scalar=x))) write(*,'(2a)') 'ALLOCATED(ARRAY=x) = ', & trim(merge('.TRUE. ','.FALSE.',allocated(array=x))) write(*,'(2a)') 'ALLOCATED(ARRAY=y) = ', & trim(merge('.TRUE. ','.FALSE.',allocated(array=y))) end program allocated_test C:\gfortran\clf\dimtest>gfortran allocated_test.f90 -oallocated_test C:\gfortran\clf\dimtest>allocated_test ALLOCATED(ARRAY=x) = .TRUE. ALLOCATED(ARRAY=y) = .FALSE. And then we get an error box that says: allocated_test.exe has encountered a problem and needs to close. We are sorry for the inconvenience. So it looks like a new version of the ALLOCATED intrinsic that has the right keyword, gives the right answer, and doesn't crash for ALLOCATABLE scalars is not yet implemented. Since there has been lots of progress with such features lately I just tried with a more recent, rather than last month's, gfortran. C:\gfortran\clf\dimtest>allocated_test ALLOCATED(ARRAY=x) = .TRUE. ALLOCATED(ARRAY=y) = .FALSE. C:\gfortran\clf\dimtest>gfortran -v Built by Equation Solution < http://www.Equation.com>. Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=c:/gcc_equation/bin/../libexec/gcc/x86_64-pc-mingw32/4.5.0/l to-wrapper.exe Target: x86_64-pc-mingw32 Configured with: .../gcc-4.5-20091217-mingw/configure --host=x86_64-pc-mingw32 -- build=x86_64-unknown-linux-gnu --target=x86_64-pc-mingw32 --prefix=/home/gfortra n/gcc-home/binary/mingw32/native/x86_64/gcc/4.5-20091217 --with-gmp=/home/gfortr an/gcc-home/binary/mingw32/native/x86_64/gmp --with-mpfr=/home/gfortran/gcc-home /binary/mingw32/native/x86_64/mpfr --with-mpc=/home/gfortran/gcc-home/binary/min gw32/native/x86_64/mpc --with-sysroot=/home/gfortran/gcc-home/binary/mingw32/cro ss/x86_64/gcc/4.5-20091217 --with-gcc --with-gnu-ld --with-gnu-as --disable-shar ed --disable-nls --disable-tls --enable-libgomp --enable-languages=c,fortran,c++ --enable-threads=win32 --disable-win32-registry Thread model: win32 gcc version 4.5.0 20091217 (experimental) (GCC) There is a difference in that the recent version didn't crash, even though it still likes the wrong keyword and gives the wrong result. -- write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, & 6.0134700243160014d-154/),(/'x'/)); end
From: steve on 27 Dec 2009 13:19 On Dec 27, 12:32 am, "James Van Buskirk" <not_va...(a)comcast.net> wrote: > In reading the gfortran manual, it says: > > > Description: > > ALLOCATED(ARRAY) checks the status of whether X is allocated. > > Now, I can envision two problems with this: > 1) It's probably checking whether ARRAY is allocated, not X. > 2) There is no provision given for the SCALAR version. > You forgot to send your observations to the gfortran developers. Try sending email to fortran at gcc gnu org. -- steve
From: robin on 27 Dec 2009 18:34 "James Van Buskirk" <not_valid(a)comcast.net> wrote in message news:hh7634$ja$1(a)news.eternal-september.org... | In reading the gfortran manual, it says: | | > Description: | > ALLOCATED(ARRAY) checks the status of whether X is allocated. | | Now, I can envision two problems with this: | 1) It's probably checking whether ARRAY is allocated, not X. That's right.
From: James Van Buskirk on 27 Dec 2009 22:42 "steve" <kargls(a)comcast.net> wrote in message news:2f134318-7f45-41e6-8045-810df1a4eaae(a)r24g2000yqd.googlegroups.com... > You forgot to send your observations to the gfortran developers. > Try sending email to fortran at gcc gnu org. I have reasons for doing thing the way I do, sorry. Maybe eventually they will become clear but for the present... Thanks for your documentation patch submitted. I appreciate the effort you have made. May a suggest a few small enhancements? ACOS - formatting error 0 \leq \Re \acos(x) \leq \pi AIMAG - AIMAG specific name is standard Change COMPLEX to COMPLEX(4) and REAL to REAL(4) 3X each IMAG & IMAGPART are also generic names: C:\gfortran\clf\dimtest>type aimagtest.f90 program aimagtest implicit none complex(8) z abstract interface elemental function f(x) complex(4), intent(in) :: x real(4) f end function f end interface procedure(f), pointer :: fp complex c z = (0.707_8,3.14_8) write(*,*) z, imag(z), kind(imag(z)) write(*,*) z, imagpart(z), kind(imagpart(z)) c = z fp => imag write(*,*) c, fp(c), kind(fp(c)) fp => imagpart write(*,*) c, fp(c), kind(fp(c)) end program aimagtest C:\gfortran\clf\dimtest>gfortran aimagtest.f90 -oaimagtest C:\gfortran\clf\dimtest>aimagtest ( 0.70699999999999996 , 3.1400000000000001 ) 3.1400000000000001 8 ( 0.70699999999999996 , 3.1400000000000001 ) 3.1400000000000001 8 ( 0.70700002 , 3.1400001 ) 3.1400001 4 ( 0.70700002 , 3.1400001 ) 3.1400001 4 AINT - Also change X to A (3X in return value) Note todo to fix compiler regarding AINT specific name ALLOCATED - Note todo to fix compiler regarding SCALAR version ANINT - Change X to A 2X in return value paragraph. Note spelling of ANINT in specific name Note todo to fix compiler regarding ANINT specific name ATAN - Add ATAN(Y,X) under description. Insert line break or something in syntax. Formatting error -\pi/2 \leq \Re \atan(x) \leq \pi/2 in return value. ATAN2 - Formatting error -\pi \le \atan (x) \leq \pi in return value. In specific names, note order of arguments is (Y,X). ATANH - Note that ATANH specific name is also a GNU extension. C:\gfortran\clf\dimtest>type atanh_test.f90 program atanh_test implicit none abstract interface elemental function f(x) real(4) f real(4), intent(in) :: x end function f end interface procedure(f), pointer :: fp real(4) x fp => atanh x = 0.5 write(*,*) x, fp(x), kind(fp(x)) end program atanh_test C:\gfortran\clf\dimtest>gfortran atanh_test.f90 -oatanh_test C:\gfortran\clf\dimtest>atanh_test 0.50000000 0.54930615 4 BESSEL_JN - Under specific names, change INTEGER to INTEGER(4) Do the bessel functions have REAL(4) specific names? I couldn't prove nor disprove: C:\gfortran\clf\dimtest>type bessel_test.f90 program bessel_test implicit none abstract interface elemental function f(x) real(4) f real(4), intent(in) :: x end function f elemental function g(n,x) real(4) g real(4), intent(in) :: x integer(4), intent(in) :: n end function g end interface procedure(f), pointer :: fp procedure(g), pointer :: gp real(4) x integer(4) n x = 1 n = 3 fp => BESJ0 write(*,*) x, fp(x), kind(fp(x)) fp => BESJ1 write(*,*) x, fp(x), kind(fp(x)) gp => BESJN write(*,*) n, x, gp(n,x), kind(gp(n,x)) fp => BESY0 write(*,*) x, fp(x), kind(fp(x)) fp => BESY1 write(*,*) x, fp(x), kind(fp(x)) gp => BESYN write(*,*) n, x, gp(n,x), kind(gp(n,x)) end program bessel_test C:\gfortran\clf\dimtest>gfortran bessel_test.f90 -obessel_test bessel_test.f90: In function 'bessel_test': bessel_test.f90:24:0: 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. CONJG - Change COMPLEX to COMPLEX(4) under specific name. COSH - Formatting error in return value \cosh (x) \geq 1 DIM - Still needs work to document extension where Y may have same type but different kind form X, with result of same type and kind as X-Y. DPROD - Of course the result is REAL(8). DREAL - Under description, change Z to A (2X). C:\gfortran\clf\dimtest>type dreal_test.f90 program dreal_test implicit none complex(8) z z = (0.707_8,3.14_8) write(*,*) dreal(Z=z) write(*,*) dreal(A=z) end program dreal_test C:\gfortran\clf\dimtest>gfortran dreal_test.f90 -odreal_test dreal_test.f90:6.13: write(*,*) dreal(Z=z) 1 Error: Can't find keyword named 'z' in call to 'dreal' at (1) Is DREAL specific? I could not confirm nor deny: C:\gfortran\clf\dimtest>type dreal_test2.f90 program dreal_test2 implicit none abstract interface elemental function f(a) real(8) f complex(8), intent(in) :: a end function f end interface procedure(f), pointer :: fp complex(8) z z = (0.707_8, 3.14_8) fp => DREAL write(*,*) z, fp(z), kind(fp(z)) end program dreal_test2 C:\gfortran\clf\dimtest>gfortran dreal_test2.f90 -odreal_test2 dreal_test2.f90: In function 'dreal_test2': dreal_test2.f90:12:0: internal compiler error: in gfc_get_extern_function_decl, at fortran/trans-decl.c:1452 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. ICHAR - Specific is not available as an actual argument, per the standard, but as todo note that compiler is looking for the wrong number of arguments. CHAR - Specific is available as an actual argument (GNU extension) but note todo: compiler is looking for the wrong number of arguments: C:\gfortran\clf\dimtest>type chartest.f90 program chartest implicit none abstract interface ! elemental function f(i) elemental function f(i,j) character(len=1,kind=1) f integer(4), intent(in) :: i integer(4), intent(in), optional :: j end function f ! elemental function g(c) elemental function g(c,j) character(len=*,kind=kind('A')), intent(in) :: c integer(4) g integer(4), intent(in), optional :: j end function g end interface procedure(f), pointer :: fp integer i procedure(g), pointer :: gp character(len=1,kind=1) c fp => CHAR i = 65 ! write(*,*) i, fp(i), kind(fp(i)) write(*,*) i, fp(i,42), kind(fp(i,42)) gp => ichar c = 'A' ! write(*,*) c, ' ', gp(c), kind(gp(c)) write(*,*) c, ' ', gp(c,42), kind(gp(c,42)) end program chartest C:\gfortran\clf\dimtest>gfortran chartest.f90 -ochartest C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\ccgdgzd8.o:chartest.f90:(.text+0xd9): undefin ed reference to `_gfortran_specific__ichar_1' collect2: ld returned 1 exit status Didn't check status of ACHAR and IACHAR. INDEX - Under specific names, change CHARACTER to CHARACTER(KIND=1). Note todo: fix compiler for correct number of arguments to specific (2). INT - Formatting error in return value (B) \geq Under specific names, change INTEGER to INTEGER(4). LEN - Under specific name, change CHARACTER to CHARACTER(KIND=1), INTEGER to INTEGER(4), and note todo: fix compiler to accept the correct number of arguments (1). LGE, LGT, LLE, LLT - Under specific names, change CHARACTER to CHARACTER(KIND=1) and LOGICAL to LOGICAL(4). MAX - Under specific MAX1 change REAL A1 to REAL(4) A1 and INT(MAX(X)) to INTEGER(4) Under specific AMAX0 change REAL(MAX(X)) to REAL(4). MIN - Under specific MIN1 change REAL A1 to REAL(4) A1. MOD - Under specific MOD change INTEGER to INTEGER(4) (2X). NINT - Note todo: fix compiler to accept correct number of arguments for NINT specific (1). REAL - Didn't check whether compiler accepts correct number of argument for REAL specific -- might as well do so now... C:\gfortran\clf\dimtest>type test_real.f90 program test_real implicit none abstract interface elemental function f(x) integer(4), intent(in) :: x real(4) f end function f end interface procedure(f), pointer :: fp integer(4) i fp => REAL i = 42 write(*,*) i, fp(i), kind(fp(i)) end program test_real C:\gfortran\clf\dimtest>gfortran test_real.f90 -otest_real test_real.f90:12.9: fp => REAL 1 Error: Interface mismatch in procedure pointer assignment at (1): Type/rank mism atch in argument 'x' So this is another todo. Thanks again. -- write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, & 6.0134700243160014d-154/),(/'x'/)); end
From: stevenb on 28 Dec 2009 07:44
On Dec 28, 7:05 am, steve <kar...(a)comcast.net> wrote: > On Dec 27, 7:42 pm, "James Van Buskirk" <not_va...(a)comcast.net> wrote: > > > "steve" <kar...(a)comcast.net> wrote in message > > >news:2f134318-7f45-41e6-8045-810df1a4eaae(a)r24g2000yqd.googlegroups.com.... > > > > You forgot to send your observations to the gfortran developers. > > > Try sending email to fortran at gcc gnu org. > > > I have reasons for doing thing the way I do, sorry. Maybe eventually > > they will become clear but for the present... > > I doubt that your reason for posting gfortran specific support > questions/observations to c.l.f will become clear to me. Same here. The usual reasons for not posting to public mailing lists do not apply here, because Usenet is just as open and public as the GCC mailing lists. And, quite honestly, gfortran bug reports and support requests are IMHO inappropriate for comp.lang.fortran because, as I understand it, c.l.f is about Fortran the language and not about any specific compiler for the language. > > AIMAG - AIMAG specific name is standard > > Change COMPLEX to COMPLEX(4) and REAL to REAL(4) 3X each > > IMAG & IMAGPART are also generic names: > > COMPLEX and COMPLEX(4) are the same type (as are REAL and REAL(4)). > This is documented in the manual. But not with -fdefault-real-8, I think? Ciao! Steven |