From: James Van Buskirk on
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
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
"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
"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
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