Try inserting:

!$omp flush(array)

after

! Can we enter this loop safely

However, instead consider placing

!$omp flush(array)
!$omp flush(checkvarg)

immediately after the

!$omp end do nowait

that fills in the array.

N.B. I specified two seperate flush(..) in hope that the flushes occur as sequenced. Placing both variables(arrays) in the same statement is ambiguous to order. IA36/Intel64 should preserve write ordering however the compiler optimizations might resequence instructions and/or use streaming writes and/or write merging. To check for these conditions, examine the results of your

write(200,*) array-1

If you see any -1's then a write was not issued or bunged up with SSE merge (read, modify (with mask), write).
If you see all 0:nth-1's then the issue is with the flush.

Jim Dempsey

On IA32, Intel64 and AMD FLUSH(var)acts asa compiler directive

if var is registered then
if register of var modified then
write to memory
end if
disassociate var from register
end if

The write ordering should be preserved.

Due to all checkvar being set and varified as .true. (indicated by all threads passing the test) this indicates that all threads passed through their slice of

array(i) = iam+1
checkvar(i) = .true.

and thus is indicitive of one or more of

1) cache coherency system not correctly performing write combining
(I seriously doubt this would be true)

2) the allocatable array isn't aligned to at least integer granularity
(I seriously doubt this would be true)

3) compiler optimizations is batching up writes into larger GP register or SSE register then performing merge (read/modify/write) either at start of slice and/or end of slice

4) bad code

Can you produce an assembler listing then attach to reply to this forum?

Jim Dempsey

Stefano,

Thanks for the assembly listings. I haven't investigated thoroughly (I'm not from Intel) but I see some flow control problems with your testflush1.s listing. Assuming this was generated from your first message then we see:

..B1.56:                        # Preds ..B1.44 ..B1.50
        xorl      %eax, %eax                                    #52.12
        call      omp_get_wtime_                                #52.12
                                # LOE r13 r12d r14d xmm0
..B1.131:                       # Preds ..B1.56
        movsd     %xmm0, -128(%rbp)                             #52.12
                                # LOE r13 r12d r14d
..B1.57:                        # Preds ..B1.131
        xorl      %eax, %eax                                    #61.12
        call      omp_get_wtime_                                #61.12
                                # LOE r13 r12d r14d xmm0
..B1.132:                       # Preds ..B1.57
        movsd     %xmm0, -104(%rbp)                             #61.12

Two of the omp_get_wtime_ function calls are made back-to-back with no interviening code.
Meaning this code section did not follow the sequence of operations (or equivilent to the sequence of operations)in the original source code.

The write loop for filling in the array and chedkvar values was sequenced properly.

If the code flow for the code around (between) your loops is incorrect then it is possible that you could incorrectly sequence the test for array fill done.

Again, I wish to state I did not examine the code flow further than the first error.

Additional note:

The two omp_get_wtime_ function calls above store into

-128(%rbp) and -104(%rbp)

the third call stores into -112(%rbp)

These three stores are to corrolat to

double precision t(3)

The above array should encompass 3 * real(8)

If -128(%rbp) is t(1), then t(2) should be -120(%rbp), t(3) should be -112(%rbp), t(4) at -104(%rbp)
IOW the array addresses for t are messed up. Now the compiler optimizations could determine that array t is only unsed within this program and each cell referenced is unique (i.e. not passing t(1:3) outside the program), and then take the liberty to move the data around, however the debugger would have a problem in displaying the discontiguous array t.

Jim Dempsey