[hwloc-devel] hwloc nightly build: SUCCESS

Successful builds: [] Skipped builds: ['v1.11', 'master'] Failed builds: [] === Build output === Branches: ['v1.11', 'master'] Starting build for v1.11 Build for revision 6379eb4 already exists, skipping. Starting build for master Build for revision 88690e3 already exists, skipping. Your

Re: [OMPI devel] about ompi_datatype_is_valid

+1 MPI_Datatype is an opaque handler, and in Open MPI, this is an ompi_datatype_t * so we can only test for NULL pointers or MPI_DATATYPE_NULL that cannot be used per the standard. fwiw, and iirc, MPICH made an other design choice and MPI_Datatype is a number, so the mpich equivalent of

Re: [OMPI devel] about ompi_datatype_is_valid

Hi, did you check the source code for ompi_datatype_is_valid() ? MPI_Datatype is an opaque handler. in Open MPI, this is an ompi_datatype_t *; iirc, ompi_datatype_is_valid() test for a NULL pointer, or MPI_DATATYPE_ NULL. in your case, you forced an invalid pointer, so the behavior is

Re: [OMPI devel] about ompi_datatype_is_valid

You have to pass it an allocated datatype, and it tells you if the pointer object is a valid MPI datatype for communications (aka it has a corresponding type with a well defined size, extent and alignment). There is no construct in C able to tell you if a random number if a valid C "object".

[OMPI devel] Master MTT results

Hey folks I scanned the nightly MTT results from last night on master, and the RTE looks pretty solid. However, there are a LOT of onesided segfaults occurring, and I know that will eat up people’s disk space. Just wanted to ensure folks were aware of the problem Ralph

Re: [OMPI devel] Time to remove Travis?

If I don't hear any disagreements by tomorrow, I'll disable Travis on the ompi Github repo. > On Jun 1, 2017, at 1:29 PM, Barrett, Brian via devel > wrote: > > +1 > >> On Jun 1, 2017, at 7:36 AM, Howard Pritchard wrote: >> >> I vote for

Re: [OMPI devel] Master MTT results

Also, we merged the RTE changes into 3.0.x this morning, so we should see how that works tonight on MTT. Thanks for all the work, Ralph! Brian > On Jun 1, 2017, at 8:34 AM, r...@open-mpi.org wrote: > > Hey folks > > I scanned the nightly MTT results from last night on master, and the RTE >

Re: [OMPI devel] Time to remove Travis?

+1 On Jun 1, 2017, at 7:36 AM, Howard Pritchard > wrote: I vote for removal too. Howard r...@open-mpi.org > schrieb am Do. 1. Juni 2017 um 08:10: I’d vote to remove it - it’s

Re: [OMPI devel] Master MTT results

A quick glance makes me think this might be related to the info changes. I am taking a look now. -Nathan On Jun 01, 2017, at 09:35 AM, "r...@open-mpi.org" wrote: Hey folks I scanned the nightly MTT results from last night on master, and the RTE looks pretty solid.

[OMPI devel] about ompi_datatype_is_valid

Hi, if I insert following lines somewhere openmpi, such as ompi/mpi/c/iscatter.c printf(" --- in MPI_Iscatter\n"); //MPI_Datatype dt00 = (MPI_Datatype) MPI_INT; *MPI_Datatype dt00 = (MPI_Datatype) -1;* if(*!ompi_datatype_is_valid(dt00)* ) { printf(" --- dt00 is NOT valid \n"); } The

Re: [OMPI devel] Time to remove Travis?

I’d vote to remove it - it’s too unreliable anyway > On Jun 1, 2017, at 6:30 AM, Jeff Squyres (jsquyres) > wrote: > > Is it time to remove Travis? > > I believe that the Open MPI PRB now covers all the modern platforms that > Travis covers, and we have people actively

[OMPI devel] Time to remove Travis?

Is it time to remove Travis? I believe that the Open MPI PRB now covers all the modern platforms that Travis covers, and we have people actively maintaining all of the machines / configurations being used for CI. -- Jeff Squyres jsquy...@cisco.com

Re: [OMPI devel] Time to remove Travis?

I vote for removal too. Howard r...@open-mpi.org schrieb am Do. 1. Juni 2017 um 08:10: > I’d vote to remove it - it’s too unreliable anyway > > > On Jun 1, 2017, at 6:30 AM, Jeff Squyres (jsquyres) > wrote: > > > > Is it time to remove Travis? > > > > I