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

[Rajan Bhakta]

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



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




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/20210929/3269f9e7/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/20210929/3269f9e7/attachment.gif>