- devel - mailman3.cels.anl.gov

Should MPI_{Comm|Win|File}_Set_info(..., MPI_INFO_NULL) fail ?
by Lisandro Dalcin 09 Apr '14

09 Apr '14

Right now, it success for Comm but fails for Win and File. IMHO, all should success, this should be a way for users to ask the implementation "please, reset the info hints to whatever the defaults are". If you decide they should fail, then the Comm case needs a fix to generate an error. $ mpicc comm_set_info.c $ ./a.out $ mpicc win_set_info.c $ ./a.out Fatal error in MPI_Win_set_info: Invalid argument, error stack: MPI_Win_set_info(126): MPI_Win_set_info(win=win=0xa0000000, info=MPI_INFO_NULL) failed MPI_Win_set_info(82).: Null MPI_Info $ mpicc file_set_info.c $ ./a.out Fatal error in PMPI_Info_dup: Invalid argument, error stack: PMPI_Info_dup(149): MPI_Info_dup(MPI_INFO_NULL, newinfo=0x7fff58b899c4) failed PMPI_Info_dup(108): Null MPI_Info PS: Perhaps you have an easy fix for the error message (PMPI -> MPI) in the last one? -- Lisandro Dalcin --------------- CIMEC (UNL/CONICET) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1016) Tel/Fax: +54-342-4511169

1 0

Default print name for MPI-3 C++ datatypes
by Lisandro Dalcin 09 Apr '14

09 Apr '14

Please review the following trivial patch (also attached), diff --git a/src/mpi/datatype/type_get_name.c b/src/mpi/datatype/type_get_name.c index 07c2f84..e550dfb 100644 --- a/src/mpi/datatype/type_get_name.c +++ b/src/mpi/datatype/type_get_name.c @@ -108,6 +108,12 @@ static mpi_names_t mpi_names[] = { type_name_entry(MPI_C_DOUBLE_COMPLEX), type_name_entry(MPI_C_LONG_DOUBLE_COMPLEX), + /* C++ types */ + type_name_entry(MPI_CXX_BOOL), + type_name_entry(MPI_CXX_FLOAT_COMPLEX), + type_name_entry(MPI_CXX_DOUBLE_COMPLEX), + type_name_entry(MPI_CXX_LONG_DOUBLE_COMPLEX), + /* address/offset types */ type_name_entry(MPI_AINT), type_name_entry(MPI_OFFSET), -- Lisandro Dalcin --------------- CIMEC (UNL/CONICET) Predio CONICET-Santa Fe Colectora RN 168 Km 472, Paraje El Pozo 3000 Santa Fe, Argentina Tel: +54-342-4511594 (ext 1016) Tel/Fax: +54-342-4511169

1 0

Re: [mpich-devel] romio questions
by Balaji, Pavan 04 Apr '14

04 Apr '14

Every time the MPICH stack is “stuck” in the progress engine (i.e., nothing happened for some time), it’ll release the lock so other threads can grab it. So unless File_write_all is blocking on a file-system operation, other threads should be able to make progress just fine. — Pavan On Apr 4, 2014, at 4:34 PM, Rob Latham <robl(a)mcs.anl.gov> wrote: > This is getting out of my depth. MPICH guys: Mark Allen is updating Platform's MPI and has been asking me some questions about multi-threaded ROMIO. > > The independent ROMIO routines might make some local MPI calls to process the data type, but otherwise, yes, the only blocking call would be the file system operation. > > I haven't thought about what would happen if MPI_File_write_all was called from two threads. > > MPICH guys: there's no way the CS_ENTER/EXIT macros can be that clever, right? > > ==rob > > On 04/04/2014 04:28 PM, Mark Allen wrote: >> Thanks. I looked a bit at the CS_ENTER/EXIT code. Am I right that all >> the non-collective MPIO calls like MPI_File_read etc are only blocking >> in the sense of waiting on some local operation to complete? If that's >> the case it would be okay for them to hold a lock from beginning to end >> of the call like that. But for the collective MPIO operations I don't >> think you could just hold the lock for the entire function call since >> you might end up waiting for remote peers to arrive, and if two >> collectives were taking place at the same time they could mismatch and >> deadlock. But I'm not sure if that's what the code is doing or not. Is >> there a release of the lock hidden somewhere when collectives block? If >> inside the MPI_Allgather for example MPI performed a release and regain >> of the MPIO lock is the blocking MPIO collective holding any shared >> resource that would get corrupted by letting other threads in at that point? >> >> Fwiw I also noticed mpi-io/ioreq_f2c.c looks to be a case where an early >> return runs the risk of a mismatched CS_ENTER w/o a corresponding >> CS_EXIT. It looks like all the other files used goto fn_exit to ensure >> a match. > > >> >> Mark >> >> >> Inactive hide details for Rob Latham ---04/04/2014 09:49:00 AM---On >> 04/04/2014 01:22 AM, Paul Coffman wrote: > ----- Forwarded Rob Latham >> ---04/04/2014 09:49:00 AM---On 04/04/2014 01:22 AM, Paul Coffman wrote: >> > ----- Forwarded by Paul Coffman/Rochester/IBM on 04/04 >> >> From: Rob Latham <robl(a)mcs.anl.gov> >> To: Paul Coffman/Rochester/IBM@IBMUS >> Cc: Mark Allen/Dallas/IBM@IBMUS >> Date: 04/04/2014 09:49 AM >> Subject: Re: Fw: romio questions >> >> ------------------------------------------------------------------------ >> >> >> >> >> >> On 04/04/2014 01:22 AM, Paul Coffman wrote: >> >> > ----- Forwarded by Paul Coffman/Rochester/IBM on 04/04/2014 01:22 AM >> ----- >> > >> > From: Mark Allen/Dallas/IBM >> > To: Paul Coffman/Rochester/IBM@IBMUS, >> > Date: 04/04/2014 01:07 AM >> > Subject: romio questions >> > ------------------------------------------------------------------------ >> > >> > >> > I have two questions/topics for you: >> > >> > First I wanted to ask do you happen to know if romio is thread safe? I >> > see a fair number of critical-section begin/end macros and am guessing >> > it is, but thought I'd ask anyway. >> >> the internal romio routines (things in the ADIO and ADIOI namespace) >> rely on several bits of global state -- the flattened representation of >> the file and memory datatype come to mind first, but there are probably >> others. The critical section macros are at the MPI-IO interface to >> romio and should provide a "big lock" to the rest. >> >> I haven't tried this though. I would be a little nervous about it >> working without a few patches. >> >> > Second, I noticed romio uses an extension of generalized requests >> > described here: >> > >> http://www.cs.illinois.edu/~wgropp/bib/papers/2007/latham_grequest-enhance-… >> > >> > but the code looks confused on whether the proposed wait_fn callback is >> > waiting for a single request or all the requests. >> > >> > In romio's definitions of >> > ADIOI_PVFS2_aio_wait_fn >> > ADIOI_GEN_aio_wait_fn >> > the wait_fn looks to me very much like it's waiting for all the reqs, vs >> > the NTFS function that looks like it's waiting on some >> > ADIOI_NTFS_aio_wait_fn >> >> the intent for the extended wait_fn was indeed to wait for all >> outstanding generalized requests. Specifically, to call aio_suspend on >> more than one operation at a time. >> >> I would not read too much into NTFS_aio_wait_fn. that work was done >> quickly for the paper and then set aside. >> >> > And where these wait_fn callbacks get used, MPI_Waitsome uses >> > MPIR_Grequest_progress_poke which conditionally calls wait_fn. It seems >> > to me this would make MPI_Waitsome erroneously block until all its >> > generalized requests finish (the code in MPIR_Grequest_progress_poke >> > looks like it believes the wait_fn is supposed to just complete one >> > request). >> >> It has been some years since I looked at the waitsome/extended-grequest >> interaction, but it does sound like I could have implemented it better... >> >> > Is this an area you've worked with any or something we need to worry >> > about? The reason I was looking at it was in order to pull in the new >> > romio I figured I'd just add MPICH's concept of extended generalized >> > requests into our MPI, so I wanted to make sure I understood how they >> > were intended to work in mpich and I think it's pretty muddled there >> > unless I'm reading it wrong. >> >> You would be the first developers besides me to look closely at our >> extended generalized request proposal. It's no surprise to me it's >> muddled, since it hasn't had a lot of attention over the years. >> >> at various points in the last 6 years MPICH developers have modified the >> implementation of generalized requests to keep the common code paths >> speedy. That might explain some murkiness or things like 'waitsome' >> actually waiting for everything. >> >> ==rob >> >> -- >> Rob Latham >> Mathematics and Computer Science Division >> Argonne National Lab, IL USA >> >> > > -- > Rob Latham > Mathematics and Computer Science Division > Argonne National Lab, IL USA

1 0

Re: [mpich-devel] Fw: romio questions
by Rob Latham 04 Apr '14

04 Apr '14

This is getting out of my depth. MPICH guys: Mark Allen is updating Platform's MPI and has been asking me some questions about multi-threaded ROMIO. The independent ROMIO routines might make some local MPI calls to process the data type, but otherwise, yes, the only blocking call would be the file system operation. I haven't thought about what would happen if MPI_File_write_all was called from two threads. MPICH guys: there's no way the CS_ENTER/EXIT macros can be that clever, right? ==rob On 04/04/2014 04:28 PM, Mark Allen wrote: > Thanks. I looked a bit at the CS_ENTER/EXIT code. Am I right that all > the non-collective MPIO calls like MPI_File_read etc are only blocking > in the sense of waiting on some local operation to complete? If that's > the case it would be okay for them to hold a lock from beginning to end > of the call like that. But for the collective MPIO operations I don't > think you could just hold the lock for the entire function call since > you might end up waiting for remote peers to arrive, and if two > collectives were taking place at the same time they could mismatch and > deadlock. But I'm not sure if that's what the code is doing or not. Is > there a release of the lock hidden somewhere when collectives block? If > inside the MPI_Allgather for example MPI performed a release and regain > of the MPIO lock is the blocking MPIO collective holding any shared > resource that would get corrupted by letting other threads in at that point? > > Fwiw I also noticed mpi-io/ioreq_f2c.c looks to be a case where an early > return runs the risk of a mismatched CS_ENTER w/o a corresponding > CS_EXIT. It looks like all the other files used goto fn_exit to ensure > a match. > > Mark > > > Inactive hide details for Rob Latham ---04/04/2014 09:49:00 AM---On > 04/04/2014 01:22 AM, Paul Coffman wrote: > ----- Forwarded Rob Latham > ---04/04/2014 09:49:00 AM---On 04/04/2014 01:22 AM, Paul Coffman wrote: > > ----- Forwarded by Paul Coffman/Rochester/IBM on 04/04 > > From: Rob Latham <robl(a)mcs.anl.gov> > To: Paul Coffman/Rochester/IBM@IBMUS > Cc: Mark Allen/Dallas/IBM@IBMUS > Date: 04/04/2014 09:49 AM > Subject: Re: Fw: romio questions > > ------------------------------------------------------------------------ > > > > > > On 04/04/2014 01:22 AM, Paul Coffman wrote: > > > ----- Forwarded by Paul Coffman/Rochester/IBM on 04/04/2014 01:22 AM > ----- > > > > From: Mark Allen/Dallas/IBM > > To: Paul Coffman/Rochester/IBM@IBMUS, > > Date: 04/04/2014 01:07 AM > > Subject: romio questions > > ------------------------------------------------------------------------ > > > > > > I have two questions/topics for you: > > > > First I wanted to ask do you happen to know if romio is thread safe? I > > see a fair number of critical-section begin/end macros and am guessing > > it is, but thought I'd ask anyway. > > the internal romio routines (things in the ADIO and ADIOI namespace) > rely on several bits of global state -- the flattened representation of > the file and memory datatype come to mind first, but there are probably > others. The critical section macros are at the MPI-IO interface to > romio and should provide a "big lock" to the rest. > > I haven't tried this though. I would be a little nervous about it > working without a few patches. > > > Second, I noticed romio uses an extension of generalized requests > > described here: > > > http://www.cs.illinois.edu/~wgropp/bib/papers/2007/latham_grequest-enhance-… > > > > but the code looks confused on whether the proposed wait_fn callback is > > waiting for a single request or all the requests. > > > > In romio's definitions of > > ADIOI_PVFS2_aio_wait_fn > > ADIOI_GEN_aio_wait_fn > > the wait_fn looks to me very much like it's waiting for all the reqs, vs > > the NTFS function that looks like it's waiting on some > > ADIOI_NTFS_aio_wait_fn > > the intent for the extended wait_fn was indeed to wait for all > outstanding generalized requests. Specifically, to call aio_suspend on > more than one operation at a time. > > I would not read too much into NTFS_aio_wait_fn. that work was done > quickly for the paper and then set aside. > > > And where these wait_fn callbacks get used, MPI_Waitsome uses > > MPIR_Grequest_progress_poke which conditionally calls wait_fn. It seems > > to me this would make MPI_Waitsome erroneously block until all its > > generalized requests finish (the code in MPIR_Grequest_progress_poke > > looks like it believes the wait_fn is supposed to just complete one > > request). > > It has been some years since I looked at the waitsome/extended-grequest > interaction, but it does sound like I could have implemented it better... > > > Is this an area you've worked with any or something we need to worry > > about? The reason I was looking at it was in order to pull in the new > > romio I figured I'd just add MPICH's concept of extended generalized > > requests into our MPI, so I wanted to make sure I understood how they > > were intended to work in mpich and I think it's pretty muddled there > > unless I'm reading it wrong. > > You would be the first developers besides me to look closely at our > extended generalized request proposal. It's no surprise to me it's > muddled, since it hasn't had a lot of attention over the years. > > at various points in the last 6 years MPICH developers have modified the > implementation of generalized requests to keep the common code paths > speedy. That might explain some murkiness or things like 'waitsome' > actually waiting for everything. > > ==rob > > -- > Rob Latham > Mathematics and Computer Science Division > Argonne National Lab, IL USA > > -- Rob Latham Mathematics and Computer Science Division Argonne National Lab, IL USA

1 0

Re: [mpich-devel] Mpich-3.1 (mpiexec)
by Lu, Huiwei 04 Mar '14

04 Mar '14

Hi, Prasenna, Due to lack of developer resources, MPICH no longer supports the Windows platform. Please refer to our FAQ for more information: http://wiki.mpich.org/mpich/index.php/Frequently_Asked_Questions#Q:_Why_can… We recommend you use Microsoft MPI, which can be found here: http://msdn.microsoft.com/en-us/library/bb524831(v=vs.85).aspx If you really want to use mpich-3.1 features, I am afraid you have to run MPICH on Unix systems. p.s. FYI, the mailing list for user discussion is discuss(a)mpich.org. devel(a)mpich.org is for developing discussions. — Huiwei Lu Postdoc Appointee Mathematics and Computer Science Division, Argonne National Laboratory http://www.mcs.anl.gov/~huiweilu/ On Mar 4, 2014, at 5:15 AM, Prasenna Kannan <prasenna.kannan(a)aaarinc.com> wrote: > Team, > > We are using the below mentioned binary version of the product in our environment. We have installed the executable in our servers and we are using mpiexec command tool for parallel processing. > > Platform > Author > Download > Base MPICH Version > Windows > Jayesh Krishna > [x86] > 1.4.1p1 > [x86_64] > 1.4.1p1 > > Now, I saw an update in the MPICH2 website that, a latest version is released as below. I went through the enhancements carried out, and found that there are considerable enhancements tailored for core processor parallel processing, for which we would like to have an executable to install, but I could not find the executable in the downloaded documents. Please, let me know if we have any executable for the latest release. > > Release > Platform > Download > Size > mpich-3.1 (stable release) > MPICH > [http] > 11 MB > hydra-3.1 (stable release) > Hydra (mpiexec) > [http] > 3 MB > > > Regards, > Prasenna

1 0

Mpich-3.1 (mpiexec)
by Prasenna Kannan 04 Mar '14

04 Mar '14

Team, We are using the below mentioned binary version of the product in our environment. We have installed the executable in our servers and we are using mpiexec command tool for parallel processing. Platform Author Download Base MPICH Version Windows <mailto:[email protected]> Jayesh Krishna [ <https://www.mpich.org/static/tarballs/1.4.1p1/mpich2-1.4.1p1-win-ia32.msi> x86] 1.4.1p1 [ <https://www.mpich.org/static/tarballs/1.4.1p1/mpich2-1.4.1p1-win-x86-64.msi > x86_64] 1.4.1p1 Now, I saw an update in the MPICH2 website that, a latest version is released as below. I went through the enhancements carried out, and found that there are considerable enhancements tailored for core processor parallel processing, for which we would like to have an executable to install, but I could not find the executable in the downloaded documents. Please, let me know if we have any executable for the latest release. Release Platform Download Size mpich-3.1 (stable release) MPICH [ <http://www.mpich.org/static/downloads/3.1/mpich-3.1.tar.gz> http] 11 MB hydra-3.1 (stable release) Hydra (mpiexec) [ <http://www.mpich.org/static/downloads/3.1/hydra-3.1.tar.gz> http] 3 MB Regards, Prasenna

1 0

Re: [mpich-devel] [mpich-commits] [mpich] MPICH primary repository branch, master, updated. v3.1-22-gde80ec8
by Dave Goodell (dgoodell) 27 Feb '14

27 Feb '14

On Feb 27, 2014, at 1:46 PM, "Latham, Robert J." <robl(a)mcs.anl.gov> wrote: > On Thu, 2014-02-27 at 19:32 +0000, Dave Goodell (dgoodell) wrote: >> I saw this fly by and a bug caught the corner of my eye (see inline) > >>> + >>> # If the program linked OK, make sure there were no warnings >>> - if test "$prog_links" = "yes" -a "`cat pac_test.log`" = "" ; then >>> + if test "$prog_links" = "yes" -a "`diff pac_test1.log pac_test2.log`" = "" ; then >>> AC_DEFINE([HAVE_MACRO_VA_ARGS],[1],[Define if C99-style variable argument list macro functionality]) >>> AC_MSG_RESULT([yes]) >>> + elif "`diff pac_test1.log pac_test2.log`" = "" ; then >> >> This is bad shell code. You probably want "elif test" instead. > > Or let autoconf worry about it for you with AS_IF You still need the "test" in that case... -Dave

1 0

Re: [mpich-devel] Fwd: [mpich-commits] [mpich] MPICH primary repository branch, master, updated. v3.1-22-gde80ec8
by Latham, Robert J. 27 Feb '14

27 Feb '14

On Thu, 2014-02-27 at 19:32 +0000, Dave Goodell (dgoodell) wrote: > I saw this fly by and a bug caught the corner of my eye (see inline) > > + > > # If the program linked OK, make sure there were no warnings > > - if test "$prog_links" = "yes" -a "`cat pac_test.log`" = "" ; then > > + if test "$prog_links" = "yes" -a "`diff pac_test1.log pac_test2.log`" = "" ; then > > AC_DEFINE([HAVE_MACRO_VA_ARGS],[1],[Define if C99-style variable argument list macro functionality]) > > AC_MSG_RESULT([yes]) > > + elif "`diff pac_test1.log pac_test2.log`" = "" ; then > > This is bad shell code. You probably want "elif test" instead. Or let autoconf worry about it for you with AS_IF ==rob

1 0

Re: [mpich-devel] [mpich-commits] [mpich] MPICH primary repository branch, master, updated. v3.1-22-gde80ec8
by Lu, Huiwei 27 Feb '14

27 Feb '14

Thanks Dave, Oops, I let the bug slip in. I will be more careful next time. — Huiwei On Feb 27, 2014, at 1:40 PM, Balaji, Pavan <balaji(a)anl.gov> wrote: > > And, of course, I totally screwed up the check — it should have been !=, rather than = in the check. > > I take solace in the fact that this is not the worst code I’ve written. :-) > > — Pavan > > On Feb 27, 2014, at 1:32 PM, Dave Goodell (dgoodell) <dgoodell(a)cisco.com> wrote: > >> I saw this fly by and a bug caught the corner of my eye (see inline) >> >> Begin forwarded message: >> >>> From: Service Account <noreply(a)mpich.org> >>> Subject: [mpich-commits] [mpich] MPICH primary repository branch, master, updated. v3.1-22-gde80ec8 >>> Date: February 27, 2014 11:27:24 AM PST >>> To: <all-commits(a)mpich.org>, <commits(a)mpich.org> >>> Reply-To: <commits(a)mpich.org> >>> >>> This is an automated email from the git hooks/post-receive script. It was >>> generated because a ref change was pushed to the repository containing >>> the project "MPICH primary repository". >>> >>> The branch, master has been updated >>> via de80ec8704071f3b9c810509fb8acee345865902 (commit) >>> from 956047a2696bdfb51d66f56d0b226df8d40ebd80 (commit) >>> >>> Those revisions listed above that are new to this repository have >>> not appeared on any other notification email; so we list those >>> revisions in full, below. >>> >>> - Log ----------------------------------------------------------------- >>> http://git.mpich.org/mpich.git/commitdiff/de80ec8704071f3b9c810509fb8acee34… >>> >>> commit de80ec8704071f3b9c810509fb8acee345865902 >>> Author: Pavan Balaji <balaji(a)mcs.anl.gov> >>> Date: Wed Feb 26 11:49:46 2014 -0600 >>> >>> Better checks for VA_ARGS. >>> >>> We were disabling VA_ARGS whenever the compiler throws warnings. >>> However, in some cases, the compiler is throwing warnings in general >>> (because of bad user-specified flags) and not specifically because of >>> VA_ARGS. See discussion on the discuss(a)mpich.org mailing list: >>> http://lists.mpich.org/pipermail/discuss/2014-February/002246.html >>> >>> This patch works around this issue by checking the difference in the >>> warning flags with and without VA_ARGS. >>> >>> Fixes #2047. >>> >>> Signed-off-by: Huiwei Lu <huiweilu(a)mcs.anl.gov> >>> >>> diff --git a/confdb/aclocal_cc.m4 b/confdb/aclocal_cc.m4 >>> index f73aa4c..2612e94 100644 >>> --- a/confdb/aclocal_cc.m4 >>> +++ b/confdb/aclocal_cc.m4 >>> @@ -1644,22 +1644,35 @@ AC_DEFUN([PAC_C_MACRO_VA_ARGS],[ >>> AC_MSG_CHECKING([for variable argument list macro functionality]) >>> >>> # check if the program links correctly >>> - rm -f pac_test.log >>> - PAC_LINK_IFELSE_LOG([pac_test.log],[AC_LANG_PROGRAM([ >>> + rm -f pac_test1.log pac_test2.log >>> + >>> + PAC_LINK_IFELSE_LOG([pac_test1.log],[AC_LANG_PROGRAM([ >>> #include <stdio.h> >>> #define conftest_va_arg_macro(...) printf(__VA_ARGS__) >>> ], >>> [conftest_va_arg_macro("a test %d", 3);])], >>> prog_links=yes,prog_links=no) >>> >>> + PAC_LINK_IFELSE_LOG([pac_test2.log],[AC_LANG_PROGRAM([ >>> + #include <stdio.h> >>> + #define conftest_va_arg_macro printf >>> + ], >>> + [conftest_va_arg_macro("a test %d", 3);])]) >>> + >>> # If the program linked OK, make sure there were no warnings >>> - if test "$prog_links" = "yes" -a "`cat pac_test.log`" = "" ; then >>> + if test "$prog_links" = "yes" -a "`diff pac_test1.log pac_test2.log`" = "" ; then >>> AC_DEFINE([HAVE_MACRO_VA_ARGS],[1],[Define if C99-style variable argument list macro functionality]) >>> AC_MSG_RESULT([yes]) >>> + elif "`diff pac_test1.log pac_test2.log`" = "" ; then >> >> This is bad shell code. You probably want "elif test" instead. >> >> -Dave >> >>> + AC_MSG_RESULT([no, compiler generates warnings]) >>> + echo "With VA_ARGS:" >>> + cat pac_test1.log >>> + echo "Without VA_ARGS:" >>> + cat pac_test2.log >>> else >>> AC_MSG_RESULT([no]) >>> fi >>> - rm -f pac_test.log >>> + rm -f pac_test1.log pac_test2.log >>> ])dnl >>> >>> # Will AC_DEFINE([HAVE_BUILTIN_EXPECT]) if the compiler supports __builtin_expect. >>> >>> ----------------------------------------------------------------------- >>> >>> Summary of changes: >>> confdb/aclocal_cc.m4 | 21 +++++++++++++++++---- >>> 1 files changed, 17 insertions(+), 4 deletions(-) >>> >>> >>> hooks/post-receive >>> -- >>> MPICH primary repository >> >

1 0

Re: [mpich-devel] [mpich-commits] [mpich] MPICH primary repository branch, master, updated. v3.1-22-gde80ec8
by Balaji, Pavan 27 Feb '14

27 Feb '14

And, of course, I totally screwed up the check — it should have been !=, rather than = in the check. I take solace in the fact that this is not the worst code I’ve written. :-) — Pavan On Feb 27, 2014, at 1:32 PM, Dave Goodell (dgoodell) <dgoodell(a)cisco.com> wrote: > I saw this fly by and a bug caught the corner of my eye (see inline) > > Begin forwarded message: > >> From: Service Account <noreply(a)mpich.org> >> Subject: [mpich-commits] [mpich] MPICH primary repository branch, master, updated. v3.1-22-gde80ec8 >> Date: February 27, 2014 11:27:24 AM PST >> To: <all-commits(a)mpich.org>, <commits(a)mpich.org> >> Reply-To: <commits(a)mpich.org> >> >> This is an automated email from the git hooks/post-receive script. It was >> generated because a ref change was pushed to the repository containing >> the project "MPICH primary repository". >> >> The branch, master has been updated >> via de80ec8704071f3b9c810509fb8acee345865902 (commit) >> from 956047a2696bdfb51d66f56d0b226df8d40ebd80 (commit) >> >> Those revisions listed above that are new to this repository have >> not appeared on any other notification email; so we list those >> revisions in full, below. >> >> - Log ----------------------------------------------------------------- >> http://git.mpich.org/mpich.git/commitdiff/de80ec8704071f3b9c810509fb8acee34… >> >> commit de80ec8704071f3b9c810509fb8acee345865902 >> Author: Pavan Balaji <balaji(a)mcs.anl.gov> >> Date: Wed Feb 26 11:49:46 2014 -0600 >> >> Better checks for VA_ARGS. >> >> We were disabling VA_ARGS whenever the compiler throws warnings. >> However, in some cases, the compiler is throwing warnings in general >> (because of bad user-specified flags) and not specifically because of >> VA_ARGS. See discussion on the discuss(a)mpich.org mailing list: >> http://lists.mpich.org/pipermail/discuss/2014-February/002246.html >> >> This patch works around this issue by checking the difference in the >> warning flags with and without VA_ARGS. >> >> Fixes #2047. >> >> Signed-off-by: Huiwei Lu <huiweilu(a)mcs.anl.gov> >> >> diff --git a/confdb/aclocal_cc.m4 b/confdb/aclocal_cc.m4 >> index f73aa4c..2612e94 100644 >> --- a/confdb/aclocal_cc.m4 >> +++ b/confdb/aclocal_cc.m4 >> @@ -1644,22 +1644,35 @@ AC_DEFUN([PAC_C_MACRO_VA_ARGS],[ >> AC_MSG_CHECKING([for variable argument list macro functionality]) >> >> # check if the program links correctly >> - rm -f pac_test.log >> - PAC_LINK_IFELSE_LOG([pac_test.log],[AC_LANG_PROGRAM([ >> + rm -f pac_test1.log pac_test2.log >> + >> + PAC_LINK_IFELSE_LOG([pac_test1.log],[AC_LANG_PROGRAM([ >> #include <stdio.h> >> #define conftest_va_arg_macro(...) printf(__VA_ARGS__) >> ], >> [conftest_va_arg_macro("a test %d", 3);])], >> prog_links=yes,prog_links=no) >> >> + PAC_LINK_IFELSE_LOG([pac_test2.log],[AC_LANG_PROGRAM([ >> + #include <stdio.h> >> + #define conftest_va_arg_macro printf >> + ], >> + [conftest_va_arg_macro("a test %d", 3);])]) >> + >> # If the program linked OK, make sure there were no warnings >> - if test "$prog_links" = "yes" -a "`cat pac_test.log`" = "" ; then >> + if test "$prog_links" = "yes" -a "`diff pac_test1.log pac_test2.log`" = "" ; then >> AC_DEFINE([HAVE_MACRO_VA_ARGS],[1],[Define if C99-style variable argument list macro functionality]) >> AC_MSG_RESULT([yes]) >> + elif "`diff pac_test1.log pac_test2.log`" = "" ; then > > This is bad shell code. You probably want "elif test" instead. > > -Dave > >> + AC_MSG_RESULT([no, compiler generates warnings]) >> + echo "With VA_ARGS:" >> + cat pac_test1.log >> + echo "Without VA_ARGS:" >> + cat pac_test2.log >> else >> AC_MSG_RESULT([no]) >> fi >> - rm -f pac_test.log >> + rm -f pac_test1.log pac_test2.log >> ])dnl >> >> # Will AC_DEFINE([HAVE_BUILTIN_EXPECT]) if the compiler supports __builtin_expect. >> >> ----------------------------------------------------------------------- >> >> Summary of changes: >> confdb/aclocal_cc.m4 | 21 +++++++++++++++++---- >> 1 files changed, 17 insertions(+), 4 deletions(-) >> >> >> hooks/post-receive >> -- >> MPICH primary repository >

1 0