- discuss - mailman3.cels.anl.gov

Fault tolerance after MPI_Comm_connect/accept
by Matthieu Dorier 04 Mar '13

04 Mar '13

Hi, I'm connecting two MPI applications A and B using MPI_Comm_accept in A and MPI_Comm_connect in B. I would like to know a bit more about the behavior in case one application stops (say B): will a communication attempt (e.g. MPI_Send) from a process from A to a process from B crash? return an error? block? Is there a way for application A to notice that B has stopped in order to avoid communicating with it? Thanks. PS: by the way for whom is involved in the MPI forum, an MPI_Comm_iaccept in the MPI3 standard would have been useful. Something to keep in mind for the next version maybe ;) Matthieu Dorier PhD student at ENS Cachan Brittany and IRISA http://people.irisa.fr/Matthieu.Dorier

1 0

Re: [mpich-discuss] MPICH2 -Problem
by hamideh jabalameli 03 Mar '13

03 Mar '13

On Tue, Feb 26, 2013 at 5:55 AM, Andrey V. Malyshev <amal(a)icm.krasn.ru>wrote: > Hello, hamideh! > You wrote to <discuss(a)mpich.org> on Tue, 26 Feb 2013 00:29:05 +0330: > > hj> Dear Andrey > hj> I checked this directory. there is correct. I use the following your > hj> ls -la /home/inet/src/applications/sct.. > hj> ls -la inet/src/applications/sctpapp/SCTPlikeAPI/include > > A V. M>>You have checked relative path, not absolute. > A V. M>>Check full path, beginning with '/', and pass it to configure. > Hello Thank you Andrey. first problem is solved and there is the related error. I typed directory correctly... :) But second problem.... > > ??>> 2) /usr/bin/ld: cannot find -lsctplike > ??>> > ??>> Have you correctly installed your SCTPlikeAPI? Add its 'lib' > directory > ??>> to ldconfig paths (/etc/ld.so.conf.d). This directory have to contain > ??>> the file (or softlink) libsctplike.so. Then run from root ldconfig > -v, > ??>> and try to configure again. > ??>> > hj> I do all of your suggestion.. > > A V. M>>Oh, no 8-) > I'm sorry... :) > A V. M>>Remove from /etc/ld.so.conf.d all libraries you have copied there, > and do > this: > > A V. M>>sudo echo > /home/my-ubuntu/inet/src/applications/sctpapp/SCTPlikeAPI/lib > > /etc/ld.so.conf.d/sctp.conf > I do it. conrrect path in sctp.conf: /home/my-ubuntu/inet/src/applications/sctpapp/SCTPlikeAPI/lib > > A V. M>>NB! It must be absolute (with beginning slash) correct path. > > A V. M>>Then sudo ldconfig -v and retry configure... > I do it but there is the fallowing ...: I send config file for you I hope to solve my problem.I need it... ../configure --with-device=ch3:sctp --with-sctp=/home/my-ubuntu/inet/src/applications/sctpapp/SCTPlikeAPI/include --prefix=/home/my-ubuntu/mpich2-hginit –disable-mpe configure: WARNING: you should use --build, --host, --target configure: WARNING: invalid host type: –disable-mpe Configuring MPICH2 version 1.0.8rc1 with '--with-device=ch3:sctp' '--with-sctp=/home/my-ubuntu/inet/src/applications/sctpapp/SCTPlikeAPI/include' '--prefix=/home/my-ubuntu/mpich2-hginit' '–disable-mpe' 'build_alias=–disable-mpe' 'host_alias=–disable-mpe' 'target_alias=–disable-mpe' Running on system: Linux myubuntu-VPCCW21FX 3.2.0-38-generic-pae #61-Ubuntu SMP Tue Feb 19 12:39:51 UTC 2013 i686 i686 i386 GNU/Linux Executing mpich2prereq in /home/my-ubuntu/mpich2-hginit/src/mpid/ch3 with sctp Executing mpich2prereq in /home/my-ubuntu/mpich2-hginit/src/mpid/ch3/channels/sctp sourcing /home/my-ubuntu/mpich2-hginit/src/pm/mpd/mpich2prereq sourcing /home/my-ubuntu/mpich2-hginit/src/pm/mpd/setup_pm checking for –disable-mpe-gcc... no checking for gcc... gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether C compiler accepts option -O2... yes checking whether routines compiled with -O2 can be linked with ones compiled without -O2... yes checking for type of weak symbol support... pragma weak checking whether __attribute__ ((weak)) allowed... yes checking for multiple weak symbol support... yes checking for –disable-mpe-g77... no checking for –disable-mpe-xlf... no checking for –disable-mpe-f77... no checking for –disable-mpe-frt... no checking for –disable-mpe-pgf77... no checking for –disable-mpe-cf77... no checking for –disable-mpe-fort77... no checking for –disable-mpe-fl32... no checking for –disable-mpe-af77... no checking for –disable-mpe-xlf90... no checking for –disable-mpe-f90... no checking for –disable-mpe-pgf90... no checking for –disable-mpe-pghpf... no checking for –disable-mpe-epcf90... no checking for –disable-mpe-gfortran... no checking for –disable-mpe-g95... no checking for –disable-mpe-xlf95... no checking for –disable-mpe-f95... no checking for –disable-mpe-fort... no checking for –disable-mpe-ifort... no checking for –disable-mpe-ifc... no checking for –disable-mpe-efc... no checking for –disable-mpe-pgf95... no checking for –disable-mpe-lf95... no checking for –disable-mpe-ftn... no checking for g77... no checking for xlf... no checking for f77... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for xlf90... no checking for f90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... no checking for g95... no checking for xlf95... no checking for f95... no checking for fort... no checking for ifort... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for ftn... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking for c++... c++ checking whether we are using the GNU C++ compiler... yes checking whether c++ accepts -g... yes checking whether the C++ compiler c++ can build an executable... yes checking whether C++ compiler works with string... yes checking whether the compiler supports exceptions... yes checking whether the compiler recognizes bool as a built-in type... yes checking whether the compiler implements namespaces... yes checking whether <iostream> available... yes checking whether the compiler implements the namespace std... yes checking whether <math> available... no checking for GNU g++ version... 4 . 6 checking whether C++ compiler accepts option -O2... yes checking whether routines compiled with -O2 can be linked with ones compiled without -O2... yes checking for perl... /usr/bin/perl checking for ar... ar checking for ranlib... ranlib checking for etags... etags checking for etags argument to specify language... --language=c checking for killall... killall checking for a BSD-compatible install... /usr/bin/install -c checking whether install works... yes checking for –disable-mpe-ranlib... (cached) ranlib checking whether install breaks libraries... no checking whether mkdir -p works... yes checking for make... make checking whether clock skew breaks make... no checking whether make supports include... yes checking whether make allows comments in actions... yes checking for virtual path format... VPATH checking whether make sets CFLAGS... no checking for bash... /bin/bash checking whether /bin/bash supports arrays... yes checking for doctext... false checking for location of doctext style files... unavailable checking for an ANSI C-conforming const... yes checking for volatile... yes checking for restrict... __restrict checking for inline... inline checking whether __attribute__ allowed... yes checking whether __attribute__((format)) allowed... yes checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... no checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking whether byte ordering is bigendian... no checking whether C compiler allows unaligned doubles... yes checking whether gcc supports __func__... yes Using gcc to determine dependencies checking whether long double is supported... yes checking whether long long is supported... yes checking for max C struct integer alignment... four checking for max C struct floating point alignment... four checking for max C struct alignment of structs with doubles... four checking for max C struct floating point alignment with long doubles... four checking if alignment of structs with doubles is based on position... no checking if alignment of structs with long long ints is based on position... no checking if double alignment breaks rules, find actual alignment... no checking for alignment restrictions on pointers... int or better checking size of char... 1 checking size of unsigned char... 1 checking size of short... 2 checking size of unsigned short... 2 checking size of int... 4 checking size of unsigned int... 4 checking size of long... 4 checking size of unsigned long... 4 checking size of long long... 8 checking size of unsigned long long... 8 checking size of float... 4 checking size of double... 8 checking size of long double... 12 checking size of wchar_t... 4 checking size of void *... 4 checking for size of float int... 8 checking for size of double int... 12 checking for size of long int... 8 checking for size of short int... 6 checking for size of 2 int... 8 checking for size of long double int... 16 checking for sys/bitypes.h... yes checking for inttypes.h... (cached) yes checking for int8_t... yes checking for int16_t... yes checking for int32_t... yes checking for int64_t... yes checking for uint8_t... yes checking for uint16_t... yes checking for uint32_t... yes checking for uint64_t... yes checking size of bool... 1 checking how to run the C++ preprocessor... c++ -E checking for complex... yes checking size of Complex... 8 checking size of DoubleComplex... 16 checking size of LongDoubleComplex... 24 checking if char * pointers use byte addresses... yes checking for alignment restrictions on ... no checking for alignment restrictions on int32_t... no checking for size of MPI_BSEND_OVERHEAD... 59 checking for gcc __asm__ and pentium cmpxchgl instruction... yes checking for gcc __asm__ and AMD x86_64 cmpxchgq instruction... no checking for gcc __asm__ and IA64 xchg4 instruction... no checking for ANSI C header files... (cached) no checking for stdlib.h... (cached) yes checking for stdarg.h... yes checking for sys/types.h... (cached) yes checking for inttypes.h... (cached) yes checking for limits.h... yes checking for stddef.h... yes checking for errno.h... yes checking for sys/socket.h... yes checking for sys/time.h... yes checking for unistd.h... (cached) yes checking for endian.h... yes checking for assert.h... yes checking for sys/uio.h... yes checking for size_t... yes checking for setitimer... yes checking for alarm... yes checking for vsnprintf... yes checking for vsprintf... yes checking whether vsnprintf needs a declaration... no checking for strerror... yes checking for snprintf... yes checking whether snprintf needs a declaration... no checking for va_copy... yes checking for working alloca.h... yes checking for alloca... yes checking for strdup... yes checking whether strdup needs a declaration... no checking for clock_gettime... no checking for clock_getres... no checking for gethrtime... no checking for gettimeofday... yes sourcing /home/my-ubuntu/mpich2-hginit/src/mpid/ch3/setup_device RUNNING SETUP_DEVICE FOR THE CH3 DEVICE sourcing /home/my-ubuntu/mpich2-hginit/src/mpid/ch3/channels/sctp/setup_channel RUNNING SETUP_CHANNEL FOR THE SCTP CHANNEL checking for pthread.h... yes checking for pthread_yield... no checking for library containing pthread_key_create... no configure: error: unable to find pthreads library > > hj> sudo su > hj> cp /home/my-ubuntu/inet/src/applications/sctpapp/SCTPlikeAPI/lib > hj> /etc/ld.so.conf.d > hj> ldconfig -v > > hj> but after configure again, the config.log was the same previous with > hj> this problem! I attached it to this email > > hj> Please help me again... :( > hj> Excuse me... > > hj>>> On Sun, Feb 24, 2013 at 12:22 PM, Andrey V. Malyshev > hj>>> <amal(a)icm.krasn.ru>wrote: > ??>> > ??>>>> Hello, hamideh! > ??>>>> You wrote to <discuss(a)mpich.org> on Sun, 24 Feb 2013 10:12:01 > +0330: > ??>>>> > hj>>>>> I think configure doesn't done correctly! > ??>>>> > ??>>>> That's right. > ??>>>> > hj>>>>> configure command is : > hj>>>>> ../configure --with-device=ch3:sctp > hj>>>>> --with-sctp=/home/inet/src/applications/sctpapp/SCTPlikeAPI > hj>>>>> --prefix=/home/mpich2-hginit –disable-mpe > hj>>>>> What I am doing? :( > ??>>>> > ??>>>> See the file 'config.log' from the same directory where the > ??>>>> 'configure' was started, or where the 'configure' file is > ??>>>> located. Pthread library was not found, you should understand, why, > ??>>>> and maybe then it becomes clear how to fix. > ??>>>> > hj>>>>> On Sun, Feb 24, 2013 at 10:07 AM, Andrey V. Malyshev > hj>>>>> <amal(a)icm.krasn.ru>wrote: > ??>>>> > ??>>>>>> Hello, hamideh! > ??>>>>>> You wrote to <discuss(a)mpich.org> on Sun, 24 Feb 2013 08:23:37 > ??>> +0330: > ??>>>>>> > hj>>>>>>> checking for pthread.h... yes > ??>>>>>> checking for pthread_yield... no > ??>>>>>> checking for library containing pthread_key_create... no > ??>>>>>> configure: error: unable to find pthreads library > ??>>>>>> > ??>>>>>> See config.log, what error occurs during this check? > ??>>>>>> > ??>>>>>> -- > ??>>>>>> With best regards, Andrey V. Malyshev. > ??>>>>>> E-mail: amal(a)krasn.ru > ??>>>>>> _______________________________________________ > ??>>>>>> discuss mailing list discuss(a)mpich.org > ??>>>>>> To manage subscription options or unsubscribe: > ??>>>>>> https://lists.mpich.org/mailman/listinfo/discuss > ??>>>>>> > hj>>>>> -- > hj>>>>> *Best Regards* > hj>>>>> * > ??>>>> > hj>>>>> Hamideh Jabalameli* > ??>>>> > hj>>>>> M.Sc Candidate, > hj>>>>> School of Electrical and Computer Engineering, > hj>>>>> College of Engineering, > hj>>>>> Electronici Shahid Beheshti Tehran University > hj>>>>> h.jabal(a)Mail.sbu.ac.ir > hj>>>>> hamideh.jabalameli(a)gmail.com > ??>>>> > ??>>>> -- > ??>>>> With best regards, Andrey V. Malyshev. > ??>>>> E-mail: amal(a)krasn.ru > ??>>>> > ??>>>> _______________________________________________ > ??>>>> discuss mailing list discuss(a)mpich.org > ??>>>> To manage subscription options or unsubscribe: > ??>>>> https://lists.mpich.org/mailman/listinfo/discuss > ??>>>> > hj>>> -- > hj>>> *Best Regards* > hj>>> * > ??>> > hj>>> Hamideh Jabalameli* > ??>> > hj>>> M.Sc Candidate, > hj>>> School of Electrical and Computer Engineering, > hj>>> College of Engineering, > hj>>> Electronici Shahid Beheshti Tehran University > hj>>> h.jabal(a)Mail.sbu.ac.ir > hj>>> hamideh.jabalameli(a)gmail.com > ??>> > ??>> -- > ??>> With best regards, Andrey V. Malyshev. > ??>> E-mail: amal(a)krasn.ru > ??>> > ??>> _______________________________________________ > ??>> discuss mailing list discuss(a)mpich.org > ??>> To manage subscription options or unsubscribe: > ??>> https://lists.mpich.org/mailman/listinfo/discuss > ??>> > hj> -- > hj> *Best Regards* > hj> * > > hj> Hamideh Jabalameli* > > hj> M.Sc Candidate, > hj> School of Electrical and Computer Engineering, > hj> College of Engineering, > hj> Electronici Shahid Beheshti Tehran University > hj> h.jabal(a)Mail.sbu.ac.ir > hj> hamideh.jabalameli(a)gmail.com > > -- > With best regards, Andrey V. Malyshev. > E-mail: amal(a)krasn.ru > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > -- *Best Regards* * Hamideh Jabalameli* M.Sc Candidate, School of Electrical and Computer Engineering, College of Engineering, Electronici Shahid Beheshti Tehran University h.jabal(a)Mail.sbu.ac.ir hamideh.jabalameli(a)gmail.com

1 0

Re: [mpich-discuss] using mpi.h with C++ and warnings that result (ultra-pedantic)
by Jeff Hammond 02 Mar '13

02 Mar '13

>>> If you actually had a compiler that would give an _error_ when "long long" was used in C++, then we could skip checking "long long" in that case. So maybe "-Werror=long-long"? >>> >>> This really is a waste of everyone's time. Just add "-Wno-long-long" and move on to a real problem. >> >> Sure, but it still surprises me that MPI_Count requires a C99 type >> when at least one member of the MPICH team is quite strict about the >> need for MPICH to use only C89 features in order to work with the >> Microsoft C compiler. > > MPI_Count does not require C99 types in all cases. It just uses them when the *C* compiler used to build MPICH supports "long long" and the device does not set MPID_NO_LONG_LONG=yes in its "_PREREQ_" m4 macros in subconfigure.m4. The issue is that none of the code is testing whether the C++ compiler supports "long long". It's just not worth actually doing it, since they all support it unless you go out of your way to disable that support with "-Werror=long-long". Thanks for the clarification. Makes sense to me. Jeff -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0

Re: [mpich-discuss] using mpi.h with C++ and warnings that result (ultra-pedantic)
by Dave Goodell 02 Mar '13

02 Mar '13

On Mar 2, 2013, at 11:57 AM CST, Jeff Hammond wrote: >> If you actually had a compiler that would give an _error_ when "long long" was used in C++, then we could skip checking "long long" in that case. So maybe "-Werror=long-long"? >> >> This really is a waste of everyone's time. Just add "-Wno-long-long" and move on to a real problem. > > Sure, but it still surprises me that MPI_Count requires a C99 type > when at least one member of the MPICH team is quite strict about the > need for MPICH to use only C89 features in order to work with the > Microsoft C compiler. MPI_Count does not require C99 types in all cases. It just uses them when the *C* compiler used to build MPICH supports "long long" and the device does not set MPID_NO_LONG_LONG=yes in its "_PREREQ_" m4 macros in subconfigure.m4. The issue is that none of the code is testing whether the C++ compiler supports "long long". It's just not worth actually doing it, since they all support it unless you go out of your way to disable that support with "-Werror=long-long". -Dave

1 0

Re: [mpich-discuss] using mpi.h with C++ and warnings that result (ultra-pedantic)
by Jeff Hammond 02 Mar '13

02 Mar '13

>> Is there a configure option that will cause MPICH to "typedef long >> MPI_Count" instead? > > No, not without someone writing some new configure logic. The ROMIO code that picks this value starts searching at the largest integer type it expects it might find ("long long") and goes down the list of types in decreasing integer rank until it finds one that works. It doesn't look for the type with the smallest integer rank which still yields 8 bytes or anything like that, which is sort of what you are implying would be preferable behavior. > > If you actually had a compiler that would give an _error_ when "long long" was used in C++, then we could skip checking "long long" in that case. So maybe "-Werror=long-long"? > > This really is a waste of everyone's time. Just add "-Wno-long-long" and move on to a real problem. Sure, but it still surprises me that MPI_Count requires a C99 type when at least one member of the MPICH team is quite strict about the need for MPICH to use only C89 features in order to work with the Microsoft C compiler. Jeff -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0

Re: [mpich-discuss] using mpi.h with C++ and warnings that result (ultra-pedantic)
by Dave Goodell 02 Mar '13

02 Mar '13

On Mar 2, 2013, at 8:28 AM CST, Jeff Hammond wrote: > Is there a configure option that will cause MPICH to "typedef long > MPI_Count" instead? No, not without someone writing some new configure logic. The ROMIO code that picks this value starts searching at the largest integer type it expects it might find ("long long") and goes down the list of types in decreasing integer rank until it finds one that works. It doesn't look for the type with the smallest integer rank which still yields 8 bytes or anything like that, which is sort of what you are implying would be preferable behavior. If you actually had a compiler that would give an _error_ when "long long" was used in C++, then we could skip checking "long long" in that case. So maybe "-Werror=long-long"? This really is a waste of everyone's time. Just add "-Wno-long-long" and move on to a real problem. -Dave

1 0

Re: [mpich-discuss] using mpi.h with C++ and warnings that result (ultra-pedantic)
by Jed Brown 02 Mar '13

02 Mar '13

On Sat, Mar 2, 2013 at 9:28 AM, Jeff Hammond <jhammond(a)alcf.anl.gov> wrote: > I compile apps with -pedantic when I want to be absolutely certainly > that a non-standard language usage is causing an error. > That is not what -pedantic means on any compiler that I'm aware of. It is stricter, but far from an assertion that the code is complaint.

1 0

Re: [mpich-discuss] using mpi.h with C++ and warnings that result (ultra-pedantic)
by Jeff Hammond 02 Mar '13

02 Mar '13

On Sat, Mar 2, 2013 at 6:29 AM, Dmitri Gribenko <gribozavr(a)gmail.com> wrote: > On Sat, Mar 2, 2013 at 6:51 AM, Dave Goodell <goodell(a)mcs.anl.gov> wrote: >> On Mar 1, 2013, at 9:57 PM CST, Jeff Hammond wrote: >> >>> I apologize in advance for being ultra-pedantic. >>> >>> I am using MPI in a purely C++ code. Is there a way to make this >>> warning go away? I know at least one MPICH developer who shares my >>> disdain for compiler warnings, so I hope this isn't too unreasonable. >>> >>> Since I am using a C++ compiler, I can't exactly tell it to use C99 mode. >>> >>> /Users/jhammond/eclipse/MPICH2/trunk/install-clang/include/mpi.h:526:9: >>> warning: 'long long' is an extension when C99 mode is not enabled >>> [-pedantic,-Wlong-long] >>> typedef long long MPI_Count; >> >> Don't compile with -pedantic. It's almost never a useful flag. Alternatively, add "-Wno-long-long" if you need other windmills to tilt at. > > I would argue that -pedantic is, in fact, a useful flag. For example, > LLVM and Clang are compiled with -pedantic, but we also add > -Wno-long-long (and a few other flags) to disable warnings about > extensions that are implemented virtually in every compiler. And, > LLVM and Clang have *zero* warnings when compiled with itself. Is there a configure option that will cause MPICH to "typedef long MPI_Count" instead? I compile apps with -pedantic when I want to be absolutely certainly that a non-standard language usage is causing an error. I know MPICH isn't the issue here but that doesn't mean that I don't aspire to compile apps without any warnings. Jeff -- Jeff Hammond Argonne Leadership Computing Facility University of Chicago Computation Institute jhammond(a)alcf.anl.gov / (630) 252-5381 http://www.linkedin.com/in/jeffhammond https://wiki.alcf.anl.gov/parts/index.php/User:Jhammond

1 0

Re: [mpich-discuss] using mpi.h with C++ and warnings that result (ultra-pedantic)
by Dmitri Gribenko 02 Mar '13

02 Mar '13

On Sat, Mar 2, 2013 at 6:51 AM, Dave Goodell <goodell(a)mcs.anl.gov> wrote: > On Mar 1, 2013, at 9:57 PM CST, Jeff Hammond wrote: > >> I apologize in advance for being ultra-pedantic. >> >> I am using MPI in a purely C++ code. Is there a way to make this >> warning go away? I know at least one MPICH developer who shares my >> disdain for compiler warnings, so I hope this isn't too unreasonable. >> >> Since I am using a C++ compiler, I can't exactly tell it to use C99 mode. >> >> /Users/jhammond/eclipse/MPICH2/trunk/install-clang/include/mpi.h:526:9: >> warning: 'long long' is an extension when C99 mode is not enabled >> [-pedantic,-Wlong-long] >> typedef long long MPI_Count; > > Don't compile with -pedantic. It's almost never a useful flag. Alternatively, add "-Wno-long-long" if you need other windmills to tilt at. I would argue that -pedantic is, in fact, a useful flag. For example, LLVM and Clang are compiled with -pedantic, but we also add -Wno-long-long (and a few other flags) to disable warnings about extensions that are implemented virtually in every compiler. And, LLVM and Clang have *zero* warnings when compiled with itself. Dmitri -- main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if (j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr(a)gmail.com>*/

1 0

Re: [mpich-discuss] using mpi.h with C++ and warnings that result (ultra-pedantic)
by Dave Goodell 01 Mar '13

01 Mar '13

On Mar 1, 2013, at 9:57 PM CST, Jeff Hammond wrote: > I apologize in advance for being ultra-pedantic. > > I am using MPI in a purely C++ code. Is there a way to make this > warning go away? I know at least one MPICH developer who shares my > disdain for compiler warnings, so I hope this isn't too unreasonable. > > Since I am using a C++ compiler, I can't exactly tell it to use C99 mode. > > /Users/jhammond/eclipse/MPICH2/trunk/install-clang/include/mpi.h:526:9: > warning: 'long long' is an extension when C99 mode is not enabled > [-pedantic,-Wlong-long] > typedef long long MPI_Count; Don't compile with -pedantic. It's almost never a useful flag. Alternatively, add "-Wno-long-long" if you need other windmills to tilt at. -Dave

1 0