[Cfp-interest 2170] Re: CFP question with FLT_EVAL_METHOD

Aaron Ballman aaron at aaronballman.com
Thu Sep 30 04:58:42 PDT 2021


Thank you Rajan and the CFP group, I appreciate the information!

~Aaron

On Wed, Sep 29, 2021 at 5:52 PM Rajan Bhakta <rbhakta at us.ibm.com> wrote:

> Hi Aaron,
>
> We discussed this in our CFP meeting today and I'd like to update you on
> what we discussed. While what I said in the last note was essentially true,
> I was remiss in mentioning that in TS18661-5 (which WG14 did NOT vote into
> C23), the FLT_EVAL_METHOD macro is actually not a constant in terms of
> being able to be used in #if and #elif preprocessing directives, and is
> intended to change to reflect the effective value as a result of the block
> level pragma "#pragma STDC FENV_FLT_EVAL_METHOD width".
>
> So if you do intend to at some point implement part 5 of the TS (Ex. if a
> later release of the C standard standardizes it and it needs to be
> implemented), then it does make sense to allow it to change values. Note
> that you do lose the #if/#elif use cases if you do this though.
>
> 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
>
> IBM
>
> [image: Inactive hide details for Rajan Bhakta---08/30/2021 03:50:04
> PM---Hi Aaron, I am forwarding this question on to the CFP group (]Rajan
> Bhakta---08/30/2021 03:50:04 PM---Hi Aaron, I am forwarding this question
> on to the CFP group (cc'd on the list), but I can also give
>
> From: Rajan Bhakta/Houston/IBM
> To: "Aaron Ballman" <aaron at aaronballman.com>
> Cc: cfp-interest at oakapple.net
> Date: 08/30/2021 03:50 PM
> Subject: Re: [EXTERNAL] CFP question with FLT_EVAL_METHOD
> ------------------------------
>
>
> Hi Aaron,
>
> I am forwarding this question on to the CFP group (cc'd on the list), but
> I can also give you my opinion of the intent right now as well.
>
> The FLT_EVAL_METHOD is intended to be a once per TU setting and it was
> expected that compile time flags or switches would change the value. In
> practice, we haven't seen an implementation really do that. Furthermore, in
> actual practice what we've heard is that a lot of implementations set it
> wrong (and would possibly be better served by the macro expanding to the
> value of -1).
>
> That being said, I don't think there is any real wording preventing a
> modification to the value via another pragma, just as there is not for many
> other macros like FLT_RADIX, and even non floating point related ones we
> traditionally consider TU level constants such as CHAR_BIT, INT_MAX, etc.
> i.e. Nothing special about FLT_EVAL_METHOD in this way.
>
> 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
>
> IBM
>
>
> [image: Inactive hide details for "Aaron Ballman" ---08/30/2021 01:57:39
> PM---I ran into an implementation question with FLT_EVAL_METHO]"Aaron
> Ballman" ---08/30/2021 01:57:39 PM---I ran into an implementation question
> with FLT_EVAL_METHOD and I was wondering if I could pick your
>
> From: "Aaron Ballman" <aaron at aaronballman.com>
> To: "Rajan Bhakta" <rbhakta at us.ibm.com>
> Date: 08/30/2021 01:57 PM
> Subject: [EXTERNAL] CFP question with FLT_EVAL_METHOD
> ------------------------------
>
>
>
> I ran into an implementation question with FLT_EVAL_METHOD and I was
> wondering if I could pick your considerable brains on what you think
> the right answer is. Imagine code like:
>
> #include <stdio.h>
> #include <float.h>
>
> #ifdef ON
> #pragma float_control(source, on, push)
> #endif
>
> int main() {
>  printf("FLT_EVAL_METHOD = %d\n", FLT_EVAL_METHOD);
> }
>
> Would you expect the FLT_EVAL_METHOD macro to expand to a different
> value depending on whether ON is defined or not? We're trying to
> figure out whether the standard requires FLT_EVAL_METHOD to report
> back transitional values that may be under control of a #pragma, or
> whether we have the latitude to decide to only report one value for
> FLT_EVAL_METHOD for the entire TU.
>
> Thanks!
>
> ~Aaron
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20210930/31fa02ea/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20210930/31fa02ea/attachment.gif>


More information about the Cfp-interest mailing list