Tighten VIS overlap UB wording

rput,rget VIS spec semantics for destinations overlapping each other or a source using wording like:

The results are undefined for any destination that is aliased by multiple runs. In the case where the current rank has load/store access to the destination mem-ory, if any destination memory is aliased by source memory then all destination addresses receive undefined results

The concept of an "address receiving undefined results" is not well-formed. Values can be indeterminate or unspecified, but undefined behavior is just undefined behavior - it's not constrained to a particular address.

The analogous text in the contiguous rput/rget appears in a precondition:

Addresses in the intervals [src,src+count) and [dest,dest+count) must all reference valid objects of type T. No object may be referenced by both intervals

and violation of this precondition implies undefined behavior.

I think the VIS wording should be strengthened to clearly specify these cases as illegal inputs generating fully undefined behavior.

Comments (1)