[Mpi-22] Borderline ticket #107: Types ofpredefined constants in Appendix A
Rolf Rabenseifner
rabenseifner at [hidden]
Fri Aug 7 15:37:25 CDT 2009
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 <erezh_at_[hidden]> 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" <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
>
>
> _______________________________________________
> 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