[Mpi-22] Borderline ticket #107: Types ofpredefined constants in Appendix A
Rolf Rabenseifner
rabenseifner at [hidden]
Thu Aug 6 14:39:10 CDT 2009
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)
More information about the Mpi-22
mailing list