Can I define the array low bound to be 0 in default in IVF 8.0?

[wu_internet]

In default, if the low bound of data array is omitted, it will assumed to be 1, say for example, the declaration of

Real aNum(10)

will assume the arry aNum's low bound to be 1. anyone knows if I can set the low bound to be 0 in the compiler configuration, so that all the data defined in the above way, including those defined by the allocate statement without low bound will start from 0?

Regards,

David.

[Jugoslav_Dujic]

Static:

REAL:: aNum(0:9)

Allocatable:

REAL, ALLOCATABLE:: aNum(:)

ALLOCATE(aNum(0:9))

Jugoslav

[wu_internet]

Thanks JugoslavDujic,

your reply is absolutely correct, but I might have not made my issuefully understood. What my real question is:

The data has already been defined as:

real aNum(10)

and

allocation(aNum(10)).

In a big project. Practically, the aNum(0) does not make any sense to my application. but if I can access to aNum(0), it will not do any harm to the software either. In the CVF, due to the run time checking of the array bound has not been implemented very strictly (or it is a bug for CVF). When the program meet the problem to access aNum(0), the CVF does not report a problemunder certain conditionseven though I set the run time checking about the array bound enabled. Now I am porting the project to IVF, such access to aNum(0) is strictly prohibited.I want to work around to set the default low bound of the array to be 0, so that the application will not crash under IVF. I understand this likely does not conforms with the Fortran language standard, but if there is such an option, it will save me a lot of troubles. I am still wondering if the IVF have such an option at all.

Regards,

David

[Jugoslav_Dujic]

Ah, sorry, didn't read the first post carefully.

I believe the failure to detect all instances of out-of-bounds access is a bug in CVF.

There's no compiler switch, however, to really compile everything with lower bound of zero. However, you can switch array bounds checking off -- I don't have IVF at hand, but in CVF it was under Project/Settings/Fortran/Run-time, and it's probably in a similarly named category of compiler settings in IVF. Array bounds checking is supposed to be turned off in Release configuration.

However, I can imagine it's possible that you get an Access Violation (instead of Array Bounds Exceeded) error occasionally. (When the accessed memory location happens to be out of heap memory page) -- if that happens, there's no workaround except to rewrite the code.

Jugoslav

[g_f_thomas]

"I believe the failure to detect all instances of out-of-bounds access is a bug in CVF."

Is this true?

Ciao,
Gerry T.

[Steven_L_Intel1]

I don't think so. The bounds checking in CVF is quite solid. Unlike some of our earlier compilers which simply looked to see if the final reference was somewhere within the array, CVF (and IVF) check each individual index against the declared bounds. Certainly I can't recall anyone ever submitting a bug report saying that the bounds checking was done incorrectly. (I have seen lots of complaints that CVF reported a bounds error where other compilers did not, but in all cases the error was correct.)

[Jugoslav_Dujic]

Assumed-size arrays? They're the only ones that come to my mind.

program arraybounds

real:: dummy = 1., x(10), dummy2 = 12.

call sub(x)

end program arraybounds

subroutine sub(x)

real:: x(*)

!y = x(0)
!write(*,*) y
y = x(11)
write(*,*) y

end subroutine sub

I admit It's difficult to check such bounds violations when the declaration of actual argument is not in scope. However, access to x(0) does indeed produce an array bounds exception.

Jugoslav

[Steven_L_Intel1]

For bounds of (*), that means (1:*). CVF will check the lower bound but will not check the upper bound because it does not have the information as to what the upper bound is. Some other compilers can check this - they do it by passing hidden diagnostic information at the call site. But this requires changes to the call interface which require that all code pass the information. It's a nice idea, but CVF (and IVF) doesn't do this.

CVF's array bounds checking works fine for the bounds it knows about.

[Jugoslav_Dujic]

True -- I thought it doesn't work for assumed-sizes at all, but I was apparently wrong. (Exactly half-wrong :-) )

I just saw the discussion in the other thread. It seems that the original poster and I had different things in mind. It appears that the differences in his case come from different order of subexpression evaluation.

I thought that CVF in Debug (unoptimized) mode doesn't do short-circuiting of logical expressions and removal of unused code? If I'm right, all of his problems would have emerged on CVF (without optimization) as well?

Jugoslav

[Steven_L_Intel1]

Possibly. CVF tends to evaluate logical expressions from right to left, due to an internal design. I wouldn't want to depend on it.

[g_f_thomas]

"However, access to x(0) does indeed produce an array bounds exception"

I should hope so.

Ciao,
Gerry T.

[wu_internet]

Jugoslav,

I assume that I am the poster of "other thread" you are referring to in your message. The reason I believe the CVF is doing something suspicious is that:

The fortran does not do the short circuit sub expression logical expression according the language itself, which you have explained that at least in the debug mode it won't do that. My guess is even under the release mode, during the compilation, it's not possible to do that. Because thecompiler acutally does not know the result of the otherexpression as it is a variable in my sample.

My guess is the CVF is trying to do the subexpression evaluation and short curcuitting of logical expression. However, it does not do according to the order of expression, suchas from left to right, or from right to left. Because if I change the order of the expression, it shows the same result. The possible way it is doing is:when some value such as the data aNum(0) can not be evaluated, it will defer its evaluation to check other expressions, if other expression can determine the final result of the whole expression, the CVF won't report any problem.

Currently, IVF is doing things different. It will report all such array bound problems which I am more happy with in my personal point of view, the problme with the IVF is its dramatical increase of build size.

Regrds,

David.

[Jugoslav_Dujic]

I assume that I am the poster of "other thread" you are referring to in your message.

Yes, unfortunately the discussion got split.

The fortran does not do the short circuit sub expression logical expression according the language itself,

You're wrong here. Per Standard, short-circuiting is allowed, but the order of evaluation/short-circuiting is left to the compiler, i.e. you cannot rely on it. As a consequence, burden of responsibility lies ona programmerto ensure that expressions involved do not contain side-effects (side-effects in a broad sense, i.e. the function do something useful other than returning the result).* Let's consider this case:

integer function CriticalSave() result(ierr)

open (11, file="Save.dat", iostat=ierr)

if (ierr.eq.0) then

write(11) VeryImportantData

close(11)

end if

end function CriticalSave

now, you should not invoke this function as a part of an (possibly short-circuited) expression:

b = .false.

if (b .and. CriticalSave().eq.0) then

...

or

i = 0*CriticalSave()

There's no guarantee that CriticalSave will be executed at all.

The Standard is bit vague of simple case of having such functions with side effects as the only member of expression:

i = CriticalSave()

This was atopic of a (heated) debate in comp.lang.fortran. First, let me assure you thatevery compiler will execute CriticalSave in such case, regardless of whether i is used later in the program. There seems to be the concensus that itmust be so and that it's the only sensible way. However, wording of the standard is unclear whether the compiler in theory might skip the execution.

Thus, CVF is right to short-circuit the expressions (and many compilers do so in optimization mode).

Jugoslav

*) Take my words with a grain of salt in this sense -- language lawyers will tell you better. An alternative approach is that compiler ought to evaluate everyFUNCTION which cannot be proven to be PURE (most intrinsic functions are PURE), but I don't think that's the case.

[Steven_L_Intel1]

I would not be so sure that the function is always called. The standard says:

"It is not necessary for a processor to evaluate all the operands of an expression, or to evaluate entirely each operand, if the value of the expression can be determined otherwise. If a statement contains a function reference in a part of an expression that need not be evaluated, all entities that would have become defined in the execution of that reference become undefined at the completion of the evaluation of the expression containing the function reference."

In cases such as the above, where the compiler can determine that CriticalSave need not be called, the compiler is free to not call it and I would expect many compilers in fact to not do so.