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

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

07 Aug '19

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

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

07 Aug '19

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> 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 > -- Jeff Hammond jeff.science(a)gmail.com http://jeffhammond.github.io/

1 0

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

07 Aug '19

Jeff, I don't think we all agree 100% to abandon C11 _Generic, and let me feedback to you what you write below for further argumentation; I am a bit surprised this is in front of the whole forum just one day after WG discussions, when more WG discussions are still in order weeks before the finalization of our proposals for Zurich. This statement alone "But if either the MPI implementation or the compiler do not support C11 _Generic, ***the "count" value will be silently truncated at run time***." is not a sufficient reason for abandoning C11 _Generic. 1) MPI Implementations have to either support MPI-4 or not; it would not be optional. Therefore the MPI implementation is incomplete. Therefore this is not a reason to abandon C11. 2) If the compiler environment doesn't support C11 _Generic, then the build process for MPI would have to warn the user or that kind of platform would be impossible to use with MPI-4. Seems harsh for non-compliant compilers. These are not sufficient conditions alone for abandoning C11 _Generic. 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? Do you have other reasons that I've missed or you don't cite below besides a) non-compliant MPI implementation, b) non-compliant C11 compiler for abandoning this feature? These are both reasons that an MPI program would not do what it should. But you also write "If the user's MPI implementation and compiler both support C11 _Generic, everything is great." I realize that I was not on the full meetings recently, but this major change of heart, although shared by others on the phone yesterday, is not unanimous (and not everyone spoke up). Maybe I am missing deeper arguments, because you yourself say that correct implementation with a correct compiler produces valid outcomes. Notice how this kind of problem with Long vs. int exists in the C interface currently; whenever you have a long long int argument, and you pass this to a current C API that takes an int (for a count), this truncation occurs. Do you agree? Help me to understand better why we should overthrow this approach. Regards, Tony 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 > -- Tony Skjellum, PhD RunTime Computing Solutions, LLC tony(a)runtimecomputing.com direct: +1-423-713-9337 cell: +1-205-807-4968

1 0

Giving up on C11 _Generic
by Jeff Squyres (jsquyres) 07 Aug '19

07 Aug '19

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

1 0

Re: [Mpi-forum] "BigCount" rendering in PDF
by N.M. Maclaren 02 Aug '19

02 Aug '19

On Aug 2 2019, Joseph Schuchart via mpi-forum wrote: > > > In any case, we can't design MPI around ignorant users who don't read >about features they're using. > >I'm not advocating to change the design, i.e., I'm not arguing against >having C11 _Generic selectors. I just think it would be beneficial to >clearly mark the potential caveat. Yes, precisely. It would also be possible to design in defences against this gotcha. In my view, the most likely cause of this is the C++ one described below, because I believe that the majority of users who call MPI from a C-like language now do it from C++. Regards, Nick Maclaren. But, back to Jeff Hammond's and your postings. You have described the language situation correctly, though it's actually worse than that. Let's start with correcting some misapprehensions (not yours). As I said, this is NOT about the compilers. This is NOT about MY code - inter alia, I would add code to test the version before depending on this, and I have been writing code that will run under multiple C languages (and more) since the early 1990s, as well as advising other people how to do it. The days when most MPI users programmed MPI calls in C are long, long gone. The vast majority use another mechanism, sometimes C++, sometimes via a pre-processor, sometimes a package. Similarly, the days when most programmers were in control of their environment are long gone - yes, it's true for the happy hackers who dominate many forums, but is not for the users. Lastly, this is NOT about users being ignorant. It's about them taking only ordinary care and having only an ordinary skillset which, in this case, is NOT enough. Examples of when users could be dropped into C99 mode without realising it include: The MPI-calling library (or even MPI) they are using was compiled that way. The ghoulishly inscrutable build mechanism for the package they are using does it. They are using MPI via a C++ compiler and the C interface, which I believe now dominates the use of a C compiler. From the C++17 standard: "Whether __STDC__ is predefined and if so, what its value is, are implementation-defined." It says the same about __STD_VERSION__. The translation of that is that a C++ compiler may implement ANY version of C, subject to a few other constraints. And they do. Also, they may be using some OTHER library that requires a specific, older version of C, or their 'house standards' require it, but one hopes that they realise they are not using C11, if so. However, even if they do, it is unreasonable to expect users to have the deep knowledge of the standards and advanced skills to defend themselves against version problems. Now, why do sites not upgrade? There are many reasons, including that a compiler or library upgrade may require a complete revalidation of their development system - which is often many months's work for their entire development team. Or the non-availability of new versions of (often just one) critical component. Or expense. Or just plain "If it ain't broke, don't fix it." All are common, and there are many more.

1 0

Re: [Mpi-forum] "BigCount" rendering in PDF
by Joseph Schuchart 02 Aug '19

02 Aug '19

> Are you saying that a C99 compiler won’t complaint if the user passes a 64b int to a 32b int argument? That’s a pretty stupid compiler if you ask me. It is perfectly valid in C *and* C++ to pass a 64bit integer value as an argument to a 32bit integer parameter. The 64bit integer value will be converted to 32bit integer and thus potentially truncated. Depending on the original value this may result in a negative or positive 32bit signed integer value so depending on the size you want to send, MPI_Send may or may not detect the overflow. Passing a pointer to a 64bit integer (int64_t*) for a parameter that is a pointer to a 32bit integer (int32_t*) is a bit different. In C, this is still valid and the compiler will only issue a warning about the type mismatch. C++ handles types stricter and pointers are not implicitly converted. > I’m fine with putting MPI C11 in separate header that can #error if C11 isn’t supported. I don't have a strong opinion on this and I don't know if this (and the implications of introducing a new header file) has been discussed in the forum already. Maybe Jeff S has considered this already? > In any case, we can’t design MPI around ignorant users who don’t read about features they’re using. I'm not advocating to change the design, i.e., I'm not arguing against having C11 _Generic selectors. I just think it would be beneficial to clearly mark the potential caveat. Joseph On 8/2/19 7:19 AM, Jeff Hammond wrote: > Are you saying that a C99 compiler won’t complaint if the user passes a > 64b int to a 32b int argument? That’s a pretty stupid compiler if you > ask me. > > I’m fine with putting MPI C11 in separate header that can #error if C11 > isn’t supported. That’s a pretty obvious user experience win that costs > nothing. We are basically doing that for Fortran already. > > Maclaren can just skip C11 and teach MPI in Fortran 2008 or C99 with the > _x symbols if the C11 is too scary. > > In any case, we can’t design MPI around ignorant users who don’t read > about features they’re using. Doing so makes it impossible to do > anything at all because there’s always somebody too ignorant to use some > feature correctly, and the union of the ignorance covers all nontrivial > changes. > > Jeff > > On Thu, Aug 1, 2019 at 7:28 AM Joseph Schuchart via mpi-forum > <mpi-forum(a)lists.mpi-forum.org <mailto:[email protected]>> > wrote: > > I think the point he wanted to make was that you won't see a > compile-time error if you /think/ you're using the MPI_Count overloads > but are in fact not, i.e., you are modernizing a legacy code base that > is stuck in the nineties and you introduce MPI_Count for size arguments > because the standard says you may do so now without a clear warning > that > this is only possible if you bump to C11. The compiler won't warn you, > the MPI standard may mention it in a subsection somewhere, which of > course you didn't read because you haven't had the time to read all ~1k > pages of 4.0, yet. Having a clear note attached to listings that these > overloads are constrained to C11 may help reduce the risk of > introducing > another caveat. MPI developers may be (more) familiar with the > differences between C99 and C11 but the average developer of HPC > software likely is not. And there are plenty of codes out there that > constrain themselves to ancient language versions, for reasons unknown > to me... > > Joseph > > On 8/1/19 12:56 PM, Jeff Hammond via mpi-forum wrote: > > That’s why there will be C90/C99 compatible symbols as well. If > you don’t like C11, don’t use it. Nothing will happen. BigCount will > still work. > > > > C11 has been the default in GCC and Clang for a while. What > compilers are going to limit users to C99 for years to come? > > > > Jeff > > > >> On Aug 1, 2019, at 3:23 AM, N.M. Maclaren via mpi-forum > <mpi-forum(a)lists.mpi-forum.org > <mailto:[email protected]>> wrote: > >> > >>> On Jul 30 2019, Jeff Squyres (jsquyres) via mpi-forum wrote: > >>> > >>> B. C11 _Generic polymorphism kinda sucks, *and* we're in a > transition period where not all C compilers are C11-capable. Hence, > we're exposing up to *3* C bindings per MPI procedure to > applications (including explicitly exposing the "_x" variant where > relevant). > >> > >> This following point may have already been debated, so please > excuse me if > >> has. Let's skip the politics, for the sake of all our blood > pressures. > >> > >> The executive summary is that the failure mode pointed out by Joseph > >> Schuchart is going to be a very, very serious problem for > BigCount users, > >> and continue for the forseeable future. I would guess until at > least > >> 2025, and possibly long after that. > >> > >> Speaking as someone who may be teaching MPI programming again, > with an > >> emphasis on reliability and portability, I would almost > certainly add > >> warnings that would be, roughly: "Don't touch BigCount if you > can find a > >> way round it; and be paranoid about it if you use it." I > already do that > >> about I/O attributes, for similar reasons. That isn't good. > >> > >> I don't know how you would document that, but the MPI standard > already > >> has gotchas that aren't easy to find, and adding another one > isn't good, > >> either. > >> > >> The explanation: > >> > >> C99 was not received favourably by most of the C-using community > (I don't > >> mean compilers here). I tracked a dozen important, active > projects, and > >> it was 2010/11 (yes, over a decade) before even half of them > converted > >> from C90 to C99 as a base. I last checked a few years ago, but > quite a > >> few C99 features were still not reliably available in compilers; > I know > >> that many of the ones I found still aren't. Courses are another > problem, > >> because they rarely include warnings about gotchas caused by > standards > >> differences (and there are lots between C90 and C99). > >> > >> I haven't tracked C11 as carefully, but the evidence I have seen > is that it > >> received even less interest and acceptance than C99, so people > are going > >> to be using C99 compilers for a LONG time yet. There is also > the problem > >> that C is not a language that is upwards compatible between > versions, but > >> C++ takes more notice, so C++ compilers' C support (which is > arguably more > >> important than direct C support, because people call MPI using > C++'s C > >> interface) is often in conflict. This is almost certainly a > case where > >> that will be true, but it may not affect these interfaces - I > can't say. > >> > >> The result is that C code (and, worse, libraries) often require > specific > >> versions (i.e. not just 'any standard later than'). I agree that > it looks > >> likely that generic interfaces are going to be one of the more > widely > >> implemented parts of C99, but don't discount the problem of > people using > >> multiple libraries where other ones constrain the C version for > other > >> reasons. > >> > >> _______________________________________________ > >> mpi-forum mailing list > >> mpi-forum(a)lists.mpi-forum.org <mailto:[email protected]> > >> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum > > _______________________________________________ > > mpi-forum mailing list > > mpi-forum(a)lists.mpi-forum.org <mailto:[email protected]> > > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum > > > _______________________________________________ > 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/

1 0

Re: [Mpi-forum] "BigCount" rendering in PDF
by Jeff Hammond 02 Aug '19

02 Aug '19

Are you saying that a C99 compiler won’t complaint if the user passes a 64b int to a 32b int argument? That’s a pretty stupid compiler if you ask me. I’m fine with putting MPI C11 in separate header that can #error if C11 isn’t supported. That’s a pretty obvious user experience win that costs nothing. We are basically doing that for Fortran already. Maclaren can just skip C11 and teach MPI in Fortran 2008 or C99 with the _x symbols if the C11 is too scary. In any case, we can’t design MPI around ignorant users who don’t read about features they’re using. Doing so makes it impossible to do anything at all because there’s always somebody too ignorant to use some feature correctly, and the union of the ignorance covers all nontrivial changes. Jeff On Thu, Aug 1, 2019 at 7:28 AM Joseph Schuchart via mpi-forum < mpi-forum(a)lists.mpi-forum.org> wrote: > I think the point he wanted to make was that you won't see a > compile-time error if you /think/ you're using the MPI_Count overloads > but are in fact not, i.e., you are modernizing a legacy code base that > is stuck in the nineties and you introduce MPI_Count for size arguments > because the standard says you may do so now without a clear warning that > this is only possible if you bump to C11. The compiler won't warn you, > the MPI standard may mention it in a subsection somewhere, which of > course you didn't read because you haven't had the time to read all ~1k > pages of 4.0, yet. Having a clear note attached to listings that these > overloads are constrained to C11 may help reduce the risk of introducing > another caveat. MPI developers may be (more) familiar with the > differences between C99 and C11 but the average developer of HPC > software likely is not. And there are plenty of codes out there that > constrain themselves to ancient language versions, for reasons unknown > to me... > > Joseph > > On 8/1/19 12:56 PM, Jeff Hammond via mpi-forum wrote: > > That’s why there will be C90/C99 compatible symbols as well. If you > don’t like C11, don’t use it. Nothing will happen. BigCount will still work. > > > > C11 has been the default in GCC and Clang for a while. What compilers > are going to limit users to C99 for years to come? > > > > Jeff > > > >> On Aug 1, 2019, at 3:23 AM, N.M. Maclaren via mpi-forum < > mpi-forum(a)lists.mpi-forum.org> wrote: > >> > >>> On Jul 30 2019, Jeff Squyres (jsquyres) via mpi-forum wrote: > >>> > >>> B. C11 _Generic polymorphism kinda sucks, *and* we're in a transition > period where not all C compilers are C11-capable. Hence, we're exposing up > to *3* C bindings per MPI procedure to applications (including explicitly > exposing the "_x" variant where relevant). > >> > >> This following point may have already been debated, so please excuse me > if > >> has. Let's skip the politics, for the sake of all our blood pressures. > >> > >> The executive summary is that the failure mode pointed out by Joseph > >> Schuchart is going to be a very, very serious problem for BigCount > users, > >> and continue for the forseeable future. I would guess until at least > >> 2025, and possibly long after that. > >> > >> Speaking as someone who may be teaching MPI programming again, with an > >> emphasis on reliability and portability, I would almost certainly add > >> warnings that would be, roughly: "Don't touch BigCount if you can find a > >> way round it; and be paranoid about it if you use it." I already do > that > >> about I/O attributes, for similar reasons. That isn't good. > >> > >> I don't know how you would document that, but the MPI standard already > >> has gotchas that aren't easy to find, and adding another one isn't good, > >> either. > >> > >> The explanation: > >> > >> C99 was not received favourably by most of the C-using community (I > don't > >> mean compilers here). I tracked a dozen important, active projects, and > >> it was 2010/11 (yes, over a decade) before even half of them converted > >> from C90 to C99 as a base. I last checked a few years ago, but quite a > >> few C99 features were still not reliably available in compilers; I know > >> that many of the ones I found still aren't. Courses are another > problem, > >> because they rarely include warnings about gotchas caused by standards > >> differences (and there are lots between C90 and C99). > >> > >> I haven't tracked C11 as carefully, but the evidence I have seen is > that it > >> received even less interest and acceptance than C99, so people are going > >> to be using C99 compilers for a LONG time yet. There is also the > problem > >> that C is not a language that is upwards compatible between versions, > but > >> C++ takes more notice, so C++ compilers' C support (which is arguably > more > >> important than direct C support, because people call MPI using C++'s C > >> interface) is often in conflict. This is almost certainly a case where > >> that will be true, but it may not affect these interfaces - I can't say. > >> > >> The result is that C code (and, worse, libraries) often require specific > >> versions (i.e. not just 'any standard later than'). I agree that it > looks > >> likely that generic interfaces are going to be one of the more widely > >> implemented parts of C99, but don't discount the problem of people using > >> multiple libraries where other ones constrain the C version for other > >> reasons. > >> > >> _______________________________________________ > >> mpi-forum mailing list > >> mpi-forum(a)lists.mpi-forum.org > >> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum > > _______________________________________________ > > mpi-forum mailing list > > mpi-forum(a)lists.mpi-forum.org > > https://lists.mpi-forum.org/mailman/listinfo/mpi-forum > > > _______________________________________________ > 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] "BigCount" rendering in PDF
by Joseph Schuchart 01 Aug '19

01 Aug '19

I think the point he wanted to make was that you won't see a compile-time error if you /think/ you're using the MPI_Count overloads but are in fact not, i.e., you are modernizing a legacy code base that is stuck in the nineties and you introduce MPI_Count for size arguments because the standard says you may do so now without a clear warning that this is only possible if you bump to C11. The compiler won't warn you, the MPI standard may mention it in a subsection somewhere, which of course you didn't read because you haven't had the time to read all ~1k pages of 4.0, yet. Having a clear note attached to listings that these overloads are constrained to C11 may help reduce the risk of introducing another caveat. MPI developers may be (more) familiar with the differences between C99 and C11 but the average developer of HPC software likely is not. And there are plenty of codes out there that constrain themselves to ancient language versions, for reasons unknown to me... Joseph On 8/1/19 12:56 PM, Jeff Hammond via mpi-forum wrote: > That’s why there will be C90/C99 compatible symbols as well. If you don’t like C11, don’t use it. Nothing will happen. BigCount will still work. > > C11 has been the default in GCC and Clang for a while. What compilers are going to limit users to C99 for years to come? > > Jeff > >> On Aug 1, 2019, at 3:23 AM, N.M. Maclaren via mpi-forum <mpi-forum(a)lists.mpi-forum.org> wrote: >> >>> On Jul 30 2019, Jeff Squyres (jsquyres) via mpi-forum wrote: >>> >>> B. C11 _Generic polymorphism kinda sucks, *and* we're in a transition period where not all C compilers are C11-capable. Hence, we're exposing up to *3* C bindings per MPI procedure to applications (including explicitly exposing the "_x" variant where relevant). >> >> This following point may have already been debated, so please excuse me if >> has. Let's skip the politics, for the sake of all our blood pressures. >> >> The executive summary is that the failure mode pointed out by Joseph >> Schuchart is going to be a very, very serious problem for BigCount users, >> and continue for the forseeable future. I would guess until at least >> 2025, and possibly long after that. >> >> Speaking as someone who may be teaching MPI programming again, with an >> emphasis on reliability and portability, I would almost certainly add >> warnings that would be, roughly: "Don't touch BigCount if you can find a >> way round it; and be paranoid about it if you use it." I already do that >> about I/O attributes, for similar reasons. That isn't good. >> >> I don't know how you would document that, but the MPI standard already >> has gotchas that aren't easy to find, and adding another one isn't good, >> either. >> >> The explanation: >> >> C99 was not received favourably by most of the C-using community (I don't >> mean compilers here). I tracked a dozen important, active projects, and >> it was 2010/11 (yes, over a decade) before even half of them converted >> from C90 to C99 as a base. I last checked a few years ago, but quite a >> few C99 features were still not reliably available in compilers; I know >> that many of the ones I found still aren't. Courses are another problem, >> because they rarely include warnings about gotchas caused by standards >> differences (and there are lots between C90 and C99). >> >> I haven't tracked C11 as carefully, but the evidence I have seen is that it >> received even less interest and acceptance than C99, so people are going >> to be using C99 compilers for a LONG time yet. There is also the problem >> that C is not a language that is upwards compatible between versions, but >> C++ takes more notice, so C++ compilers' C support (which is arguably more >> important than direct C support, because people call MPI using C++'s C >> interface) is often in conflict. This is almost certainly a case where >> that will be true, but it may not affect these interfaces - I can't say. >> >> The result is that C code (and, worse, libraries) often require specific >> versions (i.e. not just 'any standard later than'). I agree that it looks >> likely that generic interfaces are going to be one of the more widely >> implemented parts of C99, but don't discount the problem of people using >> multiple libraries where other ones constrain the C version for other >> reasons. >> >> _______________________________________________ >> mpi-forum mailing list >> mpi-forum(a)lists.mpi-forum.org >> https://lists.mpi-forum.org/mailman/listinfo/mpi-forum > _______________________________________________ > 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] "BigCount" rendering in PDF
by Jeff Hammond 01 Aug '19

01 Aug '19

That’s why there will be C90/C99 compatible symbols as well. If you don’t like C11, don’t use it. Nothing will happen. BigCount will still work. C11 has been the default in GCC and Clang for a while. What compilers are going to limit users to C99 for years to come? Jeff > On Aug 1, 2019, at 3:23 AM, N.M. Maclaren via mpi-forum <mpi-forum(a)lists.mpi-forum.org> wrote: > >> On Jul 30 2019, Jeff Squyres (jsquyres) via mpi-forum wrote: >> >> B. C11 _Generic polymorphism kinda sucks, *and* we're in a transition period where not all C compilers are C11-capable. Hence, we're exposing up to *3* C bindings per MPI procedure to applications (including explicitly exposing the "_x" variant where relevant). > > This following point may have already been debated, so please excuse me if > has. Let's skip the politics, for the sake of all our blood pressures. > > The executive summary is that the failure mode pointed out by Joseph > Schuchart is going to be a very, very serious problem for BigCount users, > and continue for the forseeable future. I would guess until at least > 2025, and possibly long after that. > > Speaking as someone who may be teaching MPI programming again, with an > emphasis on reliability and portability, I would almost certainly add > warnings that would be, roughly: "Don't touch BigCount if you can find a > way round it; and be paranoid about it if you use it." I already do that > about I/O attributes, for similar reasons. That isn't good. > > I don't know how you would document that, but the MPI standard already > has gotchas that aren't easy to find, and adding another one isn't good, > either. > > The explanation: > > C99 was not received favourably by most of the C-using community (I don't > mean compilers here). I tracked a dozen important, active projects, and > it was 2010/11 (yes, over a decade) before even half of them converted > from C90 to C99 as a base. I last checked a few years ago, but quite a > few C99 features were still not reliably available in compilers; I know > that many of the ones I found still aren't. Courses are another problem, > because they rarely include warnings about gotchas caused by standards > differences (and there are lots between C90 and C99). > > I haven't tracked C11 as carefully, but the evidence I have seen is that it > received even less interest and acceptance than C99, so people are going > to be using C99 compilers for a LONG time yet. There is also the problem > that C is not a language that is upwards compatible between versions, but > C++ takes more notice, so C++ compilers' C support (which is arguably more > important than direct C support, because people call MPI using C++'s C > interface) is often in conflict. This is almost certainly a case where > that will be true, but it may not affect these interfaces - I can't say. > > The result is that C code (and, worse, libraries) often require specific > versions (i.e. not just 'any standard later than'). I agree that it looks > likely that generic interfaces are going to be one of the more widely > implemented parts of C99, but don't discount the problem of people using > multiple libraries where other ones constrain the C version for other > reasons. > > _______________________________________________ > 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] "BigCount" rendering in PDF
by N.M. Maclaren 01 Aug '19

01 Aug '19

On Jul 30 2019, Jeff Squyres (jsquyres) via mpi-forum wrote: > > B. C11 _Generic polymorphism kinda sucks, *and* we're in a transition > period where not all C compilers are C11-capable. Hence, we're exposing > up to *3* C bindings per MPI procedure to applications (including > explicitly exposing the "_x" variant where relevant). This following point may have already been debated, so please excuse me if has. Let's skip the politics, for the sake of all our blood pressures. The executive summary is that the failure mode pointed out by Joseph Schuchart is going to be a very, very serious problem for BigCount users, and continue for the forseeable future. I would guess until at least 2025, and possibly long after that. Speaking as someone who may be teaching MPI programming again, with an emphasis on reliability and portability, I would almost certainly add warnings that would be, roughly: "Don't touch BigCount if you can find a way round it; and be paranoid about it if you use it." I already do that about I/O attributes, for similar reasons. That isn't good. I don't know how you would document that, but the MPI standard already has gotchas that aren't easy to find, and adding another one isn't good, either. The explanation: C99 was not received favourably by most of the C-using community (I don't mean compilers here). I tracked a dozen important, active projects, and it was 2010/11 (yes, over a decade) before even half of them converted from C90 to C99 as a base. I last checked a few years ago, but quite a few C99 features were still not reliably available in compilers; I know that many of the ones I found still aren't. Courses are another problem, because they rarely include warnings about gotchas caused by standards differences (and there are lots between C90 and C99). I haven't tracked C11 as carefully, but the evidence I have seen is that it received even less interest and acceptance than C99, so people are going to be using C99 compilers for a LONG time yet. There is also the problem that C is not a language that is upwards compatible between versions, but C++ takes more notice, so C++ compilers' C support (which is arguably more important than direct C support, because people call MPI using C++'s C interface) is often in conflict. This is almost certainly a case where that will be true, but it may not affect these interfaces - I can't say. The result is that C code (and, worse, libraries) often require specific versions (i.e. not just 'any standard later than'). I agree that it looks likely that generic interfaces are going to be one of the more widely implemented parts of C99, but don't discount the problem of people using multiple libraries where other ones constrain the C version for other reasons.

1 0