On Sun, Mar 11, 2012 at 10:52 PM, Bruno Haible wrote:
> Michael Goffioul wrote:
>> frexpf is actually defined as a macro in C,
>> and as an inline function in C++.
>
> Normally gnulib avoids collisions with system functions by checking whether
> a system function exists, via AC_CHECK_FUNCS. But AC
Michael Goffioul wrote:
> frexpf is actually defined as a macro in C,
> and as an inline function in C++.
Normally gnulib avoids collisions with system functions by checking whether
a system function exists, via AC_CHECK_FUNCS. But AC_CHECK_FUNCS looks
only in the libraries and misses the inline f
The functions log2(), log2f(), log2l() are easier to provide than the
previous ones.
Notable bugs:
OSF/1:
log2 (-0.0) = NaN (should be -Infinity)
log2f (-0.0f) = NaN (should be -Infinity)
Cygein 1.7.9:
log2 (2^29) = 29.0 + 3.55271e-15
log2 (2^13) != 13.0f
NetBSD 5.1, Solaris:
log2(), log2f() w
On Sun, Mar 11, 2012 at 6:58 PM, Michael Goffioul
wrote:
> To confirm my suspicion, I tested the following sample:
>
> #include "config.h"
> #include
> #include
>
> int main (int argc, char** argv)
> {
> volatile float x;
> float zero = 0.0f;
>
> x = 1.0f / zero;
> {
On Sun, Mar 11, 2012 at 6:30 PM, Michael Goffioul
wrote:
> Hi,
>
> I'm trying to clarify a potential issue when using gnulib float math
> functions like frexpf (and possibly others) with MSVC9. It all started
> when compiling octave and getting link error because of duplicate
> symbols like frexpf
Hi,
I'm trying to clarify a potential issue when using gnulib float math
functions like frexpf (and possibly others) with MSVC9. It all started
when compiling octave and getting link error because of duplicate
symbols like frexpf in libgnulib.la and octave code like Cell.cc. I
don't fully unsersta
On Sun, Mar 11, 2012 at 4:16 PM, Bruno Haible wrote:
> Michael Goffioul wrote:
>> Same problem occurs in cbrt.c and cbrtf.c.
>
> ... and probably some others of newly added math function source files.
> This is an area with work in progress. Can you remind me about this issue
> once I'm done with
Michael Goffioul wrote:
> Same problem occurs in cbrt.c and cbrtf.c.
... and probably some others of newly added math function source files.
This is an area with work in progress. Can you remind me about this issue
once I'm done with the math functions, please?
Thanks.
Bruno
On Tue, Feb 28, 2012 at 10:52 AM, Bruno Haible wrote:
> Michael Goffioul wrote:
>> With the #pragma statement, the compilation error disappears, thanks.
>
> Thanks for verifying that we were on the right track.
>
>> I think the same
>> problem will appear in round.c and trunc.c (those are also use
