thanks
fixed in r31562
On Wed, Apr 30, 2014 at 3:50 AM, Ralph Castain wrote:
> ? oshmem/shmem/fortran/profile/pshmem_pe_accessible_f.c
> ? oshmem/shmem/fortran/profile/pshmem_iget128_f.c
> ? oshmem/shmem/fortran/profile/pshmem_int4_add_f.c
> ? oshmem/shmem/fortran/profi
Lisandro,
i assume you are running OpenMPI 1.8
r31554 fixes this issue (and some others)
https://svn.open-mpi.org/trac/ompi/changeset/31554/branches/v1.8/ompi/communicator/comm_cid.c
the root cause was an unitialized variable (rc in
ompi/communicator/comm_cid.c), and the issue only occured when
? oshmem/shmem/fortran/profile/pshmem_pe_accessible_f.c
? oshmem/shmem/fortran/profile/pshmem_iget128_f.c
? oshmem/shmem/fortran/profile/pshmem_int4_add_f.c
? oshmem/shmem/fortran/profile/pshmem_int8_add_f.c
? oshmem/shmem/fortran/profile/pshmem_prod_to_all_f.c
?
I've filed a ticket for this so that we don't lose track of it:
https://svn.open-mpi.org/trac/ompi/ticket/4578
-Dave
On Apr 24, 2014, at 2:37 AM, Lisandro Dalcin wrote:
> Please review the attached patch,
>
> ==19533== Conditional jump or move depends on uninitialised value(s)
> ==19533==
Lisandro,
Thanks for the bug report. It seems that nobody has time to work on this at
the moment, so I've filed a ticket so that we don't lose track of it:
https://svn.open-mpi.org/trac/ompi/ticket/4577
-Dave
On Apr 21, 2014, at 9:55 AM, Lisandro Dalcin wrote:
> A very basic test for MPI_Co
To close the loop for the web archives: we talked about this today on the call.
The consensus was to add a new MCA var type, like Ralph suggested. It'll be a
string, so you can put whatever you want in there.
And they'll prettyprint/parsable print with "version" or something obvious in
there
the way you launch the app, you will be using ROMIO, and I am not 100%
sure about how the data representation stuff is integrated with OMPI. I
am pretty sure that we are not doing the right thing for OMPIO, but I
will look into later this week.
Thanks
Edgar
On 4/29/2014 7:03 AM, Christoph Nietham
Yes, I know - the message about the nightly tarball gets automatically sent.
Trying to figure out the problem, but it doesn't make the trunk not compile. It
only affects making of the tarball.
On Apr 28, 2014, at 10:41 PM, Mike Dubman wrote:
> hit send too soon.
> this commit:
>
> Follow the
Hello,
It seems for me that the endianness is wrong in Open MPI's I/O for the
external32 data representation. :O
Find attached my test programs which write the integer -30 and the double 16.25
into a file.
Here the output on my Linux system:
mpicc c-xdr.c -o c-xdr
mpicc mpi-io-extern
hit send too soon.
this commit:
Follow the lead set by Jeff: no need to run AC_CONFIG_HEADERS on
orte_config.h. However, unlike the MPI layer, we don't run that macro on
another file in orte/include, so ensure we add that -I path back!
On Tue, Apr 29, 2014 at 8:40 AM, Mike Dubman wrote:
> seems
seems like started from this commit:
On Tue, Apr 29, 2014 at 8:39 AM, Mike Dubman wrote:
>
> contrib/dist/make_dist_tarball -highok -distdir
> /scrap/jenkins/scrap/workspace/hpc-ompi-shmem/label/hpc-test-node/tarball
>
>
>
> *03:36:26* make[3]: warning: -jN forced in submake: disabling jobserve
contrib/dist/make_dist_tarball -highok -distdir
/scrap/jenkins/scrap/workspace/hpc-ompi-shmem/label/hpc-test-node/tarball
*03:36:26* make[3]: warning: -jN forced in submake: disabling
jobserver mode.*03:36:26* CC orte-info.o*03:36:26* CC
output.o*03:36:26* CC param.o*03:36:26*
>>> I didn't see a reply to my question about the primary use case for this
being for scripts, and therefore a slightly-more-than-trivial regexp...
The primary use-case:
collect system related info w/ help of ompi_info and validate cluster setup
is according to site/vendor rules.
Can be done manu
13 matches
Mail list logo
