From rabenseifner at [hidden] Mon Aug 3 10:50:16 2009 From: rabenseifner at [hidden] (Rolf Rabenseifner) Date: Mon, 03 Aug 2009 17:50:16 +0200 Subject: [Mpi-22] Borderline ticket #107: Types of predefined constants in Appendix A In-Reply-To: <063.e45115c60b785c1b307e3c015455315b@lists.mpi-forum.org> Message-ID: Dear all, ticket 107 was the only passed ticket with more no + abstain + miss votes than yes votes. MPI-2.1 had only C++ type information in this Appendix. With this ticket, C and Fortran type information is added to achieve consistency between all language bindings. I've implemented it and https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/107/appLang-ticket107-more-readable.pdf gives you an impression of the final (uncolored) document. (The new advices in Section 6.7.2 are not yet implemented). I hope you can now live with the result. If you would voted now with yes (based on the pdf), but you haven't voted yes at the meeting, then a short reply would be fine. The same of course if you now disagree with your yes at the meeting. Best regards Rolf Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) From erezh at [hidden] Mon Aug 3 12:36:42 2009 From: erezh at [hidden] (Erez Haba) Date: Mon, 3 Aug 2009 17:36:42 +0000 Subject: [Mpi-22] Borderline ticket #107: Types of predefined constants in Appendix A In-Reply-To: Message-ID: <85287355FA6D5646A8A8A083CE185EEB02EF8FF0@TK5EX14MBXC116.redmond.corp.microsoft.com> This might be nitpicking but wouldn't that force implementation to typecast their definition of error codes? For example, #define MPI_ERR_BUFFER 0 Is not a correct definition with the proposed change, because it is not typed. Thus, it needs to change to #define MPI_ERR_BUFFER (int)0 // you don't really need to define it as (const int)0 as a result the following statement short x = MPI_ERR_BUFFER; which compiled correctly before, would break with this change. Second comment. Adding the 'const' modifier to all types is very confusing imho. I understand that it meant to make it clear that the values are constants and should not change, but still is very confusing. For example, C Type: void * const MPI_BOTTOM This means that the value of MPI_BOTTOM is constant and not the memory it points to. however at first look you might think that it's the later. (if it was, it would break any application that uses it because the API's do not take a pointer to const void) In any case implementers should define MPI_BOTTOM as #define MPI_BOTTOM (void*)0 Rather than #define MPI_BOTTOM (void* const)0 As the value is constant and you don't need to add the const modifier. Note that the 'constness' of these values is already stated in the title of the section '19.1.1 Defined Constants' Except for my comments above, the text formatting looks good to me. (I abstained at the meeting) Just my 2c, .Erez P.S.it looks odd that the int and void* types have const modifiers while mpi types do not; like MPI_Datatype. I think that this needs to be consistent. -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Rolf Rabenseifner Sent: Monday, August 03, 2009 8:50 AM To: MPI Forum Subject: [Mpi-22] Borderline ticket #107: Types of predefined constants in Appendix A Dear all, ticket 107 was the only passed ticket with more no + abstain + miss votes than yes votes. MPI-2.1 had only C++ type information in this Appendix. With this ticket, C and Fortran type information is added to achieve consistency between all language bindings. I've implemented it and https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/107/appLang-ticket107-more-readable.pdf gives you an impression of the final (uncolored) document. (The new advices in Section 6.7.2 are not yet implemented). I hope you can now live with the result. If you would voted now with yes (based on the pdf), but you haven't voted yes at the meeting, then a short reply would be fine. The same of course if you now disagree with your yes at the meeting. Best regards Rolf Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 From rabenseifner at [hidden] Mon Aug 3 13:04:00 2009 From: rabenseifner at [hidden] (Rolf Rabenseifner) Date: Mon, 03 Aug 2009 20:04:00 +0200 Subject: [Mpi-22] Borderline ticket #107: Types of predefined constants in Appendix A In-Reply-To: <85287355FA6D5646A8A8A083CE185EEB02EF8FF0@TK5EX14MBXC116.redmond.corp.microsoft.com> Message-ID: Hi Erez, I thought that the first colored sentence "Constants with the type const int may also be implemented as literal integer constants substituted by the preprocessor." allows to implement > #define MPI_ERR_BUFFER 0 Your second topic: I'm not a C const specialist. I filled only in what I got as input from the Forum. If something is really wrong, we should use the errata method as soon as possible. Best regards Rolf On Mon, 3 Aug 2009 17:36:42 +0000 Erez Haba wrote: > This might be nitpicking but wouldn't that force implementation to >typecast their definition of error codes? For example, > > #define MPI_ERR_BUFFER 0 > > Is not a correct definition with the proposed change, because it is >not typed. Thus, it needs to change to > > #define MPI_ERR_BUFFER (int)0 // you don't really need to define >it as (const int)0 > > as a result the following statement > > short x = MPI_ERR_BUFFER; > > which compiled correctly before, would break with this change. > > > Second comment. > > Adding the 'const' modifier to all types is very confusing imho. I >understand that it meant to make it clear that the values are >constants and should not change, but still is very confusing. > >For example, > > C Type: void * const > MPI_BOTTOM > > This means that the value of MPI_BOTTOM is constant and not the >memory it points to. however at first look you might think that it's >the later. (if it was, it would break any application that uses it >because the API's do not take a pointer to const void) > > In any case implementers should define MPI_BOTTOM as > > #define MPI_BOTTOM (void*)0 > > Rather than > > #define MPI_BOTTOM (void* const)0 > > As the value is constant and you don't need to add the const >modifier. > > > Note that the 'constness' of these values is already stated in the >title of the section '19.1.1 Defined Constants' > > > Except for my comments above, the text formatting looks good to me. >(I abstained at the meeting) > > Just my 2c, > .Erez > > > P.S.it looks odd that the int and void* types have const modifiers >while mpi types do not; like MPI_Datatype. I think that this needs to >be consistent. > > -----Original Message----- >From: mpi-22-bounces_at_[hidden] >[mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Rolf >Rabenseifner > Sent: Monday, August 03, 2009 8:50 AM > To: MPI Forum > Subject: [Mpi-22] Borderline ticket #107: Types of predefined >constants in Appendix A > > Dear all, > > ticket 107 was the only passed ticket with more no + abstain + miss > votes > than yes votes. > > MPI-2.1 had only C++ type information in this Appendix. > With this ticket, C and Fortran type information is added > to achieve consistency between all language bindings. > > I've implemented it and > https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/107/appLang-ticket107-more-readable.pdf > gives you an impression of the final (uncolored) document. > (The new advices in Section 6.7.2 are not yet implemented). > > I hope you can now live with the result. > > If you would voted now with yes (based on the pdf), > but you haven't voted yes at the meeting, > then a short reply would be fine. > > The same of course if you now disagree with your yes at the meeting. > > Best regards > Rolf > > Dr. Rolf Rabenseifner . . . . . . . . . .. email >rabenseifner_at_[hidden] > High Performance Computing Center (HLRS) . phone >++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / >685-65832 > Head of Dpmt Parallel Computing . . . >www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) From erezh at [hidden] Mon Aug 3 14:19:15 2009 From: erezh at [hidden] (Erez Haba) Date: Mon, 3 Aug 2009 19:19:15 +0000 Subject: [Mpi-22] Borderline ticket #107: Types of predefined constants in Appendix A In-Reply-To: Message-ID: <85287355FA6D5646A8A8A083CE185EEB02EF9117@TK5EX14MBXC116.redmond.corp.microsoft.com> Thanks. -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Rolf Rabenseifner Sent: Monday, August 03, 2009 11:04 AM To: MPI 2.2 Subject: Re: [Mpi-22] Borderline ticket #107: Types of predefined constants in Appendix A Hi Erez, I thought that the first colored sentence "Constants with the type const int may also be implemented as literal integer constants substituted by the preprocessor." allows to implement > #define MPI_ERR_BUFFER 0 [erezh] correct; however '#define MPI_ERR_BUFFER (int)0' is also an integer substituted by the pre-processor. I don't think that this sentence makes it clear enough. Your second topic: I'm not a C const specialist. I filled only in what I got as input from the Forum. If something is really wrong, we should use the errata method as soon as possible. [erezh] I was saying that it is confusing; I was not saying that the way you use const is wrong. >From my pov, it would be better to remove the 'consts' for C in this section. unlike C++ where it's actually of a const type variable; the C value can be a literal or a variable. Best regards Rolf On Mon, 3 Aug 2009 17:36:42 +0000 Erez Haba wrote: > This might be nitpicking but wouldn't that force implementation to >typecast their definition of error codes? For example, > > #define MPI_ERR_BUFFER 0 > > Is not a correct definition with the proposed change, because it is >not typed. Thus, it needs to change to > > #define MPI_ERR_BUFFER (int)0 // you don't really need to define >it as (const int)0 > > as a result the following statement > > short x = MPI_ERR_BUFFER; > > which compiled correctly before, would break with this change. > > > Second comment. > > Adding the 'const' modifier to all types is very confusing imho. I >understand that it meant to make it clear that the values are >constants and should not change, but still is very confusing. > >For example, > > C Type: void * const > MPI_BOTTOM > > This means that the value of MPI_BOTTOM is constant and not the >memory it points to. however at first look you might think that it's >the later. (if it was, it would break any application that uses it >because the API's do not take a pointer to const void) > > In any case implementers should define MPI_BOTTOM as > > #define MPI_BOTTOM (void*)0 > > Rather than > > #define MPI_BOTTOM (void* const)0 > > As the value is constant and you don't need to add the const >modifier. > > > Note that the 'constness' of these values is already stated in the >title of the section '19.1.1 Defined Constants' > > > Except for my comments above, the text formatting looks good to me. >(I abstained at the meeting) > > Just my 2c, > .Erez > > > P.S.it looks odd that the int and void* types have const modifiers >while mpi types do not; like MPI_Datatype. I think that this needs to >be consistent. > > -----Original Message----- >From: mpi-22-bounces_at_[hidden] >[mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Rolf >Rabenseifner > Sent: Monday, August 03, 2009 8:50 AM > To: MPI Forum > Subject: [Mpi-22] Borderline ticket #107: Types of predefined >constants in Appendix A > > Dear all, > > ticket 107 was the only passed ticket with more no + abstain + miss > votes > than yes votes. > > MPI-2.1 had only C++ type information in this Appendix. > With this ticket, C and Fortran type information is added > to achieve consistency between all language bindings. > > I've implemented it and > https://svn.mpi-forum.org/trac/mpi-forum-web/attachment/ticket/107/appLang-ticket107-more-readable.pdf > gives you an impression of the final (uncolored) document. > (The new advices in Section 6.7.2 are not yet implemented). > > I hope you can now live with the result. > > If you would voted now with yes (based on the pdf), > but you haven't voted yes at the meeting, > then a short reply would be fine. > > The same of course if you now disagree with your yes at the meeting. > > Best regards > Rolf > > Dr. Rolf Rabenseifner . . . . . . . . . .. email >rabenseifner_at_[hidden] > High Performance Computing Center (HLRS) . phone >++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / >685-65832 > Head of Dpmt Parallel Computing . . . >www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 From goodell at [hidden] Mon Aug 3 16:00:13 2009 From: goodell at [hidden] (Dave Goodell) Date: Mon, 3 Aug 2009 16:00:13 -0500 Subject: [Mpi-22] Borderline ticket #107: Types of predefined constants in Appendix A In-Reply-To: <85287355FA6D5646A8A8A083CE185EEB02EF8FF0@TK5EX14MBXC116.redmond.corp.microsoft.com> Message-ID: <799DA24B-6942-4290-A20C-C88A1FD253EE@mcs.anl.gov> On Aug 3, 2009, at 12:36 PM, Erez Haba wrote: > This might be nitpicking but wouldn't that force implementation to > typecast their definition of error codes? For example, > > #define MPI_ERR_BUFFER 0 > > Is not a correct definition with the proposed change, because it is > not typed. I think that the "Constants with the type const int may also be implemented as literal integer constants substituted by the preprocessor" bit on lines 23-24 helps implementors realize that they don't need to insert a cast here. Also, the type of the integer constant 0 is typed as the first integer type in {int, long int, long long int} that can express the value, which is required to be int in this particular case. > Thus, it needs to change to > > #define MPI_ERR_BUFFER (int)0 // you don't really need to define > it as (const int)0 > > as a result the following statement > > short x = MPI_ERR_BUFFER; > > which compiled correctly before, would break with this change. To the best of my knowledge this is still perfectly legitimate C. Section 6.5.16.1 of my copy of the C99 standard seems to corroborate this: -------8<-------- Semantics 2 In simple assignment (=), the value of the right operand is converted to the type of the assignment expression and replaces the value stored in the object designated by the left operand. -------8<-------- GCC doesn't give a warning for this assignment, even when you add a bunch of warning flags. It does warn if the value is something too large for the short type (like 0xdeadbeef), although of course only for direct assignments like this when the compiler still knows the origin of the value. Does the Microsoft compiler behave differently? > Second comment. > > Adding the 'const' modifier to all types is very confusing imho. I > understand that it meant to make it clear that the values are > constants and should not change, but still is very confusing. > > For example, > > C Type: void * const > MPI_BOTTOM > > This means that the value of MPI_BOTTOM is constant and not the > memory it points to. however at first look you might think that it's > the later. (if it was, it would break any application that uses it > because the API's do not take a pointer to const void) I'm not sure that there's a lot we can do if people can't properly read cv-qualified C types. This is a standards document, not a tutorial. I don't think that this is intentionally misleading or difficult to read. > In any case implementers should define MPI_BOTTOM as > > #define MPI_BOTTOM (void*)0 > > Rather than > > #define MPI_BOTTOM (void* const)0 > > As the value is constant and you don't need to add the const modifier. The reason you don't really need the const here is that casts create rvalues. So it has the same effect as a cast to the unqualified type. This, combined with the constant initializer rule in MPI-2.1 section 2.5.4, is one reason that choosing "const int" as the type for these constants is debatable. > Note that the 'constness' of these values is already stated in the > title of the section '19.1.1 Defined Constants' I don't agree. The semantic constness of these constants is implied by the title, but not the specific language implementation constness. In the standard we could say "X, Y, and Z are constants (their values never change) with the exact type `int'". Depending on the exact uses with the rest of the API this would be perfectly valid, although we might lose some error checking assistance from C compilers. The title together with MPI-2.1 section 2.5.4 indicates that most of these are compile-time constants that may be used for initialization, so you could say that the constness doesn't matter since these may never be stored in link-time constant variables. However using "const" as a way of indicating that these constants are "non- lvalue" (and in particular, "non-(modifiable lvalue)") is fine by me. -Dave From erezh at [hidden] Tue Aug 4 12:21:16 2009 From: erezh at [hidden] (Erez Haba) Date: Tue, 4 Aug 2009 17:21:16 +0000 Subject: [Mpi-22] Borderline ticket #107: Types of predefined constants in Appendix A In-Reply-To: <799DA24B-6942-4290-A20C-C88A1FD253EE@mcs.anl.gov> Message-ID: <85287355FA6D5646A8A8A083CE185EEB02EF9AF9@TK5EX14MBXC116.redmond.corp.microsoft.com> I agree David, and as I said, it might be nitpicking :) Most compliers would probably optimize the cast out (Microsoft compiler sure does); however the question still remains; do implementers have to change the definition of their constant variables to meet this table? As for the second item, the point I'm making is that adding the 'const' qualifier for the types in the tables does not help clarity and it does quite the opposite. Would adding 'const' to MPI_Datatype, MPI_Comm or MPI_Op types in these tables helps? Which brings me to my third note which is, the use of 'const' in these tables is not consistent. Some types get the const modifiers and some do not. David, per your comment below, and to the audience, please note that this ticket is not just a trivial text change to the standard, as it introduces types for constants that were not assigned in the standard before. As you said below David, adding 'const' makes them non-lvalue for the specific C binding. I know that this ticket has passed 2nd vote, imho, wrongly without giving enough consideration to its content; as it was introduced as text only change. See the large number of abstains (including me). However it's up to us to decide. I don't know what the rules say, and if there is a way to take back this ticket without taking the entire chapter out. Thoughts?? Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Dave Goodell Sent: Monday, August 03, 2009 2:00 PM To: MPI 2.2 Subject: Re: [Mpi-22] Borderline ticket #107: Types of predefined constants in Appendix A On Aug 3, 2009, at 12:36 PM, Erez Haba wrote: > This might be nitpicking but wouldn't that force implementation to > typecast their definition of error codes? For example, > > #define MPI_ERR_BUFFER 0 > > Is not a correct definition with the proposed change, because it is > not typed. I think that the "Constants with the type const int may also be implemented as literal integer constants substituted by the preprocessor" bit on lines 23-24 helps implementors realize that they don't need to insert a cast here. Also, the type of the integer constant 0 is typed as the first integer type in {int, long int, long long int} that can express the value, which is required to be int in this particular case. > Thus, it needs to change to > > #define MPI_ERR_BUFFER (int)0 // you don't really need to define > it as (const int)0 > > as a result the following statement > > short x = MPI_ERR_BUFFER; > > which compiled correctly before, would break with this change. To the best of my knowledge this is still perfectly legitimate C. Section 6.5.16.1 of my copy of the C99 standard seems to corroborate this: -------8<-------- Semantics 2 In simple assignment (=), the value of the right operand is converted to the type of the assignment expression and replaces the value stored in the object designated by the left operand. -------8<-------- GCC doesn't give a warning for this assignment, even when you add a bunch of warning flags. It does warn if the value is something too large for the short type (like 0xdeadbeef), although of course only for direct assignments like this when the compiler still knows the origin of the value. Does the Microsoft compiler behave differently? > Second comment. > > Adding the 'const' modifier to all types is very confusing imho. I > understand that it meant to make it clear that the values are > constants and should not change, but still is very confusing. > > For example, > > C Type: void * const > MPI_BOTTOM > > This means that the value of MPI_BOTTOM is constant and not the > memory it points to. however at first look you might think that it's > the later. (if it was, it would break any application that uses it > because the API's do not take a pointer to const void) I'm not sure that there's a lot we can do if people can't properly read cv-qualified C types. This is a standards document, not a tutorial. I don't think that this is intentionally misleading or difficult to read. > In any case implementers should define MPI_BOTTOM as > > #define MPI_BOTTOM (void*)0 > > Rather than > > #define MPI_BOTTOM (void* const)0 > > As the value is constant and you don't need to add the const modifier. The reason you don't really need the const here is that casts create rvalues. So it has the same effect as a cast to the unqualified type. This, combined with the constant initializer rule in MPI-2.1 section 2.5.4, is one reason that choosing "const int" as the type for these constants is debatable. > Note that the 'constness' of these values is already stated in the > title of the section '19.1.1 Defined Constants' I don't agree. The semantic constness of these constants is implied by the title, but not the specific language implementation constness. In the standard we could say "X, Y, and Z are constants (their values never change) with the exact type `int'". Depending on the exact uses with the rest of the API this would be perfectly valid, although we might lose some error checking assistance from C compilers. The title together with MPI-2.1 section 2.5.4 indicates that most of these are compile-time constants that may be used for initialization, so you could say that the constness doesn't matter since these may never be stored in link-time constant variables. However using "const" as a way of indicating that these constants are "non- lvalue" (and in particular, "non-(modifiable lvalue)") is fine by me. -Dave _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 From wgropp at [hidden] Wed Aug 5 19:41:52 2009 From: wgropp at [hidden] (William Gropp) Date: Wed, 5 Aug 2009 19:41:52 -0500 Subject: [Mpi-22] Borderline ticket #107: Types of predefined constants in Appendix A In-Reply-To: <85287355FA6D5646A8A8A083CE185EEB02EF9AF9@TK5EX14MBXC116.redmond.corp.microsoft.com> Message-ID: <915613F7-9CCB-4FF9-AE7E-654697CE9707@illinois.edu> In terms of what we can do with this, only if the ticket was out of scope can it be withdrawn. That is, if it violates the rules for valid MPI 2.2 items by, for example, making previously valid (and unambiguous) MPI 2.1 programs invalid. If we discover something like that, we'll probably need to delay the standard. I don't believe we've reached that threshold yet. Bill On Aug 4, 2009, at 12:21 PM, Erez Haba wrote: > I agree David, and as I said, it might be nitpicking :) > > Most compliers would probably optimize the cast out (Microsoft > compiler sure does); however the question still remains; do > implementers have to change the definition of their constant > variables to meet this table? > > > As for the second item, the point I'm making is that adding the > 'const' qualifier for the types in the tables does not help clarity > and it does quite the opposite. Would adding 'const' to > MPI_Datatype, MPI_Comm or MPI_Op types in these tables helps? > > Which brings me to my third note which is, the use of 'const' in > these tables is not consistent. Some types get the const modifiers > and some do not. > > > David, per your comment below, and to the audience, please note that > this ticket is not just a trivial text change to the standard, as it > introduces types for constants that were not assigned in the > standard before. > As you said below David, adding 'const' makes them non-lvalue for > the specific C binding. > > > I know that this ticket has passed 2nd vote, imho, wrongly without > giving enough consideration to its content; as it was introduced as > text only change. See the large number of abstains (including me). > However it's up to us to decide. I don't know what the rules say, > and if there is a way to take back this ticket without taking the > entire chapter out. > > Thoughts?? > > Thanks, > .Erez > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Dave Goodell > Sent: Monday, August 03, 2009 2:00 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] Borderline ticket #107: Types of predefined > constants in Appendix A > > On Aug 3, 2009, at 12:36 PM, Erez Haba wrote: > >> This might be nitpicking but wouldn't that force implementation to >> typecast their definition of error codes? For example, >> >> #define MPI_ERR_BUFFER 0 >> >> Is not a correct definition with the proposed change, because it is >> not typed. > > I think that the "Constants with the type const int may also be > implemented as literal integer constants substituted by the > preprocessor" bit on lines 23-24 helps implementors realize that they > don't need to insert a cast here. Also, the type of the integer > constant 0 is typed as the first integer type in {int, long int, long > long int} that can express the value, which is required to be int in > this particular case. > >> Thus, it needs to change to >> >> #define MPI_ERR_BUFFER (int)0 // you don't really need to define >> it as (const int)0 >> >> as a result the following statement >> >> short x = MPI_ERR_BUFFER; >> >> which compiled correctly before, would break with this change. > > To the best of my knowledge this is still perfectly legitimate C. > Section 6.5.16.1 of my copy of the C99 standard seems to corroborate > this: > > -------8<-------- > Semantics > > 2 In simple assignment (=), the value of the right operand is > converted to the type of the assignment expression and replaces the > value stored in the object designated by the left operand. > -------8<-------- > > GCC doesn't give a warning for this assignment, even when you add a > bunch of warning flags. It does warn if the value is something too > large for the short type (like 0xdeadbeef), although of course only > for direct assignments like this when the compiler still knows the > origin of the value. Does the Microsoft compiler behave differently? > >> Second comment. >> >> Adding the 'const' modifier to all types is very confusing imho. I >> understand that it meant to make it clear that the values are >> constants and should not change, but still is very confusing. >> >> For example, >> >> C Type: void * const >> MPI_BOTTOM >> >> This means that the value of MPI_BOTTOM is constant and not the >> memory it points to. however at first look you might think that it's >> the later. (if it was, it would break any application that uses it >> because the API's do not take a pointer to const void) > > I'm not sure that there's a lot we can do if people can't properly > read cv-qualified C types. This is a standards document, not a > tutorial. I don't think that this is intentionally misleading or > difficult to read. > >> In any case implementers should define MPI_BOTTOM as >> >> #define MPI_BOTTOM (void*)0 >> >> Rather than >> >> #define MPI_BOTTOM (void* const)0 >> >> As the value is constant and you don't need to add the const >> modifier. > > The reason you don't really need the const here is that casts create > rvalues. So it has the same effect as a cast to the unqualified type. > This, combined with the constant initializer rule in MPI-2.1 section > 2.5.4, is one reason that choosing "const int" as the type for these > constants is debatable. > >> Note that the 'constness' of these values is already stated in the >> title of the section '19.1.1 Defined Constants' > > I don't agree. The semantic constness of these constants is implied > by the title, but not the specific language implementation constness. > In the standard we could say "X, Y, and Z are constants (their values > never change) with the exact type `int'". Depending on the exact uses > with the rest of the API this would be perfectly valid, although we > might lose some error checking assistance from C compilers. > > The title together with MPI-2.1 section 2.5.4 indicates that most of > these are compile-time constants that may be used for initialization, > so you could say that the constness doesn't matter since these may > never be stored in link-time constant variables. However using > "const" as a way of indicating that these constants are "non- > lvalue" (and in particular, "non-(modifiable lvalue)") is fine by me. > > -Dave > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign From alexander.supalov at [hidden] Thu Aug 6 05:52:00 2009 From: alexander.supalov at [hidden] (Supalov, Alexander) Date: Thu, 6 Aug 2009 11:52:00 +0100 Subject: [Mpi-22] Borderline ticket #107: Types of predefined constants in Appendix A In-Reply-To: <915613F7-9CCB-4FF9-AE7E-654697CE9707@illinois.edu> Message-ID: <928CFBE8E7CB0040959E56B4EA41A77EC1BFEBD0@irsmsx504.ger.corp.intel.com> Hi, The passed inter-language attribute changes (#55) do break existing programs according to our investigation. Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of William Gropp Sent: Thursday, August 06, 2009 2:42 AM To: MPI 2.2 Subject: Re: [Mpi-22] Borderline ticket #107: Types of predefined constants in Appendix A In terms of what we can do with this, only if the ticket was out of scope can it be withdrawn. That is, if it violates the rules for valid MPI 2.2 items by, for example, making previously valid (and unambiguous) MPI 2.1 programs invalid. If we discover something like that, we'll probably need to delay the standard. I don't believe we've reached that threshold yet. Bill On Aug 4, 2009, at 12:21 PM, Erez Haba wrote: > I agree David, and as I said, it might be nitpicking :) > > Most compliers would probably optimize the cast out (Microsoft > compiler sure does); however the question still remains; do > implementers have to change the definition of their constant > variables to meet this table? > > > As for the second item, the point I'm making is that adding the > 'const' qualifier for the types in the tables does not help clarity > and it does quite the opposite. Would adding 'const' to > MPI_Datatype, MPI_Comm or MPI_Op types in these tables helps? > > Which brings me to my third note which is, the use of 'const' in > these tables is not consistent. Some types get the const modifiers > and some do not. > > > David, per your comment below, and to the audience, please note that > this ticket is not just a trivial text change to the standard, as it > introduces types for constants that were not assigned in the > standard before. > As you said below David, adding 'const' makes them non-lvalue for > the specific C binding. > > > I know that this ticket has passed 2nd vote, imho, wrongly without > giving enough consideration to its content; as it was introduced as > text only change. See the large number of abstains (including me). > However it's up to us to decide. I don't know what the rules say, > and if there is a way to take back this ticket without taking the > entire chapter out. > > Thoughts?? > > Thanks, > .Erez > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Dave Goodell > Sent: Monday, August 03, 2009 2:00 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] Borderline ticket #107: Types of predefined > constants in Appendix A > > On Aug 3, 2009, at 12:36 PM, Erez Haba wrote: > >> This might be nitpicking but wouldn't that force implementation to >> typecast their definition of error codes? For example, >> >> #define MPI_ERR_BUFFER 0 >> >> Is not a correct definition with the proposed change, because it is >> not typed. > > I think that the "Constants with the type const int may also be > implemented as literal integer constants substituted by the > preprocessor" bit on lines 23-24 helps implementors realize that they > don't need to insert a cast here. Also, the type of the integer > constant 0 is typed as the first integer type in {int, long int, long > long int} that can express the value, which is required to be int in > this particular case. > >> Thus, it needs to change to >> >> #define MPI_ERR_BUFFER (int)0 // you don't really need to define >> it as (const int)0 >> >> as a result the following statement >> >> short x = MPI_ERR_BUFFER; >> >> which compiled correctly before, would break with this change. > > To the best of my knowledge this is still perfectly legitimate C. > Section 6.5.16.1 of my copy of the C99 standard seems to corroborate > this: > > -------8<-------- > Semantics > > 2 In simple assignment (=), the value of the right operand is > converted to the type of the assignment expression and replaces the > value stored in the object designated by the left operand. > -------8<-------- > > GCC doesn't give a warning for this assignment, even when you add a > bunch of warning flags. It does warn if the value is something too > large for the short type (like 0xdeadbeef), although of course only > for direct assignments like this when the compiler still knows the > origin of the value. Does the Microsoft compiler behave differently? > >> Second comment. >> >> Adding the 'const' modifier to all types is very confusing imho. I >> understand that it meant to make it clear that the values are >> constants and should not change, but still is very confusing. >> >> For example, >> >> C Type: void * const >> MPI_BOTTOM >> >> This means that the value of MPI_BOTTOM is constant and not the >> memory it points to. however at first look you might think that it's >> the later. (if it was, it would break any application that uses it >> because the API's do not take a pointer to const void) > > I'm not sure that there's a lot we can do if people can't properly > read cv-qualified C types. This is a standards document, not a > tutorial. I don't think that this is intentionally misleading or > difficult to read. > >> In any case implementers should define MPI_BOTTOM as >> >> #define MPI_BOTTOM (void*)0 >> >> Rather than >> >> #define MPI_BOTTOM (void* const)0 >> >> As the value is constant and you don't need to add the const >> modifier. > > The reason you don't really need the const here is that casts create > rvalues. So it has the same effect as a cast to the unqualified type. > This, combined with the constant initializer rule in MPI-2.1 section > 2.5.4, is one reason that choosing "const int" as the type for these > constants is debatable. > >> Note that the 'constness' of these values is already stated in the >> title of the section '19.1.1 Defined Constants' > > I don't agree. The semantic constness of these constants is implied > by the title, but not the specific language implementation constness. > In the standard we could say "X, Y, and Z are constants (their values > never change) with the exact type `int'". Depending on the exact uses > with the rest of the API this would be perfectly valid, although we > might lose some error checking assistance from C compilers. > > The title together with MPI-2.1 section 2.5.4 indicates that most of > these are compile-time constants that may be used for initialization, > so you could say that the constness doesn't matter since these may > never be stored in link-time constant variables. However using > "const" as a way of indicating that these constants are "non- > lvalue" (and in particular, "non-(modifiable lvalue)") is fine by me. > > -Dave > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From bwbarre at [hidden] Thu Aug 6 10:57:04 2009 From: bwbarre at [hidden] (Barrett, Brian W) Date: Thu, 6 Aug 2009 09:57:04 -0600 Subject: [Mpi-22] Borderline ticket #107: Types of predefined constants in Appendix A In-Reply-To: <928CFBE8E7CB0040959E56B4EA41A77EC1BFEBD0@irsmsx504.ger.corp.intel.com> Message-ID: Alexander - I'm not sure why you had to hijack a thread on a possibly valid issue with MPI 2.2 by bringing up a completely different issue, but I believe it seriously distracts from an important discussion. However, to answer your complaint regarding ticket #55, Bill was quite specific: "making previously valid (and unambiguous) MPI 2.1 programs invalid". Yes, the changes in #55 will make any codes which followed the examples instead of the text more clearly invalid, but they were invalid already as the examples are not part of the official standard language. Further, given the ambiguity (meaning the standards committee had multiple very long discussions about what the standard currently met) in the difference between deprecated and new Fortran functions, it would be nearly impossible to claim that that existing codes met the unambiguous threshold. Finally, the meaning of the standards text did not change, but was clarified to make its existing meaning more clear, as seen by the long thread between Rajeev, Rolf, and Jeff on existing text vs. new text. So although the change may cause compatibility problems with incorrectly written applications, the Forum handled ticket #55 properly. If you disagreed with specific parts of the text, the 10 months of discussion over the text was the proper time for constructive comments. The relentless attack on tickets you don't like, even after tickets have passed vote with clearly correct procedures, is rather distracting from real issues. Brian On 8/6/09 4:52 AM, "Supalov, Alexander" wrote: > Hi, > > The passed inter-language attribute changes (#55) do break existing programs > according to our investigation. > > Best regards. > > Alexander > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of William Gropp > Sent: Thursday, August 06, 2009 2:42 AM > To: MPI 2.2 > Subject: Re: [Mpi-22] Borderline ticket #107: Types of predefined constants in > Appendix A > > In terms of what we can do with this, only if the ticket was out of > scope can it be withdrawn. That is, if it violates the rules for > valid MPI 2.2 items by, for example, making previously valid (and > unambiguous) MPI 2.1 programs invalid. If we discover something like > that, we'll probably need to delay the standard. I don't believe > we've reached that threshold yet. > > Bill > > On Aug 4, 2009, at 12:21 PM, Erez Haba wrote: > >> I agree David, and as I said, it might be nitpicking :) >> >> Most compliers would probably optimize the cast out (Microsoft >> compiler sure does); however the question still remains; do >> implementers have to change the definition of their constant >> variables to meet this table? >> >> >> As for the second item, the point I'm making is that adding the >> 'const' qualifier for the types in the tables does not help clarity >> and it does quite the opposite. Would adding 'const' to >> MPI_Datatype, MPI_Comm or MPI_Op types in these tables helps? >> >> Which brings me to my third note which is, the use of 'const' in >> these tables is not consistent. Some types get the const modifiers >> and some do not. >> >> >> David, per your comment below, and to the audience, please note that >> this ticket is not just a trivial text change to the standard, as it >> introduces types for constants that were not assigned in the >> standard before. >> As you said below David, adding 'const' makes them non-lvalue for >> the specific C binding. >> >> >> I know that this ticket has passed 2nd vote, imho, wrongly without >> giving enough consideration to its content; as it was introduced as >> text only change. See the large number of abstains (including me). >> However it's up to us to decide. I don't know what the rules say, >> and if there is a way to take back this ticket without taking the >> entire chapter out. >> >> Thoughts?? >> >> Thanks, >> .Erez >> >> -----Original Message----- >> From: mpi-22-bounces_at_[hidden] >> [mailto:mpi-22-bounces_at_[hidden] >> ] On Behalf Of Dave Goodell >> Sent: Monday, August 03, 2009 2:00 PM >> To: MPI 2.2 >> Subject: Re: [Mpi-22] Borderline ticket #107: Types of predefined >> constants in Appendix A >> >> On Aug 3, 2009, at 12:36 PM, Erez Haba wrote: >> >>> This might be nitpicking but wouldn't that force implementation to >>> typecast their definition of error codes? For example, >>> >>> #define MPI_ERR_BUFFER 0 >>> >>> Is not a correct definition with the proposed change, because it is >>> not typed. >> >> I think that the "Constants with the type const int may also be >> implemented as literal integer constants substituted by the >> preprocessor" bit on lines 23-24 helps implementors realize that they >> don't need to insert a cast here. Also, the type of the integer >> constant 0 is typed as the first integer type in {int, long int, long >> long int} that can express the value, which is required to be int in >> this particular case. >> >>> Thus, it needs to change to >>> >>> #define MPI_ERR_BUFFER (int)0 // you don't really need to define >>> it as (const int)0 >>> >>> as a result the following statement >>> >>> short x = MPI_ERR_BUFFER; >>> >>> which compiled correctly before, would break with this change. >> >> To the best of my knowledge this is still perfectly legitimate C. >> Section 6.5.16.1 of my copy of the C99 standard seems to corroborate >> this: >> >> -------8<-------- >> Semantics >> >> 2 In simple assignment (=), the value of the right operand is >> converted to the type of the assignment expression and replaces the >> value stored in the object designated by the left operand. >> -------8<-------- >> >> GCC doesn't give a warning for this assignment, even when you add a >> bunch of warning flags. It does warn if the value is something too >> large for the short type (like 0xdeadbeef), although of course only >> for direct assignments like this when the compiler still knows the >> origin of the value. Does the Microsoft compiler behave differently? >> >>> Second comment. >>> >>> Adding the 'const' modifier to all types is very confusing imho. I >>> understand that it meant to make it clear that the values are >>> constants and should not change, but still is very confusing. >>> >>> For example, >>> >>> C Type: void * const >>> MPI_BOTTOM >>> >>> This means that the value of MPI_BOTTOM is constant and not the >>> memory it points to. however at first look you might think that it's >>> the later. (if it was, it would break any application that uses it >>> because the API's do not take a pointer to const void) >> >> I'm not sure that there's a lot we can do if people can't properly >> read cv-qualified C types. This is a standards document, not a >> tutorial. I don't think that this is intentionally misleading or >> difficult to read. >> >>> In any case implementers should define MPI_BOTTOM as >>> >>> #define MPI_BOTTOM (void*)0 >>> >>> Rather than >>> >>> #define MPI_BOTTOM (void* const)0 >>> >>> As the value is constant and you don't need to add the const >>> modifier. >> >> The reason you don't really need the const here is that casts create >> rvalues. So it has the same effect as a cast to the unqualified type. >> This, combined with the constant initializer rule in MPI-2.1 section >> 2.5.4, is one reason that choosing "const int" as the type for these >> constants is debatable. >> >>> Note that the 'constness' of these values is already stated in the >>> title of the section '19.1.1 Defined Constants' >> >> I don't agree. The semantic constness of these constants is implied >> by the title, but not the specific language implementation constness. >> In the standard we could say "X, Y, and Z are constants (their values >> never change) with the exact type `int'". Depending on the exact uses >> with the rest of the API this would be perfectly valid, although we >> might lose some error checking assistance from C compilers. >> >> The title together with MPI-2.1 section 2.5.4 indicates that most of >> these are compile-time constants that may be used for initialization, >> so you could say that the constness doesn't matter since these may >> never be stored in link-time constant variables. However using >> "const" as a way of indicating that these constants are "non- >> lvalue" (and in particular, "non-(modifiable lvalue)") is fine by me. >> >> -Dave >> >> _______________________________________________ >> mpi-22 mailing list >> mpi-22_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> >> >> _______________________________________________ >> mpi-22 mailing list >> mpi-22_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > William Gropp > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > --------------------------------------------------------------------- > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen Germany > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer > Registergericht: Muenchen HRB 47456 Ust.-IdNr. > VAT Registration No.: DE129385895 > Citibank Frankfurt (BLZ 502 109 00) 600119052 > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > From erezh at [hidden] Thu Aug 6 12:23:45 2009 From: erezh at [hidden] (Erez Haba) Date: Thu, 6 Aug 2009 17:23:45 +0000 Subject: [Mpi-22] Borderline ticket #107: Types of predefined constants in Appendix A In-Reply-To: <915613F7-9CCB-4FF9-AE7E-654697CE9707@illinois.edu> Message-ID: <85287355FA6D5646A8A8A083CE185EEB02F0A1FF@TK5EX14MBXC114.redmond.corp.microsoft.com> Thanks Bill, It is still not clear to me if this ticket forces implementation to change. If it does not, the discussion is over. I'm okay with this ticket (minus the 'const' which is misleading and not consistent, but I can live with it). If it does force implementations to change, I think we've been mislead (it was presented as text only ticket) and we've rushed into voting without much appropriate discussion. In that case I would like to find the scope of the change and understand if it's really necessary and whether it breaks any legit app. Bill, I don't think that anyone voting on this ticket voted for an implementation change. if this is the case, would withdrawing the ticket have to pass the high bar of "it be withdrawn only if it breaks a valid mpi 2.1 applications"? Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of William Gropp Sent: Wednesday, August 05, 2009 5:42 PM To: MPI 2.2 Subject: Re: [Mpi-22] Borderline ticket #107: Types of predefined constants in Appendix A In terms of what we can do with this, only if the ticket was out of scope can it be withdrawn. That is, if it violates the rules for valid MPI 2.2 items by, for example, making previously valid (and unambiguous) MPI 2.1 programs invalid. If we discover something like that, we'll probably need to delay the standard. I don't believe we've reached that threshold yet. Bill On Aug 4, 2009, at 12:21 PM, Erez Haba wrote: > I agree David, and as I said, it might be nitpicking :) > > Most compliers would probably optimize the cast out (Microsoft > compiler sure does); however the question still remains; do > implementers have to change the definition of their constant > variables to meet this table? > > > As for the second item, the point I'm making is that adding the > 'const' qualifier for the types in the tables does not help clarity > and it does quite the opposite. Would adding 'const' to > MPI_Datatype, MPI_Comm or MPI_Op types in these tables helps? > > Which brings me to my third note which is, the use of 'const' in > these tables is not consistent. Some types get the const modifiers > and some do not. > > > David, per your comment below, and to the audience, please note that > this ticket is not just a trivial text change to the standard, as it > introduces types for constants that were not assigned in the > standard before. > As you said below David, adding 'const' makes them non-lvalue for > the specific C binding. > > > I know that this ticket has passed 2nd vote, imho, wrongly without > giving enough consideration to its content; as it was introduced as > text only change. See the large number of abstains (including me). > However it's up to us to decide. I don't know what the rules say, > and if there is a way to take back this ticket without taking the > entire chapter out. > > Thoughts?? > > Thanks, > .Erez > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Dave Goodell > Sent: Monday, August 03, 2009 2:00 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] Borderline ticket #107: Types of predefined > constants in Appendix A > > On Aug 3, 2009, at 12:36 PM, Erez Haba wrote: > >> This might be nitpicking but wouldn't that force implementation to >> typecast their definition of error codes? For example, >> >> #define MPI_ERR_BUFFER 0 >> >> Is not a correct definition with the proposed change, because it is >> not typed. > > I think that the "Constants with the type const int may also be > implemented as literal integer constants substituted by the > preprocessor" bit on lines 23-24 helps implementors realize that they > don't need to insert a cast here. Also, the type of the integer > constant 0 is typed as the first integer type in {int, long int, long > long int} that can express the value, which is required to be int in > this particular case. > >> Thus, it needs to change to >> >> #define MPI_ERR_BUFFER (int)0 // you don't really need to define >> it as (const int)0 >> >> as a result the following statement >> >> short x = MPI_ERR_BUFFER; >> >> which compiled correctly before, would break with this change. > > To the best of my knowledge this is still perfectly legitimate C. > Section 6.5.16.1 of my copy of the C99 standard seems to corroborate > this: > > -------8<-------- > Semantics > > 2 In simple assignment (=), the value of the right operand is > converted to the type of the assignment expression and replaces the > value stored in the object designated by the left operand. > -------8<-------- > > GCC doesn't give a warning for this assignment, even when you add a > bunch of warning flags. It does warn if the value is something too > large for the short type (like 0xdeadbeef), although of course only > for direct assignments like this when the compiler still knows the > origin of the value. Does the Microsoft compiler behave differently? > >> Second comment. >> >> Adding the 'const' modifier to all types is very confusing imho. I >> understand that it meant to make it clear that the values are >> constants and should not change, but still is very confusing. >> >> For example, >> >> C Type: void * const >> MPI_BOTTOM >> >> This means that the value of MPI_BOTTOM is constant and not the >> memory it points to. however at first look you might think that it's >> the later. (if it was, it would break any application that uses it >> because the API's do not take a pointer to const void) > > I'm not sure that there's a lot we can do if people can't properly > read cv-qualified C types. This is a standards document, not a > tutorial. I don't think that this is intentionally misleading or > difficult to read. > >> In any case implementers should define MPI_BOTTOM as >> >> #define MPI_BOTTOM (void*)0 >> >> Rather than >> >> #define MPI_BOTTOM (void* const)0 >> >> As the value is constant and you don't need to add the const >> modifier. > > The reason you don't really need the const here is that casts create > rvalues. So it has the same effect as a cast to the unqualified type. > This, combined with the constant initializer rule in MPI-2.1 section > 2.5.4, is one reason that choosing "const int" as the type for these > constants is debatable. > >> Note that the 'constness' of these values is already stated in the >> title of the section '19.1.1 Defined Constants' > > I don't agree. The semantic constness of these constants is implied > by the title, but not the specific language implementation constness. > In the standard we could say "X, Y, and Z are constants (their values > never change) with the exact type `int'". Depending on the exact uses > with the rest of the API this would be perfectly valid, although we > might lose some error checking assistance from C compilers. > > The title together with MPI-2.1 section 2.5.4 indicates that most of > these are compile-time constants that may be used for initialization, > so you could say that the constness doesn't matter since these may > never be stored in link-time constant variables. However using > "const" as a way of indicating that these constants are "non- > lvalue" (and in particular, "non-(modifiable lvalue)") is fine by me. > > -Dave > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 From tony at [hidden] Thu Aug 6 13:08:49 2009 From: tony at [hidden] (Anthony Skjellum) Date: Thu, 6 Aug 2009 18:08:49 +0000 Subject: [Mpi-22] Borderline ticket #107: Types ofpredefined constants in Appendix A In-Reply-To: <85287355FA6D5646A8A8A083CE185EEB02F0A1FF@TK5EX14MBXC114.redmond.corp.microsoft.com> Message-ID: <104757022-1249582123-cardhu_decombobulator_blackberry.rim.net-757049046-@bxe1289.bisx.prod.on.blackberry> Everyone, first of all, we should not do anything rash in either direction, and everyone should keep his or her cool in the debate, even if things get contentious :-) and etc. While not taking sides on the technical matter right now, the fact is that if we find there is a serious problem, we should act in favor of quality and correctness at the expense of speed. We do not want to compound any problem (if that is what we finally agree there is) by a rash solution. We will be judged better (by our users and adopters) for delaying rather than making a step that harms the standard. We can always call an extra meeting if we had to to get back on time track :-) Serious question: I am curious as to how we are going to rationally, definitively and timely decide now if this breaks valid 2.1 programs? What about 2.0 programs (of which there are far more)? A panel of a subset of us? Regards, Tony Tony Skjellum, PhD RunTime Computing Solutions, LLC tony_at_[hidden] direct: +1-205-314-3595 cell: +1-205-807-4968 -----Original Message----- From: Erez Haba Date: Thu, 6 Aug 2009 17:23:45 To: MPI 2.2 Subject: Re: [Mpi-22] Borderline ticket #107: Types of predefined constants in Appendix A Thanks Bill, It is still not clear to me if this ticket forces implementation to change. If it does not, the discussion is over. I'm okay with this ticket (minus the 'const' which is misleading and not consistent, but I can live with it). If it does force implementations to change, I think we've been mislead (it was presented as text only ticket) and we've rushed into voting without much appropriate discussion. In that case I would like to find the scope of the change and understand if it's really necessary and whether it breaks any legit app. Bill, I don't think that anyone voting on this ticket voted for an implementation change. if this is the case, would withdrawing the ticket have to pass the high bar of "it be withdrawn only if it breaks a valid mpi 2.1 applications"? Thanks, .Erez -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of William Gropp Sent: Wednesday, August 05, 2009 5:42 PM To: MPI 2.2 Subject: Re: [Mpi-22] Borderline ticket #107: Types of predefined constants in Appendix A In terms of what we can do with this, only if the ticket was out of scope can it be withdrawn. That is, if it violates the rules for valid MPI 2.2 items by, for example, making previously valid (and unambiguous) MPI 2.1 programs invalid. If we discover something like that, we'll probably need to delay the standard. I don't believe we've reached that threshold yet. Bill On Aug 4, 2009, at 12:21 PM, Erez Haba wrote: > I agree David, and as I said, it might be nitpicking :) > > Most compliers would probably optimize the cast out (Microsoft > compiler sure does); however the question still remains; do > implementers have to change the definition of their constant > variables to meet this table? > > > As for the second item, the point I'm making is that adding the > 'const' qualifier for the types in the tables does not help clarity > and it does quite the opposite. Would adding 'const' to > MPI_Datatype, MPI_Comm or MPI_Op types in these tables helps? > > Which brings me to my third note which is, the use of 'const' in > these tables is not consistent. Some types get the const modifiers > and some do not. > > > David, per your comment below, and to the audience, please note that > this ticket is not just a trivial text change to the standard, as it > introduces types for constants that were not assigned in the > standard before. > As you said below David, adding 'const' makes them non-lvalue for > the specific C binding. > > > I know that this ticket has passed 2nd vote, imho, wrongly without > giving enough consideration to its content; as it was introduced as > text only change. See the large number of abstains (including me). > However it's up to us to decide. I don't know what the rules say, > and if there is a way to take back this ticket without taking the > entire chapter out. > > Thoughts?? > > Thanks, > .Erez > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden] > ] On Behalf Of Dave Goodell > Sent: Monday, August 03, 2009 2:00 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] Borderline ticket #107: Types of predefined > constants in Appendix A > > On Aug 3, 2009, at 12:36 PM, Erez Haba wrote: > >> This might be nitpicking but wouldn't that force implementation to >> typecast their definition of error codes? For example, >> >> #define MPI_ERR_BUFFER 0 >> >> Is not a correct definition with the proposed change, because it is >> not typed. > > I think that the "Constants with the type const int may also be > implemented as literal integer constants substituted by the > preprocessor" bit on lines 23-24 helps implementors realize that they > don't need to insert a cast here. Also, the type of the integer > constant 0 is typed as the first integer type in {int, long int, long > long int} that can express the value, which is required to be int in > this particular case. > >> Thus, it needs to change to >> >> #define MPI_ERR_BUFFER (int)0 // you don't really need to define >> it as (const int)0 >> >> as a result the following statement >> >> short x = MPI_ERR_BUFFER; >> >> which compiled correctly before, would break with this change. > > To the best of my knowledge this is still perfectly legitimate C. > Section 6.5.16.1 of my copy of the C99 standard seems to corroborate > this: > > -------8<-------- > Semantics > > 2 In simple assignment (=), the value of the right operand is > converted to the type of the assignment expression and replaces the > value stored in the object designated by the left operand. > -------8<-------- > > GCC doesn't give a warning for this assignment, even when you add a > bunch of warning flags. It does warn if the value is something too > large for the short type (like 0xdeadbeef), although of course only > for direct assignments like this when the compiler still knows the > origin of the value. Does the Microsoft compiler behave differently? > >> Second comment. >> >> Adding the 'const' modifier to all types is very confusing imho. I >> understand that it meant to make it clear that the values are >> constants and should not change, but still is very confusing. >> >> For example, >> >> C Type: void * const >> MPI_BOTTOM >> >> This means that the value of MPI_BOTTOM is constant and not the >> memory it points to. however at first look you might think that it's >> the later. (if it was, it would break any application that uses it >> because the API's do not take a pointer to const void) > > I'm not sure that there's a lot we can do if people can't properly > read cv-qualified C types. This is a standards document, not a > tutorial. I don't think that this is intentionally misleading or > difficult to read. > >> In any case implementers should define MPI_BOTTOM as >> >> #define MPI_BOTTOM (void*)0 >> >> Rather than >> >> #define MPI_BOTTOM (void* const)0 >> >> As the value is constant and you don't need to add the const >> modifier. > > The reason you don't really need the const here is that casts create > rvalues. So it has the same effect as a cast to the unqualified type. > This, combined with the constant initializer rule in MPI-2.1 section > 2.5.4, is one reason that choosing "const int" as the type for these > constants is debatable. > >> Note that the 'constness' of these values is already stated in the >> title of the section '19.1.1 Defined Constants' > > I don't agree. The semantic constness of these constants is implied > by the title, but not the specific language implementation constness. > In the standard we could say "X, Y, and Z are constants (their values > never change) with the exact type `int'". Depending on the exact uses > with the rest of the API this would be perfectly valid, although we > might lose some error checking assistance from C compilers. > > The title together with MPI-2.1 section 2.5.4 indicates that most of > these are compile-time constants that may be used for initialization, > so you could say that the constness doesn't matter since these may > never be stored in link-time constant variables. However using > "const" as a way of indicating that these constants are "non- > lvalue" (and in particular, "non-(modifiable lvalue)") is fine by me. > > -Dave > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 From rabenseifner at [hidden] Thu Aug 6 14:39:10 2009 From: rabenseifner at [hidden] (Rolf Rabenseifner) Date: Thu, 06 Aug 2009 21:39:10 +0200 Subject: [Mpi-22] Borderline ticket #107: Types ofpredefined constants in Appendix A In-Reply-To: <104757022-1249582123-cardhu_decombobulator_blackberry.rim.net-757049046-@bxe1289.bisx.prod.on.blackberry> Message-ID: It wasn't my goal to change MPI implementations. For me, it was strange, that C++ user get the type imformation in this Appendix and Fortran and C users have to look for the type info somewhere in the standard. Some details. 1) The goal of the sentence Constants with the type {{const int}} may also be implemented as literal integer constants substituted by the preprocessor. was to allow #define MPI_ANY_SOURCE -3 i.e., without any type casting! ("-3" is a "literal integer constant", and "#define MPI_ANY_SOURCE" stands for "substituted by the preprocessor".) The "const int" was used to reduce C++ / C interlanguage issues. All other types (e.g., MPI_Group MPI_GROUP_NULL) are normally without const. 2) E.g., when I understand the standard correctly, then I would expect, that an implementor is allowed to define MPI_ANY_SOURCE as -2^30, i.e., an application statement short neighor = MPI_ANY_SOURCE; MPI_Recv(...., (int)neighbor, ...); seems to me to be not portable. Therefore, I hope that this discussion is still not necessary, because correct user codes are not broken. If only one or a few types are wrong, then I would like to see the text that would be necessary to fix it in an errata. Best regards Rolf On Thu, 6 Aug 2009 18:08:49 +0000 "Anthony Skjellum" wrote: > Everyone, first of all, we should not do anything rash in either >direction, and everyone should keep his or her cool in the debate, >even if things get contentious :-) and etc. > > While not taking sides on the technical matter right now, the fact >is that if we find there is a serious problem, we should act in favor >of quality and correctness at the expense of speed. We do not want >to compound any problem (if that is what we finally agree there is) >by a rash solution. We will be judged better (by our users and >adopters) for delaying rather than making a step that harms the >standard. We can always call an extra meeting if we had to to get >back on time track :-) > > Serious question: I am curious as to how we are going to rationally, >definitively and timely decide now if this breaks valid 2.1 programs? > What about 2.0 programs (of which there are far more)? A panel of a >subset of us? > > Regards, > > Tony > > Tony Skjellum, PhD > RunTime Computing Solutions, LLC > tony_at_[hidden] > direct: +1-205-314-3595 > cell: +1-205-807-4968 > > -----Original Message----- >From: Erez Haba > > Date: Thu, 6 Aug 2009 17:23:45 > To: MPI 2.2 > Subject: Re: [Mpi-22] Borderline ticket #107: Types of > predefined constants in Appendix A > > > Thanks Bill, > > It is still not clear to me if this ticket forces implementation to >change. > > If it does not, the discussion is over. > I'm okay with this ticket (minus the 'const' which is misleading and >not consistent, but I can live with it). > > If it does force implementations to change, I think we've been >mislead (it was presented as text only ticket) and we've rushed into >voting without much appropriate discussion. In that case I would like >to find the scope of the change and understand if it's really >necessary and whether it breaks any legit app. > > > Bill, I don't think that anyone voting on this ticket voted for an >implementation change. if this is the case, would withdrawing the >ticket have to pass the high bar of "it be withdrawn only if it >breaks a valid mpi 2.1 applications"? > > Thanks, > .Erez > > -----Original Message----- >From: mpi-22-bounces_at_[hidden] >[mailto:mpi-22-bounces_at_[hidden]] On Behalf Of William >Gropp > Sent: Wednesday, August 05, 2009 5:42 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] Borderline ticket #107: Types of predefined >constants in Appendix A > > In terms of what we can do with this, only if the ticket was out of > scope can it be withdrawn. That is, if it violates the rules for > valid MPI 2.2 items by, for example, making previously valid (and > unambiguous) MPI 2.1 programs invalid. If we discover something >like > that, we'll probably need to delay the standard. I don't believe > we've reached that threshold yet. > > Bill > > On Aug 4, 2009, at 12:21 PM, Erez Haba wrote: > >> I agree David, and as I said, it might be nitpicking :) >> >> Most compliers would probably optimize the cast out (Microsoft >> compiler sure does); however the question still remains; do >> implementers have to change the definition of their constant >> variables to meet this table? >> >> >> As for the second item, the point I'm making is that adding the >> 'const' qualifier for the types in the tables does not help clarity >> and it does quite the opposite. Would adding 'const' to >> MPI_Datatype, MPI_Comm or MPI_Op types in these tables helps? >> >> Which brings me to my third note which is, the use of 'const' in >> these tables is not consistent. Some types get the const modifiers >> and some do not. >> >> >> David, per your comment below, and to the audience, please note that >> this ticket is not just a trivial text change to the standard, as it >> introduces types for constants that were not assigned in the >> standard before. >> As you said below David, adding 'const' makes them non-lvalue for >> the specific C binding. >> >> >> I know that this ticket has passed 2nd vote, imho, wrongly without >> giving enough consideration to its content; as it was introduced as >> text only change. See the large number of abstains (including me). >> However it's up to us to decide. I don't know what the rules say, >> and if there is a way to take back this ticket without taking the >> entire chapter out. >> >> Thoughts?? >> >> Thanks, >> .Erez >> >> -----Original Message----- >> From: mpi-22-bounces_at_[hidden] >>[mailto:mpi-22-bounces_at_[hidden] >> ] On Behalf Of Dave Goodell >> Sent: Monday, August 03, 2009 2:00 PM >> To: MPI 2.2 >> Subject: Re: [Mpi-22] Borderline ticket #107: Types of predefined >> constants in Appendix A >> >> On Aug 3, 2009, at 12:36 PM, Erez Haba wrote: >> >>> This might be nitpicking but wouldn't that force implementation to >>> typecast their definition of error codes? For example, >>> >>> #define MPI_ERR_BUFFER 0 >>> >>> Is not a correct definition with the proposed change, because it is >>> not typed. >> >> I think that the "Constants with the type const int may also be >> implemented as literal integer constants substituted by the >> preprocessor" bit on lines 23-24 helps implementors realize that >>they >> don't need to insert a cast here. Also, the type of the integer >> constant 0 is typed as the first integer type in {int, long int, >>long >> long int} that can express the value, which is required to be int in >> this particular case. >> >>> Thus, it needs to change to >>> >>> #define MPI_ERR_BUFFER (int)0 // you don't really need to define >>> it as (const int)0 >>> >>> as a result the following statement >>> >>> short x = MPI_ERR_BUFFER; >>> >>> which compiled correctly before, would break with this change. >> >> To the best of my knowledge this is still perfectly legitimate C. >> Section 6.5.16.1 of my copy of the C99 standard seems to corroborate >> this: >> >> -------8<-------- >> Semantics >> >> 2 In simple assignment (=), the value of the right operand is >> converted to the type of the assignment expression and replaces the >> value stored in the object designated by the left operand. >> -------8<-------- >> >> GCC doesn't give a warning for this assignment, even when you add a >> bunch of warning flags. It does warn if the value is something too >> large for the short type (like 0xdeadbeef), although of course only >> for direct assignments like this when the compiler still knows the >> origin of the value. Does the Microsoft compiler behave >>differently? >> >>> Second comment. >>> >>> Adding the 'const' modifier to all types is very confusing imho. I >>> understand that it meant to make it clear that the values are >>> constants and should not change, but still is very confusing. >>> >>> For example, >>> >>> C Type: void * const >>> MPI_BOTTOM >>> >>> This means that the value of MPI_BOTTOM is constant and not the >>> memory it points to. however at first look you might think that it's >>> the later. (if it was, it would break any application that uses it >>> because the API's do not take a pointer to const void) >> >> I'm not sure that there's a lot we can do if people can't properly >> read cv-qualified C types. This is a standards document, not a >> tutorial. I don't think that this is intentionally misleading or >> difficult to read. >> >>> In any case implementers should define MPI_BOTTOM as >>> >>> #define MPI_BOTTOM (void*)0 >>> >>> Rather than >>> >>> #define MPI_BOTTOM (void* const)0 >>> >>> As the value is constant and you don't need to add the const >>> modifier. >> >> The reason you don't really need the const here is that casts create >> rvalues. So it has the same effect as a cast to the unqualified >>type. >> This, combined with the constant initializer rule in MPI-2.1 section >> 2.5.4, is one reason that choosing "const int" as the type for these >> constants is debatable. >> >>> Note that the 'constness' of these values is already stated in the >>> title of the section '19.1.1 Defined Constants' >> >> I don't agree. The semantic constness of these constants is implied >> by the title, but not the specific language implementation >>constness. >> In the standard we could say "X, Y, and Z are constants (their >>values >> never change) with the exact type `int'". Depending on the exact >>uses >> with the rest of the API this would be perfectly valid, although we >> might lose some error checking assistance from C compilers. >> >> The title together with MPI-2.1 section 2.5.4 indicates that most of >> these are compile-time constants that may be used for >>initialization, >> so you could say that the constness doesn't matter since these may >> never be stored in link-time constant variables. However using >> "const" as a way of indicating that these constants are "non- >> lvalue" (and in particular, "non-(modifiable lvalue)") is fine by >>me. >> >> -Dave >> >> _______________________________________________ >> mpi-22 mailing list >> mpi-22_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> >> >> _______________________________________________ >> mpi-22 mailing list >> mpi-22_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > William Gropp > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) From alexander.supalov at [hidden] Fri Aug 7 06:43:52 2009 From: alexander.supalov at [hidden] (Supalov, Alexander) Date: Fri, 7 Aug 2009 12:43:52 +0100 Subject: [Mpi-22] Borderline ticket #107: Types of predefined constants in Appendix A In-Reply-To: Message-ID: <928CFBE8E7CB0040959E56B4EA41A77EC1BFF073@irsmsx504.ger.corp.intel.com> Dear Brian, Thanks. I understood Bill's email as a request to report all possible issues with backward compatibility. Hence the reference to the attributes. Best regards. Alexander -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Barrett, Brian W Sent: Thursday, August 06, 2009 5:57 PM To: MPI 2.2 Subject: Re: [Mpi-22] Borderline ticket #107: Types of predefined constants in Appendix A Alexander - I'm not sure why you had to hijack a thread on a possibly valid issue with MPI 2.2 by bringing up a completely different issue, but I believe it seriously distracts from an important discussion. However, to answer your complaint regarding ticket #55, Bill was quite specific: "making previously valid (and unambiguous) MPI 2.1 programs invalid". Yes, the changes in #55 will make any codes which followed the examples instead of the text more clearly invalid, but they were invalid already as the examples are not part of the official standard language. Further, given the ambiguity (meaning the standards committee had multiple very long discussions about what the standard currently met) in the difference between deprecated and new Fortran functions, it would be nearly impossible to claim that that existing codes met the unambiguous threshold. Finally, the meaning of the standards text did not change, but was clarified to make its existing meaning more clear, as seen by the long thread between Rajeev, Rolf, and Jeff on existing text vs. new text. So although the change may cause compatibility problems with incorrectly written applications, the Forum handled ticket #55 properly. If you disagreed with specific parts of the text, the 10 months of discussion over the text was the proper time for constructive comments. The relentless attack on tickets you don't like, even after tickets have passed vote with clearly correct procedures, is rather distracting from real issues. Brian On 8/6/09 4:52 AM, "Supalov, Alexander" wrote: > Hi, > > The passed inter-language attribute changes (#55) do break existing programs > according to our investigation. > > Best regards. > > Alexander > > -----Original Message----- > From: mpi-22-bounces_at_[hidden] > [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of William Gropp > Sent: Thursday, August 06, 2009 2:42 AM > To: MPI 2.2 > Subject: Re: [Mpi-22] Borderline ticket #107: Types of predefined constants in > Appendix A > > In terms of what we can do with this, only if the ticket was out of > scope can it be withdrawn. That is, if it violates the rules for > valid MPI 2.2 items by, for example, making previously valid (and > unambiguous) MPI 2.1 programs invalid. If we discover something like > that, we'll probably need to delay the standard. I don't believe > we've reached that threshold yet. > > Bill > > On Aug 4, 2009, at 12:21 PM, Erez Haba wrote: > >> I agree David, and as I said, it might be nitpicking :) >> >> Most compliers would probably optimize the cast out (Microsoft >> compiler sure does); however the question still remains; do >> implementers have to change the definition of their constant >> variables to meet this table? >> >> >> As for the second item, the point I'm making is that adding the >> 'const' qualifier for the types in the tables does not help clarity >> and it does quite the opposite. Would adding 'const' to >> MPI_Datatype, MPI_Comm or MPI_Op types in these tables helps? >> >> Which brings me to my third note which is, the use of 'const' in >> these tables is not consistent. Some types get the const modifiers >> and some do not. >> >> >> David, per your comment below, and to the audience, please note that >> this ticket is not just a trivial text change to the standard, as it >> introduces types for constants that were not assigned in the >> standard before. >> As you said below David, adding 'const' makes them non-lvalue for >> the specific C binding. >> >> >> I know that this ticket has passed 2nd vote, imho, wrongly without >> giving enough consideration to its content; as it was introduced as >> text only change. See the large number of abstains (including me). >> However it's up to us to decide. I don't know what the rules say, >> and if there is a way to take back this ticket without taking the >> entire chapter out. >> >> Thoughts?? >> >> Thanks, >> .Erez >> >> -----Original Message----- >> From: mpi-22-bounces_at_[hidden] >> [mailto:mpi-22-bounces_at_[hidden] >> ] On Behalf Of Dave Goodell >> Sent: Monday, August 03, 2009 2:00 PM >> To: MPI 2.2 >> Subject: Re: [Mpi-22] Borderline ticket #107: Types of predefined >> constants in Appendix A >> >> On Aug 3, 2009, at 12:36 PM, Erez Haba wrote: >> >>> This might be nitpicking but wouldn't that force implementation to >>> typecast their definition of error codes? For example, >>> >>> #define MPI_ERR_BUFFER 0 >>> >>> Is not a correct definition with the proposed change, because it is >>> not typed. >> >> I think that the "Constants with the type const int may also be >> implemented as literal integer constants substituted by the >> preprocessor" bit on lines 23-24 helps implementors realize that they >> don't need to insert a cast here. Also, the type of the integer >> constant 0 is typed as the first integer type in {int, long int, long >> long int} that can express the value, which is required to be int in >> this particular case. >> >>> Thus, it needs to change to >>> >>> #define MPI_ERR_BUFFER (int)0 // you don't really need to define >>> it as (const int)0 >>> >>> as a result the following statement >>> >>> short x = MPI_ERR_BUFFER; >>> >>> which compiled correctly before, would break with this change. >> >> To the best of my knowledge this is still perfectly legitimate C. >> Section 6.5.16.1 of my copy of the C99 standard seems to corroborate >> this: >> >> -------8<-------- >> Semantics >> >> 2 In simple assignment (=), the value of the right operand is >> converted to the type of the assignment expression and replaces the >> value stored in the object designated by the left operand. >> -------8<-------- >> >> GCC doesn't give a warning for this assignment, even when you add a >> bunch of warning flags. It does warn if the value is something too >> large for the short type (like 0xdeadbeef), although of course only >> for direct assignments like this when the compiler still knows the >> origin of the value. Does the Microsoft compiler behave differently? >> >>> Second comment. >>> >>> Adding the 'const' modifier to all types is very confusing imho. I >>> understand that it meant to make it clear that the values are >>> constants and should not change, but still is very confusing. >>> >>> For example, >>> >>> C Type: void * const >>> MPI_BOTTOM >>> >>> This means that the value of MPI_BOTTOM is constant and not the >>> memory it points to. however at first look you might think that it's >>> the later. (if it was, it would break any application that uses it >>> because the API's do not take a pointer to const void) >> >> I'm not sure that there's a lot we can do if people can't properly >> read cv-qualified C types. This is a standards document, not a >> tutorial. I don't think that this is intentionally misleading or >> difficult to read. >> >>> In any case implementers should define MPI_BOTTOM as >>> >>> #define MPI_BOTTOM (void*)0 >>> >>> Rather than >>> >>> #define MPI_BOTTOM (void* const)0 >>> >>> As the value is constant and you don't need to add the const >>> modifier. >> >> The reason you don't really need the const here is that casts create >> rvalues. So it has the same effect as a cast to the unqualified type. >> This, combined with the constant initializer rule in MPI-2.1 section >> 2.5.4, is one reason that choosing "const int" as the type for these >> constants is debatable. >> >>> Note that the 'constness' of these values is already stated in the >>> title of the section '19.1.1 Defined Constants' >> >> I don't agree. The semantic constness of these constants is implied >> by the title, but not the specific language implementation constness. >> In the standard we could say "X, Y, and Z are constants (their values >> never change) with the exact type `int'". Depending on the exact uses >> with the rest of the API this would be perfectly valid, although we >> might lose some error checking assistance from C compilers. >> >> The title together with MPI-2.1 section 2.5.4 indicates that most of >> these are compile-time constants that may be used for initialization, >> so you could say that the constness doesn't matter since these may >> never be stored in link-time constant variables. However using >> "const" as a way of indicating that these constants are "non- >> lvalue" (and in particular, "non-(modifiable lvalue)") is fine by me. >> >> -Dave >> >> _______________________________________________ >> mpi-22 mailing list >> mpi-22_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> >> >> _______________________________________________ >> mpi-22 mailing list >> mpi-22_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > William Gropp > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > --------------------------------------------------------------------- > Intel GmbH > Dornacher Strasse 1 > 85622 Feldkirchen/Muenchen Germany > Sitz der Gesellschaft: Feldkirchen bei Muenchen > Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer > Registergericht: Muenchen HRB 47456 Ust.-IdNr. > VAT Registration No.: DE129385895 > Citibank Frankfurt (BLZ 502 109 00) 600119052 > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 --------------------------------------------------------------------- Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen Germany Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Douglas Lusk, Peter Gleissner, Hannes Schwaderer Registergericht: Muenchen HRB 47456 Ust.-IdNr. VAT Registration No.: DE129385895 Citibank Frankfurt (BLZ 502 109 00) 600119052 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From erezh at [hidden] Fri Aug 7 14:25:43 2009 From: erezh at [hidden] (Erez Haba) Date: Fri, 7 Aug 2009 19:25:43 +0000 Subject: [Mpi-22] Borderline ticket #107: Types ofpredefined constants in Appendix A In-Reply-To: Message-ID: <85287355FA6D5646A8A8A083CE185EEB02F0B4F4@TK5EX14MBXC114.redmond.corp.microsoft.com> What is the conclusion? Does this ticket forces *any* implementation change? -----Original Message----- From: mpi-22-bounces_at_[hidden] [mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Rolf Rabenseifner Sent: Thursday, August 06, 2009 12:39 PM To: tony_at_[hidden]; MPI 2.2 Subject: Re: [Mpi-22] Borderline ticket #107: Types ofpredefined constants in Appendix A It wasn't my goal to change MPI implementations. For me, it was strange, that C++ user get the type imformation in this Appendix and Fortran and C users have to look for the type info somewhere in the standard. Some details. 1) The goal of the sentence Constants with the type {{const int}} may also be implemented as literal integer constants substituted by the preprocessor. was to allow #define MPI_ANY_SOURCE -3 i.e., without any type casting! ("-3" is a "literal integer constant", and "#define MPI_ANY_SOURCE" stands for "substituted by the preprocessor".) The "const int" was used to reduce C++ / C interlanguage issues. All other types (e.g., MPI_Group MPI_GROUP_NULL) are normally without const. 2) E.g., when I understand the standard correctly, then I would expect, that an implementor is allowed to define MPI_ANY_SOURCE as -2^30, i.e., an application statement short neighor = MPI_ANY_SOURCE; MPI_Recv(...., (int)neighbor, ...); seems to me to be not portable. Therefore, I hope that this discussion is still not necessary, because correct user codes are not broken. If only one or a few types are wrong, then I would like to see the text that would be necessary to fix it in an errata. Best regards Rolf On Thu, 6 Aug 2009 18:08:49 +0000 "Anthony Skjellum" wrote: > Everyone, first of all, we should not do anything rash in either >direction, and everyone should keep his or her cool in the debate, >even if things get contentious :-) and etc. > > While not taking sides on the technical matter right now, the fact >is that if we find there is a serious problem, we should act in favor >of quality and correctness at the expense of speed. We do not want >to compound any problem (if that is what we finally agree there is) >by a rash solution. We will be judged better (by our users and >adopters) for delaying rather than making a step that harms the >standard. We can always call an extra meeting if we had to to get >back on time track :-) > > Serious question: I am curious as to how we are going to rationally, >definitively and timely decide now if this breaks valid 2.1 programs? > What about 2.0 programs (of which there are far more)? A panel of a >subset of us? > > Regards, > > Tony > > Tony Skjellum, PhD > RunTime Computing Solutions, LLC > tony_at_[hidden] > direct: +1-205-314-3595 > cell: +1-205-807-4968 > > -----Original Message----- >From: Erez Haba > > Date: Thu, 6 Aug 2009 17:23:45 > To: MPI 2.2 > Subject: Re: [Mpi-22] Borderline ticket #107: Types of > predefined constants in Appendix A > > > Thanks Bill, > > It is still not clear to me if this ticket forces implementation to >change. > > If it does not, the discussion is over. > I'm okay with this ticket (minus the 'const' which is misleading and >not consistent, but I can live with it). > > If it does force implementations to change, I think we've been >mislead (it was presented as text only ticket) and we've rushed into >voting without much appropriate discussion. In that case I would like >to find the scope of the change and understand if it's really >necessary and whether it breaks any legit app. > > > Bill, I don't think that anyone voting on this ticket voted for an >implementation change. if this is the case, would withdrawing the >ticket have to pass the high bar of "it be withdrawn only if it >breaks a valid mpi 2.1 applications"? > > Thanks, > .Erez > > -----Original Message----- >From: mpi-22-bounces_at_[hidden] >[mailto:mpi-22-bounces_at_[hidden]] On Behalf Of William >Gropp > Sent: Wednesday, August 05, 2009 5:42 PM > To: MPI 2.2 > Subject: Re: [Mpi-22] Borderline ticket #107: Types of predefined >constants in Appendix A > > In terms of what we can do with this, only if the ticket was out of > scope can it be withdrawn. That is, if it violates the rules for > valid MPI 2.2 items by, for example, making previously valid (and > unambiguous) MPI 2.1 programs invalid. If we discover something >like > that, we'll probably need to delay the standard. I don't believe > we've reached that threshold yet. > > Bill > > On Aug 4, 2009, at 12:21 PM, Erez Haba wrote: > >> I agree David, and as I said, it might be nitpicking :) >> >> Most compliers would probably optimize the cast out (Microsoft >> compiler sure does); however the question still remains; do >> implementers have to change the definition of their constant >> variables to meet this table? >> >> >> As for the second item, the point I'm making is that adding the >> 'const' qualifier for the types in the tables does not help clarity >> and it does quite the opposite. Would adding 'const' to >> MPI_Datatype, MPI_Comm or MPI_Op types in these tables helps? >> >> Which brings me to my third note which is, the use of 'const' in >> these tables is not consistent. Some types get the const modifiers >> and some do not. >> >> >> David, per your comment below, and to the audience, please note that >> this ticket is not just a trivial text change to the standard, as it >> introduces types for constants that were not assigned in the >> standard before. >> As you said below David, adding 'const' makes them non-lvalue for >> the specific C binding. >> >> >> I know that this ticket has passed 2nd vote, imho, wrongly without >> giving enough consideration to its content; as it was introduced as >> text only change. See the large number of abstains (including me). >> However it's up to us to decide. I don't know what the rules say, >> and if there is a way to take back this ticket without taking the >> entire chapter out. >> >> Thoughts?? >> >> Thanks, >> .Erez >> >> -----Original Message----- >> From: mpi-22-bounces_at_[hidden] >>[mailto:mpi-22-bounces_at_[hidden] >> ] On Behalf Of Dave Goodell >> Sent: Monday, August 03, 2009 2:00 PM >> To: MPI 2.2 >> Subject: Re: [Mpi-22] Borderline ticket #107: Types of predefined >> constants in Appendix A >> >> On Aug 3, 2009, at 12:36 PM, Erez Haba wrote: >> >>> This might be nitpicking but wouldn't that force implementation to >>> typecast their definition of error codes? For example, >>> >>> #define MPI_ERR_BUFFER 0 >>> >>> Is not a correct definition with the proposed change, because it is >>> not typed. >> >> I think that the "Constants with the type const int may also be >> implemented as literal integer constants substituted by the >> preprocessor" bit on lines 23-24 helps implementors realize that >>they >> don't need to insert a cast here. Also, the type of the integer >> constant 0 is typed as the first integer type in {int, long int, >>long >> long int} that can express the value, which is required to be int in >> this particular case. >> >>> Thus, it needs to change to >>> >>> #define MPI_ERR_BUFFER (int)0 // you don't really need to define >>> it as (const int)0 >>> >>> as a result the following statement >>> >>> short x = MPI_ERR_BUFFER; >>> >>> which compiled correctly before, would break with this change. >> >> To the best of my knowledge this is still perfectly legitimate C. >> Section 6.5.16.1 of my copy of the C99 standard seems to corroborate >> this: >> >> -------8<-------- >> Semantics >> >> 2 In simple assignment (=), the value of the right operand is >> converted to the type of the assignment expression and replaces the >> value stored in the object designated by the left operand. >> -------8<-------- >> >> GCC doesn't give a warning for this assignment, even when you add a >> bunch of warning flags. It does warn if the value is something too >> large for the short type (like 0xdeadbeef), although of course only >> for direct assignments like this when the compiler still knows the >> origin of the value. Does the Microsoft compiler behave >>differently? >> >>> Second comment. >>> >>> Adding the 'const' modifier to all types is very confusing imho. I >>> understand that it meant to make it clear that the values are >>> constants and should not change, but still is very confusing. >>> >>> For example, >>> >>> C Type: void * const >>> MPI_BOTTOM >>> >>> This means that the value of MPI_BOTTOM is constant and not the >>> memory it points to. however at first look you might think that it's >>> the later. (if it was, it would break any application that uses it >>> because the API's do not take a pointer to const void) >> >> I'm not sure that there's a lot we can do if people can't properly >> read cv-qualified C types. This is a standards document, not a >> tutorial. I don't think that this is intentionally misleading or >> difficult to read. >> >>> In any case implementers should define MPI_BOTTOM as >>> >>> #define MPI_BOTTOM (void*)0 >>> >>> Rather than >>> >>> #define MPI_BOTTOM (void* const)0 >>> >>> As the value is constant and you don't need to add the const >>> modifier. >> >> The reason you don't really need the const here is that casts create >> rvalues. So it has the same effect as a cast to the unqualified >>type. >> This, combined with the constant initializer rule in MPI-2.1 section >> 2.5.4, is one reason that choosing "const int" as the type for these >> constants is debatable. >> >>> Note that the 'constness' of these values is already stated in the >>> title of the section '19.1.1 Defined Constants' >> >> I don't agree. The semantic constness of these constants is implied >> by the title, but not the specific language implementation >>constness. >> In the standard we could say "X, Y, and Z are constants (their >>values >> never change) with the exact type `int'". Depending on the exact >>uses >> with the rest of the API this would be perfectly valid, although we >> might lose some error checking assistance from C compilers. >> >> The title together with MPI-2.1 section 2.5.4 indicates that most of >> these are compile-time constants that may be used for >>initialization, >> so you could say that the constness doesn't matter since these may >> never be stored in link-time constant variables. However using >> "const" as a way of indicating that these constants are "non- >> lvalue" (and in particular, "non-(modifiable lvalue)") is fine by >>me. >> >> -Dave >> >> _______________________________________________ >> mpi-22 mailing list >> mpi-22_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> >> >> _______________________________________________ >> mpi-22 mailing list >> mpi-22_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > William Gropp > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 From rabenseifner at [hidden] Fri Aug 7 15:37:25 2009 From: rabenseifner at [hidden] (Rolf Rabenseifner) Date: Fri, 07 Aug 2009 22:37:25 +0200 Subject: [Mpi-22] Borderline ticket #107: Types ofpredefined constants in Appendix A In-Reply-To: <85287355FA6D5646A8A8A083CE185EEB02F0B4F4@TK5EX14MBXC114.redmond.corp.microsoft.com> Message-ID: For the literal integer / const int / unnamed enum, the problem seems to be solved. For some special values may be still some need, but only if an implementor shows up with a clear discrepancy between MPI-2.2 and his implementation. On Fri, 7 Aug 2009 19:25:43 +0000 Erez Haba wrote: > What is the conclusion? Does this ticket forces *any* implementation >change? > > -----Original Message----- >From: mpi-22-bounces_at_[hidden] >[mailto:mpi-22-bounces_at_[hidden]] On Behalf Of Rolf >Rabenseifner > Sent: Thursday, August 06, 2009 12:39 PM > To: tony_at_[hidden]; MPI 2.2 > Subject: Re: [Mpi-22] Borderline ticket #107: Types ofpredefined >constants in Appendix A > > It wasn't my goal to change MPI implementations. >For me, it was strange, that C++ user get the type imformation > in this Appendix and Fortran and C users have to look for the > type info somewhere in the standard. > > Some details. > > 1) The goal of the sentence > > Constants with the type {{const int}} may also be implemented > as literal integer constants substituted by the preprocessor. > > was to allow > > #define MPI_ANY_SOURCE -3 > > i.e., without any type casting! > ("-3" is a "literal integer constant", and "#define > MPI_ANY_SOURCE" > stands for "substituted by the preprocessor".) > The "const int" was used to reduce C++ / C interlanguage issues. > All other types (e.g., MPI_Group MPI_GROUP_NULL) are normally > without const. > > 2) E.g., when I understand the standard correctly, then I would > expect, that an implementor is allowed to define MPI_ANY_SOURCE > as -2^30, i.e., an application statement > > short neighor = MPI_ANY_SOURCE; > MPI_Recv(...., (int)neighbor, ...); > > seems to me to be not portable. > > Therefore, I hope that this discussion is still not necessary, >because > correct user codes are not broken. > > If only one or a few types are wrong, then I would like to see the > text that would be necessary to fix it in an errata. > > Best regards > Rolf > > On Thu, 6 Aug 2009 18:08:49 +0000 > "Anthony Skjellum" wrote: >> Everyone, first of all, we should not do anything rash in either >>direction, and everyone should keep his or her cool in the debate, >>even if things get contentious :-) and etc. >> >> While not taking sides on the technical matter right now, the fact >>is that if we find there is a serious problem, we should act in favor >>of quality and correctness at the expense of speed. We do not want >>to compound any problem (if that is what we finally agree there is) >>by a rash solution. We will be judged better (by our users and >>adopters) for delaying rather than making a step that harms the >>standard. We can always call an extra meeting if we had to to get >>back on time track :-) >> >> Serious question: I am curious as to how we are going to rationally, >>definitively and timely decide now if this breaks valid 2.1 programs? >> What about 2.0 programs (of which there are far more)? A panel of a >>subset of us? >> >> Regards, >> >> Tony >> >> Tony Skjellum, PhD >> RunTime Computing Solutions, LLC >> tony_at_[hidden] >> direct: +1-205-314-3595 >> cell: +1-205-807-4968 >> >> -----Original Message----- >>From: Erez Haba >> >> Date: Thu, 6 Aug 2009 17:23:45 >> To: MPI 2.2 >> Subject: Re: [Mpi-22] Borderline ticket #107: Types of >> predefined constants in Appendix A >> >> >> Thanks Bill, >> >> It is still not clear to me if this ticket forces implementation to >>change. >> >> If it does not, the discussion is over. >> I'm okay with this ticket (minus the 'const' which is misleading and >>not consistent, but I can live with it). >> >> If it does force implementations to change, I think we've been >>mislead (it was presented as text only ticket) and we've rushed into >>voting without much appropriate discussion. In that case I would like >>to find the scope of the change and understand if it's really >>necessary and whether it breaks any legit app. >> >> >> Bill, I don't think that anyone voting on this ticket voted for an >>implementation change. if this is the case, would withdrawing the >>ticket have to pass the high bar of "it be withdrawn only if it >>breaks a valid mpi 2.1 applications"? >> >> Thanks, >> .Erez >> >> -----Original Message----- >>From: mpi-22-bounces_at_[hidden] >>[mailto:mpi-22-bounces_at_[hidden]] On Behalf Of William >>Gropp >> Sent: Wednesday, August 05, 2009 5:42 PM >> To: MPI 2.2 >> Subject: Re: [Mpi-22] Borderline ticket #107: Types of predefined >>constants in Appendix A >> >> In terms of what we can do with this, only if the ticket was out of >> scope can it be withdrawn. That is, if it violates the rules for >> valid MPI 2.2 items by, for example, making previously valid (and >> unambiguous) MPI 2.1 programs invalid. If we discover something >>like >> that, we'll probably need to delay the standard. I don't believe >> we've reached that threshold yet. >> >> Bill >> >> On Aug 4, 2009, at 12:21 PM, Erez Haba wrote: >> >>> I agree David, and as I said, it might be nitpicking :) >>> >>> Most compliers would probably optimize the cast out (Microsoft >>> compiler sure does); however the question still remains; do >>> implementers have to change the definition of their constant >>> variables to meet this table? >>> >>> >>> As for the second item, the point I'm making is that adding the >>> 'const' qualifier for the types in the tables does not help clarity >>> and it does quite the opposite. Would adding 'const' to >>> MPI_Datatype, MPI_Comm or MPI_Op types in these tables helps? >>> >>> Which brings me to my third note which is, the use of 'const' in >>> these tables is not consistent. Some types get the const modifiers >>> and some do not. >>> >>> >>> David, per your comment below, and to the audience, please note that >>> this ticket is not just a trivial text change to the standard, as it >>> introduces types for constants that were not assigned in the >>> standard before. >>> As you said below David, adding 'const' makes them non-lvalue for >>> the specific C binding. >>> >>> >>> I know that this ticket has passed 2nd vote, imho, wrongly without >>> giving enough consideration to its content; as it was introduced as >>> text only change. See the large number of abstains (including me). >>> However it's up to us to decide. I don't know what the rules say, >>> and if there is a way to take back this ticket without taking the >>> entire chapter out. >>> >>> Thoughts?? >>> >>> Thanks, >>> .Erez >>> >>> -----Original Message----- >>> From: mpi-22-bounces_at_[hidden] >>>[mailto:mpi-22-bounces_at_[hidden] >>> ] On Behalf Of Dave Goodell >>> Sent: Monday, August 03, 2009 2:00 PM >>> To: MPI 2.2 >>> Subject: Re: [Mpi-22] Borderline ticket #107: Types of predefined >>> constants in Appendix A >>> >>> On Aug 3, 2009, at 12:36 PM, Erez Haba wrote: >>> >>>> This might be nitpicking but wouldn't that force implementation to >>>> typecast their definition of error codes? For example, >>>> >>>> #define MPI_ERR_BUFFER 0 >>>> >>>> Is not a correct definition with the proposed change, because it is >>>> not typed. >>> >>> I think that the "Constants with the type const int may also be >>> implemented as literal integer constants substituted by the >>> preprocessor" bit on lines 23-24 helps implementors realize that >>>they >>> don't need to insert a cast here. Also, the type of the integer >>> constant 0 is typed as the first integer type in {int, long int, >>>long >>> long int} that can express the value, which is required to be int in >>> this particular case. >>> >>>> Thus, it needs to change to >>>> >>>> #define MPI_ERR_BUFFER (int)0 // you don't really need to define >>>> it as (const int)0 >>>> >>>> as a result the following statement >>>> >>>> short x = MPI_ERR_BUFFER; >>>> >>>> which compiled correctly before, would break with this change. >>> >>> To the best of my knowledge this is still perfectly legitimate C. >>> Section 6.5.16.1 of my copy of the C99 standard seems to corroborate >>> this: >>> >>> -------8<-------- >>> Semantics >>> >>> 2 In simple assignment (=), the value of the right operand is >>> converted to the type of the assignment expression and replaces the >>> value stored in the object designated by the left operand. >>> -------8<-------- >>> >>> GCC doesn't give a warning for this assignment, even when you add a >>> bunch of warning flags. It does warn if the value is something too >>> large for the short type (like 0xdeadbeef), although of course only >>> for direct assignments like this when the compiler still knows the >>> origin of the value. Does the Microsoft compiler behave >>>differently? >>> >>>> Second comment. >>>> >>>> Adding the 'const' modifier to all types is very confusing imho. I >>>> understand that it meant to make it clear that the values are >>>> constants and should not change, but still is very confusing. >>>> >>>> For example, >>>> >>>> C Type: void * const >>>> MPI_BOTTOM >>>> >>>> This means that the value of MPI_BOTTOM is constant and not the >>>> memory it points to. however at first look you might think that it's >>>> the later. (if it was, it would break any application that uses it >>>> because the API's do not take a pointer to const void) >>> >>> I'm not sure that there's a lot we can do if people can't properly >>> read cv-qualified C types. This is a standards document, not a >>> tutorial. I don't think that this is intentionally misleading or >>> difficult to read. >>> >>>> In any case implementers should define MPI_BOTTOM as >>>> >>>> #define MPI_BOTTOM (void*)0 >>>> >>>> Rather than >>>> >>>> #define MPI_BOTTOM (void* const)0 >>>> >>>> As the value is constant and you don't need to add the const >>>> modifier. >>> >>> The reason you don't really need the const here is that casts create >>> rvalues. So it has the same effect as a cast to the unqualified >>>type. >>> This, combined with the constant initializer rule in MPI-2.1 section >>> 2.5.4, is one reason that choosing "const int" as the type for these >>> constants is debatable. >>> >>>> Note that the 'constness' of these values is already stated in the >>>> title of the section '19.1.1 Defined Constants' >>> >>> I don't agree. The semantic constness of these constants is implied >>> by the title, but not the specific language implementation >>>constness. >>> In the standard we could say "X, Y, and Z are constants (their >>>values >>> never change) with the exact type `int'". Depending on the exact >>>uses >>> with the rest of the API this would be perfectly valid, although we >>> might lose some error checking assistance from C compilers. >>> >>> The title together with MPI-2.1 section 2.5.4 indicates that most of >>> these are compile-time constants that may be used for >>>initialization, >>> so you could say that the constness doesn't matter since these may >>> never be stored in link-time constant variables. However using >>> "const" as a way of indicating that these constants are "non- >>> lvalue" (and in particular, "non-(modifiable lvalue)") is fine by >>>me. >>> >>> -Dave >>> >>> _______________________________________________ >>> mpi-22 mailing list >>> mpi-22_at_[hidden] >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >>> >>> >>> _______________________________________________ >>> mpi-22 mailing list >>> mpi-22_at_[hidden] >>> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> >> William Gropp >> Deputy Director for Research >> Institute for Advanced Computing Applications and Technologies >> Paul and Cynthia Saylor Professor of Computer Science >> University of Illinois Urbana-Champaign >> >> >> >> >> _______________________________________________ >> mpi-22 mailing list >> mpi-22_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> >> >> _______________________________________________ >> mpi-22 mailing list >> mpi-22_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 >> >> _______________________________________________ >> mpi-22 mailing list >> mpi-22_at_[hidden] >> http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > Dr. Rolf Rabenseifner . . . . . . . . . .. email >rabenseifner_at_[hidden] > High Performance Computing Center (HLRS) . phone >++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / >685-65832 > Head of Dpmt Parallel Computing . . . >www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) From rabenseifner at [hidden] Thu Aug 20 15:02:56 2009 From: rabenseifner at [hidden] (Rolf Rabenseifner) Date: Thu, 20 Aug 2009 22:02:56 +0200 Subject: [Mpi-22] Ticket #77 review In-Reply-To: <052.de1a00947ee3a1d006ee7c147bdddcfa@lists.mpi-forum.org> Message-ID: Bill, I'm not sure, whether you get the email automatically through ticket 77 because you are not on the CC list. Therefore here the same text as in the ticket: Because final MPI-2.2 meeting is approaching soon, I checked also this ticket. Here some details. All page:linenumbers are based on review-pdf from svn revision 384. - svn384_xxii:22 - "Jeffrey M." instead of "Jeff" - svn384_xxii:22 - add "; MPI-2.1 Secretary" - svn384_xxiii:3 - "The HDF Group" instead of "HDF Group" - svn384_xxiii:25 - "SUN Microsystems, Inc.", i.e., with "s Inc." - svn384_xxiv:2 - There was a comment, to make plural ("Communications"), but the chapter title is singular. - svn384_xxiv:7 - ", Info-Object", i.e., with comma after "Träff" - svn384_xxiv:16 - add "; MPI-2.2 Secretary" - svn384_xxiv:19 - "Bindings" instead of "bindings" - svn384_xxiv:23 - remove "This list needs to be checked ..." - svn384_xxiv:40 - "Jeffrey M." instead of "Jeff" - svn384_xxv:10 - remove line with "HLRS" (it is already there on xxv:36) - svn384_xxv:14 - please check, for full name of "Inst. Adv. Sci. & Eng. - svn384_xxiii:38-40 and svn384_xxv:41-43 - should you write the two sentences in both locations in the same sequence? When I understood correctly, then NSF has funded more than HDF. - MPI-2.1_4:19, you added new text. One list item is "Any extension must have significant benefit for users". The period at the end of the sentence is missing. Best regards Rolf Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) From treumann at [hidden] Fri Aug 21 08:39:40 2009 From: treumann at [hidden] (Richard Treumann) Date: Fri, 21 Aug 2009 09:39:40 -0400 Subject: [Mpi-22] [MPI Forum] #107: Types of predefined constants in Appendix A In-Reply-To: <063.fee767ac9729489c8d2274005d4e75d9@lists.mpi-forum.org> Message-ID: I took the text from the ticket by copy/paste and added LaTeX formatting. I did not notice the typo in agruments or the problem with "and comm_copy_attr_fn comm_delete_attr_fn" I can correct the typo but I would appreciate a definite statement about what "and comm_copy_attr_fn comm_delete_attr_fn" should be. I presume is should say "and comm_copy_attr_fn or comm_delete_attr_fn" but I would like confirmation on that from the author of this paragraph Dick Dick Treumann - MPI Team IBM Systems & Technology Group Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 From: "MPI Forum" To: undisclosed-recipients:; Date: 08/21/2009 09:14 AM Subject: Re: [MPI Forum] #107: Types of predefined constants in Appendix A #107: Types of predefined constants in Appendix A -----------------------------------------------------+---------------------- Reporter: RolfRabenseifner | Owner: RolfRabenseifner Type: Text (only) changes | Status: new Priority: Waiting for PDF reviews | Milestone: 2009/07/27 Chicago Version: MPI 2.2 | Resolution: Keywords: | Implementation: Unnecessary Author_bill_gropp: 0 | Author_rich_graham: 0 Author_adam_moody: 0 | Author_torsten_hoefler: 0 Author_dick_treumann: 1 | Author_jesper_larsson_traeff: 0 Author_george_bosilca: 0 | Author_david_solt: 0 Author_bronis_de_supinski: 0 | Author_rajeev_thakur: 0 Author_jeff_squyres: 0 | Author_alexander_supalov: 1 Author_rolf_rabenseifner: 1 | -----------------------------------------------------+---------------------- Comment(by traff): PDF/ticket not ok: 1. Advice to implementors: spelling "agruments" should be corrected (in ticket and pdf) 2. Advice to users: some punctuation or conjunction seems to be missing in "and comm_copy_attr_fn comm_delete_attr_fn"; what is intended here? -- Ticket URL: < https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/107#comment:51> MPI Forum MPI Forum * -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: application/octet-stream Size: 229 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ecblank.gif Type: application/octet-stream Size: 45 bytes Desc: not available URL: From wgropp at [hidden] Fri Aug 21 09:19:36 2009 From: wgropp at [hidden] (William Gropp) Date: Fri, 21 Aug 2009 09:19:36 -0500 Subject: [Mpi-22] [MPI Forum] #107: Types of predefined constants in Appendix A In-Reply-To: Message-ID: <4199EDB0-7688-4716-9230-D8CA3A912C1A@illinois.edu> It should be and/or. I'll fix it. Bill On Aug 21, 2009, at 8:39 AM, Richard Treumann wrote: > I took the text from the ticket by copy/paste and added LaTeX > formatting. I did not notice the typo in agruments or the problem > with "and comm_copy_attr_fn comm_delete_attr_fn" > > I can correct the typo but I would appreciate a definite statement > about what "and comm_copy_attr_fn comm_delete_attr_fn" should be. I > presume is should say "and comm_copy_attr_fn or comm_delete_attr_fn" > but I would like confirmation on that from the author of this > paragraph > > Dick > > > Dick Treumann - MPI Team > IBM Systems & Technology Group > Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 > Tele (845) 433-7846 Fax (845) 433-8363 > > > "MPI Forum" ---08/21/2009 09:14:57 AM---#107: Types of > predefined constants in Appendix A > -------------------------------------------------- > > > From: > "MPI Forum" > > To: > undisclosed-recipients:; > > Date: > 08/21/2009 09:14 AM > > Subject: > Re: [MPI Forum] #107: Types of predefined constants in Appendix A > > > > #107: Types of predefined constants in Appendix A > ----------------------------------------------------- > +---------------------- > Reporter: RolfRabenseifner > | Owner: RolfRabenseifner > Type: Text (only) changes > | Status: new > Priority: Waiting for PDF reviews > | Milestone: 2009/07/27 Chicago > Version: MPI 2.2 > | Resolution: > Keywords: > | Implementation: Unnecessary > Author_bill_gropp: 0 | > Author_rich_graham: 0 > Author_adam_moody: 0 | > Author_torsten_hoefler: 0 > Author_dick_treumann: 1 | > Author_jesper_larsson_traeff: 0 > Author_george_bosilca: 0 | > Author_david_solt: 0 > Author_bronis_de_supinski: 0 | > Author_rajeev_thakur: 0 > Author_jeff_squyres: 0 | > Author_alexander_supalov: 1 > Author_rolf_rabenseifner: 1 | > ----------------------------------------------------- > +---------------------- > > Comment(by traff): > > PDF/ticket not ok: > > 1. Advice to implementors: spelling "agruments" should be corrected > (in > ticket and pdf) > > 2. Advice to users: some punctuation or conjunction seems to be > missing in > "and comm_copy_attr_fn comm_delete_attr_fn"; what is intended here? > > -- > Ticket URL: > > MPI Forum > MPI Forum > > > William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign * -------------- next part -------------- An HTML attachment was scrubbed... URL: From treumann at [hidden] Fri Aug 21 09:25:19 2009 From: treumann at [hidden] (Richard Treumann) Date: Fri, 21 Aug 2009 10:25:19 -0400 Subject: [Mpi-22] [MPI Forum] #107: Types of predefined constants in Appendix A In-Reply-To: <4199EDB0-7688-4716-9230-D8CA3A912C1A@illinois.edu> Message-ID: Thanks Bill I will assume you mean you will fix both typos and I am not to do another edit round. Dick Dick Treumann - MPI Team IBM Systems & Technology Group Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 From: William Gropp To: "MPI 2.2" Date: 08/21/2009 10:20 AM Subject: Re: [Mpi-22] [MPI Forum] #107: Types of predefined constants in Appendix A Sent by: mpi-22-bounces_at_[hidden] It should be and/or. I'll fix it. Bill On Aug 21, 2009, at 8:39 AM, Richard Treumann wrote: I took the text from the ticket by copy/paste and added LaTeX formatting. I did not notice the typo in agruments or the problem with "and comm_copy_attr_fn comm_delete_attr_fn" I can correct the typo but I would appreciate a definite statement about what "and comm_copy_attr_fn comm_delete_attr_fn" should be. I presume is should say "and comm_copy_attr_fn or comm_delete_attr_fn" but I would like confirmation on that from the author of this paragraph Dick Dick Treumann - MPI Team IBM Systems & Technology Group Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 Tele (845) 433-7846 Fax (845) 433-8363 "MPI Forum" ---08/21/2009 09:14:57 AM---#107: Types of predefined constants in Appendix A -------------------------------------------------- From: "MPI Forum" To: undisclosed-recipients:; Date: 08/21/2009 09:14 AM Subject: Re: [MPI Forum] #107: Types of predefined constants in Appendix A #107: Types of predefined constants in Appendix A -----------------------------------------------------+---------------------- Reporter: RolfRabenseifner | Owner: RolfRabenseifner Type: Text (only) changes | Status: new Priority: Waiting for PDF reviews | Milestone: 2009/07/27 Chicago Version: MPI 2.2 | Resolution: Keywords: | Implementation: Unnecessary Author_bill_gropp: 0 | Author_rich_graham: 0 Author_adam_moody: 0 | Author_torsten_hoefler: 0 Author_dick_treumann: 1 | Author_jesper_larsson_traeff: 0 Author_george_bosilca: 0 | Author_david_solt: 0 Author_bronis_de_supinski: 0 | Author_rajeev_thakur: 0 Author_jeff_squyres: 0 | Author_alexander_supalov: 1 Author_rolf_rabenseifner: 1 | -----------------------------------------------------+---------------------- Comment(by traff): PDF/ticket not ok: 1. Advice to implementors: spelling "agruments" should be corrected (in ticket and pdf) 2. Advice to users: some punctuation or conjunction seems to be missing in "and comm_copy_attr_fn comm_delete_attr_fn"; what is intended here? -- Ticket URL: < https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/107#comment:51> MPI Forum MPI Forum William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign _______________________________________________ mpi-22 mailing list mpi-22_at_[hidden] http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 * -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: application/octet-stream Size: 229 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ecblank.gif Type: application/octet-stream Size: 45 bytes Desc: not available URL: From wgropp at [hidden] Fri Aug 21 09:29:05 2009 From: wgropp at [hidden] (William Gropp) Date: Fri, 21 Aug 2009 09:29:05 -0500 Subject: [Mpi-22] [MPI Forum] #107: Types of predefined constants in Appendix A In-Reply-To: Message-ID: Yes. Bill On Aug 21, 2009, at 9:25 AM, Richard Treumann wrote: > Thanks Bill > > I will assume you mean you will fix both typos and I am not to do > another edit round. > > Dick > > Dick Treumann - MPI Team > IBM Systems & Technology Group > Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 > Tele (845) 433-7846 Fax (845) 433-8363 > > > William Gropp ---08/21/2009 10:20:59 AM---It should be > and/or. I'll fix it. Bill > > > From: > William Gropp > > To: > "MPI 2.2" > > Date: > 08/21/2009 10:20 AM > > Subject: > Re: [Mpi-22] [MPI Forum] #107: Types of predefined constants in > Appendix A > > Sent by: > mpi-22-bounces_at_[hidden] > > > > It should be and/or. I'll fix it. > > Bill > > On Aug 21, 2009, at 8:39 AM, Richard Treumann wrote: > I took the text from the ticket by copy/paste and added LaTeX > formatting. I did not notice the typo in agruments or the problem > with "and comm_copy_attr_fn comm_delete_attr_fn" > > I can correct the typo but I would appreciate a definite statement > about what "and comm_copy_attr_fn comm_delete_attr_fn" should be. I > presume is should say "and comm_copy_attr_fn or comm_delete_attr_fn" > but I would like confirmation on that from the author of this > paragraph > > Dick > > > Dick Treumann - MPI Team > IBM Systems & Technology Group > Dept X2ZA / MS P963 -- 2455 South Road -- Poughkeepsie, NY 12601 > Tele (845) 433-7846 Fax (845) 433-8363 > > > "MPI Forum" ---08/21/2009 09:14:57 AM---#107: Types of > predefined constants in Appendix A > -------------------------------------------------- > > From: > "MPI Forum" > > To: > undisclosed-recipients:; > > Date: > 08/21/2009 09:14 AM > > Subject: > Re: [MPI Forum] #107: Types of predefined constants in Appendix A > > > > #107: Types of predefined constants in Appendix A > ----------------------------------------------------- > +---------------------- > Reporter: RolfRabenseifner > | Owner: RolfRabenseifner > Type: Text (only) changes > | Status: new > Priority: Waiting for PDF reviews > | Milestone: 2009/07/27 Chicago > Version: MPI 2.2 > | Resolution: > Keywords: | > Implementation: Unnecessary > Author_bill_gropp: 0 | > Author_rich_graham: 0 > Author_adam_moody: 0 | > Author_torsten_hoefler: 0 > Author_dick_treumann: 1 | > Author_jesper_larsson_traeff: 0 > Author_george_bosilca: 0 | > Author_david_solt: 0 > Author_bronis_de_supinski: 0 | > Author_rajeev_thakur: 0 > Author_jeff_squyres: 0 | > Author_alexander_supalov: 1 > Author_rolf_rabenseifner: 1 | > ----------------------------------------------------- > +---------------------- > > Comment(by traff): > > PDF/ticket not ok: > > 1. Advice to implementors: spelling "agruments" should be corrected > (in > ticket and pdf) > > 2. Advice to users: some punctuation or conjunction seems to be > missing in > "and comm_copy_attr_fn comm_delete_attr_fn"; what is intended here? > > -- > Ticket URL: > > MPI Forum > MPI Forum > > > > > William Gropp > Deputy Director for Research > Institute for Advanced Computing Applications and Technologies > Paul and Cynthia Saylor Professor of Computer Science > University of Illinois Urbana-Champaign > > > > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 > > > William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign * -------------- next part -------------- An HTML attachment was scrubbed... URL: From htor at [hidden] Sat Aug 22 15:41:28 2009 From: htor at [hidden] (Torsten Hoefler) Date: Sat, 22 Aug 2009 16:41:28 -0400 Subject: [Mpi-22] Ticket #33 review Message-ID: <20090822204128.GA21949@benten.cs.indiana.edu> Hello, Ticket #33 is implemented and ready for PDF review. I attached my review. I think it seems to be the most complex MPI-2.2 ticket and I am trying to motivate more people to do a review! https://svn.mpi-forum.org/trac/mpi-forum-web/ticket/33 Thanks & All the Best, Torsten -- bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- Torsten Hoefler | Postdoctoral Fellow Open Systems Lab | Indiana University 150 S. Woodlawn Ave. | Bloomington, IN, 474045, USA Lindley Hall Room 135 | +01 (812) 855-3608 From rabenseifner at [hidden] Tue Aug 25 02:53:07 2009 From: rabenseifner at [hidden] (Rolf Rabenseifner) Date: Tue, 25 Aug 2009 09:53:07 +0200 Subject: [Mpi-22] Final state transition - was Re: [MPI Forum] #104: MPI_ARGV_NULL and MPI_ARGVS_NULL missing on p465:13-15. In-Reply-To: <063.fe8c35f2bcfc89cfa3df80fceb354bc3@lists.mpi-forum.org> Message-ID: Hi all, based on our final state transition diagram, the last state transition we are currently doing is: Priority: Waiting for PDF reviews --> Ticket complete This should be done by the ticket author (blue arrow), and not by the chapter author (arrow is not black). We don't define to set the ticket to Status: closed Resolution: Text committed Therefore, I'll set my ticket back to Status: reopened All othe completed tickets are in the same state, i.e., Status "open" or "reopened", and Priority "ticket complete". I hope that this is okay. Best regards Rolf > From: Jeff Squyres > Subject: Re: [Mpi-22] SVN committing MPI-2.2 latex > Date: Fri, 12 Jun 2009 08:47:48 -0700 > > Ok, try this diagram. ... > Attachment: MPI-2.2 ticket states.pdf (463Kbytes) On Tue, 25 Aug 2009 01:08:32 -0000 "MPI Forum" wrote: > #104: MPI_ARGV_NULL and MPI_ARGVS_NULL missing on p465:13-15. > --------------------------------------------------+------------------------- > Reporter: RolfRabenseifner | > Owner: RolfRabenseifner > Type: Trivial text changes | > Status: closed > Priority: Ticket complete | > Milestone: 2009/06/08 California > Version: MPI 2.2 | > Resolution: Text committed > Keywords: | > Implementation: Unnecessary > Author_bill_gropp: 0 | > Author_rich_graham: 0 > Author_adam_moody: 0 | > Author_torsten_hoefler: 0 > Author_dick_treumann: 0 | > Author_jesper_larsson_traeff: 0 > Author_george_bosilca: 0 | > Author_david_solt: 0 > Author_bronis_de_supinski: 0 | > Author_rajeev_thakur: 0 > Author_jeff_squyres: 1 | > Author_alexander_supalov: 0 > Author_rolf_rabenseifner: 0 | > --------------------------------------------------+------------------------- > Changes (by jsquyres): > > * status: new => closed > * resolution: => Text committed > > > Comment: > > The changes Rolf made look good to me. I attached a new PDF, just >in case > anyone cares. > > Resolving this ticket to "text committed". > > -- > Ticket URL: > > MPI Forum > MPI Forum Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) From rabenseifner at [hidden] Tue Aug 25 03:00:36 2009 From: rabenseifner at [hidden] (Rolf Rabenseifner) Date: Tue, 25 Aug 2009 10:00:36 +0200 Subject: [Mpi-22] Wit attachment Re: Final state transition - was Re: [MPI Forum] #104: MPI_ARGV_NULL and MPI_ARGVS_NULL missing on p465:13-15. In-Reply-To: Message-ID: Here the attachment. On Tue, 25 Aug 2009 09:53:07 +0200 "Rolf Rabenseifner" wrote: > Hi all, > > based on our final state transition diagram, > the last state transition we are currently doing is: > > Priority: Waiting for PDF reviews --> Ticket complete > > This should be done by the ticket author (blue arrow), > and not by the chapter author (arrow is not black). > > We don't define to set the ticket to > Status: closed > Resolution: Text committed > > Therefore, I'll set my ticket back to > Status: reopened > > All othe completed tickets are in the same state, > i.e., Status "open" or "reopened", > and Priority "ticket complete". > > I hope that this is okay. > > Best regards > Rolf > >> From: Jeff Squyres >> Subject: Re: [Mpi-22] SVN committing MPI-2.2 latex >> Date: Fri, 12 Jun 2009 08:47:48 -0700 >> >> Ok, try this diagram. > ... >> Attachment: MPI-2.2 ticket states.pdf (463Kbytes) > > > On Tue, 25 Aug 2009 01:08:32 -0000 > "MPI Forum" wrote: >> #104: MPI_ARGV_NULL and MPI_ARGVS_NULL missing on p465:13-15. >> --------------------------------------------------+------------------------- >> Reporter: RolfRabenseifner | >> Owner: RolfRabenseifner >> Type: Trivial text changes | >> Status: closed >> Priority: Ticket complete | >> Milestone: 2009/06/08 California >> Version: MPI 2.2 | >> Resolution: Text committed >> Keywords: | >> Implementation: Unnecessary >> Author_bill_gropp: 0 | >> Author_rich_graham: 0 >> Author_adam_moody: 0 | >> Author_torsten_hoefler: 0 >> Author_dick_treumann: 0 | >> Author_jesper_larsson_traeff: 0 >> Author_george_bosilca: 0 | >> Author_david_solt: 0 >> Author_bronis_de_supinski: 0 | >> Author_rajeev_thakur: 0 >> Author_jeff_squyres: 1 | >> Author_alexander_supalov: 0 >> Author_rolf_rabenseifner: 0 | >> --------------------------------------------------+------------------------- >> Changes (by jsquyres): >> >> * status: new => closed >> * resolution: => Text committed >> >> >> Comment: >> >> The changes Rolf made look good to me. I attached a new PDF, just >>in case >> anyone cares. >> >> Resolving this ticket to "text committed". >> >> -- >> Ticket URL: >> >> MPI Forum >> MPI Forum > > Dr. Rolf Rabenseifner . . . . . . . . . .. email >rabenseifner_at_[hidden] > High Performance Computing Center (HLRS) . phone >++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / >685-65832 > Head of Dpmt Parallel Computing . . . >www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) * -------------- next part -------------- A non-text attachment was scrubbed... Name: MPI-2.2_ticket_states.pdf Type: application/pdf Size: 467281 bytes Desc: MPI-2.2_ticket_states.pdf URL: From wgropp at [hidden] Wed Aug 26 00:01:26 2009 From: wgropp at [hidden] (William Gropp) Date: Wed, 26 Aug 2009 00:01:26 -0500 Subject: [Mpi-22] Final state transition - was Re: [MPI Forum] #104: MPI_ARGV_NULL and MPI_ARGVS_NULL missing on p465:13-15. In-Reply-To: Message-ID: Thanks, Rolf. You are correct. Bill On Aug 25, 2009, at 2:53 AM, Rolf Rabenseifner wrote: > Hi all, > > based on our final state transition diagram, > the last state transition we are currently doing is: > > Priority: Waiting for PDF reviews --> Ticket complete > > This should be done by the ticket author (blue arrow), > and not by the chapter author (arrow is not black). > > We don't define to set the ticket to > Status: closed > Resolution: Text committed > > Therefore, I'll set my ticket back to > Status: reopened > > All othe completed tickets are in the same state, > i.e., Status "open" or "reopened", > and Priority "ticket complete". > > I hope that this is okay. > > Best regards > Rolf > >> From: Jeff Squyres >> Subject: Re: [Mpi-22] SVN committing MPI-2.2 latex >> Date: Fri, 12 Jun 2009 08:47:48 -0700 >> >> Ok, try this diagram. > ... >> Attachment: MPI-2.2 ticket states.pdf (463Kbytes) > > > On Tue, 25 Aug 2009 01:08:32 -0000 > "MPI Forum" wrote: >> #104: MPI_ARGV_NULL and MPI_ARGVS_NULL missing on p465:13-15. >> -------------------------------------------------- >> +------------------------- >> Reporter: RolfRabenseifner | >> Owner: RolfRabenseifner >> Type: Trivial text changes | >> Status: closed >> Priority: Ticket complete | >> Milestone: 2009/06/08 California >> Version: MPI 2.2 | >> Resolution: Text committed >> Keywords: | >> Implementation: Unnecessary >> Author_bill_gropp: 0 | >> Author_rich_graham: 0 >> Author_adam_moody: 0 | >> Author_torsten_hoefler: 0 >> Author_dick_treumann: 0 | >> Author_jesper_larsson_traeff: 0 >> Author_george_bosilca: 0 | >> Author_david_solt: 0 >> Author_bronis_de_supinski: 0 | >> Author_rajeev_thakur: 0 >> Author_jeff_squyres: 1 | >> Author_alexander_supalov: 0 >> Author_rolf_rabenseifner: 0 | >> -------------------------------------------------- >> +------------------------- >> Changes (by jsquyres): >> >> * status: new => closed >> * resolution: => Text committed >> >> >> Comment: >> >> The changes Rolf made look good to me. I attached a new PDF, just >> in case >> anyone cares. >> >> Resolving this ticket to "text committed". >> >> -- >> Ticket URL: >> >> MPI Forum >> MPI Forum > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign From rabenseifner at [hidden] Sat Aug 29 02:21:28 2009 From: rabenseifner at [hidden] (Rolf Rabenseifner) Date: Sat, 29 Aug 2009 09:21:28 +0200 Subject: [Mpi-22] Urgent ticket review - shocked! In-Reply-To: Message-ID: After significant number of MPI Forum members already "ordered" the book, I checked the status of the "Waiting for PDF-review"-tickets. !!!! I was deeply shocked !!!! From 41 tickets, - 17 had not seen a (positiv) review: #7 #10 #13 #18 #19 #37 #50 #51 #57 #70 #71 #98 #115 #116 #121 #128 #137 -- I've done 8 from them in the last night, and -- 1 was relly incorrectly implemented, -- 5 had small macro problems, and (I corrected themin the svn source, chapter authors may make new pdfs, but I personally review based on the actual full pdf) -- 2 were correct - 6 are waiting for corrections: #24 #31 #33 #120 #143 #146 - 9 had only one review #4 #33 #103 #107 #122 #132 #143 #146 - 8 had 2 reviews #1 #8 #27 #45 #94 #124 #136 #150 - 3 had 3 reviews (#31 buggy) #60 #74 - 3 had 4 and more reviews #3 #55 #89 (#120 buggy) More than 700 hundred people enjoyed the MPI-2.1 book. At SC08, more people wanted to get the book than I had with me. To publish MPI-2.2 at SC09, many people would be happy to see this standard as a real book, rather tahn only a pdf file in the web. The printing and binding service is already prepared to start on Monday after the Helsinki meeting. Therefore, if you are not in vacation, please help and take some reviews. Best regards Rolf Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) From htor at [hidden] Sat Aug 29 06:11:10 2009 From: htor at [hidden] (Torsten Hoefler) Date: Sat, 29 Aug 2009 07:11:10 -0400 Subject: [Mpi-22] Urgent ticket review - shocked! In-Reply-To: Message-ID: <20090829111110.GD26124@benten.cs.indiana.edu> Rolf, I was on travel last week. Fortunately, Rajeev promoted many of my tickets to "Ticket complete" (thanks!). I can't do much more than sending out review reminders (see comments on #74, #31, #136). I assume that everybody on CC should review the tickets. I will request missing reviews here again: #74: Rich, Bronis #31: Rolf #33: Brian, Jeff (commented but didn't say that he reviewed it), Bronis, Howard, Bill, Hubert, Alexander #136: Rolf, Jesper, Tony, Bronis, Hubert > - 6 are waiting for corrections: > #24 #31 #33 #120 #143 #146 I fixed the two in my chapters even though I was not the author (I hope that's fine) -- #33 (seems like Jesper is travelling) and #24 (I notified Adam a week ago and didn't hear back). > - 9 had only one review > #4 #33 #103 #107 #122 #132 #143 #146 > - 8 had 2 reviews > #1 #8 #27 #45 #94 #124 #136 #150 > - 3 had 3 reviews > (#31 buggy) #60 #74 see above :-/. Can't do more. We decided that the ticket author is responsible for requesting the reviews. I think that I reviewed all tickets that name me in CC. I hope the respective author will hunt me down if I forgot one :-). Thanks & All the Best, Torsten -- bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- Torsten Hoefler | Postdoctoral Fellow Open Systems Lab | Indiana University 150 S. Woodlawn Ave. | Bloomington, IN, 474045, USA Lindley Hall Room 135 | +01 (812) 855-3608 From rabenseifner at [hidden] Sat Aug 29 17:09:47 2009 From: rabenseifner at [hidden] (Rolf Rabenseifner) Date: Sun, 30 Aug 2009 00:09:47 +0200 Subject: [Mpi-22] 6-12 reviews per reviewer needed - Re: Urgent ticket review - shocked! In-Reply-To: <20090829111110.GD26124@benten.cs.indiana.edu> Message-ID: Torsten and all, to make reviews easier, I put current r435 on https://fs.hlrs.de/projects/par/mpi/mpi21/doc/mpi22-report-review_r435.pdf user and pw is as usual: mpi21 You have done many PDF reviews. The problem is that in vacation / travel time, we have only 20 active members. With 82 tickets and 3 reviews/ticket, we need about 12 !!! reviews from each forum member. Am I wrong ??? PDF reviewing can be done independent on which ticket one was ticket reviewer. PDF reviews are independent from special technical knowledge on the ticket content. On the remaining 40 tickets, this means 6 tickets/reviewer. I saw yesterday only about 11 (not 20) reviewers on these tickets and only 5 reviewers (you are included) have done 6 and more reviews on these tickets. Most have done only zero or one. I do not want to spend my time on statistics. I say this only to show you all, that we all should help. MPI 1 and 2.0 worked because all reviewing was done at the meetings. MPI-2.1 and 2.2 need the reviewing at home before the meetings. Best regards Rolf On Sat, 29 Aug 2009 07:11:10 -0400 Torsten Hoefler wrote: > Rolf, > I was on travel last week. Fortunately, Rajeev promoted many of my > tickets to "Ticket complete" (thanks!). > > I can't do much more than sending out review reminders (see comments >on > #74, #31, #136). I assume that everybody on CC should review the > tickets. > > I will request missing reviews here again: > #74: Rich, Bronis > #31: Rolf > #33: Brian, Jeff (commented but didn't say that he reviewed it), > Bronis, Howard, Bill, Hubert, Alexander > #136: Rolf, Jesper, Tony, Bronis, Hubert > >> - 6 are waiting for corrections: >> #24 #31 #33 #120 #143 #146 > I fixed the two in my chapters even though I was not the author (I >hope > that's fine) -- #33 (seems like Jesper is travelling) and #24 (I > notified Adam a week ago and didn't hear back). > >> - 9 had only one review >> #4 #33 #103 #107 #122 #132 #143 #146 >> - 8 had 2 reviews >> #1 #8 #27 #45 #94 #124 #136 #150 >> - 3 had 3 reviews >> (#31 buggy) #60 #74 > see above :-/. Can't do more. > > We decided that the ticket author is responsible for requesting the > reviews. I think that I reviewed all tickets that name me in CC. I >hope > the respective author will hunt me down if I forgot one :-). > > Thanks & All the Best, > Torsten > > -- > bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- > Torsten Hoefler | Postdoctoral Fellow > Open Systems Lab | Indiana University > 150 S. Woodlawn Ave. | Bloomington, IN, 474045, USA > Lindley Hall Room 135 | +01 (812) 855-3608 > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) From traff at [hidden] Sun Aug 30 06:39:01 2009 From: traff at [hidden] (Jesper-Larsson Träff) Date: Sun, 30 Aug 2009 13:39:01 +0200 Subject: [Mpi-22] Urgent ticket review - shocked! In-Reply-To: <20090829111110.GD26124@benten.cs.indiana.edu> Message-ID: <20090830113901.GA10723@fourier.it.neclab.eu> Dear Rolf and Torsten, I have done a bunch of more reviews (sorry for the ones I should have done but missed in the first place). For #33 I would also really like to solicit more reviews, and as many volunteer readers as possible; this is a complex ticket, so please do have a look! Best, Jesper On Sat, Aug 29, 2009 at 07:11:10AM -0400, Torsten Hoefler wrote: > Rolf, > I was on travel last week. Fortunately, Rajeev promoted many of my > tickets to "Ticket complete" (thanks!). > > I can't do much more than sending out review reminders (see comments on > #74, #31, #136). I assume that everybody on CC should review the > tickets. > > I will request missing reviews here again: > #74: Rich, Bronis > #31: Rolf > #33: Brian, Jeff (commented but didn't say that he reviewed it), > Bronis, Howard, Bill, Hubert, Alexander > #136: Rolf, Jesper, Tony, Bronis, Hubert > > > - 6 are waiting for corrections: > > #24 #31 #33 #120 #143 #146 > I fixed the two in my chapters even though I was not the author (I hope > that's fine) -- #33 (seems like Jesper is travelling) and #24 (I > notified Adam a week ago and didn't hear back). > > > - 9 had only one review > > #4 #33 #103 #107 #122 #132 #143 #146 > > - 8 had 2 reviews > > #1 #8 #27 #45 #94 #124 #136 #150 > > - 3 had 3 reviews > > (#31 buggy) #60 #74 > see above :-/. Can't do more. > > We decided that the ticket author is responsible for requesting the > reviews. I think that I reviewed all tickets that name me in CC. I hope > the respective author will hunt me down if I forgot one :-). > > Thanks & All the Best, > Torsten > > -- > bash$ :(){ :|:&};: --------------------- http://www.unixer.de/ ----- > Torsten Hoefler | Postdoctoral Fellow > Open Systems Lab | Indiana University > 150 S. Woodlawn Ave. | Bloomington, IN, 474045, USA > Lindley Hall Room 135 | +01 (812) 855-3608 > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 * -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3376 bytes Desc: smime.p7s URL: From rabenseifner at [hidden] Mon Aug 31 07:40:56 2009 From: rabenseifner at [hidden] (Rolf Rabenseifner) Date: Mon, 31 Aug 2009 14:40:56 +0200 Subject: [Mpi-22] pdf for reviewing of svn revision 442 In-Reply-To: Message-ID: Hi all, as a service for Bill and you all, and to simplify reviewing, I put the pdfs of the current svn revision 422 on our webserver: https://fs.hlrs.de/projects/par/mpi/mpi22/doc/ Username and password are mpi22 The major basis for reviewing is https://fs.hlrs.de/projects/par/mpi/mpi22/doc/mpi22-report-r442-review.pdf This r442 is the current version and seems to be stable, i.e., as far as I can see, all tickets had already a positve review (i.e., detected errors are already corrected). Best regards Rolf Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) From wgropp at [hidden] Mon Aug 31 10:07:43 2009 From: wgropp at [hidden] (William Gropp) Date: Mon, 31 Aug 2009 10:07:43 -0500 Subject: [Mpi-22] pdf for reviewing of svn revision 442 In-Reply-To: Message-ID: <399E8614-7CC9-4A6E-80EB-A600F5677521@illinois.edu> Thanks, Rolf. Everyone, Please use this one for review. No changes will be made to it before the meeting this week. Bill On Aug 31, 2009, at 7:40 AM, Rolf Rabenseifner wrote: > Hi all, > > as a service for Bill and you all, and to simplify reviewing, > I put the pdfs of the current svn revision 422 on our webserver: > > https://fs.hlrs.de/projects/par/mpi/mpi22/doc/ > > Username and password are mpi22 > > The major basis for reviewing is > https://fs.hlrs.de/projects/par/mpi/mpi22/doc/mpi22-report-r442-review.pdf > > This r442 is the current version and seems to be stable, > i.e., as far as I can see, all tickets had already a positve review > (i.e., detected errors are already corrected). > > Best regards > Rolf > > > Dr. Rolf Rabenseifner . . . . . . . . . .. email rabenseifner_at_[hidden] > High Performance Computing Center (HLRS) . phone ++49(0)711/685-65530 > University of Stuttgart . . . . . . . . .. fax ++49(0)711 / 685-65832 > Head of Dpmt Parallel Computing . . . www.hlrs.de/people/rabenseifner > Nobelstr. 19, D-70550 Stuttgart, Germany . (Office: Allmandring 30) > _______________________________________________ > mpi-22 mailing list > mpi-22_at_[hidden] > http://lists.mpi-forum.org/mailman/listinfo.cgi/mpi-22 William Gropp Deputy Director for Research Institute for Advanced Computing Applications and Technologies Paul and Cynthia Saylor Professor of Computer Science University of Illinois Urbana-Champaign