Select case restrictions
Gordon Sande
In the fragment
select case ( expression )
case ( value )
....
end select
the restrictions listed in F95 Handbook are that both
expression and value must be of the same discrete type,
that is either integer, logical or character and that in
the case of character must be of the same kind but may be
of differing length.
gfortran is diagnosing an error for differing kinds
of integers. Either this is an error, my guess, or
many other compilers have been letting this extension
through without comment.
Do I get to report one error to gfortran or an error
to many others?
In the spirit of equal time I have reported the problem
with g95's driver that does not handle "g95 a.f90 b.f90"
on MacOsX as it dumps b.f90 into ld.
Compile times for xlf, gftn and g95 seem to be 5, 5, 50
of real time with xlf using only 1 or 2 of user and system
time with much disk chatter while the other two are processor
limited. Execution times seem to be 4, 5, 15. Namelist on gftn
does not accept array elements so testbed programs using
namelist do not work. Phooey! Timings do not mean much as
I expect there is a fair amount of internal checking still
enabled.
Finding g95 and gftn is more like a urban scavenger hunt
that one would like. Fink is supposed to be the easy route
for MacOsX but it seems "not fully functional". There is
a g95 package on www.g95.org and and sourceforge has a
gftn under the guise of g95v4.0 (ask google).
James Van Buskirk
news:SFCwd.1792$0C1.1649@edtnps91...
> the restrictions listed in F95 Handbook are that both
> expression and value must be of the same discrete type,
> that is either integer, logical or character and that in
> the case of character must be of the same kind but may be
> of differing length.
> gfortran is diagnosing an error for differing kinds
> of integers. Either this is an error, my guess, or
> many other compilers have been letting this extension
> through without comment.
> Do I get to report one error to gfortran or an error
> to many others?
The f95 standard document seems to follow the herd here.
I would recommend reporting one error to gfortran.
What do the compilers do when a case-value ends up out
of range of the case-expr? Do any warn for unreachable
code?
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
Steven G. Kargl
Gordon Sande <g.s...@worldnet.att.net> writes:
>
> In the fragment
>
> select case ( expression )
> case ( value )
> ....
> end select
>
> the restrictions listed in F95 Handbook are that both
> expression and value must be of the same discrete type,
> that is either integer, logical or character and that in
> the case of character must be of the same kind but may be
> of differing length.
>
> gfortran is diagnosing an error for differing kinds
> of integers. Either this is an error, my guess, or
> many other compilers have been letting this extension
> through without comment.
This could be an error with gfortran. Please file a
bugzilla report at http://gcc.gnu.org. If you don't
want to use bugzilla, send me a short test program
exhibiting the problem and I'll pursue this issue.
(I re-arrange your paragraph below)
> Compile times for xlf, gftn and g95 seem to be 5, 5, 50
> of real time with xlf using only 1 or 2 of user and system
> time with much disk chatter while the other two are processor
> limited. Execution times seem to be 4, 5, 15.
> Timings do not mean much as I expect there is a fair amount
> of internal checking still enabled.
For gfortran, if you build from the cvs sources, you can
disable (some of) the internal checking by giving configure
the --disable-checking switch.
> Namelist on gftn does not accept array elements so testbed
> programs using namelist do not work. Phooey!
Work on namelist is currently under discussion.
http://gcc.gnu.org/ml/fortran/2004-12/msg00168.html
> Finding g95 and gftn is more like a urban scavenger hunt
> that one would like. Fink is supposed to be the easy route
> for MacOsX but it seems "not fully functional". There is
> a g95 package on www.g95.org and and sourceforge has a
> gftn under the guise of g95v4.0 (ask google).
Binary packages can be found at www.gfortran.org. Unfortunately,
MacOsX is not one of few available packages. www.gfortran.org
provides information on retrieving the cvs source code and
building gfortran.
Gordon Sande
James Van Buskirk wrote:
> "Gordon Sande" <g.s...@worldnet.att.net> wrote in message
> news:SFCwd.1792$0C1.1649@edtnps91...
>
>
> What do the compilers do when a case-value ends up out
> of range of the case-expr? Do any warn for unreachable
> code?
>
That is what "default" is all about.
James Van Buskirk
> James Van Buskirk wrote:
> > What do the compilers do when a case-value ends up out
> > of range of the case-expr? Do any warn for unreachable
> > code?
> That is what "default" is all about.
I guess I must sound like I'm talking backwards to many
readers. That's why there's Fortran, I suppose. Here's
what I meant:
! File: case_ex.f90
program case_ex
implicit none
integer, parameter :: ik1 = selected_int_kind(2)
integer(ik1) x
integer io
write(*,'(a)',advance='no',iostat=io) ' Enter the value of x:> '
read(*,*) x
if(io /= 0) x = 0
select case(x)
case(7)
write(*,'(a)') ' Sorry, bad guess.'
case(200)
write(*,'(a)') ' You win the prize!'
case default
write(*,'(a)') ' You aren''t even trying.'
end select
end program case_ex
C:\g95_stuff\clf\case_ex>g95 case_ex.f90 -ocase_ex
C:\g95_stuff\clf\case_ex>case_ex
Enter the value of x:> 7
Sorry, bad guess.
C:\g95_stuff\clf\case_ex>case_ex
Enter the value of x:> 200
At line 9 of file case_ex.f90 (Unit 5)
Fortran runtime error: Integer overflow while reading item 1
C:\g95_stuff\clf\case_ex>case_ex
Enter the value of x:> -56
You win the prize!
C:\g95_stuff\clf\case_ex>lf95 case_ex
[snip]
Compiling file case_ex.f90.
Compiling program unit case_ex at line 1:
2312-S: "case_ex.f90", line 14: Case value invalid type or value.
Encountered 1 error, 0 warnings in file case_ex.f90.
C:\g95_stuff\clf\case_ex>df case_ex
[snip]
case_ex
case_ex.F90(14) : Error: The case-value is out-of-range. [200]
case(200)
--------^
So g95 overflows that impossible case-value to fit in the
range of the case-expr while lf95 and cvf refuse the out-
of-range case-value entirely. I couldn't find anything in
the f95 standard document about this. Maybe you should simply
send bug reports to all vendors without exception.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
P.S. Paul is dead, miss him, miss him.
Richard E Maine
...
> integer, parameter :: ik1 = selected_int_kind(2)
...
> select case(x)
...
> case(200)
> I couldn't find anything in
> the f95 standard document about this.
I can (I think).
The code looks fine to me. There is no requirement that the case
values be of the same kind as the case-expr. (It would be a PITA
if there were such a requirement, as you would have to decorate all
the selectors with a kind number - not just keep them in range).
The operations of comparison are all well defined between integers
of diffferent kinds. See (whereever that stuff is in chapter 7).
This is not different in principle from writing
if (ik1 == 200) then ...
The result should always be false, but it is "clearly" a valid
expression. The CASE construct is defined in terms of expressions
like this.
--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain
Gordon Sande
Richard E Maine wrote:
> "James Van Buskirk" <not_...@comcast.net> writes:
>
> ....
>
>> integer, parameter :: ik1 = selected_int_kind(2)
>
> ....
>
>> select case(x)
>
> ....
>
>> case(200)
>
>
>>I couldn't find anything in
>>the f95 standard document about this.
>
>
> I can (I think).
>
> The code looks fine to me. There is no requirement that the case
> values be of the same kind as the case-expr. (It would be a PITA
> if there were such a requirement, as you would have to decorate all
> the selectors with a kind number - not just keep them in range).
Which is why I wanted to check before reporting the bug. It was code
that had been around for quite a while that pulled the diagnostic.
> The operations of comparison are all well defined between integers
> of diffferent kinds. See (whereever that stuff is in chapter 7).
> This is not different in principle from writing
>
> if (ik1 == 200) then ...
>
> The result should always be false, but it is "clearly" a valid
> expression. The CASE construct is defined in terms of expressions
> like this.
>
It might be a nice courtesy warning for a good quality implementation
but I can picture all sorts of (sometimes temporary) reasons why I might
have code like it and then we are back to the case above.
James Van Buskirk
news:m14qiks...@MLMCE0000L22801.local...
> The code looks fine to me.
OK, I sent in a report outlining 3 bugs in g95 relating to this
program to Andy, and 1 bug for Lahey/Fujitsu. CVF seems moot,
so they didn't get anything in their stocking. Thanks for
rendering your valued opinion.
Steven G. Kargl
> news:m14qiks...@MLMCE0000L22801.local...
>
>> The code looks fine to me.
>
> OK, I sent in a report outlining 3 bugs in g95 relating to this
> program to Andy, and 1 bug for Lahey/Fujitsu. CVF seems moot,
> so they didn't get anything in their stocking. Thanks for
> rendering your valued opinion.
>
I sent a patch to GCC for gfortran, which appears to allow your
program to run.
Yes, Gordon, I took 7.2.3 into account.
Herman D. Knoble
for input value, 200:
Run-time Error
*** Error 53, Overflow detected by input/output
routine (data out-of-range)
main - in file caseexample.f90 at line 9 [+0106]
Line 9: read(*,*) x
Question: Is it valid to input (or assign) a number x bigger
than ik1 = selected_int_kind(2) ?
Skip
On Sat, 18 Dec 2004 00:34:10 GMT, "James Van Buskirk" <not_...@comcast.net> wrote:
-|"Richard E Maine" <nos...@see.signature> wrote in message
-|news:m14qiks...@MLMCE0000L22801.local...
-|
-|> The code looks fine to me.
-|
-|OK, I sent in a report outlining 3 bugs in g95 relating to this
-|program to Andy, and 1 bug for Lahey/Fujitsu. CVF seems moot,
-|so they didn't get anything in their stocking. Thanks for
-|rendering your valued opinion.
Herman D. (Skip) Knoble, Research Associate
(a computing professional for 38 years)
Email: SkipKnobleLESS at SPAMpsu dot edu
Web: http://www.personal.psu.edu/hdk
Penn State Information Technology Services
Academic Services and Emerging Technologies
Graduate Education and Research Services
Penn State University
214C Computer Building
University Park, PA 16802-21013
Phone:+1 814 865-0818 Fax:+1 814 863-7049
Ron Shepard
Herman D. Knoble <SkipKno...@SPAMpsu.DOT.edu> wrote:
> Question: Is it valid to input (or assign) a number x bigger
> than ik1 = selected_int_kind(2) ?
I'm not sure I'm replying to the question that you asked, but if it
is about the argument of selected_int_kind(), then suppose on a
particular computer that selected_int_kind(2) is the same as
selected_int_kind(9) or selected_int_kind(18). That is, suppose the
machine supported only 32-bit or 64-bit integers, and nothing
smaller. For that machine, I think it would be legal to read or
assign a number larger than 99. However, on a machine that
supported 8-bit integers, then assignment of values larger than 127
would fail. Note that the limit would be 127, the actual limit for
that data type, not 99, the requested limit. So I think the answer
is that it is legal, because a compiler is allowed to support larger
integers than requested, but nonportable, because it is not required
to support larger integers. If you want portability of the fortran
source code, then the assignments would have to be small enough to
fit within the requested range.
It has been discussed here in the past in c.l.f. that the
decimal-based requests are not consistent with the binary-based
actual data types. That is, if you want to assign values up to 127,
then there is no way to use selected_int_kind() to return an 8-bit
integer type that covers exactly that desired range of values. If
you request a 2-digit range, then the numbers between 100 and 127
would be outside of the requested range, but if you request a
3-digit range, the compiler is required to return a type that would
support values up to 999, which of course will not fit in an 8-bit
integer type, so a larger type would be returned. So in practice
you have to request the 2-digit integer type with
selected_int_kind(2), and trust that the compiler will return the
8-bit integer that you really want.
The proposed solutions to this problem have included additional
arguments to the selected_int_kind() function to specify either the
number of bits or to specify the base in which the number of digits
is to be interpreted.
$.02 -Ron Shepard
James Van Buskirk
news:jvsds09r8kskkh9np...@4ax.com...
> Just for information, Salford FTN95 (using debug options) yields
> for input value, 200:
> Run-time Error
> *** Error 53, Overflow detected by input/output
> routine (data out-of-range)
> main - in file caseexample.f90 at line 9 [+0106]
> Line 9: read(*,*) x
> Question: Is it valid to input (or assign) a number x bigger
> than ik1 = selected_int_kind(2) ?
I am interpreting the question as: "Is it valid to input (or assign)
a value to x bigger than HUGE(x)?" The answer I would give is "Yes,
provided the input is no larger than the largest number representable
by x." But normally HUGE(x) is the largest number representable by
x, so the answer would normally be "No."
There was a bug in my code in that I put an IOSTAT= specifier in
the WRITE statement rather than the READ statement. Accordingly,
the program was helpless to trap invalid input at run-time, so
there were actually only two bugs detected in g95's behavior on
this example.
James Van Buskirk
news:cpvu6j$lhh$1...@gnus01.u.washington.edu...
> I sent a patch to GCC for gfortran, which appears to allow your
> program to run.
It wasn't immediately obvious to me how to follow up to
your post to the gfortran mailing list, so I thought I
would convey my hope that gfortran smokes out the errors
in your example:
subroutine (x,y)
integer*1 x
integer y
select case (x)
case y
end select
end
No name for subroutine, no parentheses around case-
value-range-list, case value not an initialization expression.
Steven G. Kargl
> news:cpvu6j$lhh$1...@gnus01.u.washington.edu...
>
>> I sent a patch to GCC for gfortran, which appears to allow your
>> program to run.
>
> It wasn't immediately obvious to me how to follow up to
> your post to the gfortran mailing list, so I thought I
> would convey my hope that gfortran smokes out the errors
> in your example:
>
> subroutine (x,y)
> integer*1 x
> integer y
> select case (x)
> case y
> end select
> end
>
> No name for subroutine, no parentheses around case-
> value-range-list, case value not an initialization expression.
>
Actually, I used the short program that you posted to
locate the problem within gfortran. Here's the original
thread.
http://gcc.gnu.org/ml/fortran/2004-12/msg00178.html
You took the above snippet from
http://gcc.gnu.org/ml/fortran/2004-12/msg00182.html
where my attempt at pseudo-code to explain why g77 has
an invalid program in its testsuite looks more like actual
code.
The important portion of the 2nd post is that the SELECT CASE
construct in the first chunk is equivalent to the IF-ENDIF
construct in the second, so we are concerned with a numeric
rational operation; circa 7.2.3.
PS: Yes, there is an error in the 2nd post. x is promoted to
the kind of x+y not y. I haven't quite figured out the
significance of specifying x+y over just y.
--
Steve