|
|
 Up |
|
|
  |
Author: James Van BuskirkJames Van Buskirk Date: May 16, 2008 01:19
I found that gfortran is missing the KIND optional argument in some
of the transformational intrinsics. Also a couple of usages of KIND
were not documented, and gfortran does not yet accept f2008 usage for
the SIZE intrinsic.
C:\gfortran\james\intrinsics\func1>type kind.f90
program test
implicit none
integer, parameter :: ck = kind('A')
integer, parameter :: ik = selected_int_kind(18)
integer i
real x
integer array(1)
i = 42
x = 3.14
array = 13
|
| Show full article (1.76Kb) |
|
| | 16 Comments |
|
|
Author: FXFX Date: May 16, 2008 01:28
> write(*,*) achar(i,kind=ck) ! KIND works but is not documented
> write(*,*) char(i,kind=ck) ! KIND works but is not documented
> write(*,*) maxloc(array,kind=ik) ! Consistent with f2003 usage
> write(*,*) minloc(array,kind=ik) ! Consistent with f2003 usage
> write(*,*) nint(x,kind=ik) ! KIND works but is not documented
> write(*,*) shape(array,kind=ik) ! Consistent with f2003 usage
The "works but not documented" cases are documentation bugs indeed. The
others are just because gfortran is not yet a full F2003 compiler, and
are already known.
--
FX
|
| |
|
| | no comments |
|
|
Author: James GilesJames Giles Date: May 16, 2008 11:01
James Van Buskirk wrote:
> [...] and gfortran does not yet accept f2008 usage for
> the SIZE intrinsic.
You astonish me. An F95 complier with some f2003
features that doesn't fully support a standard that hasn't
even been approved yet?!? This is unacceptable!
--
J. Giles
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
|
| |
| no comments |
|
|
Author: James Van BuskirkJames Van Buskirk Date: May 16, 2008 11:49
> James Van Buskirk wrote:
>> [...] and gfortran does not yet accept f2008 usage for
>> the SIZE intrinsic.
> You astonish me. An F95 complier with some f2003
> features that doesn't fully support a standard that hasn't
> even been approved yet?!? This is unacceptable!
Well, I was hoping that the issues raised in this thread were in the
feasible range. Not supporting KIND optional argument for MAXLOC,
MINLOC, and SHAPE for a compiler that uses nondefault integers for
array indices internally might be considered a bug by some:
C:\gfortran\test\large>gfortran large.f90 -olarge
C:\gfortran\test\large>large
2
1
2
|
| Show full article (1.61Kb) |
| no comments |
|
|
Author: Thomas KoenigThomas Koenig Date: May 16, 2008 12:03
On 2008-05-16, James Van Buskirk comcast.net> wrote:
> Well, I was hoping that the issues raised in this thread were in the
> feasible range. Not supporting KIND optional argument for MAXLOC,
> MINLOC, and SHAPE for a compiler that uses nondefault integers for
> array indices internally might be considered a bug by some:
|
| |
| no comments |
|
|
Author: James Van BuskirkJames Van Buskirk Date: May 16, 2008 12:34
"James Van Buskirk" comcast.net> wrote in message
news:UtKdneAOs8GoSrDVnZ2dnUVZ_vadnZ2d@comcast.com...
> Man, that paged everything out! Also supporting scalar actual
> argument for ARRAY argument to SIZE intrinsic doesn't seem that
> hard: the compiler already detects the case, so all that would be
> left is to check the DIM argument (1 <= DIM <= 0) :) and give the
> result as INT(0,KIND).
Must have paged me out as well. The result should have been
INT(1,KIND) for scalar ARRAY actual argument (I think).
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
|
| |
| no comments |
|
|
Author: James GilesJames Giles Date: May 16, 2008 12:35
James Van Buskirk wrote:
...
>> You astonish me. An F95 complier with some f2003
>> features that doesn't fully support a standard that hasn't
>> even been approved yet?!? This is unacceptable!
Well, I misread your original article. I thought the following
really was some new f2008 usage:
write(*,*) size(ik) ! Consistent with f2008 usage
Turns out that F2008 also requires the initial (non-optional)
argument to SIZE to be an array. You line is simply wrong.
(I thought maybe F2008 was doing this as a way of reporting
the bit- or byte-size of a default integer.)
Now, if your example had said:
write(*,*) size(array,ik) ! Consistent with f2008 usage
Maybe I wouldn't have thought that was so completely absurd.
|
| Show full article (1.38Kb) |
| no comments |
|
|
Author: James Van BuskirkJames Van Buskirk Date: May 16, 2008 12:56
> James Van Buskirk wrote:
> Well, I misread your original article. I thought the following
> really was some new f2008 usage:
> write(*,*) size(ik) ! Consistent with f2008 usage
> Turns out that F2008 also requires the initial (non-optional)
> argument to SIZE to be an array. You line is simply wrong.
> (I thought maybe F2008 was doing this as a way of reporting
> the bit- or byte-size of a default integer.)
Am I reading an obsolete draft? In N1723.pdf, section 13.7.155:
"SIZE(ARRAY[, DIM, KIND])
Description. Extent of an array along a specified dimension or
the total number of elements in the array.
Class. Inquiry function.
Arguments.
ARRAY shall be a scalar or array of any type."
So where do I find the more current draft that says this is wrong?
> Now, if your example had said:
|
| Show full article (2.08Kb) |
| no comments |
|
|
Author: James GilesJames Giles Date: May 16, 2008 14:13
James Van Buskirk wrote:
>> James Van Buskirk wrote:
>
>> Well, I misread your original article. I thought the following
>> really was some new f2008 usage:
>
>> write(*,*) size(ik) ! Consistent with f2008 usage
>
>> Turns out that F2008 also requires the initial (non-optional)
>> argument to SIZE to be an array. You line is simply wrong.
>> (I thought maybe F2008 was doing this as a way of reporting
>> the bit- or byte-size of a default integer.)
>
> Am I reading an obsolete draft? In N1723.pdf, section 13.7.155:
>
> "SIZE(ARRAY[, DIM, KIND]
|
| Show full article (1.55Kb) |
| no comments |
|
|
|
|
|
Author: James Van BuskirkJames Van Buskirk Date: May 16, 2008 14:30
> James Van Buskirk wrote:
>> "SIZE(ARRAY[, DIM, KIND]
> Looks like the correct description. In what way does SIZE(IK)
> match the above syntax diagram? IK is a scalar integer named
> constant in your sample program. The first (and only) non-optional
> argument to SIZE must be an array.
I observe that you have chosen to omit the passage I quoted that
said in plain terms that you were wrong. It read:
> Arguments.
> ARRAY shall be a scalar or array of any type."
SIZE(ik) matches that description, ik being scalar and scalar
being a member of the set {scalar, array}. Or has the standard
document for the English language changed in the interim?
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
|
| |
| no comments |
|
|
|
|
