On 12/18/2012 11:40 PM, Jeff Johnston wrote:
On 12/18/2012 05:36 PM, Jeff Johnston wrote:
On 12/18/2012 04:43 PM, Craig Howland wrote:
Jeff:
The first alteration is fine, but the second (no checks on log2f
macro) stops the patch from fixing the issue that Jordy Portman
reported
at the start of this thread. If we want that issue to be fixed, either
the log2f macro needs to be deleted now, or else the added gates/checks
would need to go back. I don't care much either way. The gates
preserve the small speed increase (1 function call overhead) gained by
the macro for those cases where it is used (probably almost all uses
because nobody complained before Jordy did), but do make it messier.
Craig
Oh, so in Jordy's case, the value of FLT_EVAL_METHOD is set but not 0,
1, or 2? Otherwise, it is covered.
I will remove the macro.
Just for the record, the issue was that the original code in Newlib's
math.h did not typedef float_t at all when FLT_EVAL_METHOD was already
defined because the code was just:
#ifndef FLT_EVAL_METHOD
#define FLT_EVAL_METHOD 0
typedef float float_t;
typedef double double_t;
#endif /* FLT_EVAL_METHOD */
This caused an issue when float.h is included before math.h and the
log2f macro is used because float.h defines FLT_EVAL_METHOD, so math.h
would not typedef float_t, but the log2f macro would use float_t.
In my case (clang based compiler) FLT_EVAL_METHOD is set to
__FLT_EVAL_METHOD__ in float.h and __FLT_EVAL_METHOD__ is set to 0 by
default. So for my case the issue would have been fixed without removing
the log2f macro.
Jordy