Begin forwarded message:

> From: Service Account <noreply@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@mpich.org>, <commits@mpich.org>
> Reply-To: <commits@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/eda105b029572ebf7f4008f6de2e1afb9ccf6fc2
>
> commit eda105b029572ebf7f4008f6de2e1afb9ccf6fc2
> Author: Junchao Zhang <jczhang@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@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

_______________________________________________
To manage subscription options or unsubscribe:
https://lists.mpich.org/mailman/listinfo/devel