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

[Aaron Ballman]

On Mon, Aug 30, 2021 at 4:50 PM Rajan Bhakta <rbhakta at us.ibm.com> wrote:
>
> 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.

Thank you!

> 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.

Fantastic, thank you for this information! I didn't want to bias the
initial opinions with my thoughts, but we're (Intel) trying to do this
work in Clang and ran into an interesting situation with preprocessed
source code. Our initial implementation would allow the #pragma to
change the value of FLT_EVAL_METHOD, but then we figured out that
preprocessing to a file in Clang strips the #pragmas from the output,
and so a preprocessed file and a not preprocessed file could behave
differently. So we were trying to figure out if the standard allows us
to *not* update the value of FLT_EVAL_METHOD due to the #pragma
because we can then base its value purely on the command line flags.
If that's a kosher thing to do, it'd make our implementation efforts
far easier.

Thank you for your time!

~Aaron

>
> 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
>
> "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
>
>
>
>