The macro symbol FLT_EVAL_METHOD of <float.h> is not defined.
On Intel x86 computers, there are two floating-point units (FPUs).
For a x87 FPU, FLT_EVAL_METHOD should be 2
For a SSE FPU, FLT_EVAL_METHOD should be 0
This is supposed to affect how floating-point expressions for static initializers are evaluated.

Description

The macro symbol FLT_EVAL_METHOD of <float.h> is not defined.
On Intel x86 computers, there are two floating-point units (FPUs).
For a x87 FPU, FLT_EVAL_METHOD should be 2
For a SSE FPU, FLT_EVAL_METHOD should be 0
This is supposed to affect how floating-point expressions for static initializers are evaluated.

Can you explain your comment "affect how floating-point expressions for static initializers are evaluated"? Is there are section in the standard to read? Do you have code snippets which demonstrate how this works with gcc?

Gregory McGarry added a comment - 20/Apr/11 02:00 AM Can you explain your comment "affect how floating-point expressions for static initializers are evaluated"? Is there are section in the standard to read? Do you have code snippets which demonstrate how this works with gcc?
Thanks for your help.

9 Except for assignment and cast (which remove all extra range and
precision), the values yielded by operators with floating operands and
values subject to the usual arithmetic conversions and of floating
constants are evaluated to a format whose range and precision may be
greater than required by the type. The use of evaluation formats is
characterized by the implementation-defined value of
FLT_EVAL_METHOD:24)

-1 indeterminable;

0 evaluate all operations and constants just to the range and
precision of the type;

1 evaluate operations and constants of type float and double to the
range and precision of the double type, evaluate long double
operations and constants to the range and precision of the long
double type;

2 evaluate all operations and constants to the range and precision
of the long double type.

All other negative values for FLT_EVAL_METHOD characterize
implementation-defined behavior.

6.6 Constant expressions

5 An expression that evaluates to a constant is required in several
contexts. If a floating expression is evaluated in the translation
environment, the arithmetic range and precision shall be at least as
great as if the expression were being evaluated in the execution
environment.116)

116) The use of evaluation formats as characterized by FLT_EVAL_METHOD
also applies to evaluation in the translation environment.

As you can read from above, ALL floating-point (FP) constants and
operations are supposed to be evaluated as per FLT_EVAL_METHOD.
This applies to BOTH translation time and run-time.

Fred J. Tydeman added a comment - 20/Apr/11 03:12 AM 5.2.4.2.2 Characteristics of floating types <float.h>
9 Except for assignment and cast (which remove all extra range and
precision), the values yielded by operators with floating operands and
values subject to the usual arithmetic conversions and of floating
constants are evaluated to a format whose range and precision may be
greater than required by the type. The use of evaluation formats is
characterized by the implementation-defined value of
FLT_EVAL_METHOD:24)
-1 indeterminable;
0 evaluate all operations and constants just to the range and
precision of the type;
1 evaluate operations and constants of type float and double to the
range and precision of the double type, evaluate long double
operations and constants to the range and precision of the long
double type;
2 evaluate all operations and constants to the range and precision
of the long double type.
All other negative values for FLT_EVAL_METHOD characterize
implementation-defined behavior.
6.6 Constant expressions
5 An expression that evaluates to a constant is required in several
contexts. If a floating expression is evaluated in the translation
environment, the arithmetic range and precision shall be at least as
great as if the expression were being evaluated in the execution
environment.116)
116) The use of evaluation formats as characterized by FLT_EVAL_METHOD
also applies to evaluation in the translation environment.
As you can read from above, ALL floating-point (FP) constants and
operations are supposed to be evaluated as per FLT_EVAL_METHOD.
This applies to BOTH translation time and run-time.
So, the FP constant .1f could be done as .1f, .1, or .1L
Some ways to detect FLT_EVAL_FORMAT of translation time:
static float f1 = .1f - .1L; /* which precision is .1f? */
static float f2 = (FLT_MAX*2.f)/2.f; /* extra range? */
static float f3 = (1.f/3.f - (4.f/3.f - 1.f));
static float f4 = (((4.f/3.f - 1.f) - 1.f/4.f)*3.f - 1.f/4.f);

Having FLT_EVAL_METHOD be 0 will be a problem for 32-bit Intel usage of the x87.

I believe that I was told in another bug report that there is no way to pick whcih FPU is targeted by the code generator. That is, it is fixed:
32-bit Intel => x87 => FLT_EVAL_METHOD should be 2
64-bit Intel => SSE => FLT_EVAL_METHOD should be 0
Best would be the <float.h> header checks some compiler defined symbol to find out which FPU is being used and set
FLT_EVAL_METHOD accordingly. If that cannot be done, and <float.h> will be used for both FPUs, then FLT_EVAL_METHOD
should be defined as -1

Fred J. Tydeman added a comment - 04/May/11 04:30 AM Having FLT_EVAL_METHOD be 0 will be a problem for 32-bit Intel usage of the x87.
I believe that I was told in another bug report that there is no way to pick whcih FPU is targeted by the code generator. That is, it is fixed:
32-bit Intel => x87 => FLT_EVAL_METHOD should be 2
64-bit Intel => SSE => FLT_EVAL_METHOD should be 0
Best would be the <float.h> header checks some compiler defined symbol to find out which FPU is being used and set
FLT_EVAL_METHOD accordingly. If that cannot be done, and <float.h> will be used for both FPUs, then FLT_EVAL_METHOD
should be defined as -1

Does the compiler define some macro symbol that my program can test with an '#if' to determine if the program is being compiled for 32-bit versus 64-bit CPU?
Also, is there some macro symbol that can be tested to determine if the FPU is the x87 versus sse?
Is there some way to find out the list of predefined macro symbols?
Doing 'pcc --help' gets me the help for 'ld'. This is for pcc 1.0.0-2 of 2011/12/16 on Fedora Core 16.

Fred J. Tydeman added a comment - 24/Jan/12 08:51 PM Does the compiler define some macro symbol that my program can test with an '#if' to determine if the program is being compiled for 32-bit versus 64-bit CPU?
Also, is there some macro symbol that can be tested to determine if the FPU is the x87 versus sse?
Is there some way to find out the list of predefined macro symbols?
Doing 'pcc --help' gets me the help for 'ld'. This is for pcc 1.0.0-2 of 2011/12/16 on Fedora Core 16.

you can use "pcc -E -Wp,-dM - </dev/null" to produce a list of the 'built-in' symbols

there is nothing that is standard to pcc to indicate 64-bit except for the standard processor definition
such as __i386__ or __amd64__, though there may be something like _LP64 defined on some 64-bit
targets, see the <ccconfig.h> file for your OS

perhaps there should be a __FLT_EVAL_METHOD__ macro produced correctly for the target, so that the
header can do the right thing?

Iain Hibbert added a comment - 27/May/12 08:34 AM you can use "pcc -E -Wp,-dM - </dev/null" to produce a list of the 'built-in' symbols
there is nothing that is standard to pcc to indicate 64-bit except for the standard processor definition
such as __i386__ or __amd64__, though there may be something like _LP64 defined on some 64-bit
targets, see the <ccconfig.h> file for your OS
perhaps there should be a __FLT_EVAL_METHOD__ macro produced correctly for the target, so that the
header can do the right thing?