PCC
http://pcc.ludd.ltu.se/jira
This file is an XML representation of an issueen-uk3.13.133323-10-2008Enterprise[PCC-317] FLT_EVAL_METHOD not defined
http://pcc.ludd.ltu.se/jira/browse/PCC-317
The macro symbol FLT_EVAL_METHOD of <float.h> is not defined.
<br/>
On Intel x86 computers, there are two floating-point units (FPUs).
<br/>
For a x87 FPU, FLT_EVAL_METHOD should be 2
<br/>
For a SSE FPU, FLT_EVAL_METHOD should be 0
<br/>
This is supposed to affect how floating-point expressions for static initializers are evaluated.
<br/>
Intel Core i5 (64 bit); Linux Fedora Core 14 (64 bit); pcc of 2011/02/21PCC-317FLT_EVAL_METHOD not definedBugMinorResolvedFixedAnders MagnussonFred J. TydemanThu, 14 Apr 2011 17:15:10 +0200 (CEST)Sat, 3 May 2014 12:40:55 +0200 (CEST)0Can 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?
<br/>
<br/>
Thanks for your help.
<br/>
5.2.4.2.2 Characteristics of floating types <float.h>
<br/>
<br/>
9 Except for assignment and cast (which remove all extra range and
<br/>
precision), the values yielded by operators with floating operands and
<br/>
values subject to the usual arithmetic conversions and of floating
<br/>
constants are evaluated to a format whose range and precision may be
<br/>
greater than required by the type. The use of evaluation formats is
<br/>
characterized by the implementation-defined value of
<br/>
FLT_EVAL_METHOD:24)
<br/>
<br/>
-1 indeterminable;
<br/>
<br/>
0 evaluate all operations and constants just to the range and
<br/>
precision of the type;
<br/>
<br/>
1 evaluate operations and constants of type float and double to the
<br/>
range and precision of the double type, evaluate long double
<br/>
operations and constants to the range and precision of the long
<br/>
double type;
<br/>
<br/>
2 evaluate all operations and constants to the range and precision
<br/>
of the long double type.
<br/>
<br/>
All other negative values for FLT_EVAL_METHOD characterize
<br/>
implementation-defined behavior.
<br/>
<br/>
<br/>
6.6 Constant expressions
<br/>
<br/>
5 An expression that evaluates to a constant is required in several
<br/>
contexts. If a floating expression is evaluated in the translation
<br/>
environment, the arithmetic range and precision shall be at least as
<br/>
great as if the expression were being evaluated in the execution
<br/>
environment.116)
<br/>
<br/>
116) The use of evaluation formats as characterized by FLT_EVAL_METHOD
<br/>
also applies to evaluation in the translation environment.
<br/>
<br/>
<br/>
<br/>
As you can read from above, ALL floating-point (FP) constants and
<br/>
operations are supposed to be evaluated as per FLT_EVAL_METHOD.
<br/>
This applies to BOTH translation time and run-time.
<br/>
<br/>
So, the FP constant .1f could be done as .1f, .1, or .1L
<br/>
<br/>
Some ways to detect FLT_EVAL_FORMAT of translation time:
<br/>
<br/>
static float f1 = .1f - .1L; /* which precision is .1f? */
<br/>
static float f2 = (FLT_MAX*2.f)/2.f; /* extra range? */
<br/>
static float f3 = (1.f/3.f - (4.f/3.f - 1.f));
<br/>
static float f4 = (((4.f/3.f - 1.f) - 1.f/4.f)*3.f - 1.f/4.f);
<br/>
Thanks for the info.
<br/>
<br/>
Yeah, pcc doesn't support this. I just defined FLT_EVAL_FORMAT to 0 in the libpcc headers, which shouldn't be a problem.
<br/>
Having FLT_EVAL_METHOD be 0 will be a problem for 32-bit Intel usage of the x87.
<br/>
<br/>
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:
<br/>
32-bit Intel => x87 => FLT_EVAL_METHOD should be 2
<br/>
64-bit Intel => SSE => FLT_EVAL_METHOD should be 0
<br/>
Best would be the <float.h> header checks some compiler defined symbol to find out which FPU is being used and set
<br/>
FLT_EVAL_METHOD accordingly. If that cannot be done, and <float.h> will be used for both FPUs, then FLT_EVAL_METHOD
<br/>
should be defined as -1
<br/>
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?
<br/>
Also, is there some macro symbol that can be tested to determine if the FPU is the x87 versus sse?
<br/>
Is there some way to find out the list of predefined macro symbols?
<br/>
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.
<br/>
you can use "pcc -E -Wp,-dM - </dev/null" to produce a list of the 'built-in' symbols
<br/>
<br/>
there is nothing that is standard to pcc to indicate 64-bit except for the standard processor definition
<br/>
such as __i386__ or __amd64__, though there may be something like _LP64 defined on some 64-bit
<br/>
targets, see the <ccconfig.h> file for your OS
<br/>
<br/>
perhaps there should be a __FLT_EVAL_METHOD__ macro produced correctly for the target, so that the
<br/>
header can do the right thing?Now FLT_EVAL_METHOD should be defined as specified.