Issue Details (XML | Word | Printable)

Key: PCC-317
Type: Bug Bug
Status: Resolved Resolved
Resolution: Fixed
Priority: Minor Minor
Assignee: Anders Magnusson
Reporter: Fred J. Tydeman
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.

FLT_EVAL_METHOD not defined

Created: 14/Apr/11 05:15 PM   Updated: 03/May/14 12:40 PM
Component/s: None
Affects Version/s: None
Fix Version/s: None

Environment: Intel Core i5 (64 bit); Linux Fedora Core 14 (64 bit); pcc of 2011/02/21

 Description  « Hide
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.

 All   Comments   Change History      Sort Order: Ascending order - Click to sort in descending order
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.

Fred J. Tydeman added a comment - 20/Apr/11 03:12 AM 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

  -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

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);

Gregory McGarry added a comment - 04/May/11 04:16 AM
Thanks for the info.

Yeah, pcc doesn't support this. I just defined FLT_EVAL_FORMAT to 0 in the libpcc headers, which shouldn't be a problem.

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

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.

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?

Anders Magnusson added a comment - 03/May/14 12:40 PM
Now FLT_EVAL_METHOD should be defined as specified.