A little more data...
ompi_datatype_module.c:442 says
#if 0 /* XXX TODO The following may be deleted, both CXX and F77/F90
complex types are statically set up */
...followed by code to initialize ompi_mpi_cplx (i.e., MPI_COMPLEX).
(another TODO!!)
But ompi_mpi_cplex is setup with:
ompi_pre
On Jul 21, 2009, at 8:44 PM, Jeff Squyres (jsquyres) wrote:
The extent for MPI_COMPLEX is returning 0.
Sorry -- I accidentally hit "send" way before I finished typing. :-\
You can reproduce the problem with a trivial program:
-
#include
#include
int main(int argc, char* argv[])
{
The extent for MPI_COMPLEX is returning 0.
This is causing many the intel Fortran tests to fail, because they
loop over testing types, and MPI_COMPLEX is one of those types.
Specifically, you get a floating point exception because the intel
test computes (size / extent), and extent==0, so
On Jul 21, 2009, at 8:01 PM, Iain Bason wrote:
> $ mpicc -g -Isrc -c -o libmpitest.o libmpitest.c
> Cannot open configuration file ${datadir}/openmpi/mpicc-wrapper-
> data.txt
> Error parsing data file mpicc: Not found
Is this just mpicc, or is it also ompi_info and mpirun failing like
this?
On Jul 21, 2009, at 7:48 PM, Jeff Squyres wrote:
Arrgh!! Even with .ompi_ignore, everything is broken on OS X and
Linux (perhaps this is what Ralph was referring to -- not a compile
time problem?):
-
$ mpicc -g -Isrc -c -o libmpitest.o libmpitest.c
Cannot open configuration file ${d
On Jul 21, 2009, at 7:55 PM, Iain Bason wrote:
> $ ./configure --prefix=/home/jsquyres/bogus --disable-mpi-f77 --
> enable-mpirun-prefix-by-default
>
> No OPAL_* env variables set.
>
> Same thing happens on OS X and Linux.
And does it fail when actually installed in /home/jsquyres/bogus, or
on
On Jul 21, 2009, at 7:50 PM, Jeff Squyres wrote:
On Jul 21, 2009, at 7:46 PM, Iain Bason wrote:
> The help file should have been found. This is on Linux RHEL4,
but I
> doubt it's a Linux-version-specific issue...
Could you send me your configure options, and your OPAL_XXX
environment vari
On Jul 21, 2009, at 7:50 PM, Jeff Squyres wrote:
If you have an immediate fix for this, that would be great --
otherwise, please back this commit out (I said in my previous mail
that I would back it out, but I had assumed that you were gone for
the day. If you're around, please make the c
On Jul 21, 2009, at 7:46 PM, Iain Bason wrote:
> The help file should have been found. This is on Linux RHEL4, but I
> doubt it's a Linux-version-specific issue...
Could you send me your configure options, and your OPAL_XXX
environment variables?
$ ./configure --prefix=/home/jsquyres/bog
On Jul 21, 2009, at 7:35 PM, Jeff Squyres wrote:
However, I see that autodetect configure.m4 is checking
$backtrace_installdirs_happy -- which seems like a no-no. The
ordering of framework / component configure.m4 scripts is not
guaranteed, so it's not a good idea to check the output of a
Arrgh!! Even with .ompi_ignore, everything is broken on OS X and
Linux (perhaps this is what Ralph was referring to -- not a compile
time problem?):
-
$ mpicc -g -Isrc -c -o libmpitest.o libmpitest.c
Cannot open configuration file ${datadir}/openmpi/mpicc-wrapper-data.txt
Error parsing
On Jul 21, 2009, at 6:34 PM, Jeff Squyres wrote:
Also, it seems broken:
[15:31] svbu-mpi:~/svn/ompi4 % ompi_info | grep installd
--
Sorry! You were supposed to get help about:
developer warning: field too long
But I co
FWIW, it seems to compile ok for me on Leopard (i.e., autodetect
disables itself):
--- MCA component installdirs:autodetect (m4 configuration macro)
checking for MCA component installdirs:autodetect compile mode... static
checking procfs.h usability... no
checking procfs.h presence... no
checki
On Jul 21, 2009, at 6:34 PM, Jeff Squyres wrote:
I'm quite confused about what this component did to the base
functions. I haven't had a chance to digest it properly, but it
"feels wrong"... Iain -- can you please explain the workings of
this component and its interactions with the base?
On Jul 21, 2009, at 6:31 PM, Ralph Castain wrote:
This commit appears to have broken the build system for Mac OSX.
Could you please fix it - since it only supports Solaris and Linux,
how about setting it so it continues to work in other environments??
That was the intent of the configure.m
I'm quite confused about what this component did to the base
functions. I haven't had a chance to digest it properly, but it
"feels wrong"... Iain -- can you please explain the workings of this
component and its interactions with the base?
Also, it seems broken:
[15:31] svbu-mpi:~/svn/om
This commit appears to have broken the build system for Mac OSX. Could
you please fix it - since it only supports Solaris and Linux, how
about setting it so it continues to work in other environments??
Thanks
Ralph
On Jul 21, 2009, at 2:19 PM, i...@osl.iu.edu wrote:
Author: igb
Date: 2009-
This is on Linux with a very recent kernel (2.6.30), gcc 4.3.3:
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../../../opal/include -
I../../../../orte/include -I../../../../ompi/include -I../../../../
opal/mca/paffinity/linux/plpa/src/libplpa -I../../../.. -I/users/
jsquyres -g -Wall -Wunde
Thank you for your hint. I found that prepare_src() didn't
return the correct size, i.e. it did
ompi_convertor_pack(...,&max_data);
*size = max_data;
However, after ompi_convertor_pack(), max_data == 0 thus *size == 0
and free() is called without a prior send() in pml_ob1_sendreq.c:1064
I took
Based on your code the only reason I can imagine for the second send
to never be triggered is that the request is considered completed at
that point.
I can't imagine how the free is called without a prior send. If I look
at the code pml_ob1_sendreq.c:1061, the free is only called when the
Hello,
I am developing a new BTL component (Open MPI v1.3.2) for a new
3D-torus interconnect. During a simple message transfer of 16362 B
between two nodes with MPI_Send(), MPI_Recv() I encounter the following:
The sender:
---
1. prepare_src() size: 16304 reserve: 32
-> alloc() s
Jeff Squyres wrote:
Do we really want asserts here, or orte_show_help()'s?
asserts won't fire in production builds, will they?
No but isn't this a critical path in the code?
--td
On Jul 17, 2009, at 10:54 AM, wrote:
Author: tdd
Date: 2009-07-17 10:54:18 EDT (Fri, 17 Jul 2009)
New Revisi
Do we really want asserts here, or orte_show_help()'s?
asserts won't fire in production builds, will they?
On Jul 17, 2009, at 10:54 AM, wrote:
Author: tdd
Date: 2009-07-17 10:54:18 EDT (Fri, 17 Jul 2009)
New Revision: 21707
URL: https://svn.open-mpi.org/trac/ompi/changeset/21707
Log:
Add
Note that with the DDT changes, there's a few more configure tests
that may have added or changed configure cache value names, such as
the type alignment values.
Just a heads-up for those who are cross-compiling...
--
Jeff Squyres
jsquy...@cisco.com
24 matches
Mail list logo
