October 2014 - devel - mailman3.cels.anl.gov

Re: [mpich-devel] odd timings in type create/free (related to handle pool?)
by Balaji, Pavan 03 Oct '14

03 Oct '14

Hmm. My initial thought when I saw this email was that you are running out of the direct block set that MPICH allocates and falling into the indirect allocation, so the performance gets worse when you allocate too many objects. But then I realized that you are freeing all of the structures as soon as you allocate them so that shouldn’t happen. I added a few debug statements in mpich to verify that, and you are indeed only using three objects through the entire program. No indirect blocks. So now I’m no longer sure why the performance degradation is happening, but it’s certainly not expected. A quick parse through the related code didn’t pop up anything weird. I’ve created a ticket for it: https://trac.mpich.org/projects/mpich/ticket/2184 — Pavan On Oct 3, 2014, at 5:36 PM, Jeff Hammond <jeff.science(a)gmail.com> wrote: > I wanted to time how long it took to create a datatype. Obviously, > timing a series of calls is the normal way to get reasonable data. > However, I find that my test shows that the time per call is in some > way proportional to the number of calls in the series, even when I > reuse the same handle. I previously timed on a vector of handles and > saw the same result. > > I can only assume this is related to how MPICH does handle allocation > internally. Can you confirm? Is there any way to get MPICH to > garbage collect the internal handle pool so that the time per call > goes back down again? An increase from 4 us to 112 us per call is > pretty substantial if I have a library that is going to use a lot of > derived datatypes and has no reasonable way to cache them. > > Thanks, > > Jeff > > OUTPUT > > create, commit (free?) 100 Type_contig_x in 0.000393 s (3.926220 us per call) > create, commit (free?) 1000 Type_contig_x in 0.006105 s (6.105444 us per call) > create, commit (free?) 10000 Type_contig_x in 0.082496 s (8.249623 us per call) > create, commit (free?) 25000 Type_contig_x in 0.341852 s (13.674085 us per call) > create, commit (free?) 50000 Type_contig_x in 1.280882 s (25.617630 us per call) > create, commit (free?) 100000 Type_contig_x in 4.565911 s (45.659108 > us per call) > create, commit (free?) 250000 Type_contig_x in 27.989672 s (111.958686 > us per call) > > > SOURCE > > #include <stdint.h> > #include <stdio.h> > #include <stdlib.h> > #include <string.h> > #include <limits.h> > #include <math.h> > #include <mpi.h> > > /* there is a reason for this silliness */ > static volatile int bigmpi_int_max = 3; > > int MPIX_Type_contiguous_x(MPI_Count count, MPI_Datatype oldtype, > MPI_Datatype * newtype) > { > MPI_Count c = count/bigmpi_int_max; > MPI_Count r = count%bigmpi_int_max; > > MPI_Datatype chunks; > MPI_Type_vector(c, bigmpi_int_max, bigmpi_int_max, oldtype, &chunks); > > MPI_Datatype remainder; > MPI_Type_contiguous(r, oldtype, &remainder); > > MPI_Aint lb /* unused */, extent; > MPI_Type_get_extent(oldtype, &lb, &extent); > > MPI_Aint remdisp = (MPI_Aint)c*bigmpi_int_max*extent; > int blocklengths[2] = {1,1}; > MPI_Aint displacements[2] = {0,remdisp}; > MPI_Datatype types[2] = {chunks,remainder}; > MPI_Type_create_struct(2, blocklengths, displacements, types, newtype); > > MPI_Type_free(&chunks); > MPI_Type_free(&remainder); > > return MPI_SUCCESS; > } > > int main(int argc, char* argv[]) > { > int rank=0, size=1; > MPI_Init(&argc, &argv); > MPI_Comm_rank(MPI_COMM_WORLD, &rank); > MPI_Comm_size(MPI_COMM_WORLD, &size); > > int n = (argc>1) ? atoi(argv[1]) : 10000; > //MPI_Datatype * dtout = malloc(n*sizeof(MPI_Datatype)); > MPI_Datatype dtout; > double t0 = MPI_Wtime(); > for (int i=0; i<n; i++) { > //MPIX_Type_contiguous_x((MPI_Count)i, MPI_DOUBLE, &(dtout[i])); > //MPI_Type_commit(&(dtout[i])); > MPIX_Type_contiguous_x((MPI_Count)i, MPI_DOUBLE, &dtout); > MPI_Type_commit(&dtout); > MPI_Type_free(&dtout); > } > double t1 = MPI_Wtime(); > double dt = t1-t0; > printf("create, commit (free?) %d Type_contig_x in %lf s (%lf us > per call)\n", > n, dt, 1.e6*dt/(double)n); > > //for (int i=0; i<n; i++) { > // MPI_Type_free(&(dtout[i])); > //} > //free(dtout); > > MPI_Finalize(); > return 0; > } > > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel -- Pavan Balaji ✉️ http://www.mcs.anl.gov/~balaji

1 0

odd timings in type create/free (related to handle pool?)
by Jeff Hammond 03 Oct '14

03 Oct '14

I wanted to time how long it took to create a datatype. Obviously, timing a series of calls is the normal way to get reasonable data. However, I find that my test shows that the time per call is in some way proportional to the number of calls in the series, even when I reuse the same handle. I previously timed on a vector of handles and saw the same result. I can only assume this is related to how MPICH does handle allocation internally. Can you confirm? Is there any way to get MPICH to garbage collect the internal handle pool so that the time per call goes back down again? An increase from 4 us to 112 us per call is pretty substantial if I have a library that is going to use a lot of derived datatypes and has no reasonable way to cache them. Thanks, Jeff OUTPUT create, commit (free?) 100 Type_contig_x in 0.000393 s (3.926220 us per call) create, commit (free?) 1000 Type_contig_x in 0.006105 s (6.105444 us per call) create, commit (free?) 10000 Type_contig_x in 0.082496 s (8.249623 us per call) create, commit (free?) 25000 Type_contig_x in 0.341852 s (13.674085 us per call) create, commit (free?) 50000 Type_contig_x in 1.280882 s (25.617630 us per call) create, commit (free?) 100000 Type_contig_x in 4.565911 s (45.659108 us per call) create, commit (free?) 250000 Type_contig_x in 27.989672 s (111.958686 us per call) SOURCE #include <stdint.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <limits.h> #include <math.h> #include <mpi.h> /* there is a reason for this silliness */ static volatile int bigmpi_int_max = 3; int MPIX_Type_contiguous_x(MPI_Count count, MPI_Datatype oldtype, MPI_Datatype * newtype) { MPI_Count c = count/bigmpi_int_max; MPI_Count r = count%bigmpi_int_max; MPI_Datatype chunks; MPI_Type_vector(c, bigmpi_int_max, bigmpi_int_max, oldtype, &chunks); MPI_Datatype remainder; MPI_Type_contiguous(r, oldtype, &remainder); MPI_Aint lb /* unused */, extent; MPI_Type_get_extent(oldtype, &lb, &extent); MPI_Aint remdisp = (MPI_Aint)c*bigmpi_int_max*extent; int blocklengths[2] = {1,1}; MPI_Aint displacements[2] = {0,remdisp}; MPI_Datatype types[2] = {chunks,remainder}; MPI_Type_create_struct(2, blocklengths, displacements, types, newtype); MPI_Type_free(&chunks); MPI_Type_free(&remainder); return MPI_SUCCESS; } int main(int argc, char* argv[]) { int rank=0, size=1; MPI_Init(&argc, &argv); MPI_Comm_rank(MPI_COMM_WORLD, &rank); MPI_Comm_size(MPI_COMM_WORLD, &size); int n = (argc>1) ? atoi(argv[1]) : 10000; //MPI_Datatype * dtout = malloc(n*sizeof(MPI_Datatype)); MPI_Datatype dtout; double t0 = MPI_Wtime(); for (int i=0; i<n; i++) { //MPIX_Type_contiguous_x((MPI_Count)i, MPI_DOUBLE, &(dtout[i])); //MPI_Type_commit(&(dtout[i])); MPIX_Type_contiguous_x((MPI_Count)i, MPI_DOUBLE, &dtout); MPI_Type_commit(&dtout); MPI_Type_free(&dtout); } double t1 = MPI_Wtime(); double dt = t1-t0; printf("create, commit (free?) %d Type_contig_x in %lf s (%lf us per call)\n", n, dt, 1.e6*dt/(double)n); //for (int i=0; i<n; i++) { // MPI_Type_free(&(dtout[i])); //} //free(dtout); MPI_Finalize(); return 0; } -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [mpich-devel] [mpich-commits] [mpich] MPICH primary repository branch, master, updated. v3.2a1-34-geda105b
by Dave Goodell (dgoodell) 02 Oct '14

02 Oct '14

On Oct 2, 2014, at 7:36 AM, William Gropp <wgropp(a)illinois.edu> wrote: > There are two points here: > > [... C89 / compiler warning screed here ...] I'm not going to waste our time debating this with you, as we both know we are highly unlikely to change the other's views on this issue. I think that achieving zero warnings on common compilers in strict compilation mode is important and more valuable than certain other things, and you don't. It's largely a value judgement either direction, which doesn't make either of us right in any absolute sense. > 2) Language version choices and coding standards. The real point here is that coding standards are important and should be followed by anyone working on the code. Changes to the coding standard need to be made collectively and explicitly; individuals must not decide that they know better. On this specific question, it may very well be time to move to C99, but that must be a deliberate, collective choice. And the issue is not whether such compilers exist, but whether our user community uses and trusts them. At this point, the answer to that question is probably yes as well, but that’s the correct question to ask (and yes, a deliberate and explicit decision could be made to require a C99 compiler and exclude any users that insist on sticking with C89). > > Junchao made the right call. I was not asking Junchao to go off and make a bunch of cowboy changes, but for him to push for modernization in a collective decision instead of accepting the C89 coding standards as dogma. I just said it in a terse, semi-inflammatory style that could be misunderstood. Perhaps it's time to take my iconoclastic views and go back to full-on lurking on this list. -Dave

1 0

Re: [mpich-devel] [mpich-commits] [mpich] MPICH primary repository branch, master, updated. v3.2a1-34-geda105b
by William Gropp 02 Oct '14

02 Oct '14

There are two points here: 1) Should the code compile “cleanly” with every compiler and many choices of warning options? This sounds like a good idea on the surface, but in fact it is not. Lots of compilers generate too many false positives, and suppressing them often requires adding unnecessary code and distorting the rest of the code. That is the case here (the same compiler that can’t figure out that the array isn’t referenced before use is going to have to perform the initialization, adding unnecessary overhead and thus latency). Rather, the code should compile cleanly with some compiler and set of warnings that is accurate and effective. The fact that some compiler has poor accuracy in its warnings should not be a reason to harm the code just to keep that compiler quiet. Note that this is more important for performance sensitive code (particularly for latency) such as MPICH; however, even for non-performance-sensitive codes, making the compiler happy can distort the code, making it harder, not easier, to maintain. 2) Language version choices and coding standards. The real point here is that coding standards are important and should be followed by anyone working on the code. Changes to the coding standard need to be made collectively and explicitly; individuals must not decide that they know better. On this specific question, it may very well be time to move to C99, but that must be a deliberate, collective choice. And the issue is not whether such compilers exist, but whether our user community uses and trusts them. At this point, the answer to that question is probably yes as well, but that’s the correct question to ask (and yes, a deliberate and explicit decision could be made to require a C99 compiler and exclude any users that insist on sticking with C89). Junchao made the right call. Bill On Oct 1, 2014, at 11:15 PM, Dave Goodell (dgoodell) <dgoodell(a)cisco.com> wrote: > On Oct 1, 2014, at 10:20 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: > >> On Wed, Oct 1, 2014 at 5:40 PM, Dave Goodell (dgoodell) <dgoodell(a)cisco.com> >> wrote: >> >>> Begin forwarded message: >>> >>>> - Log ----------------------------------------------------------------- >>>> >>> http://git.mpich.org/mpich.git/commitdiff/eda105b029572ebf7f4008f6de2e1afb9… >>>> >>>> commit eda105b029572ebf7f4008f6de2e1afb9ccf6fc2 >>>> Author: Junchao Zhang <jczhang(a)mcs.anl.gov> >>>> Date: Tue Sep 16 15:58:55 2014 -0500 >>>> >>>> Remove unnessary array init in MPIU_CHKLMEM_DECL >>>> >>>> Initializing mpiu_chklmem_stk_sp_ to 0 should already have the effect >>> to >>>> initialize mpiu_chklmem_stk_[n_]. >>>> >>>> Signed-off-by: Antonio J. Pena <apenya(a)mcs.anl.gov> >>>> >>>> diff --git a/src/include/mpimem.h b/src/include/mpimem.h >>>> index a217e8b..e1478a5 100644 >>>> --- a/src/include/mpimem.h >>>> +++ b/src/include/mpimem.h >>>> @@ -317,7 +317,7 @@ extern char *strdup( const char * ); >>>> }} >>>> #else >>>> #define MPIU_CHKLMEM_DECL(n_) \ >>>> - void *(mpiu_chklmem_stk_[n_]) = {0};\ >>>> + void *(mpiu_chklmem_stk_[n_]); \ >>>> int mpiu_chklmem_stk_sp_=0;\ >>>> MPIU_AssertDeclValue(const int mpiu_chklmem_stk_sz_,n_) >>> >>> You might want to revert this. My recollection is that not all compilers >>> are smart enough to see that mpiu_chklmem_stk_ is not used before being >>> defined, which can lead to a *lot* of warnings throughout the MPICH >>> codebase. >>> >> >> Dave, I don't quite understand your concern. I removed the array >> initialization code since MPIU_CHKLMEM_FREEALL() can only free pointers set >> before. The number of pointers is mpiu_chklmem_stk_sp_, which is >> initialized to 0. > > Look, I don't have time (or frankly, that much interest) to run down an example compiler where this will happen, but I definitely made this change in the past because we were encountering the warning: http://git.mpich.org/mpich.git/commitdiff/70f4742 > > I wish I had made a better commit message at the time :-/ > > I have a suspicion that GCC ~4.1 with some set of (non-?)optimization flags would issue the "may be used uninitialized" warning, but I really don't recall for sure. I don't disagree with your analysis that the value cannot actually be used uninitialized, I'm just disputing whether the compiler will issue a warning about it. > > Actually, it looks like I'm not the only person who has experienced this, Toni fixed an issue like this much more recently than 2009: http://git.mpich.org/mpich.git/commitdiff/d8b8eb6 > >>> Also, what's the sudden interest in restoring C89 support again? The >>> whole world really does support enough of C99 now... Seems like a big >>> waste of time and an unnecessary annoyance to developers who might want to >>> use useful C99 features (e.g., named structure initializers). >>> >>> >> See https://trac.mpich.org/projects/mpich/ticket/2167 > > > That's not really an answer. It's just a rehash of the endless discussion that MPICH development has had for the past 7+ years. > > Open MPI and many other projects now require nominal C99 compliance for any recent release. All the work that you did to run around and fix the "--enable-strict=c89" mode was just a huge waste of time. The correct fix is to delete "--enable-strict=c89" and embrace the "future" of 6+ years ago. > > -Dave > > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel

1 0

Re: [mpich-devel] [mpich-commits] [mpich] MPICH primary repository branch, master, updated. v3.2a1-34-geda105b
by Dave Goodell (dgoodell) 01 Oct '14

01 Oct '14

On Oct 1, 2014, at 10:20 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: > On Wed, Oct 1, 2014 at 5:40 PM, Dave Goodell (dgoodell) <dgoodell(a)cisco.com> > wrote: > >> Begin forwarded message: >> >>> - Log ----------------------------------------------------------------- >>> >> http://git.mpich.org/mpich.git/commitdiff/eda105b029572ebf7f4008f6de2e1afb9… >>> >>> commit eda105b029572ebf7f4008f6de2e1afb9ccf6fc2 >>> Author: Junchao Zhang <jczhang(a)mcs.anl.gov> >>> Date: Tue Sep 16 15:58:55 2014 -0500 >>> >>> Remove unnessary array init in MPIU_CHKLMEM_DECL >>> >>> Initializing mpiu_chklmem_stk_sp_ to 0 should already have the effect >> to >>> initialize mpiu_chklmem_stk_[n_]. >>> >>> Signed-off-by: Antonio J. Pena <apenya(a)mcs.anl.gov> >>> >>> diff --git a/src/include/mpimem.h b/src/include/mpimem.h >>> index a217e8b..e1478a5 100644 >>> --- a/src/include/mpimem.h >>> +++ b/src/include/mpimem.h >>> @@ -317,7 +317,7 @@ extern char *strdup( const char * ); >>> }} >>> #else >>> #define MPIU_CHKLMEM_DECL(n_) \ >>> - void *(mpiu_chklmem_stk_[n_]) = {0};\ >>> + void *(mpiu_chklmem_stk_[n_]); \ >>> int mpiu_chklmem_stk_sp_=0;\ >>> MPIU_AssertDeclValue(const int mpiu_chklmem_stk_sz_,n_) >> >> You might want to revert this. My recollection is that not all compilers >> are smart enough to see that mpiu_chklmem_stk_ is not used before being >> defined, which can lead to a *lot* of warnings throughout the MPICH >> codebase. >> > > Dave, I don't quite understand your concern. I removed the array > initialization code since MPIU_CHKLMEM_FREEALL() can only free pointers set > before. The number of pointers is mpiu_chklmem_stk_sp_, which is > initialized to 0. Look, I don't have time (or frankly, that much interest) to run down an example compiler where this will happen, but I definitely made this change in the past because we were encountering the warning: http://git.mpich.org/mpich.git/commitdiff/70f4742 I wish I had made a better commit message at the time :-/ I have a suspicion that GCC ~4.1 with some set of (non-?)optimization flags would issue the "may be used uninitialized" warning, but I really don't recall for sure. I don't disagree with your analysis that the value cannot actually be used uninitialized, I'm just disputing whether the compiler will issue a warning about it. Actually, it looks like I'm not the only person who has experienced this, Toni fixed an issue like this much more recently than 2009: http://git.mpich.org/mpich.git/commitdiff/d8b8eb6 >> Also, what's the sudden interest in restoring C89 support again? The >> whole world really does support enough of C99 now... Seems like a big >> waste of time and an unnecessary annoyance to developers who might want to >> use useful C99 features (e.g., named structure initializers). >> >> > See https://trac.mpich.org/projects/mpich/ticket/2167 That's not really an answer. It's just a rehash of the endless discussion that MPICH development has had for the past 7+ years. Open MPI and many other projects now require nominal C99 compliance for any recent release. All the work that you did to run around and fix the "--enable-strict=c89" mode was just a huge waste of time. The correct fix is to delete "--enable-strict=c89" and embrace the "future" of 6+ years ago. -Dave

1 0

Re: [mpich-devel] Fwd: [mpich-commits] [mpich] MPICH primary repository branch, master, updated. v3.2a1-34-geda105b
by Junchao Zhang 01 Oct '14

01 Oct '14

On Wed, Oct 1, 2014 at 5:40 PM, Dave Goodell (dgoodell) <dgoodell(a)cisco.com> wrote: > Begin forwarded message: > > > From: Service Account <noreply(a)mpich.org> > > Subject: [mpich-commits] [mpich] MPICH primary repository branch, > master, updated. v3.2a1-34-geda105b > > Date: October 1, 2014 5:29:25 PM CDT > > 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 eda105b029572ebf7f4008f6de2e1afb9ccf6fc2 (commit) > > via 98114df4c0504568ab188ea98a9d1269d087bd82 (commit) > > via ad25799865749680338c05264c8007242f01326a (commit) > > from 6b8c426d90b28bb0ed6ff6ade6ac03a4e4b96634 (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/eda105b029572ebf7f4008f6de2e1afb9… > > > > commit eda105b029572ebf7f4008f6de2e1afb9ccf6fc2 > > Author: Junchao Zhang <jczhang(a)mcs.anl.gov> > > Date: Tue Sep 16 15:58:55 2014 -0500 > > > > Remove unnessary array init in MPIU_CHKLMEM_DECL > > > > Initializing mpiu_chklmem_stk_sp_ to 0 should already have the effect > to > > initialize mpiu_chklmem_stk_[n_]. > > > > Signed-off-by: Antonio J. Pena <apenya(a)mcs.anl.gov> > > > > diff --git a/src/include/mpimem.h b/src/include/mpimem.h > > index a217e8b..e1478a5 100644 > > --- a/src/include/mpimem.h > > +++ b/src/include/mpimem.h > > @@ -317,7 +317,7 @@ extern char *strdup( const char * ); > > }} > > #else > > #define MPIU_CHKLMEM_DECL(n_) \ > > - void *(mpiu_chklmem_stk_[n_]) = {0};\ > > + void *(mpiu_chklmem_stk_[n_]); \ > > int mpiu_chklmem_stk_sp_=0;\ > > MPIU_AssertDeclValue(const int mpiu_chklmem_stk_sz_,n_) > > You might want to revert this. My recollection is that not all compilers > are smart enough to see that mpiu_chklmem_stk_ is not used before being > defined, which can lead to a *lot* of warnings throughout the MPICH > codebase. > Dave, I don't quite understand your concern. I removed the array initialization code since MPIU_CHKLMEM_FREEALL() can only free pointers set before. The number of pointers is mpiu_chklmem_stk_sp_, which is initialized to 0. > > Also, what's the sudden interest in restoring C89 support again? The > whole world really does support enough of C99 now... Seems like a big > waste of time and an unnecessary annoyance to developers who might want to > use useful C99 features (e.g., named structure initializers). > > See https://trac.mpich.org/projects/mpich/ticket/2167 > -Dave > > _______________________________________________ > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/devel >

1 0

Fwd: [mpich-commits] [mpich] MPICH primary repository branch, master, updated. v3.2a1-34-geda105b
by Dave Goodell (dgoodell) 01 Oct '14

01 Oct '14

Begin forwarded message: > From: Service Account <noreply(a)mpich.org> > Subject: [mpich-commits] [mpich] MPICH primary repository branch, master, updated. v3.2a1-34-geda105b > Date: October 1, 2014 5:29:25 PM CDT > 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 eda105b029572ebf7f4008f6de2e1afb9ccf6fc2 (commit) > via 98114df4c0504568ab188ea98a9d1269d087bd82 (commit) > via ad25799865749680338c05264c8007242f01326a (commit) > from 6b8c426d90b28bb0ed6ff6ade6ac03a4e4b96634 (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/eda105b029572ebf7f4008f6de2e1afb9… > > commit eda105b029572ebf7f4008f6de2e1afb9ccf6fc2 > Author: Junchao Zhang <jczhang(a)mcs.anl.gov> > Date: Tue Sep 16 15:58:55 2014 -0500 > > Remove unnessary array init in MPIU_CHKLMEM_DECL > > Initializing mpiu_chklmem_stk_sp_ to 0 should already have the effect to > initialize mpiu_chklmem_stk_[n_]. > > Signed-off-by: Antonio J. Pena <apenya(a)mcs.anl.gov> > > diff --git a/src/include/mpimem.h b/src/include/mpimem.h > index a217e8b..e1478a5 100644 > --- a/src/include/mpimem.h > +++ b/src/include/mpimem.h > @@ -317,7 +317,7 @@ extern char *strdup( const char * ); > }} > #else > #define MPIU_CHKLMEM_DECL(n_) \ > - void *(mpiu_chklmem_stk_[n_]) = {0};\ > + void *(mpiu_chklmem_stk_[n_]); \ > int mpiu_chklmem_stk_sp_=0;\ > MPIU_AssertDeclValue(const int mpiu_chklmem_stk_sz_,n_) You might want to revert this. My recollection is that not all compilers are smart enough to see that mpiu_chklmem_stk_ is not used before being defined, which can lead to a *lot* of warnings throughout the MPICH codebase. Also, what's the sudden interest in restoring C89 support again? The whole world really does support enough of C99 now... Seems like a big waste of time and an unnecessary annoyance to developers who might want to use useful C99 features (e.g., named structure initializers). -Dave

1 0