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" <tony_at_[hidden]> 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 <erezh_at_[hidden]>

Date: Thu, 6 Aug 2009 17:23:45 To: MPI 2.2<mpi-22_at_[hidden]> 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