I'll take care of the one ompio warning.
Edgar
On 12/12/2014 12:01 PM, Nathan Hjelm wrote:
The osc warnings will go away after the btl modifications are applied. I
made signifigant changes to the component.
-Nathan
On Fri, Dec 12, 2014 at 09:49:47AM -0800, Ralph Castain wrote:
While buil
The osc warnings will go away after the btl modifications are applied. I
made signifigant changes to the component.
-Nathan
On Fri, Dec 12, 2014 at 09:49:47AM -0800, Ralph Castain wrote:
>While building optimized on Linux:
>bcol_ptpcoll_allreduce.c: In function
>'bcol_ptpcoll_allredu
While building optimized on Linux:
bcol_ptpcoll_allreduce.c: In function 'bcol_ptpcoll_allreduce_narraying_init':
bcol_ptpcoll_allreduce.c:236: warning: unused variable 'dtype'
bcol_ptpcoll_allreduce.c:235: warning: unused variable ‘count'
io_ompio_file_set_view.c: In function 'mca_io_ompio_final
Paul and all,
before r32408, the environment/abort test from the ibm test suite
crashed with SIGSEGV.
there is no more crash after the fix :-)
that being said, i experience some (random) hangs on my VM :
--mca btl tcp,self => no hang
--mca btl sm,self or --mca btl vader,self => hang about 25% of
Paul,
i confirm ampersand was missing and this was a bug
/* a similar bug was fixed by Ralph in r32357 */
i commited r32408 in order to fix these three bugs.
i also took the liberty to replace the OMPI_CAST_RTE_NAME
with an inline function (only in debug mode) in order to get a
compiler warning
Paul,
imho, the root cause is a missing ampersand.
I will double check this from tomorrow only
Cheers,
Gilles
Ralph Castain wrote:
>Arg - that raises an interesting point. This is a pointer to a 64-bit number.
>Will uintptr_t resolve that problem on such platforms?
>
>
>On Aug 2, 2014, at 8:
Whether just adding a (uintptr_t) cast is sufficient or not depends on the
usage, and I don't pretend to have looked much deeper than seeing that this
macro is common to the line numbers in the warnings I quoted.
If the intent is to uniformly store a pointer then a (uintptr_t *) cast may
be approp
Arg - that raises an interesting point. This is a pointer to a 64-bit number.
Will uintptr_t resolve that problem on such platforms?
On Aug 2, 2014, at 8:12 PM, Paul Hargrove wrote:
> Looks like on a 32-bit platform a (uintptr_t) cast is desired in the
> OMPI_CAST_RTE_NAME() macro.
>
> Warnin
Looks like on a 32-bit platform a (uintptr_t) cast is desired in the
OMPI_CAST_RTE_NAME() macro.
Warnings from current trunk tarball attributable to the missing case
include:
/home/pcp1/phargrov/OMPI/openmpi-trunk-linux-x86-gcc/openmpi-1.9a1r32406/ompi/runtime/ompi_mpi_abort.c:89:
warning: cast t
In file included from btl_vader_module.c:29:
btl_vader_fbox.h:51: warning: type qualifiers ignored on function return
type
In file included from btl_vader_component.c:34:
btl_vader_fbox.h:51: warning: type qualifiers ignored on function return
type
In file included from btl_vader_send.c:29:
btl_vad
We are looking at this issue...
Pavel (Pasha) Shamis
---
Computer Science Research Group
Computer Science and Math Division
Oak Ridge National Laboratory
On Nov 11, 2012, at 8:49 PM, Ralph Castain wrote:
Seeing the following warnings in the trunk:
bcol_ptpcoll_bcast.c: In function 'bcol_pt
Seeing the following warnings in the trunk:
bcol_ptpcoll_bcast.c: In function 'bcol_ptpcoll_bcast_k_nomial_known_root':
bcol_ptpcoll_bcast.c:606: warning: 'data_src' may be used uninitialized in this
function
bcol_ptpcoll_bcast.c: In function 'bcol_ptpcoll_bcast_k_nomial_anyroot':
bcol_ptpcoll_bc
12 matches
Mail list logo
