Fortran 95 Forall Construct - Strange Behaviour

[uofa_geo]

Hi,

I am having a problem with the forall construct in fortran 95. I am attempting to build a symmetric matrix by filling half of it with a function and copying the filled half to the other half of the matrix.

I have found a forall expression that will produce the proper matrix:

forall (i=1:na,j=1:na,j>i) a(i,j) = 0.5
forall (i=1:na,j=1:na,j>i) a(j,i) = a(i,j)


But I was hoping someone could tell me why the forall construct below gives incorrect results.

forall (i=1:na,j=1:na,i>j)
a(i,j) = 0.5
a(j,i) = a(i,j)
end forall


I have attached a small portion of my code that can be compiled and tested.

Thanks,
Chad

[Steven_L_Intel1]

Seems to work ok for me using Intel Fortran 8.1.030, but it doesn't work using CVF 6.6C. Which compiler are you using?

Did you mean to have j>i in the "correct" case and i>j in the "incorrect" case? (Not that it seems to matter - I get the same matrix either way - but it struck me as odd.)

[uofa_geo]

Hi Steve,

Thanks for your input. I am using CVF 6.6c. Strange that the results for the 2 compilers are not the same.

The mask i>j or j>i should not matter. I was trying to see if the indexing was the cause of the problem, but it seems to be CVF.

Thanks,
Chad

[Steven_L_Intel1]

Not strange at all - lots of bugs have been fixed in Intel Visual Fortran since CVF stopped changing. You're right that the mask direction doesn't matter here - I just thought it odd.

[ivfuser]

Ok, I was curious and tapped out the attached demo code in a hurry, so please be no harsher than required by standard. ;)

I confirm that this is a problem in CVF 6.6C3 but not in IVF 8.1 build 030 for IA-32. The attached demo seems to suggest that in CVF forall *appears* to work on a temporary copy, which is copied to store only at the conclusion of the forall construction.

I have run an additional test (not included here) which further shows that the problem is not with the conditional clause of the forall; the expected iterations and only the expected iterations are occur in both CVF and IVF. (This requires inference (or looking at object code) since we can't do much with the dummy variables inside a forall.)

I doubt CVF is conforming, though perhaps I should not say so with my copy of M&R lying in the other office. If I had to rationalize this behavior, I might posit that automatic parallelization of forall contructs could give a compiler fits if both (1) self-referential assignments such as in this example were allowed; and (2) order of execution were not guaranteed. I'm not sure how the standard speaks to this. Now my head hurts, since I'm not even sure that IVF *should* get it right... ;)

Being hit on the head with a copy of Plauger very early on, with increasing force each time, I tend to eschew cleverness anyway. But this looks like another good reason to retire the venerable CVF.

[ivfuser]

I don't mean to beat a dead compiler, but some of us are still using CVF for production as we come up to speed with IVF. So this seems relevant, if only as another reason to move to IVF.

See section 6.9 of M&R. As I read it, each assignment statement in a forall construct is evaluated with temporary store, which the compiler must assign to named store before proceeding to the next assignment, if any. Order of execution within individual assignment statements is not specified, to enable optimization.

I have not looked at the object code, but it seems that CVF may not copy temporary store back to named store until all assignment statements (working on shared tempoary store) have completed. That would be non-conforming. If this interpretation is correct, then it's safe to use the forall statement (not the forall construct!) or a non-nested forall construct with single a single assignment statement in CVF. I have not tested nested forall constructs, but I would expect problems with CVF unless there is exactly one assignment statement in the entire nested structure.

RIP CVF and viva IVF.