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 <[email protected]> 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 [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

_______________________________________________ discuss mailing list [email protected] To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss