- devel - mailman3.cels.anl.gov

Re: [mpich-devel] mpi is dying?
by Jeff Hammond 09 Apr '15

09 Apr '15

>> Let's look at >> http://on-demand.gputechconf.com/gtc/2014/webinar/gtc-express-acoates-webin…. >> The author works for Baidu's Silicon Valley AI Lab. Baidu is the >> Chinese Google. About as Silicon Valley as it gets. > > we can find silicon valley using MPI, but it's not widespread. Another > instance that comes to mind is this not heavily cited 2007 work from yahoo > using mpi for indexing: > > http://link.springer.com/chapter/10.1007%2F978-3-540-75416-9_21 True, but the reason it is widespread is not for the reasons that Dursi states. The primary reasons are sociological and economic, rather than technical. Jeff -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpich-devel] mpi is dying?
by Rob Latham 09 Apr '15

09 Apr '15

On 04/09/2015 09:45 AM, Jeff Hammond wrote: > www.hammond.us/programming-model-discourse-is-dying-and-false-dichotomies-a… > > Let's look at http://on-demand.gputechconf.com/gtc/2014/webinar/gtc-express-acoates-webin…. > The author works for Baidu's Silicon Valley AI Lab. Baidu is the > Chinese Google. About as Silicon Valley as it gets. we can find silicon valley using MPI, but it's not widespread. Another instance that comes to mind is this not heavily cited 2007 work from yahoo using mpi for indexing: http://link.springer.com/chapter/10.1007%2F978-3-540-75416-9_21 ==rob > Slide 30 says: > > OTS HPC Sotware Infrastructure > ï¿½ Infiniband (ï¿½IBï¿½): Use MPI > ï¿½ MPI = Message Passing Interface > ï¿½ Standard mid-level API usually supporing IB. > > Slide 32 says "Enables message passing, but this is pretty unnatural." > I guess Dursi is right. MPI sucks so hard. And it's definitely MPI > alone that uses send-recv semantics. It's not like the Internet is > based upon that or anything. And one definitely must switch to UPC to > get one-sided semantics. > > Oh, but then - <bam> - we see on slide 33, "Hide communication inside > "distributed array". OMG it's a high-level abstraction layer on top > of MPI that hides the supposed assembly language of parallel > programming and makes the programmer productive. > > But maybe Baidu is exceptional and most HPC programmers who deal with > array are doomed to tedious MPI programming. Let's see if there any > distributed array abstraction layers out there that hide MPI. It took > me about 42 microseconds to find http://libelemental.org/ and > https://www.emsl.pnl.gov/docs/global/, and those are just the ones > that I have a personal relationship with. And that is just the tip of > the MPI library iceberg. > > So yeah, most people that criticize MPI do so in a manner that is > logically equivalent to "Linux is way better than Fortran". > > http://arxiv.org/abs/cs/0109017 is a must-read, for anyone that hasn't already. > > Jeff > > > On Thu, Apr 9, 2015 at 7:16 AM, Rob Latham <robl(a)mcs.anl.gov> wrote: >> I (and it seems quite a few others) found this yesterday: >> >> http://www.dursi.ca/hpc-is-dying-and-mpi-is-killing-it/ >> >> The premise is a couple things: >> - spark, hadoop, and the "silicon valley stack" has tremendous mindshare >> - MPI is too hard for application writers >> - and too challenging for library writers >> - and HPC has "not invented here" blinders keeping it from adopting new >> techonolgy >> >> now, when someone writes "X is dying" it's more of an opening position >> statement for a discussion than a statement of fact. But it does bother >> me immensely that there is an "HPC stack" and a "silicon valley stack". >> Convergence is happening, but not fast enough. >> >> ==rob >> >> -- >> Rob Latham >> Mathematics and Computer Science Division >> Argonne National Lab, IL USA >> _______________________________________________ >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/devel > > > -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA

1 0

Re: [mpich-devel] mpi is dying?
by Rob Latham 09 Apr '15

09 Apr '15

On 04/09/2015 09:45 AM, Jeff Hammond wrote: > Oh, but then - <bam> - we see on slide 33, "Hide communication inside > "distributed array". OMG it's a high-level abstraction layer on top > of MPI that hides the supposed assembly language of parallel > programming and makes the programmer productive. > > But maybe Baidu is exceptional and most HPC programmers who deal with > array are doomed to tedious MPI programming. Let's see if there any > distributed array abstraction layers out there that hide MPI. It took > me about 42 microseconds to find http://libelemental.org/ and > https://www.emsl.pnl.gov/docs/global/, and those are just the ones > that I have a personal relationship with. And that is just the tip of > the MPI library iceberg. > > So yeah, most people that criticize MPI do so in a manner that is > logically equivalent to "Linux is way better than Fortran". This is but one of the points made, but I'm glad you brought it up. Parallel HDF5 and Parallel-NetCDF layer on top of MPI-IO routines, as well. so you and I know MPI meets one of its goals: be a good foundation for parallel libraries. Can you speak to Dursi's point about Gasnet and Charm++ 's relationship to MPI? It was you, not the GASNET folks, that developed the MPI transport layer for ARMCI, after all, but I am not familiar with those groups thought processes. ==rob > > http://arxiv.org/abs/cs/0109017 is a must-read, for anyone that hasn't already. > > Jeff > > > On Thu, Apr 9, 2015 at 7:16 AM, Rob Latham <robl(a)mcs.anl.gov> wrote: >> I (and it seems quite a few others) found this yesterday: >> >> http://www.dursi.ca/hpc-is-dying-and-mpi-is-killing-it/ >> >> The premise is a couple things: >> - spark, hadoop, and the "silicon valley stack" has tremendous mindshare >> - MPI is too hard for application writers >> - and too challenging for library writers >> - and HPC has "not invented here" blinders keeping it from adopting new >> techonolgy >> >> now, when someone writes "X is dying" it's more of an opening position >> statement for a discussion than a statement of fact. But it does bother >> me immensely that there is an "HPC stack" and a "silicon valley stack". >> Convergence is happening, but not fast enough. >> >> ==rob >> >> -- >> Rob Latham >> Mathematics and Computer Science Division >> Argonne National Lab, IL USA >> _______________________________________________ >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/devel > > > -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA

1 0

Re: [mpich-devel] mpi is dying?
by Jeff Hammond 09 Apr '15

09 Apr '15

www.hammond.us/programming-model-discourse-is-dying-and-false-dichotomies-a… Let's look at http://on-demand.gputechconf.com/gtc/2014/webinar/gtc-express-acoates-webin…. The author works for Baidu's Silicon Valley AI Lab. Baidu is the Chinese Google. About as Silicon Valley as it gets. Slide 30 says: OTS HPC Sotware Infrastructure • Infiniband (“IB”): Use MPI – MPI = Message Passing Interface • Standard mid-level API usually supporing IB. Slide 32 says "Enables message passing, but this is pretty unnatural." I guess Dursi is right. MPI sucks so hard. And it's definitely MPI alone that uses send-recv semantics. It's not like the Internet is based upon that or anything. And one definitely must switch to UPC to get one-sided semantics. Oh, but then - <bam> - we see on slide 33, "Hide communication inside "distributed array". OMG it's a high-level abstraction layer on top of MPI that hides the supposed assembly language of parallel programming and makes the programmer productive. But maybe Baidu is exceptional and most HPC programmers who deal with array are doomed to tedious MPI programming. Let's see if there any distributed array abstraction layers out there that hide MPI. It took me about 42 microseconds to find http://libelemental.org/ and https://www.emsl.pnl.gov/docs/global/, and those are just the ones that I have a personal relationship with. And that is just the tip of the MPI library iceberg. So yeah, most people that criticize MPI do so in a manner that is logically equivalent to "Linux is way better than Fortran". http://arxiv.org/abs/cs/0109017 is a must-read, for anyone that hasn't already. Jeff On Thu, Apr 9, 2015 at 7:16 AM, Rob Latham <robl(a)mcs.anl.gov> wrote: > I (and it seems quite a few others) found this yesterday: > > http://www.dursi.ca/hpc-is-dying-and-mpi-is-killing-it/ > > The premise is a couple things: > - spark, hadoop, and the "silicon valley stack" has tremendous mindshare > - MPI is too hard for application writers > - and too challenging for library writers > - and HPC has "not invented here" blinders keeping it from adopting new > techonolgy > > now, when someone writes "X is dying" it's more of an opening position > statement for a discussion than a statement of fact. But it does bother > me immensely that there is an "HPC stack" and a "silicon valley stack". > Convergence is happening, but not fast enough. > > ==rob > > -- > Rob Latham > Mathematics and Computer Science Division > Argonne National Lab, IL USA > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

mpi is dying?
by Rob Latham 09 Apr '15

09 Apr '15

I (and it seems quite a few others) found this yesterday: http://www.dursi.ca/hpc-is-dying-and-mpi-is-killing-it/ The premise is a couple things: - spark, hadoop, and the "silicon valley stack" has tremendous mindshare - MPI is too hard for application writers - and too challenging for library writers - and HPC has "not invented here" blinders keeping it from adopting new techonolgy now, when someone writes "X is dying" it's more of an opening position statement for a discussion than a statement of fact. But it does bother me immensely that there is an "HPC stack" and a "silicon valley stack". Convergence is happening, but not fast enough. ==rob -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA

1 0

Re: [mpich-devel] warning: returning 'uint32_t *' (aka 'unsigned int *') from a function with result type 'int *' converts between pointers to integer types with different sign
by Bland, Wesley B. 10 Mar '15

10 Mar '15

I’ll take a look. That’s my nasty code. On 3/9/15, 8:24 PM, ""Antonio J. Peña"" <apenya(a)mcs.anl.gov> wrote: > >Thanks Jeff. This will be ticket #2245 > > http://trac.mpich.org/projects/mpich/ticket/2245 > > >On 03/09/2015 08:02 PM, Jeff Hammond wrote: >> See below, but the propriety of this cast can be verified in source >> without a compiler :-) >> >> Jeff >> >> ## Local Branches: >> >> * master >> >> ## Most Recent Commit: >> >> commit 957ceec598103d8d643c9345512ae8ad4e88e993 >> Author: Ken Raffenetti <raffenet(a)mcs.anl.gov> >> >> testsuite: remove leading spaces in testlist files >> >> jrhammon-mac01:build jrhammon$ head config.log >> This file contains any messages produced by compilers while >> running configure, to aid debugging if configure makes a mistake. >> >> It was created by MPICH configure 3.2b1, which was >> generated by GNU Autoconf 2.69. Invocation command line was >> >> $ ../configure CC=icc CXX=icpc FC=ifort F77=ifort --enable-fortran >> --enable-threads=runtime --enable-g=dbg --with-pm=hydra >> --prefix=/opt/mpich/dev/intel/default --enable-wrapper-rpath >> --enable-static --enable-shared >> >> jrhammon-mac01:build jrhammon$ icc --version >> icc (ICC) 15.0.1 20141022 >> Copyright (C) 1985-2014 Intel Corporation. All rights reserved. >> >> >> >> On Mon, Mar 9, 2015 at 5:58 PM, "Antonio J. Peña" <apenya(a)mcs.anl.gov> wrote: >>> Hi Jeff, >>> >>> Please also report compiler, compiler version, and MPICH version. >>> >>> Best, >>> Toni >>> >>> >>> >>> On 03/09/2015 07:53 PM, Jeff Hammond wrote: >>>> I know some of you like warning-clean builds... >>>> >>>> ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:20:14: warning: >>>> assigning to 'uint32_t *' (aka 'unsigned int *') from 'int *' >>>> converts between pointers to integer types with different sign >>>> [-Wpointer-sign] >>>> bitarray = (int *) MPIU_Malloc(sizeof(int) * bitarray_size); >>>> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:24:16: warning: >>>> returning 'uint32_t *' (aka 'unsigned int *') from a function >>>> with result type 'int *' converts between pointers to integer >>>> types with different sign [-Wpointer-sign] >>>> return bitarray; >>>> ^~~~~~~~ >>>> ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:46:12: warning: >>>> returning 'uint32_t *' (aka 'unsigned int *') from a function >>>> with result type 'int *' converts between pointers to integer >>>> types with different sign [-Wpointer-sign] >>>> return bitarray; >>>> ^~~~~~~~ >>>> ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:107:14: warning: >>>> assigning to 'uint32_t *' (aka 'unsigned int *') from >>>> 'int *' converts between pointers to integer types with >>>> different sign [-Wpointer-sign] >>>> bitarray = group_to_bitarray(local_fail, comm_ptr); >>>> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>> 4 warnings generated. >>>> >>>> Best, >>>> >>>> Jeff >>>> >>> >>> -- >>> Antonio J. Peña >>> Postdoctoral Appointee >>> Mathematics and Computer Science Division >>> Argonne National Laboratory >>> 9700 South Cass Avenue, Bldg. 240, Of. 3148 >>> Argonne, IL 60439-4847 >>> apenya(a)mcs.anl.gov >>> www.mcs.anl.gov/~apenya >>> >>> _______________________________________________ >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/devel >> >> > > >-- >Antonio J. Peña >Postdoctoral Appointee >Mathematics and Computer Science Division >Argonne National Laboratory >9700 South Cass Avenue, Bldg. 240, Of. 3148 >Argonne, IL 60439-4847 >apenya(a)mcs.anl.gov >www.mcs.anl.gov/~apenya > >_______________________________________________ >To manage subscription options or unsubscribe: >https://lists.mpich.org/mailman/listinfo/devel

1 0

Re: [mpich-devel] warning: returning 'uint32_t *' (aka 'unsigned int *') from a function with result type 'int *' converts between pointers to integer types with different sign
by "Antonio J. Peña" 09 Mar '15

09 Mar '15

Thanks Jeff. This will be ticket #2245 http://trac.mpich.org/projects/mpich/ticket/2245 On 03/09/2015 08:02 PM, Jeff Hammond wrote: > See below, but the propriety of this cast can be verified in source > without a compiler :-) > > Jeff > > ## Local Branches: > > * master > > ## Most Recent Commit: > > commit 957ceec598103d8d643c9345512ae8ad4e88e993 > Author: Ken Raffenetti <raffenet(a)mcs.anl.gov> > > testsuite: remove leading spaces in testlist files > > jrhammon-mac01:build jrhammon$ head config.log > This file contains any messages produced by compilers while > running configure, to aid debugging if configure makes a mistake. > > It was created by MPICH configure 3.2b1, which was > generated by GNU Autoconf 2.69. Invocation command line was > > $ ../configure CC=icc CXX=icpc FC=ifort F77=ifort --enable-fortran > --enable-threads=runtime --enable-g=dbg --with-pm=hydra > --prefix=/opt/mpich/dev/intel/default --enable-wrapper-rpath > --enable-static --enable-shared > > jrhammon-mac01:build jrhammon$ icc --version > icc (ICC) 15.0.1 20141022 > Copyright (C) 1985-2014 Intel Corporation. All rights reserved. > > > > On Mon, Mar 9, 2015 at 5:58 PM, "Antonio J. Peña" <apenya(a)mcs.anl.gov> wrote: >> Hi Jeff, >> >> Please also report compiler, compiler version, and MPICH version. >> >> Best, >> Toni >> >> >> >> On 03/09/2015 07:53 PM, Jeff Hammond wrote: >>> I know some of you like warning-clean builds... >>> >>> ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:20:14: warning: >>> assigning to 'uint32_t *' (aka 'unsigned int *') from 'int *' >>> converts between pointers to integer types with different sign >>> [-Wpointer-sign] >>> bitarray = (int *) MPIU_Malloc(sizeof(int) * bitarray_size); >>> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:24:16: warning: >>> returning 'uint32_t *' (aka 'unsigned int *') from a function >>> with result type 'int *' converts between pointers to integer >>> types with different sign [-Wpointer-sign] >>> return bitarray; >>> ^~~~~~~~ >>> ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:46:12: warning: >>> returning 'uint32_t *' (aka 'unsigned int *') from a function >>> with result type 'int *' converts between pointers to integer >>> types with different sign [-Wpointer-sign] >>> return bitarray; >>> ^~~~~~~~ >>> ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:107:14: warning: >>> assigning to 'uint32_t *' (aka 'unsigned int *') from >>> 'int *' converts between pointers to integer types with >>> different sign [-Wpointer-sign] >>> bitarray = group_to_bitarray(local_fail, comm_ptr); >>> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> 4 warnings generated. >>> >>> Best, >>> >>> Jeff >>> >> >> -- >> Antonio J. Peña >> Postdoctoral Appointee >> Mathematics and Computer Science Division >> Argonne National Laboratory >> 9700 South Cass Avenue, Bldg. 240, Of. 3148 >> Argonne, IL 60439-4847 >> apenya(a)mcs.anl.gov >> www.mcs.anl.gov/~apenya >> >> _______________________________________________ >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/devel > > -- Antonio J. Peña Postdoctoral Appointee Mathematics and Computer Science Division Argonne National Laboratory 9700 South Cass Avenue, Bldg. 240, Of. 3148 Argonne, IL 60439-4847 apenya(a)mcs.anl.gov www.mcs.anl.gov/~apenya

1 0

Re: [mpich-devel] warning: returning 'uint32_t *' (aka 'unsigned int *') from a function with result type 'int *' converts between pointers to integer types with different sign
by Jeff Hammond 09 Mar '15

09 Mar '15

See below, but the propriety of this cast can be verified in source without a compiler :-) Jeff ## Local Branches: * master ## Most Recent Commit: commit 957ceec598103d8d643c9345512ae8ad4e88e993 Author: Ken Raffenetti <raffenet(a)mcs.anl.gov> testsuite: remove leading spaces in testlist files jrhammon-mac01:build jrhammon$ head config.log This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by MPICH configure 3.2b1, which was generated by GNU Autoconf 2.69. Invocation command line was $ ../configure CC=icc CXX=icpc FC=ifort F77=ifort --enable-fortran --enable-threads=runtime --enable-g=dbg --with-pm=hydra --prefix=/opt/mpich/dev/intel/default --enable-wrapper-rpath --enable-static --enable-shared jrhammon-mac01:build jrhammon$ icc --version icc (ICC) 15.0.1 20141022 Copyright (C) 1985-2014 Intel Corporation. All rights reserved. On Mon, Mar 9, 2015 at 5:58 PM, "Antonio J. Peña" <apenya(a)mcs.anl.gov> wrote: > > Hi Jeff, > > Please also report compiler, compiler version, and MPICH version. > > Best, > Toni > > > > On 03/09/2015 07:53 PM, Jeff Hammond wrote: >> >> I know some of you like warning-clean builds... >> >> ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:20:14: warning: >> assigning to 'uint32_t *' (aka 'unsigned int *') from 'int *' >> converts between pointers to integer types with different sign >> [-Wpointer-sign] >> bitarray = (int *) MPIU_Malloc(sizeof(int) * bitarray_size); >> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:24:16: warning: >> returning 'uint32_t *' (aka 'unsigned int *') from a function >> with result type 'int *' converts between pointers to integer >> types with different sign [-Wpointer-sign] >> return bitarray; >> ^~~~~~~~ >> ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:46:12: warning: >> returning 'uint32_t *' (aka 'unsigned int *') from a function >> with result type 'int *' converts between pointers to integer >> types with different sign [-Wpointer-sign] >> return bitarray; >> ^~~~~~~~ >> ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:107:14: warning: >> assigning to 'uint32_t *' (aka 'unsigned int *') from >> 'int *' converts between pointers to integer types with >> different sign [-Wpointer-sign] >> bitarray = group_to_bitarray(local_fail, comm_ptr); >> ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> 4 warnings generated. >> >> Best, >> >> Jeff >> > > > -- > Antonio J. Peña > Postdoctoral Appointee > Mathematics and Computer Science Division > Argonne National Laboratory > 9700 South Cass Avenue, Bldg. 240, Of. 3148 > Argonne, IL 60439-4847 > apenya(a)mcs.anl.gov > www.mcs.anl.gov/~apenya > > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpich-devel] warning: returning 'uint32_t *' (aka 'unsigned int *') from a function with result type 'int *' converts between pointers to integer types with different sign
by "Antonio J. Peña" 09 Mar '15

09 Mar '15

Hi Jeff, Please also report compiler, compiler version, and MPICH version. Best, Toni On 03/09/2015 07:53 PM, Jeff Hammond wrote: > I know some of you like warning-clean builds... > > ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:20:14: warning: > assigning to 'uint32_t *' (aka 'unsigned int *') from 'int *' > converts between pointers to integer types with different sign > [-Wpointer-sign] > bitarray = (int *) MPIU_Malloc(sizeof(int) * bitarray_size); > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:24:16: warning: > returning 'uint32_t *' (aka 'unsigned int *') from a function > with result type 'int *' converts between pointers to integer > types with different sign [-Wpointer-sign] > return bitarray; > ^~~~~~~~ > ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:46:12: warning: > returning 'uint32_t *' (aka 'unsigned int *') from a function > with result type 'int *' converts between pointers to integer > types with different sign [-Wpointer-sign] > return bitarray; > ^~~~~~~~ > ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:107:14: warning: > assigning to 'uint32_t *' (aka 'unsigned int *') from > 'int *' converts between pointers to integer types with > different sign [-Wpointer-sign] > bitarray = group_to_bitarray(local_fail, comm_ptr); > ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 4 warnings generated. > > Best, > > Jeff > -- Antonio J. Peña Postdoctoral Appointee Mathematics and Computer Science Division Argonne National Laboratory 9700 South Cass Avenue, Bldg. 240, Of. 3148 Argonne, IL 60439-4847 apenya(a)mcs.anl.gov www.mcs.anl.gov/~apenya

1 0

warning: returning 'uint32_t *' (aka 'unsigned int *') from a function with result type 'int *' converts between pointers to integer types with different sign
by Jeff Hammond 09 Mar '15

09 Mar '15

I know some of you like warning-clean builds... ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:20:14: warning: assigning to 'uint32_t *' (aka 'unsigned int *') from 'int *' converts between pointers to integer types with different sign [-Wpointer-sign] bitarray = (int *) MPIU_Malloc(sizeof(int) * bitarray_size); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:24:16: warning: returning 'uint32_t *' (aka 'unsigned int *') from a function with result type 'int *' converts between pointers to integer types with different sign [-Wpointer-sign] return bitarray; ^~~~~~~~ ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:46:12: warning: returning 'uint32_t *' (aka 'unsigned int *') from a function with result type 'int *' converts between pointers to integer types with different sign [-Wpointer-sign] return bitarray; ^~~~~~~~ ../src/mpid/ch3/src/mpid_comm_get_all_failed_procs.c:107:14: warning: assigning to 'uint32_t *' (aka 'unsigned int *') from 'int *' converts between pointers to integer types with different sign [-Wpointer-sign] bitarray = group_to_bitarray(local_fail, comm_ptr); ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 4 warnings generated. Best, Jeff -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0