[Cfp-interest 1602] Re: promotion for binary interchange types

Mon Jun 1 19:13:38 PDT 2020

I assumed so, and remember discussing doing this at the last WG21 meeting.
What I’m asking for the other direction to follow as well :-)

On Mon, Jun 1, 2020 at 7:12 PM David Olsen <dolsen at nvidia.com> wrote:

> That’s exactly what I am doing.  As the current author of the C++ extended
> floating-point type proposal (P1467), I reached out to Jim and to CFP to
> make sure C and C++ stay in synch.
>
>
>
>
>
> *From:* Cfp-interest <cfp-interest-bounces at oakapple.net> *On Behalf Of *JF
> Bastien
> *Sent:* Monday, June 1, 2020 7:05 PM
> *To:* Jim Thomas <jaswthomas at sbcglobal.net>
> *Cc:* CFP <cfp-interest at ucbtest.org>
> *Subject:* [Cfp-interest 1600] Re: promotion for binary interchange types
>
>
>
> *External email: Use caution opening links or attachments*
>
>
>
> Can you please synchronize with the C++ committee so that compatible
> conclusions are reached?
>
>
>
> On Mon, Jun 1, 2020 at 6:31 PM Jim Thomas <jaswthomas at sbcglobal.net>
> wrote:
>
> David Olsen raised the question of whether automatic promotions should be
> extended so that narrower (or no-wider) binary interchange types are
> promoted to double. This could allow printf arguments of types _Float16,
> _Float32, and _Float64, without adding width modifiers. Below is an email
> discussion between David Olsen and myself. We’ll discuss this at the June
> CFP meeting.
>
>
>
> - Jim Thomas
>
>
>
> Begin forwarded message:
>
>
>
> *From: *David Olsen <dolsen at nvidia.com>
>
> *Subject: **RE: [Cfp-interest 1597] TS3 annex review*
>
> *Date: *May 27, 2020 at 5:38:41 PM PDT
>
> *To: *Jim Thomas <jaswthomas at sbcglobal.net>
>
>
>
> Forwarding my messages to the CFP group is fine.  Thank you for adding it
> to the agenda.
>
>
>
> I assumed that the promotion of float to double and char/short to int is a
> hold-over from the K&R days when there were no function prototypes.  Doing
> the default promotions (both at the call site and in the function
> definitions) decreased the chance of a type mismatch between the argument
> and the parameter by converting things to the common int or double.  I
> would be surprised if it was a hardware accommodation.  With the near
> universality of function prototypes these days, this reasoning doesn’t
> apply any more, and the promotion rules are only used for the ellipsis part
> of variadic functions.
>
>
>
> I don’t have a list of pros or cons for whether or not to do these
> automatic promotions.  The only real pro is that you can pass the smaller
> binary floating-point types to printf (but not scanf).  I can’t think of
> any cons.
>
>
>
> I don’t care about format specifiers for printf for the new floating-point
> types.  I am not proposing any for C++.  I asked only because what I was
> seeing didn’t match my memory of what I had seen before.  I must have seen
> the format specifiers for the decimal types, and then misremembered that as
> format specifiers for the binary interchange formats as well.
>
>
>
>
>
> *From:* Jim Thomas <jaswthomas at sbcglobal.net>
> *Sent:* Wednesday, May 27, 2020 11:17 AM
> *To:* David Olsen <dolsen at nvidia.com>
> *Subject:* Re: [Cfp-interest 1597] TS3 annex review
>
>
>
> *External email: Use caution opening links or attachments*
>
>
>
> I agree having C and C ++ be compatible on printf is desirable. I suspect
> the rationale for promoting float to double was to accommodate hardware
> that doesn't exist anymore. On the other hand it’s what C does and
>  promoting extension types in the manner you suggest might be ok. What are
> the pros and cons of these automatic promotions?
>
>
>
> The three decimal floating types from TS2 (which is in the main body of
> the draft C standard now) have length modifiers for printf. The new types
> in TS3 (proposed for an annex) do not. The printf conversions for the TS3
> types can be done with a %s applied to the result of a strfrom function
> with the desired formatting. We might could say _Float32 and _Float64
> behave like float and double for varargs (they are already required to have
> the same representations and alignments). Then with automatic promotions as
> you suggest, _Float16, _Float32, and _Float64 could be used directly with
> printf.
>
>
>
> If it’s ok with you, I’ll forward our email discussion to the CFP group
> and say that this topic will be on the June agenda.
>
>
>
> - Jim
>
>
>
> On May 26, 2020, at 12:00 PM, David Olsen <dolsen at nvidia.com> wrote:
>
>
>
> I have tentatively made the opposite decision for C++.  In P1467, any
> floating-point type whose set of values is a subset of the values of double
> is promoted to double when passed to the ellipsis part of a varargs
> functions.  That seemed like the right thing to do, like it was the intent
> behind the specific rule of promoting float to double.  I don’t feel
> strongly about that decision, and it hasn’t come up in any C++ committee
> discussions yet.
>
>
>
> I would be willing to let C and C++ diverge in this area because it is an
> obscure corner of the language and almost no C++ programmers write varargs
> functions any more. Except for one thing: printf.  That function is still
> used in C++, and most C++ implementations use the printf directly from the
> C library.  So C++ really needs to match C’s behavior for printf, and
> therefore should match C for all varargs functions.
>
>
>
> Are printf/scanf format specifiers being proposed for the interchange
> floating types?  I thought I remembered seeing format specifiers in some
> other document, but I can’t find them in the document you posted
> yesterday.  (If all smaller floating-point types are promoted to double,
> then users can pass _Float16 and _Float32 values to printf without needing
> to define a format specifier for those types.)
>
>
>
> I would like the CFP group to discuss the issue of interchange floating
> types and varargs functions.  I don’t really care what decision is made,
> whether to promote or not.  I just want it to be an informed decision and
> not an oversight.  Then I will probably just do the same on the C++ side.
>
>
>
>
>
> *From:* Jim Thomas <jaswthomas at sbcglobal.net>
> *Sent:* Tuesday, May 26, 2020 8:24 AM
> *To:* David Olsen <dolsen at nvidia.com>
> *Subject:* Re: [Cfp-interest 1597] TS3 annex review
>
>
>
> *External email: Use caution opening links or attachments*
>
>
>
> Thanks, David. I’ll forward this to the review team. My first thought is
> that the float to double promotion is legacy from K&R C and double-based
> floating-point hardware and there wasn’t seen a technical reason for
> extending it to the extension types.
>
>
>
> - Jim
>
>
>
> On May 25, 2020, at 10:26 PM, David Olsen <dolsen at nvidia.com> wrote:
>
>
>
> Something just occurred to me while glancing over the TS3 annex:
>
>
>
> Should the default argument promotion rules (6.5.2.2/p6) be adjusted to
> cover binary floating types?  In other words, should _Float16 and _Float32
> function arguments be promoted to double when passed to the varargs part of
> a varargs function, the same way that float arguments are?
>
>
>
> void vfunc(int a, ...);
>
> void testing() {
>
>   float f = 1.0;
>
>   _Float16 f16 = 2.0;
>
>   _Float32 f32 = 3.0;
>
>   vfunc(1, f); /* “f” is promoted to double */
>
>   vfunc(2, f16); /* should “f16” be promoted to double? */
>
>   vfunc(3, f32); /* should “f32” be promoted to double? */
>
> }
>
>
>
>
>
> *From:* Cfp-interest <cfp-interest-bounces at oakapple.net> *On Behalf Of *Jim
> Thomas
> *Sent:* Monday, May 25, 2020 8:52 PM
> *To:* CFP <cfp-interest at ucbtest.org>
> *Subject:* [Cfp-interest 1597] Re: TS3 annex review
>
>
>
> *External email: Use caution opening links or attachments*
>
>
>
> The message below was intended for the review team, not the entire CFP
> list.
>
>
>
> However, comments from anyone are welcome. If you’re not on the review
> team, please send any comments you have to me and I’ll forward them to the
> review team.
>
>
>
> Jim Thomas
>
>
>
>
> On May 25, 2020, at 5:15 PM, Jim Thomas <jaswthomas at sbcglobal.net> wrote:
>
>
>
> Review team,
>
>
>
> Thank you for volunteering to help with the review of our updated proposed
> TS3 annex. We’re reviewing the document in preparation for submittal to
> WG 14. If WG 14 affirms is earlier decision, the TS3 annex will be added to
> the C2X draft. If not, we plan to include it in an updated TS3. Either way,
> your review is a valuable service to everyone who will be completing,
> publishing, implementing, or using the specification in the future.
>
>
>
> Look for all sorts of errors, technical and editorial. Send comments to
> me and cc the review team. I’m proposing you complete your review and send
> comments by *Monday, June 8*.
>
>
>
> Here are the assignments (from our meeting minutes):
>
>
>
>         X.2 Types -
>         X.3 Characteristics in <float.h> -
>         X.4 Conversions - David H.
>         X.5-X.8 Lexical elements, Expressions, Declarations, Identifiers
> in standard headers - Rajan
>         X.9, X.10 Complex, Floating-point environment - Damian
>         X.11 (X.11.1, X.11.2) Math Macros and Function prototypes - Fred
>         X.11.3, X.12 Encoding conversion functions, Numeric conversions
> functions in stdlib.h - David H.
>         X.13 Type-generic math - Fred
>
>
>
> Here are links to PDF and DOCX representations of the document for review
> (use whichever you prefer):
>
>
>
> http://wiki.edg.com/pub/CFP/WebHome/cfp3-annex-20200525.pdf
>
>
>
> http://wiki.edg.com/pub/CFP/WebHome/cfp3-annex-20200525.docx
>
>
>
> The references in the document to the C standard are to the C2X draft:
>
>
>
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2478.pdf
>
>
>
>
>
> - Jim Thomas
>
>
>
> _______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20200601/e6d94f46/attachment-0001.htm>