Document: WG14 N1365

Constant expressions

Submitter: Fred Tydeman (USA)
Submission Date: 2009-02-26
Related WG14 documents: N1321, N1353, DR 290
Subject: Constant expressions

6.6 Constant expressions [#5] has:

If a floating expression is evaluated in the translation environment, the arithmetic precision and range shall be at least as great as if the expression were being evaluated in the execution environment.

It is unclear to me if that is supposed to be covered by FLT_EVAL_METHOD [5.2.4.2.2, paragraph 8] or not.

The places where this matters are initialization of static objects and expressions folded during translation.

This matters for cross compilers (the two FPUs are most likely different). It could be difficult for the translator to emulate the runtime FPU. So that would argue for translation time being excluded from FLT_EVAL_METHOD.

This matters for compilers that "optimize" some expressions and do them during translation (allowed when FENV_ACCESS is OFF). If the translation time expression evaluation is different from the runtime evaluation, that "optmization" could be changing the value. That would argue for translation time being included in FLT_EVAL_METHOD.

The case of FENV_ACCESS is ON is covered by:

F.7.4 Constant expressions

1 An arithmetic constant expression of floating type, other than one in an initializer for an object that has static storage duration, is evaluated (as if) during execution; thus, it is affected by any operative floating-point control modes and raises floating-point exceptions as required by IEC 60559 (provided the state for the FENV_ACCESS pragma is "on").318)

F.7.5 Initialization

1 All computation for automatic initialization is done (as if) at execution time; thus, it is affected by any operative modes and raises floating-point exceptions as required by IEC 60559 (provided the state for the FENV_ACCESS pragma is "on"). All computation for initialization of objects that have static storage duration is done (as if) at translation time.

Doug Gwyn said: The basic problem seems to be that FLT_EVAL_METHOD can be specified as other than -1 only (for a conforming implementation) when the F.P. implementation follows one of two simple models, and if the actual implementation deviates from these models at all then FLT_EVAL_METHOD has to be defined as -1. I wonder if FLT_EVAL_METHOD is useful at all to the programmer.

Summary of issues:

• If FLT_EVAL_METHOD covers too much, then many implementations will end up with the value of -1 (meaning no information).
• If FLT_EVAL_METHOD covers too little, we might end up with quiet changes from C99.

Suggested changes to C1x:

• Change 5.2.4.2.2, paragraph 8, "operations" to "execution-time operators".
• Add to 6.6 Constant expressions, paragraph 5, These translation time constant expressions are not covered by FLT_EVAL_METHOD.
• An alternative: Add to 6.6 Constant expressions, paragraph 5, When the translation-time environment differs from the execution time environment, these translation time constant expressions are not covered by FLT_EVAL_METHOD; otherwise they are covered.