[Cfp-interest 2590] Preliminary WG14 IEEE 754-C binding meeting minutes - 2023/01/05

[Rajan Bhakta]

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
rbhakta at us.ibm.com<mailto:rbhakta at us.ibm.com>

IBM

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