Clement, I would continue to use the SIZE_T atomics but define the PVARs type accordingly (UNSIGNED_LONG or UNSIGNED_LONG_LONG depending on which of their size match the one from size_t).
George. On Wed, Mar 22, 2017 at 6:45 AM, Clement FOYER <clement.fo...@gmail.com> wrote: > Hi everyone, > > I'm facing an issue with the typing of the performance variables I try to > register. > > They are basically counters of type MCA_BASE_PVAR_CLASS_AGGREGATE, > MCA_BASE_PVAR_CLASS_COUNTER, or MCA_BASE_PVAR_CLASS_SIZE depending on the > case. In order to silence some warnings when using opal_atomic_add_*() > functions they were switched from uint64_t to int64_t. But doing so, we > loose some consistency in the code. It was then decided to move from > int64_t to size_t, in order to keep consistency across every functions of > our component's API. > > The problem the following : I can't register properly my variables > anymore, because of the restrictions over the types as defined in the > MPI3.1 standard (Sec. 14.3.7, p.580), I can't define these variable as > MCA_BASE_VAR_TYPE_SIZE_T, as they are not explicitly authorized. However, > the SIZE_T type is not even allowed as type for performance variables, as > it is not defined in the list given Section 14.3.5 p.571. So should this > type never to be used for defining performance variables, and thus it > should not be given as part of the enum mca_base_var_type_t type, or can it > be considered as an alias for unsigned long or unsigned long long, and thus > it should be possible to use them in the same cases unsigned long int and > unsigned long long int are ? > > Thenk you in advance for your answer, > > Clement FOYER > > _______________________________________________ > devel mailing list > devel@lists.open-mpi.org > https://rfd.newmexicoconsortium.org/mailman/listinfo/devel >
_______________________________________________ devel mailing list devel@lists.open-mpi.org https://rfd.newmexicoconsortium.org/mailman/listinfo/devel
