checkmate fails to point out zero ref

Hello,

checkmate seems to overlook full-array assignments to not-allocated arrays. There's no problem with assigning only a single element (or a range) which is correctly claimed as invalid operation when using checkmate.

Sample:

program alloc
    integer, allocatable, dimension(:) :: array
    array = 0
    print*, 'Should not reach this.'
end program alloc

Compile with

ftn95 /checkmate alloc.f90 /link and it just runs (which is wrong).

Compile it with

ftn95 alloc.f90 /link and it will throw an access violation when running the app (this is basically correct as the unallocated array is a zero reference).

Is this expected to behave like that (why)?

Thanks.

We will take a look at this to see if the error can be trapped.

Thanks.

Do you happen to know if it is actually an error (coding bug) or should a full-array assignment just be ignored by the compiler if the array is not allocated yet? The latter would make sense if the full-array alloc is something like 'initialize all elements' where elements==0 for unallocated arrays.

It is a programming error but it would be nice if checkmate was clever enough to flag it.

We have investigated this matter to see if checkmate can be extended to check for this programming error. Unfortunately this is not possible without endangering other parts of the compiler. In other words the undef check works for individual elements but not for block assignment and we cannot see a way to improve on this.

What happens is the compiler expands the block assignment into a loop but the loop is never entered because the default size is negative. As a result the built-in test on individual elements is never applied.

In practice the fault will become apparent when you try to access the array values.

In practice the fault will become apparent when you try to access the array values.

Actually the faulting instruction when compiling in release mode is the full-array assignment and not a following read or write access to an array element. Means if the array is (for whatever reason) never used, the checkmate compile works without error, but the releasemode executable crashes.

but the loop is never entered because the default size is negative

What is the default value for that loop in release mode? Or is it undefined?

Thanks.

I do understand where the fault occurs but, as you pointed out, the impact of the programming error may occur later.

In theory the default value of the size (of an unallocated array) is undefined. You cannot rely on its value either from one compiler to another or even within FTN95 from one release to another.

You cannot rely on its value either from one compiler to another or even within FTN95 from one release to another.

But using additional checks/preinitializations (fieldsize negative for checkmate) it would be possible, right? But that's the 'without endangering other parts of the compiler' part you talked about I guess.

Thanks anyways for looking into it.