We seem to have gotten into a state again of generating a ton of warnings on
master - can folks take a look at these and clean them up?
opal_datatype_pack.c: In function ‘pack_predefined_heterogeneous’:
opal_datatype_pack.c:421:24: warning: variable ‘_l_blength’ set but not used
[-Wunused-but-se
Thanks Ralph,
The signed vs. unsigned warnings in the TCP BTL are fixed by 702f80ad7.
George.
On Sat, Apr 30, 2016 at 10:46 AM, Gilles Gouaillardet <
gilles.gouaillar...@gmail.com> wrote:
> Ralph,
>
> the OMPI_ENABLE_MPI_PROFILING related warnings are fixed in
> https://github.com/open-mpi/omp
Ralph,
the OMPI_ENABLE_MPI_PROFILING related warnings are fixed in
https://github.com/open-mpi/ompi-release/pull/1056
Cheers,
Gilles
On Saturday, April 30, 2016, Ralph Castain wrote:
> On CentOS-7 using gcc 4.8:
>
>
> btl_tcp.c: In function ‘mca_btl_tcp_add_procs’:
> btl_tcp.c:97:28: warning:
On CentOS-7 using gcc 4.8:
btl_tcp.c: In function ‘mca_btl_tcp_add_procs’:
btl_tcp.c:97:28: warning: comparison between signed and unsigned integer
expressions [-Wsign-compare]
for (int j = 0 ; j < tcp_proc->proc_endpoint_count ; ++j) {
^
btl_tcp_proc.c: In f
I silenced these (Nathan reviewed) - will be in nightly 1.8 tarball tomorrow.
It will return an error when we get a zero size as that shouldn’t be happening,
so it might expose some other error(s)
> On May 7, 2015, at 1:47 AM, Lisandro Dalcin wrote:
>
> Folks, I've just built 1.8.5 to test wi
Folks, I've just built 1.8.5 to test with mpi4py. My configure line was:
$ ./configure --prefix=/home/devel/mpi/openmpi/1.8.5 --enable-debug
--enable-mem-debug
While running the tests, my terminal was flooded with malloc(0)
warnings, below a list of unique lines.
malloc debug: Request for 0 byte
On Jan 17, 2014, at 12:44 PM, Paul Hargrove wrote:
> Ralph,
>
> I might be the most active lurker on Earth, but I am still that: an
> individual outside the OMPI core developers who follows the devel list. So,
> excepting bugs that cause me actual harm (and this is NOT one) I am usually
> h
Ralph,
I might be the most active lurker on Earth, but I am still that: an
individual outside the OMPI core developers who follows the devel list.
So, excepting bugs that cause me actual harm (and this is NOT one) I am
usually happy to defer to the core developers.
As I just sent in response to
Paul,
> So, if I follow your report correctly is is probably the "static" (not the
> "const") property of the string literals' type that leads pgcc to warn. If
> that is the case, then I agree that this is NOT a warning that is consistent
> with the C standard's rules for type compatibility.
Hmmm...I hate chasing compiler bugs, and since this is only a warning, I would
tend to defer making changes and just let folks push on PGI to fix their bug.
Anyone object to that strategy?
On Jan 17, 2014, at 12:04 PM, Paul Hargrove wrote:
> Larry,
>
> So, if I follow your report correctly i
Larry,
So, if I follow your report correctly is is probably the "static" (not the
"const") property of the string literals' type that leads pgcc to warn. If
that is the case, then I agree that this is NOT a warning that is
consistent with the C standard's rules for type compatibility. Thus I
agr
Paul,
From what I can see in the arguments to OPAL_OUTPUT_VERBOSE() in line 356 at
https://bitbucket.org/ompiteam/ompi-svn-mirror/src/f48eeda443104a64dc89e4f5fab4c940e44d8615/opal/mca/db/hash/db_hash.c,
this is the same PGI bug I reported 22 Jul 2010, which was assigned TPR 17139.
> Customer i
Ralph,
You are probably right that the string literals are a likely cause (type
char[] ? ).
I will poke at this a bit by adding (char *) casts to see which argument(s)
are actually the cause and get back to you.
-Paul
On Fri, Jan 17, 2014 at 8:56 AM, Ralph Castain wrote:
> Hi Paul
>
> Looking
Paul, Ralph,I had several issues in 2010 with with PGI pgcc being overly picky about type mismatches. Attached are my e-mails from that time. I was working on NetCDF and OpenMPI. In the OpenMPI report (17 Aug 2010), I found problems in conditional expressions. The last e-mail in the thread from
Hi Paul
Looking at these, I'm a tad puzzled. It would appear that PGI is complaining
about the fixed string being passed in the last three cases as there is no
(const char*)foo being used in those areas. Yet we use that same logic
elsewhere and your report isn't showing those as warnings.
Do y
My builds of the trunk with pgcc-13.10 turned up the following warnings:
PGC-W-0095-Type cast required for this conversion
(/scratch/scratchdirs/hargrove/OMPI/openmpi-trunk-linux-x86_64-pgi-13.10/openmpi-1.9a1r30302/opal/mca/db/hash/db_hash.c:
354)
PGC-W-0095-Type cast required for this conversion
Ralph Castain
Sent: Wednesday, October 23, 2013 7:19 PM
To: Open MPI Developers
Subject: [OMPI devel] Warnings in v1.7.4: rcache
One of the recent CMRs has created new warnings in v1.7.4:
rcache_vma.c: In function 'mca_rcache_vma_find':
rcache_vma.c:58:23: warning: pointer of type '
One of the recent CMRs has created new warnings in v1.7.4:
rcache_vma.c: In function 'mca_rcache_vma_find':
rcache_vma.c:58:23: warning: pointer of type 'void *' used in arithmetic
[-Wpedantic]
bound_addr = addr + size - 1;
^
rcache_vma.c:58:30: warning: pointer of type
On the trunk:
pml_ob1_component.c: In function 'mca_pml_ob1_component_register':
pml_ob1_component.c:207: warning: passing argument 12 of
'mca_base_pvar_register' from incompatible pointer type
pml_ob1_component.c:213: warning: passing argument 12 of
'mca_base_pvar_register' from incompatible po
coll_libnbc_component.c: In function 'libnbc_module_destruct':
coll_libnbc_component.c:274: warning: pointer targets in passing argument 1 of
'opal_atomic_add_32' differ in signedness
coll_libnbc_component.c:274: warning: signed and unsigned type in conditional
expression
nbc.c: In function 'NBC_
Cool - thanks!
My configure is available in the code base at
contrib/platform/greenplum/bend/linux.
Appreciate it!
On Sep 12, 2012, at 7:53 AM, "Shamis, Pavel" wrote:
> Ralph,
>
> Please see our comment inline.
>
>> common_allgather.c: In function 'comm_allgather_pml':
>> common_allgather.c
Ralph,
Please see our comment inline.
> common_allgather.c: In function 'comm_allgather_pml':
> common_allgather.c:45: warning: 'recv_iov[1].iov_len' may be used
> uninitialized in this function
> common_allgather.c:45: warning: 'send_iov[1].iov_len' may be used
> uninitialized in this function
Hi folks
I built an optimized version of the trunk and the 1.7 branch on a Linux/SLURM
box and got the following warnings - can people please identify which ones
belong to you and fix them?
common_allgather.c: In function 'comm_allgather_pml':
common_allgather.c:45: warning: 'recv_iov[1].iov_le
Thanks for the patch.
These got confused / lost in the last few days of furious commits. :-(
On Jun 26, 2012, at 9:47 AM, George Bosilca wrote:
> It's a copy/paste typo in mpi.h.in. Please try with the attached patch:
>
> Index: ompi/include/mpi.h.in
>
It's a copy/paste typo in mpi.h.in. Please try with the attached patch:
Index: ompi/include/mpi.h.in
===
--- ompi/include/mpi.h.in (revision 26662)
+++ ompi/include/mpi.h.in (working copy)
@@ -2006,9 +2006,9 @@
Anyone recognize these?
preduce_scatter_block.c:44: warning: no previous prototype for
'PMPI_Reduce_scatter_block'
pireduce_scatter_block.c:45: warning: no previous prototype for
'PMPI_Ireduce_scatter_block'
Not sure where they came from - seeing this on Linux.
Ralph
Thanks for reporting the issue. I fixed it on the SVN trunk in
https://svn.open-mpi.org/trac/ompi/changeset/24989, and filed changset move
requests for v1.4 and v1.5.
On Aug 4, 2011, at 9:30 AM, Júlio Hoffimann wrote:
> Dear OpenMPI developers,
>
> When compiling C++ applications with OpenMP
Dear OpenMPI developers,
When compiling C++ applications with OpenMPI 1.4.3 installed from Ubuntu
repositories, some easily addressable warnings occurs due to unused
arguments in function definitions. Namely, comm_inln.h has the following two
definitions:
inline int
MPI::Comm::NULL_COPY_FN(const
Yes, I do. All of them are on BTL_ERROR lines; I think these came in
last night with the opal attribute updates.
Looking at last night's MTT, those attribute changes turned up a LOT
of warnings in various BTLs... Doh!
On May 14, 2009, at 9:34 AM, Ralph Castain wrote:
I'm not entirely su
Hi Jeff,
On Thursday 14 May 2009 09:22:18 am Jeff Squyres wrote:
> Ralph -- did these messages come in due to the opal_attribute changes
> from last night?
They certainly are due to adding the __opal_attribute_format__ changes.
A similar patch as btl_tcp_frag should be applied...
Thanks,
Rainer
-
I'm not entirely sure as I'm unclear as to when this component would attempt
to build. I was building the latest trunk on a new (to me) system last night
(Jeff's cluster) when I saw the warnings.
Jeff: have you seen them before on your cluster?
On Thu, May 14, 2009 at 7:22 AM, Jeff Squyres wrot
On May 14, 2009, at 1:14 AM, Brad Penoff wrote:
At UBC, we are trying to find a new student who can maintain the SCTP
BTL. Unfortunately, it is has not been maintained since the progress
engine overhaul a while ago. At the moment, this is still on the TODO
list. I hope to get to this myself,
hey Ralph,
At UBC, we are trying to find a new student who can maintain the SCTP
BTL. Unfortunately, it is has not been maintained since the progress
engine overhaul a while ago. At the moment, this is still on the TODO
list. I hope to get to this myself, if no student is found.
It was my impr
Hi folks
Not sure who is maintaining the SCTP BTL, but I found the following
warnings when building tonight:
btl_sctp_frag.c: In function `mca_btl_sctp_frag_large_send':
btl_sctp_frag.c:179: warning: int format, different type arg (arg 3)
btl_sctp_frag.c:179: warning: int format, different ty
34 matches
Mail list logo
