Home > Archive > Fortran > June 2004 > ifc error?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
| Bastiaan Braams 2004-06-25, 7:43 pm |
| What to make of this?
> cat foo.f90
program foo
integer, parameter :: ind(0:0)=(/ 0 /)
if (2.le.size(ind)) then
write (*,*) ind(1)
endif
stop
end
> ifc foo.f90
program FOO
write (*,*) ind(1)
^
Error 173 at (4:foo.f90) : Array element subscript is not within array bounds
1 Error
compilation aborted for foo.f90 (code 1)
There is nothing wrong with foo that I can see.
> ifc -V
Intel(R) Fortran Compiler for 32-bit applications, Version 6.0
Build 020609Z
Bas Braams
| |
| James Van Buskirk 2004-06-25, 7:43 pm |
| "Bastiaan Braams" <braams@courant.nyu.edu> wrote in message
news:9b35cf8.0406191226.79c0fd2f@posting.google.com...
> There is nothing wrong with foo that I can see.
Try replacing your write statement with:
write(*,*) ubound(ind)
and reflect on the fact that the subscript in your
actual write statement is greater than the output of
the above.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
| |
| lkrupp@pssw.NOSPAM.com.INVALID 2004-06-25, 7:43 pm |
| Bastiaan Braams wrote:
> What to make of this?
>
>
>
> program foo
> integer, parameter :: ind(0:0)=(/ 0 /)
> if (2.le.size(ind)) then
> write (*,*) ind(1)
> endif
> stop
> end
>
>
>
> program FOO
> write (*,*) ind(1)
> ^
> Error 173 at (4:foo.f90) : Array element subscript is not within array bounds
> 1 Error
> compilation aborted for foo.f90 (code 1)
>
> There is nothing wrong with foo that I can see.
Your write statement will never be executed, but the compiler apparently
doesn't know that; it looks like it's smart enough to know that ind(1)
is bad, but not smart enough to know that 2 is not less than or equal to
size(ind).
The compiler is just trying to be helpful. Intrusive and annoying, but
helpful.
Louis
| |
| Richard Maine 2004-06-25, 7:43 pm |
| braams@courant.nyu.edu (Bastiaan Braams) writes:
> write (*,*) ind(1)
> ^
> Error 173 at (4:foo.f90) : Array element subscript is not within array bounds
....
> There is nothing wrong with foo that I can see.
The compiler is telling the truth; the index 1 is not
within the array bounds of 0 to 0. Several other compilers
will also catch things like this.
--
Richard Maine
email: my last name at domain
domain: summertriangle dot net
| |
| James Van Buskirk 2004-06-25, 7:43 pm |
| "lkrupp@pssw.NOSPAM.com.INVALID" <"lkrupp@pssw.NOSPAM.com.INVALID"> wrote in
message news:10d9i85ar2dpuaf@corp.supernews.com...
> Your write statement will never be executed, but the compiler apparently
> doesn't know that; it looks like it's smart enough to know that ind(1)
> is bad, but not smart enough to know that 2 is not less than or equal to
> size(ind).
OK, I encountered this problem in my first reply.
> The compiler is just trying to be helpful. Intrusive and annoying, but
> helpful.
Well, the compiler must try to check whether everything in
a block if is syntactically correct even if it knows that
the code won't be executed:
if(.FALSE.) then
icky && [icky] @@ poooo!!
end if
Should probably be detected as an error by the compiler.
But how about :
if(.FALSE.) then
i = sum((/int(1,-1)/))
end if
While checking for syntactic correctness, the compiler has
to make sure that the KIND argument to the INT intrinsic is
a valid kind type parameter for an integer. One would expect
this last example to be rejected out by the compiler for
this reason.
To detect problem like this with kind type parameters the
compiler might have to do something like propagate constant
expressions even in code sections that it already knows won't
be executed. This brings us to ind(1), which, since ind is
a named constant array and 1 is a literal constant, is itself
a constant expression. The compiler might well be expected
to catch ind(1) as in this thread while it might let a similar
expression ride if the array in question were a variable.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
| |
|
| On Sun, 20 Jun 2004 at 01:29 GMT, Richard Maine (aka Bruce)
was almost, but not quite, entirely unlike tea:
> braams@courant.nyu.edu (Bastiaan Braams) writes:
>
> ...
>
> The compiler is telling the truth; the index 1 is not
> within the array bounds of 0 to 0. Several other compilers
> will also catch things like this.
But what about the test beforehand? At compile time, that test *ought*
to be found to be false, so that section of code is
unreachable. Replace that constant with a variable, and the test looks
just like the end-of-loop condition - you don;t want the compiler
breaking just becuase your exit condition to your loop tests whether
we have reached the i=end of an array yet, and so accessing array
element[i+1] will fail.
--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
Black holes are where God divided by zero. -- Steven Wright
| |
| James Van Buskirk 2004-06-25, 7:43 pm |
| "TimC" <tconnors@no.astro.spam.swin.accepted.edu.here.au> wrote in message
news:slrn-0.9.7.4-8309-28594-200406201428-tc@hexane.ssi.swin.edu.au...
> But what about the test beforehand? At compile time, that test *ought*
> to be found to be false, so that section of code is
> unreachable. Replace that constant with a variable, and the test looks
> just like the end-of-loop condition - you don;t want the compiler
> breaking just becuase your exit condition to your loop tests whether
> we have reached the i=end of an array yet, and so accessing array
> element[i+1] will fail.
This is not just like the end-of-loop condition: even code elided
in a trivial block if can affect the code so it has to be scanned.
Consider:
! File: sub1a.f90
subroutine sub1
if(.FALSE.) then
call A
end if
call sub2(A)
end subroutine sub1
! End of file: sub1a.f90
And then the same code with the trivial if block
commented out:
! File: sub1b.f90
subroutine sub1
! if(.FALSE.) then
! call A
! end if
call sub2(A)
end subroutine sub1
! End of file: sub1b.f90
The two versions of subroutine sub1 are different in
that sub1 from sub1a is going to pass an external
subroutine, A, to sub2, whereas sub1 from sub1b will
pass the REAL local variable A to sub2. Semantic
difference from unreachable code!
Let's use a test file:
! File: sub0.f90
subroutine A
write(*,*) ' Was that so hard?'
end subroutine A
subroutine sub2(B)
external B
call B
end subroutine sub2
program sub0
call sub1
end program sub0
! End of file: sub0.f90
We see that in the context of this program we need sub1
from sub1a. Let's try a little batch file:
@echo off
REM File: compile.bat
del *.obj
%1 -c sub1a.f90
%1 -c sub1b.f90
%1 sub0.f90 sub1a.obj
sub0
%1 sub0.f90 sub1b.obj
sub0
REM End of file: compile.bat
C:\LF9556\James\clf\elided>compile lf95
Lahey/Fujitsu Fortran 95 Express Release 5.70d S/N: XXXXXXXX
Copyright (C) 1994-2003 Lahey Computer Systems. All rights reserved.
Copyright (C) 1998-2003 FUJITSU LIMITED. All rights reserved.
Registered to: James Van Buskirk
YYYYYYYYYYYYY
Options:
-nap -c -nchk -nchkglobal -dal
-ndbl -ndll -nf95 -nfix -ng
-nin -ninfo -li -nlst -nlong
-maxfatals 50 -o1 -npause -nprefetch -nprivate
-npca -nquad -nsav -staticlib -nstaticlink
-stchk -tp -trace -ntrap -w
-nwide -winconsole -nwo -nxref -zero
Compiling file sub1a.f90.
Compiling program unit sub1 at line 1:
Encountered 0 errors, 0 warnings in file sub1a.f90.
Lahey/Fujitsu Fortran 95 Express Release 5.70d S/N: XXXXXXXX
Copyright (C) 1994-2003 Lahey Computer Systems. All rights reserved.
Copyright (C) 1998-2003 FUJITSU LIMITED. All rights reserved.
Registered to: James Van Buskirk
YYYYYYYYYYYYY
Options:
-nap -c -nchk -nchkglobal -dal
-ndbl -ndll -nf95 -nfix -ng
-nin -ninfo -li -nlst -nlong
-maxfatals 50 -o1 -npause -nprefetch -nprivate
-npca -nquad -nsav -staticlib -nstaticlink
-stchk -tp -trace -ntrap -w
-nwide -winconsole -nwo -nxref -zero
Compiling file sub1b.f90.
Compiling program unit sub1 at line 1:
Encountered 0 errors, 0 warnings in file sub1b.f90.
Lahey/Fujitsu Fortran 95 Express Release 5.70d S/N: XXXXXXXX
Copyright (C) 1994-2003 Lahey Computer Systems. All rights reserved.
Copyright (C) 1998-2003 FUJITSU LIMITED. All rights reserved.
Registered to: James Van Buskirk
YYYYYYYYYYYYY
Options:
-nap -nc -nchk -nchkglobal -dal
-ndbl -ndll -nf95 -nfix -ng
-nin -ninfo -li -nlst -nlong
-maxfatals 50 -o1 -npause -nprefetch -nprivate
-npca -nquad -nsav -staticlib -nstaticlink
-stchk -tp -trace -ntrap -w
-nwide -winconsole -nwo -nxref -zero
Compiling file sub0.f90.
Compiling program unit A at line 1:
Compiling program unit sub2 at line 5:
Compiling program unit sub0 at line 10:
Encountered 0 errors, 0 warnings in file sub0.f90.
Microsoft (R) Incremental Linker Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
Was that so hard?
Lahey/Fujitsu Fortran 95 Express Release 5.70d S/N: XXXXXXXX
Copyright (C) 1994-2003 Lahey Computer Systems. All rights reserved.
Copyright (C) 1998-2003 FUJITSU LIMITED. All rights reserved.
Registered to: James Van Buskirk
YYYYYYYYYYYYY
Options:
-nap -nc -nchk -nchkglobal -dal
-ndbl -ndll -nf95 -nfix -ng
-nin -ninfo -li -nlst -nlong
-maxfatals 50 -o1 -npause -nprefetch -nprivate
-npca -nquad -nsav -staticlib -nstaticlink
-stchk -tp -trace -ntrap -w
-nwide -winconsole -nwo -nxref -zero
Compiling file sub0.f90.
Compiling program unit A at line 1:
Compiling program unit sub2 at line 5:
Compiling program unit sub0 at line 10:
Encountered 0 errors, 0 warnings in file sub0.f90.
Microsoft (R) Incremental Linker Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
jwe0019i-u The program was terminated abnormally with Exception Code
EXCEPTION_A
CCESS_VIOLATION.
error summary (Fortran)
error number error level error count
jwe0019i u 1
total error count = 1
C:\LF9556\James\clf\elided>compile df
Compaq Visual Fortran Optimizing Compiler Version 6.6 (Update C)
Copyright 2003 Compaq Computer Corp. All rights reserved.
sub1a.f90
sub1a.f90(6) : Error: If an external or dummy procedure name is used as an
actua
l argument, its interface shall be explicit or it shall be explicitly
declared
to have the EXTERNAL attribute [A]
call sub2(A)
-------------^
Compaq Visual Fortran Optimizing Compiler Version 6.6 (Update C)
Copyright 2003 Compaq Computer Corp. All rights reserved.
sub1b.f90
Compaq Visual Fortran Optimizing Compiler Version 6.6 (Update C)
Copyright 2003 Compaq Computer Corp. All rights reserved.
sub0.f90
Microsoft (R) Incremental Linker Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
/subsystem:console
/entry:mainCRTStartup
/debugtype:cv
/pdb:none
C:\DOCUME~1\James\LOCALS~1\Temp\obj8E.tmp
sub1a.obj
dfor.lib
libc.lib
dfconsol.lib
dfport.lib
kernel32.lib
/out:sub0.exe
LINK : fatal error LNK1181: cannot open input file "sub1a.obj"
'sub0' is not recognized as an internal or external command,
operable program or batch file.
Compaq Visual Fortran Optimizing Compiler Version 6.6 (Update C)
Copyright 2003 Compaq Computer Corp. All rights reserved.
sub0.f90
Microsoft (R) Incremental Linker Version 6.00.8447
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.
/subsystem:console
/entry:mainCRTStartup
/debugtype:cv
/pdb:none
C:\DOCUME~1\James\LOCALS~1\Temp\obj90.tmp
sub1b.obj
dfor.lib
libc.lib
dfconsol.lib
dfport.lib
kernel32.lib
/out:sub0.exe
forrtl: severe (157): Program Exception - access violation
Image PC Routine Line Source
sub0.exe 0043B98A Unknown Unknown Unknown
sub0.exe 00401092 SUB1 6 sub1b.f90
sub0.exe 00401071 SUB0 12 sub0.f90
sub0.exe 004264E9 Unknown Unknown Unknown
sub0.exe 0041D844 Unknown Unknown Unknown
KERNEL32.dll 7C581AF6 Unknown Unknown Unknown
SO we can see that LF95 liked both versions of sub1 but
linked a bombing executable with sub1b.f90. CVF rejected
sub1a.f90 because it knew that A was an external subroutine
name from elided code but it didn't see the EXTERNAL statement
for A in the declaration section of subroutine sub1. For
both compilers the trivial code in the if block made a
difference and had to be examined by the compiler in order
to determine the meaning of subroutine sub1.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
| |
| beliavsky@aol.com 2004-06-25, 7:43 pm |
|
braams@courant.nyu.edu (Bastiaan Braams) wrote:
>What to make of this?
>
>program foo
>integer, parameter :: ind(0:0)=(/ 0 /)
>if (2.le.size(ind)) then
> write (*,*) ind(1)
>endif
>stop
>end
>
> program FOO
> write (*,*) ind(1)
> ^
>Error 173 at (4:foo.f90) : Array element subscript is not within array bounds
>1 Error
>compilation aborted for foo.f90 (code 1)
>
>There is nothing wrong with foo that I can see.
Others have explained what is wrong. The program does work if ind(1) is replaced
by ind(1:1), which would be a zero-sized array in your program.
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
| |
| Robert Corbett 2004-06-25, 7:43 pm |
| Richard Maine <nospam@see.signature> wrote in message news:<m2pt7vdnkh.fsf@vega.avradionet.com>...
> braams@courant.nyu.edu (Bastiaan Braams) writes:
>
> ...
>
> The compiler is telling the truth; the index 1 is not
> within the array bounds of 0 to 0. Several other compilers
> will also catch things like this.
Yes, the compiler is telling the truth. Nonetheless, because of the
conditional, the code fragment shown is standard-conforming.
Therefore, the compilation should not abort.
I raised a similar issue in e-mail to J3 some years ago. Sun's f90
compiler gave an error and aborted compilation for the subroutine
SUBROUTINE SUBR
DO I = 1, 10
IF (.FALSE.) THEN
I = 1
END IF
END DO
END
I sent e-mail to J3 asking if a standard-conforming compiler is allowed
to reject the code because of the assignment. Some members of J3
responded that, because the offending code cannot be executed, a
standard-conforming compiler cannot fail to compile the subroutine
because of the assignment statement. Furthermore, they said the
simpler case
SUBROUTINE SUBR
DO I = 1, 10
I = 1
END DO
END
must compile unless the compiler can determine that the subroutine
will be called (which is hard to do if the subroutine is compiled in
isolation). They recommended that the compiler give a warning for
such cases and give a run-time error if the offending code is executed,
but they said it must compile. While their responses were not official
interpretations, no one from J3 contradicted their position.
The same logic applied to the example I presented applies to the
example presented here. I see no basis for reaching a different
conclusion.
Sincerely,
Bob Corbett
| |
| Steve Lionel 2004-06-25, 7:43 pm |
| On 19 Jun 2004 13:26:31 -0700, braams@courant.nyu.edu (Bastiaan Braams) wrote:
>Intel(R) Fortran Compiler for 32-bit applications, Version 6.0
>Build 020609Z
This is a two year old compiler. You would not see this behavior in the
current version 8.0.
Typically, compile time bounds checking is done long before flow analysis and
optimization. It also usually results in warnings, not fatal errors. I'm not
familiar with the Intel 6.0 implementation.
Steve Lionel
Software Products Division
Intel Corporation
Nashua, NH
User communities for Intel Software Development Products
http://softwareforums.intel.com/
Intel Fortran Support
http://developer.intel.com/software/products/support/
| |
| Richard Maine 2004-06-25, 7:43 pm |
| robert.corbett@sun.com (Robert Corbett) writes:
> I sent e-mail to J3 asking if a standard-conforming compiler is allowed
> to reject the code because of the assignment. Some members of J3
> responded that, because the offending code cannot be executed, a
> standard-conforming compiler cannot fail to compile the subroutine
> because of the assignment statement. Furthermore, they said the
> simpler case
>
> SUBROUTINE SUBR
> DO I = 1, 10
> I = 1
> END DO
> END
>
> must compile unless the compiler can determine that the subroutine
> will be called (which is hard to do if the subroutine is compiled in
> isolation). They recommended that the compiler give a warning for
> such cases and give a run-time error if the offending code is executed,
> but they said it must compile. While their responses were not official
> interpretations, no one from J3 contradicted their position.
I find that baroque. Yes, I guess I can see some rationale for it,
but I still find it baroque. Extrapolate that very far and before
long you are at a postion where compilers can't give error messages.
I'll admit it can be hard to draw the line precisely, but I'd
personally consider this to be past it.
My guess is that you'd have a hard time gettng an interpretation
answer that said a compiler must accept the above code. It is an
objectionable enough answer that I'd expect it to generate second
thougts before the committee would pass such an answer - just my
opinion, there.
To grab at a somewhat flimsy justification, let me note that the
definition of a standard-conforming program unit (in 1.5 of the DIS)
is that it "can be included in a program in a manner that allows the
program to be standard-conforming." I might wonder about what the
term "included" means in this context; if the only way to "include" it
in a standard-conforming program is to make sure that it is never
called, can that really be said to be included? I don't know; just
wondering here.
For a different point, let me note that the standard does not provide
an interpretation for what the assignment statement in the above code
would mean. I thus think it might also run afowl of the later part of
the prior sentence in 1.5, which requires that a standard-conforming
program have an interpretation according to the standard. Since the
standard doesn't give an interpretation for the assignment statement,
I don't think that gives a valid "out"; who is to say, if the standard
doesn't, that it necessarily has no effect just because the subroutine
it is in is not called. As James has pointed out, things that are not
executed can have effects. I see no more reason why that assignment
statement should be considered standard-conforming than that some
random collection of gibberish characters in the same context should
be considered standard-conforming; the standard doesn't give an
interpretation of either.
--
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
| |
| James Giles 2004-06-25, 7:43 pm |
| Robert Corbett wrote:
....
> SUBROUTINE SUBR
> DO I = 1, 10
> I = 1
> END DO
> END
I won't give an opinion on the standard compliance of this code.
I will say that if the compiler does not have some mode or filter
which causes it to flag this as an error, I don't want the compiler.
The fact is, whether this is standard or not, the compiler can't
generate code for this procedure - at least none that corresponds
to the source given. It seems to me that the compiler should
really tell me when no code can be produced! Is there anyone
that prefers to wait till run-time for this to be diagnosed?
Also, in cases similar to the others on this thread, I want
an error. Maybe in the case you gave (with a literal constant
as the conditional in the IF), you can convincingly argue that
no error is required, but what of:
...
DO I = 1, 10
IF (EXPR) THEN
I = 1
END IF
END DO
...
I don't want to wait for a rare instance after the program has been
released for production to find a blatant problem like this.
--
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
| |
| James Van Buskirk 2004-06-25, 7:44 pm |
| "Steve Lionel" <Steve.Lionel@intel.com> wrote in message
news:d1rdd0pbmgqb2tvr3dm9cruru7ell5ord3@
4ax.com...
> Typically, compile time bounds checking is done long before flow analysis
and
> optimization. It also usually results in warnings, not fatal errors. I'm
not
> familiar with the Intel 6.0 implementation.
I can imagine cases where bounds checking should likely result
in an error:
! File: sub.i90
subroutine sub_(x)
integer(n), intent(in) :: x
write(*,*) 'The result, ',int(1,kind(x)),' should be obvious.'
end subroutine sub_
! End of file: sub.i90
! File: illegal_kind.f90
module mykinds
implicit none
integer, private :: i
integer, parameter :: ik(4) = (/(selected_int_kind(2**i),i=1,4)/)
end module mykinds
module ik1
use mykinds
implicit none
private
integer, parameter :: n = ik(1)
public sub
interface sub
module procedure sub_
end interface sub
contains
include 'sub.i90'
end module ik1
module ik2
use mykinds
implicit none
private
integer, parameter :: n = ik(2)
public sub
interface sub
module procedure sub_
end interface sub
contains
include 'sub.i90'
end module ik2
module ik3
use mykinds
implicit none
private
integer, parameter :: n = ik(3)
public sub
interface sub
module procedure sub_
end interface sub
contains
include 'sub.i90'
end module ik3
module ik4
use mykinds
implicit none
private
integer, parameter :: n = ik(4)
public sub
interface sub
module procedure sub_
end interface sub
contains
include 'sub.i90'
end module ik4
module generic_recombination
use ik1
use ik2
use ik3
use ik4
implicit none
end module generic_recombination
program illegal_kind
use mykinds
use generic_recombination
implicit none
if(.FALSE.) then
call sub(int(1,ik(5)))
end if
end program illegal_kind
! End of file: illegal_kind.f90
Here the compiler needs to know what the KIND argument
to the INT intrinsic is so that it knows what kind of
argument it's passing to subroutine SUB so that it
knows what specific version of SUB to invoke. It's
hard to get this vital information from an out-of-bounds
array reference. Errors in constant or initialization
expressions seem to me to be something a compiler might
try to ride herd on more intensively than other errors
because it needs to know the value of the initialization
expression to be able to make any conclusions about that
semantics of the code it's trying to compile. Indeed,
both CVF and LF95 report their displeasure with the above
example and don't generate an executable.
--
write(*,*) transfer((/17.392111325966148d0,6.5794487871554595D-85, &
6.0134700243160014d-154/),(/'x'/)); end
| |
| Robert Corbett 2004-06-25, 7:44 pm |
| "James Giles" <jamesgiles@worldnet.att.net> wrote in message news:<lJDBc.12699$OB3.8136@bgtnsc05-news.ops.worldnet.att.net>...
>
> I won't give an opinion on the standard compliance of this code.
Obviously if the code is ever executed, the program is not standard-
conforming. If the code is not executed, the program might be
standard-conforming.
> I will say that if the compiler does not have some mode or filter
> which causes it to flag this as an error, I don't want the compiler.
> The fact is, whether this is standard or not, the compiler can't
> generate code for this procedure - at least none that corresponds
> to the source given. It seems to me that the compiler should
> really tell me when no code can be produced!
The members of J3 who responded to my question agreed that the compiler
should tell you about the bad assignment. The question was whether it
should be allowed to reject it.
> Is there anyone
> that prefers to wait till run-time for this to be diagnosed?
I didn't think so when I posted my original question. At the time, I
wanted J3 to add a constraint prohibiting direct assignment to a DO-loop
control variable within the body of the DO-loop. Once the point was
made that that addition would cause standard-conforming programs to
cease being standard-conforming, I knew there was no point in pursuing
the matter.
Sincerely,
Bob Corbett
| |
| Robert Corbett 2004-06-25, 7:44 pm |
| Richard Maine <nospam@see.signature> wrote in message news:<m1eko9c6f5.fsf@macfortran.local>...
> I find that baroque. Yes, I guess I can see some rationale for it,
> but I still find it baroque.
It is what the words of the standard say.
> Extrapolate that very far and before
> long you are at a postion where compilers can't give error messages.
Given the permissive nature of the Fortran standard, a compiler has
to be much more careful about which codes it rejects than which codes
it accepts. If the standard means anything, a standard-conforming
Fortran processor should not reject standard-conforming codes.
> I'll admit it can be hard to draw the line precisely, but I'd
> personally consider this to be past it.
I thought so too until I got the responses to my e-mail to J3.
> My guess is that you'd have a hard time gettng an interpretation
> answer that said a compiler must accept the above code.
It must be in the way one asks the question. My e-mail asked if it
was permissible to reject the code. Members of J3 told me it was
not. Perhaps if I had asked if a processor was required to accept
the code, they would have said it was not.
> It is an
> objectionable enough answer that I'd expect it to generate second
> thougts before the committee would pass such an answer - just my
> opinion, there.
The people who responded seemed to have no doubts.
> To grab at a somewhat flimsy justification, let me note that the
> definition of a standard-conforming program unit (in 1.5 of the DIS)
> is that it "can be included in a program in a manner that allows the
> program to be standard-conforming." I might wonder about what the
> term "included" means in this context; if the only way to "include" it
> in a standard-conforming program is to make sure that it is never
> called, can that really be said to be included? I don't know; just
> wondering here.
>
> For a different point, let me note that the standard does not provide
> an interpretation for what the assignment statement in the above code
> would mean. I thus think it might also run afowl of the later part of
> the prior sentence in 1.5, which requires that a standard-conforming
> program have an interpretation according to the standard. Since the
> standard doesn't give an interpretation for the assignment statement,
> I don't think that gives a valid "out"; who is to say, if the standard
> doesn't, that it necessarily has no effect just because the subroutine
> it is in is not called. As James has pointed out, things that are not
> executed can have effects. I see no more reason why that assignment
> statement should be considered standard-conforming than that some
> random collection of gibberish characters in the same context should
> be considered standard-conforming; the standard doesn't give an
> interpretation of either.
What you are saying seems to attack the logical basis of the standard.
The first requirement placed on a conforming processor is
(1) It executes any standard-conforming program in a manner that
fulfills the interpretations herein, subject to any limits
that the processor may impose on the size and complexity of
the program;
The assignment statement is syntactically correct. It does not violate
any constraints. Unless it is executed, which in the first example it
cannot be, it does not violate any of the rules of the standard. What
then is the basis for rejecting it? If this example can be rejected,
what can a programmer be assured will be accepted?
Sincerely,
Bob Corbett
| |
|
|
"James Giles" <jamesgiles@worldnet.att.net> wrote in message
news:lJDBc.12699$OB3.8136@bgtnsc05-news.ops.worldnet.att.net...
<snip> ...
>
> I don't want to wait for a rare instance after the program has been
> released for production to find a blatant problem like this.
>
In my experience it's not always that rare. Usually the day after release
:-(
Les
> --
> 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
>
>
| |
| Michael Metcalf 2004-06-25, 7:44 pm |
|
"beliavsky@aol.com" <beliavsky@127.0.0.1:7501> wrote in message
news:40d5b335_1@127.0.0.1...
>
> Others have explained what is wrong. The program does work if ind(1) is
replaced
> by ind(1:1), which would be a zero-sized array in your program.
>
Better late than never, but just to point out that ind(1:1) is an rank-one
array of size one, not zero.
The reason the original version does not (and should not) compile, is that
Section 6.2.2.1 of the standard requires the subscript of an array element
to be in bounds, which ind(1) clearly is not. For an array section,
out-of-bounds elements may not actually be referenced, but can be written.
Regards,
Mike Metcalf
| |
| Richard Maine 2004-06-25, 7:44 pm |
| robert.corbett@sun.com (Robert Corbett) writes:
> The assignment statement is syntactically correct. It does not violate
> any constraints. Unless it is executed, which in the first example it
> cannot be, it does not violate any of the rules of the standard. What
> then is the basis for rejecting it?
I thought I was pretty explicit about stating the basis. Now I'm not
sure whether my point is correct, but I did make one (two, actually),
neither of which you seemed to pay much attention to. Being syntactically
correct and not violating any constraints is not sufficient for standard
conformance. In particular, to be conforming, a program unit
1. must be capable of being "included" in a standard-conforming program
(I admit that the definition of "included" could be questioned)
and
2. must have an interpretation according to the standard.
I would say that the standard does not give an interpretation for what
the assignment statement in question would mean. The "normal" interpretation
of assignment statements would not seem to cover this case.
I'm not sure whether you overlooked those, just considered them too poor
to be worth commenting on, or what, but I did state them as at least
possible bases (I'm not sure about the plural of that word - looks funny,
but basises looks more so). How strong they are, I'm less sure.
Oh, and I'm also with Giles on this. Regardless of how one interprets
the fine details of the standard-speak, don't expect me personally to
buy or use a compiler that doesn't give an error for this (and the
error better be given by default without needing a -keep-rich-happy
switch). I really think it should be an error instead of a warning,
but I suppose I could deal with it as a warning without doing more than
grumbling about compiler silliness.
--
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
|
|
|
|
|