<< Back to previous view

[PCC-317] FLT_EVAL_METHOD not defined Created: 14/Apr/11  Updated: 03/May/14

Status: Resolved
Project: pcc
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Fred J. Tydeman Assignee: Anders Magnusson
Resolution: Fixed Votes: 0
Environment: Intel Core i5 (64 bit); Linux Fedora Core 14 (64 bit); pcc of 2011/02/21

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.

Comment by Gregory McGarry [ 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.
Comment by Fred J. Tydeman [ 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);
Comment by Gregory McGarry [ 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.
Comment by Fred J. Tydeman [ 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
Comment by Fred J. Tydeman [ 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.
Comment by Iain Hibbert [ 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?
Comment by Anders Magnusson [ 03/May/14 12:40 PM ]
Now FLT_EVAL_METHOD should be defined as specified.
Generated at Fri Apr 27 08:50:23 CEST 2018 using JIRA Enterprise Edition, Version: 3.13.1-#333.