August 2019 - mpi-forum - mailman3.cels.anl.gov

Re: [Mpi-forum] Giving up on C11 _Generic
by Jim Dinan 08 Aug '19

08 Aug '19

The polymorphic C front-end (i.e. macros) can be bypassed by talking a pointer to the underlying function [1]. This is the desired behavior for backward compatibility. I agree that this could be surprising to users and it must be clearly documented. In the case where the user is not bypassing the C polymorphic front-end and the compiler does not support _Generic, we can either detect or prevent silent truncation using one of the approaches that I posted. ~Jim. [1] The C preprocessor only invokes a function-like macro if the macro name is followed by (. So, &MPI_Send takes the pointer of the function even though there is a function-like macro with the same name. On Thu, Aug 8, 2019 at 6:51 AM HOLMES Daniel <d.holmes(a)epcc.ed.ac.uk> wrote: > Hi Jim, > > Are we sure the function pointer “worked" in your example? It silently > truncated the large value, because the function pointer bypasses the > redirection macro. > > Cheers, > Dan. > — > Dr Daniel Holmes PhD > Architect (HPC Research) > d.holmes(a)epcc.ed.ac.uk > Phone: +44 (0) 131 651 3465 > Mobile: +44 (0) 7940 524 088 > Address: Room 2.09, Bayes Centre, 47 Potterrow, Central Area, Edinburgh, > EH8 9BT > — > The University of Edinburgh is a charitable body, registered in Scotland, > with registration number SC005336. > — > > On 7 Aug 2019, at 22:00, Jim Dinan via mpi-forum < > mpi-forum(a)lists.mpi-forum.org> wrote: > > Even simpler than this, we could just forward all calls to the MPI_Count > interface (see below). The int count argument should type convert to > MPI_Count without issue. Note that it still needs to be a function-like > macro so that function pointers work. > > Don't give up yet! :D > > ~Jim. > > #include <stdio.h> > > > typedef int MPI_Datatype; > typedef int MPI_Comm; > > int MPI_Send(const void* buf, int count, MPI_Datatype datatype, int dest, > int tag, MPI_Comm comm) > { > printf("MPI_Send(count = %d)\n", count); > return 0; > } > > int MPI_Send_x(const void* buf, long long count, MPI_Datatype datatype, > int dest, > int tag, MPI_Comm comm) > { > printf("MPI_Send_x(count = %lld)\n", count); > return 0; > } > > #define MPI_Send(buf, count, datatype, dest, tag, comm) MPI_Send_x(buf, > count, datatype, dest, tag, comm) > > int main(int argc, char *argv[]) { > /* 8589934592LL == 2^33 */ > long long i = 8589934592LL + 11; > int ret; > int (*snd_ptr)(const void*, int, MPI_Datatype, int, int, MPI_Comm) = > &MPI_Send; > ret = MPI_Send(NULL, i, 0, 0, 0, 0); > ret = MPI_Send(NULL, 5, 0, 0, 0, 0); > ret = (*snd_ptr)(NULL, i, 0, 0, 0, 0); > ret = (*snd_ptr)(NULL, 5, 0, 0, 0, 0); > return 0; > > } > > MPI_Send_x(count = 8589934603) > MPI_Send_x(count = 5) > MPI_Send(count = 11) > > MPI_Send(count = 5) > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum > > >

1 0

Re: [Mpi-forum] Giving up on C11 _Generic
by Jeff Hammond 08 Aug '19

08 Aug '19

That you use code that does unsafe conversions really has nothing to do with the business of the MPI Forum. Again, if you think C89 is the best C, then use and teach that. No one here is trying to make you use C11. Jeff > On Aug 8, 2019, at 5:56 AM, N.M. Maclaren via mpi-forum <mpi-forum(a)lists.mpi-forum.org> wrote: > >> On Aug 7 2019, Jeff Hammond via mpi-forum wrote: >> >> "silently truncated at run time" is trivially addressed with -Wconversion >> or -Wshorten-64-to-32. The example program below is addressed by this. > > Unfortunately, no. While I have no trouble using such options on MY > code, I have frequently found them unusable on imported packages, because > of the flood of non-errors they generate. For example, the following > code is both common and reasonable, and includes narrowing conversions: > > int i; > i = sizeof(double); > float x; > x = 1.0;

1 0

Re: [Mpi-forum] Giving up on C11 _Generic
by N.M. Maclaren 08 Aug '19

08 Aug '19

On Aug 7 2019, Jeff Squyres (jsquyres) via mpi-forum wrote: > > After much debate, the BigCount WG has decided that C11 _Generic just > isn't worth it. That's no reason to penalize Fortran, though. That is certainly the simplest solution. There may be others, but see below. At a wild guess, this is probably trappable by implementations (at some effort, and needing deep knowledge of the standards and issues) for MPI being called directly from conforming C compilers, but not from C++ ones using their C interface. And that is a very serious gotcha. On Aug 7 2019, Anthony Skjellum via mpi-forum wrote: > >Conclusion: You can't use non-compliant MPI-4 with C11 compilers that are >non-compliant with C11, except maybe with a special flag??? >Is there more that I am missing? It's a LOT more complicated than that, as I tried to explain earlier. Even when I was most active in this area, it would have taken me many hours, probably days, of investigation (including on systems to which I had no access), studying at least the C99, C11, C++ and MPI standards in great detail, and working out flow-charts, to be fairly sure of the situation. This area is a gibbering nightmare, and is a major reason the UK voted "no" to C99. On Aug 7 2019, Jeff Hammond via mpi-forum wrote: > >"silently truncated at run time" is trivially addressed with -Wconversion >or -Wshorten-64-to-32. The example program below is addressed by this. Unfortunately, no. While I have no trouble using such options on MY code, I have frequently found them unusable on imported packages, because of the flood of non-errors they generate. For example, the following code is both common and reasonable, and includes narrowing conversions: int i; i = sizeof(double); float x; x = 1.0; On Aug 8 2019, Gropp, William D via mpi-forum wrote: > That -Wall is a lie is also true for gcc. Yes, this is a extremely poor > design. If you want to provide -Wmostcommon then do that (and maybe > abbreviate to -Wmost). Agreed, but it's a digression here! I believe that the gcc people agree, too, but changing it now is just too evil. Regards, Nick Maclaren.

1 0

Re: [Mpi-forum] Giving up on C11 _Generic
by Gropp, William D 08 Aug '19

08 Aug '19

That -Wall is a lie is also true for gcc. Yes, this is a extremely poor design. If you want to provide -Wmostcommon then do that (and maybe abbreviate to -Wmost). Bill William Gropp Director and Chief Scientist, NCSA Thomas M. Siebel Chair in Computer Science University of Illinois Urbana-Champaign On Aug 8, 2019, at 6:42 AM, HOLMES Daniel via mpi-forum <mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]>> wrote: After a brief search that I never knew was necessary, I find that “all” is smaller than “everything” in clang world. http://clang.llvm.org/docs/UsersManual.html#enabling-all-diagnostics<https://urldefense.proofpoint.com/v2/url?u=http-3A__clang.llvm.org_docs_Use…> So, my question “why isn’t -Wconversion implied by -Wall?” might have an astonishing answer.

1 0

Re: [Mpi-forum] Giving up on C11 _Generic
by HOLMES Daniel 08 Aug '19

08 Aug '19

Hi JeffH, After a brief search that I never knew was necessary, I find that “all” is smaller than “everything” in clang world. http://clang.llvm.org/docs/UsersManual.html#enabling-all-diagnostics So, my question “why isn’t -Wconversion implied by -Wall?” might have an astonishing answer. The resulting workflow is then: 1) notice the symptoms of a bug in the output/effect of the code 2) re-compile with -Weverything -Wno-c++98-compat -Wno-c++-compat 3) re-compile with -Weverything -Wno-c++98-compat -Wno-c++-compat -Wno-<other-conflicts> 4) re-compile with -Weverything -Wno-c++98-compat -Wno-c++-compat -Wno-<other-conflicts> -Wno-<unrelated> 5) address all remaining warnings by changing code Experience and repeated exposure would permit combining steps 2-4. This is documented, once you know to go look for it. However, it was not obvious to me that looking beyond “-Wall” was needed. Whilst I agree wholeheartedly that “incorrect programs are incorrect”, I think designers of interfaces/standards have some responsibility to select a design that makes it easy to discover incorrect usage over one that makes it hard. Ideally, a design should be selected that makes it hard to form incorrect usage rather than one that makes misuse easy. Cheers, Dan. — Dr Daniel Holmes PhD Architect (HPC Research) d.holmes(a)epcc.ed.ac.uk<mailto:[email protected]> Phone: +44 (0) 131 651 3465 Mobile: +44 (0) 7940 524 088 Address: Room 2.09, Bayes Centre, 47 Potterrow, Central Area, Edinburgh, EH8 9BT — The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. — On 7 Aug 2019, at 21:14, Jeff Hammond via mpi-forum <mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]>> wrote: I don't care that much about C11 _Generic, which is why I have always focused on a C99 solution to the large-count problem, but I disagree with your reasons for abandoning it. "silently truncated at run time" is trivially addressed with -Wconversion or -Wshorten-64-to-32. The example program below is addressed by this. $ clang -Wshorten-64-to-32 -c truncation.c truncation.c:10:9: warning: implicit conversion loses integer precision: 'long long' to 'int' [-Wshorten-64-to-32] foo(i); ~~~ ^ 1 warning generated. $ gcc-9 -Wconversion -c truncation.c truncation.c: In function 'main': truncation.c:10:9: warning: conversion from 'long long int' to 'int' may change value [-Wconversion] 10 | foo(i); | ^ $ icc -Wconversion -c truncation.c truncation.c(10): warning #1682: implicit conversion of a 64-bit integral type to a smaller integral type (potential portability problem) foo(i); ^ In any case, incorrect programs are incorrect. It is a quality-of-implementation issue whether C compilers and MPI libraries detect incorrect usage. We have never designed MPI around people who can't follow directions and we should not start now. Jeff On Wed, Aug 7, 2019 at 6:59 AM Jeff Squyres (jsquyres) via mpi-forum <mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]>> wrote: SHORT VERSION ============= Due to the possibility of silently introducing errors into user applications, the BigCount WG no longer thinks that C11 _Generic is a good idea. We are therefore dropping that from our proposal. The new proposal will therefore essentially just be the addition of a bunch of MPI_Count-enabled "_x" functions in C, combined with the addition of a bunch of polymorphic MPI_Count-enabled interfaces in Fortran. MORE DETAIL =========== Joseph Schuchart raised a very important point in a recent mailing thread: the following C/C++ code does not raise a compiler warning: ----- #include <stdio.h> static void foo(int j) { printf("foo(j) = %d\n", j); } int main(int argc, char *argv[]) { /* 8589934592LL == 2^33 */ long long i = 8589934592LL + 11; foo(i); return 0; } ----- If you compile and run this program on a commodity x86-64 platform, a) you won't get a warning from the compiler, and b) you'll see "11" printed out. I tried with gcc 9 and clang 8 -- both with the C and C++ compilers. I even tried with "-Wall -pedantic". No warnings. This is because casting from a larger int type to a smaller int type is perfectly valid C/C++. Because of this, there is a possibility that we could be silently introducing errors into user applications. Consider: 1. An application upgrades its "count" parameters to type MPI_Count for all calls to MPI_Send. --> Recall that "MPI_Count" already exists in MPI-3.1, and is likely of type (long long) on commodity x86-64 platforms 2. The application then uses values in that "count" parameter that are greater than 2^32. If the user's MPI implementation and compiler both support C11 _Generic, everything is great. But if either the MPI implementation or the compiler do not support C11 _Generic, ***the "count" value will be silently truncated at run time***. This seems like a very bad idea, from a design standpoint. We have therefore come full circle: we are back to adding a bunch of "_x" functions for C, and there will be no polymorphism (in C). Sorry, folks. Note that Fortran does not have similar problems: 1. Fortran compilers have supported polymorphism for 20+ years 2. Fortran does not automatically cast between INTEGER values of different sizes After much debate, the BigCount WG has decided that C11 _Generic just isn't worth it. That's no reason to penalize Fortran, though. -- Jeff Squyres jsquyres(a)cisco.com<mailto:[email protected]> _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum -- Jeff Hammond jeff.science(a)gmail.com<mailto:[email protected]> http://jeffhammond.github.io/ _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

1 0

Re: [Mpi-forum] Giving up on C11 _Generic
by HOLMES Daniel 08 Aug '19

08 Aug '19

Hi Jim, Are we sure the function pointer “worked" in your example? It silently truncated the large value, because the function pointer bypasses the redirection macro. Cheers, Dan. — Dr Daniel Holmes PhD Architect (HPC Research) d.holmes(a)epcc.ed.ac.uk<mailto:[email protected]> Phone: +44 (0) 131 651 3465 Mobile: +44 (0) 7940 524 088 Address: Room 2.09, Bayes Centre, 47 Potterrow, Central Area, Edinburgh, EH8 9BT — The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. — On 7 Aug 2019, at 22:00, Jim Dinan via mpi-forum <mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]>> wrote: Even simpler than this, we could just forward all calls to the MPI_Count interface (see below). The int count argument should type convert to MPI_Count without issue. Note that it still needs to be a function-like macro so that function pointers work. Don't give up yet! :D ~Jim. #include <stdio.h> typedef int MPI_Datatype; typedef int MPI_Comm; int MPI_Send(const void* buf, int count, MPI_Datatype datatype, int dest, int tag, MPI_Comm comm) { printf("MPI_Send(count = %d)\n", count); return 0; } int MPI_Send_x(const void* buf, long long count, MPI_Datatype datatype, int dest, int tag, MPI_Comm comm) { printf("MPI_Send_x(count = %lld)\n", count); return 0; } #define MPI_Send(buf, count, datatype, dest, tag, comm) MPI_Send_x(buf, count, datatype, dest, tag, comm) int main(int argc, char *argv[]) { /* 8589934592LL == 2^33 */ long long i = 8589934592LL + 11; int ret; int (*snd_ptr)(const void*, int, MPI_Datatype, int, int, MPI_Comm) = &MPI_Send; ret = MPI_Send(NULL, i, 0, 0, 0, 0); ret = MPI_Send(NULL, 5, 0, 0, 0, 0); ret = (*snd_ptr)(NULL, i, 0, 0, 0, 0); ret = (*snd_ptr)(NULL, 5, 0, 0, 0, 0); return 0; } MPI_Send_x(count = 8589934603) MPI_Send_x(count = 5) MPI_Send(count = 11) MPI_Send(count = 5) _______________________________________________ mpi-forum mailing list mpi-forum(a)lists.mpi-forum.org<mailto:[email protected]> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum

1 0

Re: [Mpi-forum] Giving up on C11 _Generic
by Jim Dinan 07 Aug '19

07 Aug '19

That case should not have the implicit type conversion issue that Joseph raised and should be fine without the extra macro when _Generic is unsupported. On Wed, Aug 7, 2019, 5:43 PM Jeff Hammond <jeff.science(a)gmail.com> wrote: > You can't do that forwarding for vectors of counts. > > On Wed, Aug 7, 2019 at 2:10 PM Jim Dinan via mpi-forum < > mpi-forum(a)lists.mpi-forum.org> wrote: > >> Even simpler than this, we could just forward all calls to the MPI_Count >> interface (see below). The int count argument should type convert to >> MPI_Count without issue. Note that it still needs to be a function-like >> macro so that function pointers work. >> >> Don't give up yet! :D >> >> ~Jim. >> >> #include <stdio.h> >> >> >> >> typedef int MPI_Datatype; >> >> typedef int MPI_Comm; >> >> >> int MPI_Send(const void* buf, int count, MPI_Datatype datatype, int dest, >> >> int tag, MPI_Comm comm) >> >> { >> >> printf("MPI_Send(count = %d)\n", count); >> >> return 0; >> >> } >> >> >> int MPI_Send_x(const void* buf, long long count, MPI_Datatype datatype, >> int dest, >> >> int tag, MPI_Comm comm) >> >> { >> >> printf("MPI_Send_x(count = %lld)\n", count); >> >> return 0; >> >> } >> >> >> #define MPI_Send(buf, count, datatype, dest, tag, comm) MPI_Send_x(buf, >> count, datatype, dest, tag, comm) >> >> >> int main(int argc, char *argv[]) { >> >> /* 8589934592LL == 2^33 */ >> >> long long i = 8589934592LL + 11; >> >> int ret; >> >> int (*snd_ptr)(const void*, int, MPI_Datatype, int, int, MPI_Comm) = >> &MPI_Send; >> >> ret = MPI_Send(NULL, i, 0, 0, 0, 0); >> >> ret = MPI_Send(NULL, 5, 0, 0, 0, 0); >> >> ret = (*snd_ptr)(NULL, i, 0, 0, 0, 0); >> >> ret = (*snd_ptr)(NULL, 5, 0, 0, 0, 0); >> >> return 0; >> >> } >> >> >> MPI_Send_x(count = 8589934603) >> >> MPI_Send_x(count = 5) >> >> MPI_Send(count = 11) >> >> MPI_Send(count = 5) >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum >> > > > -- > Jeff Hammond > jeff.science(a)gmail.com > http://jeffhammond.github.io/ >

1 0

Re: [Mpi-forum] Giving up on C11 _Generic
by Jeff Hammond 07 Aug '19

07 Aug '19

You can't do that forwarding for vectors of counts. On Wed, Aug 7, 2019 at 2:10 PM Jim Dinan via mpi-forum < mpi-forum(a)lists.mpi-forum.org> wrote: > Even simpler than this, we could just forward all calls to the MPI_Count > interface (see below). The int count argument should type convert to > MPI_Count without issue. Note that it still needs to be a function-like > macro so that function pointers work. > > Don't give up yet! :D > > ~Jim. > > #include <stdio.h> > > > > typedef int MPI_Datatype; > > typedef int MPI_Comm; > > > int MPI_Send(const void* buf, int count, MPI_Datatype datatype, int dest, > > int tag, MPI_Comm comm) > > { > > printf("MPI_Send(count = %d)\n", count); > > return 0; > > } > > > int MPI_Send_x(const void* buf, long long count, MPI_Datatype datatype, > int dest, > > int tag, MPI_Comm comm) > > { > > printf("MPI_Send_x(count = %lld)\n", count); > > return 0; > > } > > > #define MPI_Send(buf, count, datatype, dest, tag, comm) MPI_Send_x(buf, > count, datatype, dest, tag, comm) > > > int main(int argc, char *argv[]) { > > /* 8589934592LL == 2^33 */ > > long long i = 8589934592LL + 11; > > int ret; > > int (*snd_ptr)(const void*, int, MPI_Datatype, int, int, MPI_Comm) = > &MPI_Send; > > ret = MPI_Send(NULL, i, 0, 0, 0, 0); > > ret = MPI_Send(NULL, 5, 0, 0, 0, 0); > > ret = (*snd_ptr)(NULL, i, 0, 0, 0, 0); > > ret = (*snd_ptr)(NULL, 5, 0, 0, 0, 0); > > return 0; > > } > > > MPI_Send_x(count = 8589934603) > > MPI_Send_x(count = 5) > > MPI_Send(count = 11) > > MPI_Send(count = 5) > _______________________________________________ > mpi-forum mailing list > mpi-forum(a)lists.mpi-forum.org > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

Re: [Mpi-forum] Giving up on C11 _Generic
by Jim Dinan 07 Aug '19

07 Aug '19

Even simpler than this, we could just forward all calls to the MPI_Count interface (see below). The int count argument should type convert to MPI_Count without issue. Note that it still needs to be a function-like macro so that function pointers work. Don't give up yet! :D ~Jim. #include <stdio.h> typedef int MPI_Datatype; typedef int MPI_Comm; int MPI_Send(const void* buf, int count, MPI_Datatype datatype, int dest, int tag, MPI_Comm comm) { printf("MPI_Send(count = %d)\n", count); return 0; } int MPI_Send_x(const void* buf, long long count, MPI_Datatype datatype, int dest, int tag, MPI_Comm comm) { printf("MPI_Send_x(count = %lld)\n", count); return 0; } #define MPI_Send(buf, count, datatype, dest, tag, comm) MPI_Send_x(buf, count, datatype, dest, tag, comm) int main(int argc, char *argv[]) { /* 8589934592LL == 2^33 */ long long i = 8589934592LL + 11; int ret; int (*snd_ptr)(const void*, int, MPI_Datatype, int, int, MPI_Comm) = &MPI_Send; ret = MPI_Send(NULL, i, 0, 0, 0, 0); ret = MPI_Send(NULL, 5, 0, 0, 0, 0); ret = (*snd_ptr)(NULL, i, 0, 0, 0, 0); ret = (*snd_ptr)(NULL, 5, 0, 0, 0, 0); return 0; } MPI_Send_x(count = 8589934603) MPI_Send_x(count = 5) MPI_Send(count = 11) MPI_Send(count = 5)

1 0

Re: [Mpi-forum] Giving up on C11 _Generic
by Jim Dinan 07 Aug '19

07 Aug '19

This example is a bit more representative of how we would use this to implement the MPI bindings (renamed "bar" macro to "foo" and shifted down to enable the name aliasing): #include <stdio.h> static void foo(int j) { printf("foo(j) = %d\n", j); } #define foo(j) foo(sizeof(j) > sizeof(int) ? -1 : j) int main(int argc, char *argv[]) { /* 8589934592LL == 2^33 */ long long i = 8589934592LL + 11; foo(i); return 0; } foo(j) = -1 ~Jim. On Wed, Aug 7, 2019 at 4:16 PM Jim Dinan <james.dinan(a)gmail.com> wrote: > Jeff, > > You can wrap the function in a macro that checks for truncation: > > #include <stdio.h> > > > > #define bar(j) foo(sizeof(j) > sizeof(int) ? -1 : j) > > > static void foo(int j) { > > printf("foo(j) = %d\n", j); > > } > > > int main(int argc, char *argv[]) { > > /* 8589934592LL == 2^33 */ > > long long i = 8589934592LL + 11; > > foo(i); > > bar(i); > > return 0; > > } > > foo(j) = 11 > > foo(j) = -1 > > ~Jim. > > On Wed, Aug 7, 2019 at 9:59 AM Jeff Squyres (jsquyres) via mpi-forum < > mpi-forum(a)lists.mpi-forum.org> wrote: > >> SHORT VERSION >> ============= >> >> Due to the possibility of silently introducing errors into user >> applications, the BigCount WG no longer thinks that C11 _Generic is a good >> idea. We are therefore dropping that from our proposal. The new proposal >> will therefore essentially just be the addition of a bunch of >> MPI_Count-enabled "_x" functions in C, combined with the addition of a >> bunch of polymorphic MPI_Count-enabled interfaces in Fortran. >> >> MORE DETAIL >> =========== >> >> Joseph Schuchart raised a very important point in a recent mailing >> thread: the following C/C++ code does not raise a compiler warning: >> >> ----- >> #include <stdio.h> >> >> static void foo(int j) { >> printf("foo(j) = %d\n", j); >> } >> >> int main(int argc, char *argv[]) { >> /* 8589934592LL == 2^33 */ >> long long i = 8589934592LL + 11; >> foo(i); >> return 0; >> } >> ----- >> >> If you compile and run this program on a commodity x86-64 platform, a) >> you won't get a warning from the compiler, and b) you'll see "11" printed >> out. I tried with gcc 9 and clang 8 -- both with the C and C++ compilers. >> I even tried with "-Wall -pedantic". No warnings. >> >> This is because casting from a larger int type to a smaller int type is >> perfectly valid C/C++. >> >> Because of this, there is a possibility that we could be silently >> introducing errors into user applications. Consider: >> >> 1. An application upgrades its "count" parameters to type MPI_Count for >> all calls to MPI_Send. >> --> Recall that "MPI_Count" already exists in MPI-3.1, and is likely >> of type (long long) on commodity x86-64 platforms >> 2. The application then uses values in that "count" parameter that are >> greater than 2^32. >> >> If the user's MPI implementation and compiler both support C11 _Generic, >> everything is great. >> >> But if either the MPI implementation or the compiler do not support C11 >> _Generic, ***the "count" value will be silently truncated at run time***. >> >> This seems like a very bad idea, from a design standpoint. >> >> We have therefore come full circle: we are back to adding a bunch of "_x" >> functions for C, and there will be no polymorphism (in C). Sorry, folks. >> >> Note that Fortran does not have similar problems: >> >> 1. Fortran compilers have supported polymorphism for 20+ years >> 2. Fortran does not automatically cast between INTEGER values of >> different sizes >> >> After much debate, the BigCount WG has decided that C11 _Generic just >> isn't worth it. That's no reason to penalize Fortran, though. >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum >> >

1 0