Jeff, i did not get any reply :-(
from the OpenSHMEM 1.1 specs : Data object on the PE identified by pe that contains the data to be copied. This data object must be remotely accessible. so i assumed the test was incorrect and i commited a new one (r2418) Cheers, Gilles On 2014/08/29 23:41, Jeff Squyres (jsquyres) wrote: > Gilles -- > > Did you get a reply about this? > > > On Aug 26, 2014, at 3:17 AM, Gilles Gouaillardet > <gilles.gouaillar...@iferc.org> wrote: > >> Folks, >> >> the test_shmem_zero_get.x from the openshmem-release-1.0d test suite is >> currently failing. >> >> i looked at the test itself, and compared it to test_shmem_zero_put.x >> (that is a success) and >> i am very puzzled ... >> >> the test calls several flavors of shmem_*_get where : >> - the destination is in the shmem (why not, but this is useless) >> - the source is *not* in the shmem >> - the number of elements to be transferred is zero >> >> currently, this is failing because the source is *not* in the shmem. >> >> 1) is the test itself correct ? >> i mean that if we compare it to test_shmem_zero_put.x, i would guess that >> destination should be in the local memory and source should be in the shmem. >> >> 2) should shmem_*_get even fail ? >> i mean there is zero data to be transferred, so why do we even care >> whether source is in the shmem or not ? >> is the openshmem standard explicit about this case (e.g. zero elements >> to be transferred) ? >> >> 3) is a failure expected ? >> even if i doubt it, this is an option ... and in this case, mtt should >> be aware about it and report a success when the test fails >> >> 4) the test is a success on v1.8. >> the reason is the default configure value is --oshmem-param-check=never >> on v1.8 whereas it is --oshmem-param-check=always on trunk >> is there any reason for this ? >> >> Cheers, >> >> Gilles >> _______________________________________________ >> devel mailing list >> de...@open-mpi.org >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/devel >> Link to this post: >> http://www.open-mpi.org/community/lists/devel/2014/08/15707.php >
