[Cfp-interest 2592] Re: Preliminary WG14 IEEE 754-C binding meetingminutes - 2023/01/05

[Mike Cowlishaw]

As always .. many thanks for the excellent notes!
 
Mike


  _____  

From: Cfp-interest [mailto:cfp-interest-bounces at oakapple.net] On Behalf Of
Rajan Bhakta
Sent: 05 January 2023 17:52
To: CFP
Subject: [Cfp-interest 2590] Preliminary WG14 IEEE 754-C binding
meetingminutes - 2023/01/05



Attendees: Rajan, Jim, Damian, David H, Fred

 

Continuing NB comment discussion:

    Missed issues (from yesterday):

      GB14: Jim: If the constants are wider, you can't use them with
constexpr since there is a change in value.

        Fred: You can add a cast since they are allowed for arithmetic
constant expressions.

        Damian: Can't you do "constexpr float a = (float)5.0;"?

        Jim: Yes, though rounding direction can change it. There is another
comment for that. - Agreed.

      US5-18: No issues. - Agreed.

 

    Revisit issues needing a look:

      US26-75: Jim: The problem with Fred's approach would vary between
implementations. Ex. One could only do the default rounding mode so the
constexpr evaluation would be valid on that implementation but not in
another.

        Rajan: Not an issue for strictly conforming programs.

        Jim: Lets look at GB279 first and come back to this. It is related.

      GB279: Jim: Why can't it have the same semantics as static
initialization?

        Damian: The benefit of constexpr allows constexpr variables to be
used on the right hand side of other constexpr initializations.

        Jim: So looking at "like static" or "independence of mode". This
means "constexpr double x = (double)(1.0/3.0);" would be a constraint
violation for independence of mode but not for static.

        Rajan: We could propose both and let WG14 decide.

        Fred: Probably the best choice.

        Damian: constexpr can use auto/register/static as well. See 6.7.1#14
for a similar example.

        Jim: Doesn't change the rounding mode. Can say "for determination of
constraint violations, the translation time mode is assumed."

        Rajan: Mode should be state or something else since it is not just
rounding mode.

        Jim: Right, wide evaluation would also effect this.

        ^ToDo: Jim: Look to provide words for constexpr float issues saying
something like "for determination of constraint violations, the translation
time state is assumed" for GB279 and US26-75.

        Jim: What does this do to C++ compatibility? Side issue.

      GB127: No issues. - Agreed.

        Fred: 6.7.10#11 is the related clause in the standard.

      GB151: Jim: Issues with -0 and +0, since they are equal but not
equivalent. Instead we can say "For a complex variable z, z and CMPLX(.) are
equivalent expressions, and z and creal(z) . are equivalent expressions if
imaginary types are supported." - Mostly agreed.

      GB157: No issues. - Agreed.

      GB163: No issues. - Agreed.

      GB286: Jim: Add in 7.33.20 post paragraph 1 saying wcstofN are
reserved for wide character analogs of the strtofN functions. - Agreed.

      GB287: Jim: Suggested change is too large at this stage. Instead
change 7.24.1.6#4 bullet 1 from "it is not a hexadecimal floating number" to
"Whether the subject sequence may be hexadecimal floating number is
implementation defined" with Recommended Practice being "Rounding for
hexadecimal input should follow the method in H.12.2". Also update the
"0x1.8p+4" example to say "If hexadecimal input is accepted (+1, 24, 0). If
hexadecimal input is not accepted, ".

        Fred: Should we add to future directions that strtod will accept
hexadecimal input in the future.

        Rajan: I disagree. We don't know if WG14 will accept that.

        Fred: Should we have a feature test macro for this then?

        Jim: Want to keep it as simple as possible right now. - Agreed.

      GB288: Jim: Updated the text in the 20230105 document. - Agreed.

        Fred: Can you get an exact value for a value smaller than one so the
preferred exponent wouldn't be zero?

        Jim: 0.8. That's exact.

        Fred: My concern is you are requiring the preferred quantum exponent
to be zero for exact. It should be as close to zero as possible.

        Jim: That is the meaning of preferred quantum exponent. It is not
the quantum exponent.

 

Regards,

Rajan Bhakta
z/OS XL C/C++ Compiler Technical Architect
ISO C Standards Representative (Canada, USA), PL22.11 Chair
C/C++ Compiler Development

 <mailto:rbhakta at us.ibm.com> rbhakta at us.ibm.com

 

IBM

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20230105/bccc40ac/attachment-0001.htm>