Also, could there be a way (maybe in a future clang release) for me to get static type checking for my own types, such as __float128 or pair types like {long,long} (which are not in the MPI standard)? It can't truly be a static value because I have to create the type at run-time, but perhaps there could be a way to tell clang "I promise to set this type up like so."

On Wed, Jan 2, 2013 at 11:31 AM, Dave Goodell <goodell@mcs.anl.gov> wrote:

[adding Hal Finkel and Dmitri Gribenko, who did most of the annotations work]

Hal/Dmitri,

Do you have any ideas about how to handle Jed's case? Will the MPICH_ATTR_TYPE_TAG_LAYOUT_COMPATIBLE macro (reproduced below) help in this case?

----8<----
# define MPICH_ATTR_TYPE_TAG_LAYOUT_COMPATIBLE(type) __attribute__((type_tag_for_datatype(MPI,type,layout_compatible)))
----8<----

-Dave

On Dec 30, 2012, at 11:13 PM CST, Jed Brown wrote:

> I upgraded to clang-3.2 and the new type annotations are great. I'd like to have a identified for enum types, e.g.
>
> typedef enum {SOME, VALUES} MyEnum;
> #define MY_MPI_ENUM MPI_INT // or define some other way
> static const MPI_Datatype my_mpi_enum MPICH_ATTR_TYPE_TAG(MyEnum) = MY_MPI_ENUM;
>
>
> Of course the above does not work because the new definition masks the old one, so all the normal 'int' uses are hidden. Unfortunately, the annotation syntax requires compile-time constants, which are not accessible to me.
>
> Is there any hope for something like this, or do I have to choose between (a) ugly cast at all MPI call points and (b) make MY_MPI_ENUM a variable so that the compiler can't check it statically?

> _______________________________________________
> discuss mailing list discuss@mpich.org
> To manage subscription options or unsubscribe:
> https://lists.mpich.org/mailman/listinfo/discuss

_______________________________________________
discuss mailing list discuss@mpich.org
To manage subscription options or unsubscribe:
https://lists.mpich.org/mailman/listinfo/discuss