[prev in list] [next in list] [prev in thread] [next in thread]
List: mingw-notify
Subject: MinGW-notify Digest, Vol 28, Issue 12
From: mingw-notify-request () lists ! sourceforge ! net
Date: 2008-09-26 10:07:51
Message-ID: mailman.15807.1222423671.15241.mingw-notify () lists ! sourceforge ! net
[Download RAW message or body]
Send MinGW-notify mailing list submissions to
mingw-notify@lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/mingw-notify
or, via email, send a message with subject or body 'help' to
mingw-notify-request@lists.sourceforge.net
You can reach the person managing the list at
mingw-notify-owner@lists.sourceforge.net
When replying, please edit your Subject line so it is more specific
than "Re: Contents of MinGW-notify digest..."
This list is used to send updates of submitted patches, bug reports and file \
releases. You are discouraged from posting to this list. If you wish to unsubscribe \
you can do so at https://lists.sourceforge.net/lists/listinfo/mingw-notify.
Today's Topics:
1. [ mingw-Bugs-2125708 ] mingwrt-3.15: gcc fails if
__MSVCRT_VERSION__>=0x0800 (SourceForge.net)
2. [ mingw-Bugs-2125708 ] mingwrt-3.15: gcc fails if
__MSVCRT_VERSION__>=0x0800 (SourceForge.net)
3. [ mingw-Bugs-2117590 ] correction of function asinh - inverse
hyperbolic sine (SourceForge.net)
----------------------------------------------------------------------
Message: 1
Date: Thu, 25 Sep 2008 21:57:55 +0000
From: "SourceForge.net" <noreply@sourceforge.net>
Subject: [Mingw-notify] [ mingw-Bugs-2125708 ] mingwrt-3.15: gcc fails
if __MSVCRT_VERSION__>=0x0800
To: noreply@sourceforge.net
Message-ID: <E1KiyqR-0007oY-Vz@g45xhf1.ch3.sourceforge.com>
Content-Type: text/plain; charset="UTF-8"
Bugs item #2125708, was opened at 2008-09-24 05:33
Message generated for change (Comment added) made by keithmarshall
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2125708&group_id=2435
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: mingw runtime
> Group: IINR - Include In Next Release
> Status: Closed
> Resolution: Fixed
Priority: 5
Private: No
Submitted By: Alexandr Zamaraev (shura_zam)
Assigned to: Keith Marshall (keithmarshall)
Summary: mingwrt-3.15: gcc fails if __MSVCRT_VERSION__>=0x0800
Initial Comment:
Os WinXP Home Ru + sp3
g++ (GCC) 3.4.5 (mingw-vista special r3)
GNU ld (GNU Binutils) 2.18.50.20080109
binutils-2.18.50-20080109-2.tar.gz
mingwrt-3.15-mingw32-dev.tar.gz
mingwrt-3.15-mingw32-dll.tar.gz
w32api-3.12-mingw32-dev.tar.gz
Test source (mini2.c):
#include <windows.h>
int STDCALL
WinMain (HINSTANCE hInst, HINSTANCE hPrev, LPSTR lpCmd, int nShow) {
MessageBox (NULL, "Test message", "Test", MB_OK);
return 0;
}
Command line and output:
C:\test>gcc -c -D__MSVCRT_VERSION__=0x0800 mini2.c
In file included from \
C:/Lang/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/objbase.h:12,
from \
C:/Lang/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/ole2.h:9,
from \
C:/Lang/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/windows.h:114, from \
mini2.c:1: C:/Lang/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/stdlib.h:470: \
error: syntax error before "uintptr_t"
----------------------------------------------------------------------
> Comment By: Keith Marshall (keithmarshall)
Date: 2008-09-25 21:57
Message:
Patch applied:
* include/stdlib.h (intptr_t) [!_INTPTR_T_DEFINED]: Unused typedef;
not wanted here; remove it; replace it by...
(uintptr_t) [!_UINTPTR_T_DEFINED]: ...this typedef; needed by...
(_invalid_parameter_handler): ...this function typedef.
----------------------------------------------------------------------
Comment By: Chris Sutcliffe (ir0nh34d)
Date: 2008-09-24 13:19
Message:
> Chris, I can pick this one up, unless you'd prefer to handle it yourself.
Please feel free Keith. I'd like to role out a new mingwrt soon to deal
with an issue with -std=gnu99 in stdio.h that shipped with 3.15 and was
corrected with your subsequent commit.
Thanx!
Chris
----------------------------------------------------------------------
Comment By: Keith Marshall (keithmarshall)
Date: 2008-09-24 10:37
Message:
Thanks.
I've identified the error, as described below. As a workaround, if you
don't want to fix it locally in your own headers, you may #include
stdint.h, *before* stdlib.h.
Chris, I can pick this one up, unless you'd prefer to handle it yourself.
The error is in stdlib.h; at line 452 I see:
#if __MSVCRT_VERSION__ >= 0x800
#ifndef _INTPTR_T_DEFINED
#define _INTPTR_T_DEFINED
#ifdef _WIN64
typedef __int64 intptr_t;
#else
typedef int intptr_t;
#endif
#endif
but this is never used. Later, at line 466 I see (reformatted):
typedef void
(* _invalid_parameter_handler) (
const wchar_t *,
const wchar_t *,
const wchar_t *,
unsigned int,
uintptr_t);
requiring `uintptr_t' and not `intptr_t'. This suggests that the defines
at line 452 should actually be (reproduced from stdint.h, and
reformatted):
# if __MSVCRT_VERSION__ >= 0x800
# ifndef _UINTPTR_T_DEFINED
# define _UINTPTR_T_DEFINED
# ifdef _WIN64
typedef unsigned __int64 uintptr_t;
# else
typedef unsigned int uintptr_t;
# endif
# endif
----------------------------------------------------------------------
Comment By: Alexandr Zamaraev (shura_zam)
Date: 2008-09-24 05:35
Message:
If define __MSVCRT_VERSION__=0x0900 also error
Command line and output:
C:\test>gcc -c -D__MSVCRT_VERSION__=0x0900 mini2.c
In file included from
C:/Lang/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/objbase.h:12,
from
C:/Lang/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/ole2.h:9,
from
C:/Lang/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/windows.h:114,
from mini2.c:1:
C:/Lang/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/stdlib.h:470:
error: syntax error before "uintptr_t"
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2125708&group_id=2435
------------------------------
Message: 2
Date: Fri, 26 Sep 2008 09:05:03 +0000
From: "SourceForge.net" <noreply@sourceforge.net>
Subject: [Mingw-notify] [ mingw-Bugs-2125708 ] mingwrt-3.15: gcc fails
if __MSVCRT_VERSION__>=0x0800
To: noreply@sourceforge.net
Message-ID: <E1Kj9G3-00078s-Us@565xhf1.ch3.sourceforge.com>
Content-Type: text/plain; charset="UTF-8"
Bugs item #2125708, was opened at 2008-09-24 05:33
Message generated for change (Comment added) made by keithmarshall
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2125708&group_id=2435
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: mingw runtime
Group: IINR - Include In Next Release
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Alexandr Zamaraev (shura_zam)
Assigned to: Keith Marshall (keithmarshall)
Summary: mingwrt-3.15: gcc fails if __MSVCRT_VERSION__>=0x0800
Initial Comment:
Os WinXP Home Ru + sp3
g++ (GCC) 3.4.5 (mingw-vista special r3)
GNU ld (GNU Binutils) 2.18.50.20080109
binutils-2.18.50-20080109-2.tar.gz
mingwrt-3.15-mingw32-dev.tar.gz
mingwrt-3.15-mingw32-dll.tar.gz
w32api-3.12-mingw32-dev.tar.gz
Test source (mini2.c):
#include <windows.h>
int STDCALL
WinMain (HINSTANCE hInst, HINSTANCE hPrev, LPSTR lpCmd, int nShow) {
MessageBox (NULL, "Test message", "Test", MB_OK);
return 0;
}
Command line and output:
C:\test>gcc -c -D__MSVCRT_VERSION__=0x0800 mini2.c
In file included from \
C:/Lang/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/objbase.h:12,
from \
C:/Lang/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/ole2.h:9,
from \
C:/Lang/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/windows.h:114, from \
mini2.c:1: C:/Lang/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/stdlib.h:470: \
error: syntax error before "uintptr_t"
----------------------------------------------------------------------
> Comment By: Keith Marshall (keithmarshall)
Date: 2008-09-26 09:05
Message:
Chris,
> I'd like to role out a new mingwrt soon...
That's a reasonable suggestion. IMO, it wouldn't merit a 3.16 release,
but I'd suggest 3.15.1 rather than simply a snapshot. Perhaps we should
also address the version indication in configure, while we're about it.
I did post a note to this effect, on MinGW-Dvlpr, but it seems to have
vanished into a black hole somewhere; if it hasn't turned up later this
evening, I'll post it again.
----------------------------------------------------------------------
Comment By: Keith Marshall (keithmarshall)
Date: 2008-09-25 21:57
Message:
Patch applied:
* include/stdlib.h (intptr_t) [!_INTPTR_T_DEFINED]: Unused typedef;
not wanted here; remove it; replace it by...
(uintptr_t) [!_UINTPTR_T_DEFINED]: ...this typedef; needed by...
(_invalid_parameter_handler): ...this function typedef.
----------------------------------------------------------------------
Comment By: Chris Sutcliffe (ir0nh34d)
Date: 2008-09-24 13:19
Message:
> Chris, I can pick this one up, unless you'd prefer to handle it yourself.
Please feel free Keith. I'd like to role out a new mingwrt soon to deal
with an issue with -std=gnu99 in stdio.h that shipped with 3.15 and was
corrected with your subsequent commit.
Thanx!
Chris
----------------------------------------------------------------------
Comment By: Keith Marshall (keithmarshall)
Date: 2008-09-24 10:37
Message:
Thanks.
I've identified the error, as described below. As a workaround, if you
don't want to fix it locally in your own headers, you may #include
stdint.h, *before* stdlib.h.
Chris, I can pick this one up, unless you'd prefer to handle it yourself.
The error is in stdlib.h; at line 452 I see:
#if __MSVCRT_VERSION__ >= 0x800
#ifndef _INTPTR_T_DEFINED
#define _INTPTR_T_DEFINED
#ifdef _WIN64
typedef __int64 intptr_t;
#else
typedef int intptr_t;
#endif
#endif
but this is never used. Later, at line 466 I see (reformatted):
typedef void
(* _invalid_parameter_handler) (
const wchar_t *,
const wchar_t *,
const wchar_t *,
unsigned int,
uintptr_t);
requiring `uintptr_t' and not `intptr_t'. This suggests that the defines
at line 452 should actually be (reproduced from stdint.h, and
reformatted):
# if __MSVCRT_VERSION__ >= 0x800
# ifndef _UINTPTR_T_DEFINED
# define _UINTPTR_T_DEFINED
# ifdef _WIN64
typedef unsigned __int64 uintptr_t;
# else
typedef unsigned int uintptr_t;
# endif
# endif
----------------------------------------------------------------------
Comment By: Alexandr Zamaraev (shura_zam)
Date: 2008-09-24 05:35
Message:
If define __MSVCRT_VERSION__=0x0900 also error
Command line and output:
C:\test>gcc -c -D__MSVCRT_VERSION__=0x0900 mini2.c
In file included from
C:/Lang/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/objbase.h:12,
from
C:/Lang/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/ole2.h:9,
from
C:/Lang/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/windows.h:114,
from mini2.c:1:
C:/Lang/mingw/bin/../lib/gcc/mingw32/3.4.5/../../../../include/stdlib.h:470:
error: syntax error before "uintptr_t"
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2125708&group_id=2435
------------------------------
Message: 3
Date: Fri, 26 Sep 2008 10:07:42 +0000
From: "SourceForge.net" <noreply@sourceforge.net>
Subject: [Mingw-notify] [ mingw-Bugs-2117590 ] correction of function
asinh - inverse hyperbolic sine
To: noreply@sourceforge.net
Message-ID: <E1KjAEg-0002sk-1s@565xhf1.ch3.sourceforge.com>
Content-Type: text/plain; charset="UTF-8"
Bugs item #2117590, was opened at 2008-09-18 09:41
Message generated for change (Comment added) made by keithmarshall
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2117590&group_id=2435
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Roumen Petrov (rumen)
Assigned to: Nobody/Anonymous (nobody)
Summary: correction of function asinh - inverse hyperbolic sine
Initial Comment:
The current implementation of mingwex function with declaration "double asinh(double \
x)" return unexpected value for some arguments. Please to replace implementation with \
new one that pass at least following tests(argument->result): 1) 0.0->0.0
2) -0.0->-0.0
3) -1.0000000000000002e+299->-689.16608998577965
The current code return -0.0 for argument 0.0.
Uncommenting code for "/* Avoid setting FPU underflow exception flag in x * x. */" \
isn't enough since the case 3) will return NaN.
----------------------------------------------------------------------
> Comment By: Keith Marshall (keithmarshall)
Date: 2008-09-26 10:07
Message:
Roumen,
> > Also for long double I would like to propose an additional
> > modification that deal with big long double.
>
> Ok, thanks. That's basically a useful refinement of the technique
> I proposed; I've no issue with adopting it...
However, I am curious as to why you propose
if (z > 0.5/__LDBL_EPSILON__)
as the cut-off point, for switching from the analytically exact
computation to the rounded approximation? Surely a more analytically
appropriate expression is
if( z > 1.0L / sqrtl( LDBL_EPSILON ) )
(and BTW, we should `#include <float.h>', and use the generic standard
LDBL_EPSILON, rather than rely on a compiler specific definition such as
__LDBL_EPSILON__).
Granted, with this expression, the compiler is unlikely to recognise that
the RHS is a constant, so will not be able to optimise away the sqrtl()
call -- we'd need to help it out, by providing a suitable manifest constant
definition, if we want that optimisation. Is this the basis of your
proposal? You know `0.5 / EPSILON' > `1 / sqrt(EPSILON)', yet should still
be safe to square, and you are prepared to ignore the insignificance of
unity in the intermediate interval, to have a generically reproducible and
recognisably constant term on the RHS of the comparison?
I also wonder if there might be merit in adding
if( z < sqrtl( LDBL_EPSILON ) )
return copysignl( __fast_log1pl( z ), x );
or, (if we accept the `0.5 / EPSILON' paradigm for the overflow case)
if( z < (2.0L * LDBL_EPSILON) )
return copysignl( __fast_log1pl( z ), x );
to trap any potential underflow issues.
----------------------------------------------------------------------
Comment By: Keith Marshall (keithmarshall)
Date: 2008-09-23 13:26
Message:
> Compiler is build from package
> gcc-core-3.4.5-20060117-1-src.tar.gz
As is mine, using the x86-mingw32-build.sh script package, from our SF
download site, with the installation directory set as $HOME/mingw32, and
the cross-compiler identifying name set simply as `mingw32'.
> To compile minwgex I modify configure.in
Why do you do this? As a user, you should have no need to *ever* modify
configure.in.
> to substitute CFLAGS (also i see this reported in the tracker).
Which tracker would that be, then?
> Also I remove flag -nostdinc from Makefile.in,
> otherwise build fail - missing include header stddef.h.
You *definitely* should not need to do this. It may not be wrong to do
so, but if you are referring to the tracker item I think you are, then I do
not think that the solution proposed there is necessarily the correct way
to address the problem.
> Dunno why after modification my library return NaN for big double.
Nor do I; I certainly cannot reproduce this behaviour. FWIW, here's how I
build, from CVS, with the following sandbox structure:--
$HOME/mingw-sandbox
|
+-- build
| |
| +-- runtime
|
+-- runtime
(the CVS sources are checked out to $HOME/mingw-sandbox/runtime)
$ cd $HOME/mingw-sandbox/build/runtime
$ ../../runtime/configure --prefix=$HOME/mingw32 \
--build=i686-pc-linux --host=mingw32
$ make CFLAGS='-s -O2 -mtune=i686 -mms-bitfields'
$ make install
With this, I keep my cross-compiler up to date with the current state of
the MinGW CVS. Note that I do not use this build tree for creating
distributable packages -- I leave that to Chris. The Makefiles are broken
in this regard; they require entirely inappropriate misuse of configure's
--target spec, to achieve a correctly structured MinGW package directory
hierarchy.
> Also for long double I would like to propose an additional
> modification that deal with big long double.
Ok, thanks. That's basically a useful refinement of the technique I
proposed; I've no issue with adopting it, but I think the explanatory
comments could be improved, to make them more acceptable in a
mathematically correct sense. You may leave it with me, to come up with
suitable wording.
I also think it may be advantageous to handle the potential overflow
similarly, within asinhf() and asinh(), rather than relying on the
obfuscated method of the present implementation.
----------------------------------------------------------------------
Comment By: Roumen Petrov (rumen)
Date: 2008-09-20 14:07
Message:
Also I attach my new tests case build with (part from Makefile):
test-asinhex-my.exe: test-asinh.c
$(MINGWCC) -posix -o $@ $^ -lmingwex-my
The output is (mysterious nan for asinh is still here, but output for
asinhl,asinhf look good):
=== sizeof(double)=8
asinh(1.0000000000000002e+299)=nan
..... z=688.47294280521965
asinh(-1.0000000000000002e+299)=nan
..... z=-688.47294280521965
asinh(1.7976931348623157e+308)=nan
..... z=709.78271289338397
asinh(-1.7976931348623157e+308)=nan
..... z=-709.78271289338397
asinh(3.4028234663852886e+038)=89.415986232628299
..... z=89.415986232628299
asinh(-3.4028234663852886e+038)=-89.415986232628299
..... z=-89.415986232628299
asinh(0)=0
..... z=0
asinh(-0)=-0
..... z=-0
=== sizeof(long double)=12
asinhl(1.189731495357231765021264e+4932)=11357.21655347470389507691
asinhl(-1.189731495357231765021264e+4932)=-11357.21655347470389507691
asinhl(1.797693134862315708145274e+308)=710.4758600739439420301835
asinhl(-1.797693134862315708145274e+308)=-710.4758600739439420301835
asinhl(3.402823466385288598117042e+038)=89.41598623262829834135168
asinhl(-3.402823466385288598117042e+038)=-89.41598623262829834135168
asinhl(0)=0
asinhl(-0)=-0
=== sizeof(float)=4
asinhf(3.40282347e+038)=89.4159851
asinhf(-3.40282347e+038)=-89.4159851
asinhf(0)=0
asinhf(-0)=-0
File Added: test-asinh.c
----------------------------------------------------------------------
Comment By: Roumen Petrov (rumen)
Date: 2008-09-20 13:57
Message:
May I ask you to apply similar modification to math/asinh{l|f}.c with call
to copysign{l|f}.
I'm tired. I couldn't find why my self-build library return NaN for big
numbers.
If I add code from asinh (with call to copysign) into test program along
with inline function from fastmath.h - it work as expected, i.e. without
NaN for big numbers.
Compiler is build from package gcc-core-3.4.5-20060117-1-src.tar.gz
To compile minwgex I modify configure.in to substitute CFLAGS (also i see
this reported in the tracker). Also I remove flag -nostdinc from
Makefile.in, otherwise build fail - missing include header stddef.h.
Dunno why after modification my library return NaN for big double.
Also for long double I would like to propose an additional modification
that deal with big long double.
File Added: mingwex-asinhl.diff
----------------------------------------------------------------------
Comment By: Keith Marshall (keithmarshall)
Date: 2008-09-19 17:20
Message:
I applied this:
Index: mingwex/math/asinh.c
===================================================================
RCS file: /cvs/src/src/winsup/mingw/mingwex/math/asinh.c,v
retrieving revision 1.1
diff -u -r1.1 asinh.c
--- mingwex/math/asinh.c 6 Oct 2004 20:31:32 -0000 1.1
+++ mingwex/math/asinh.c 19 Sep 2008 17:14:04 -0000
@@ -23,6 +23,6 @@
z = __fast_log1p (z + z * z / (__fast_sqrt (z * z + 1.0) + 1.0));
- return ( x > 0.0 ? z : -z);
+ return copysign (z, x);
}
It fixes the signed zero issue; I STILL cannot reproduce your other fault,
(this time just running under wine).
----------------------------------------------------------------------
Comment By: Roumen Petrov (rumen)
Date: 2008-09-19 15:25
Message:
May NaN is because my mingwex library is modified to use copysign instead
xx> 0.0 ...
Yes in the original there is no problem for the big numbers - only sign of
zero.
----------------------------------------------------------------------
Comment By: Keith Marshall (keithmarshall)
Date: 2008-09-19 13:21
Message:
FTR, I've now taken your test case to my own Ubuntu 8.04 box, compiled with
mingw32-gcc (GCC-3.4.5, mingwrt-3.15), and run it under wine-1.0. It
behaves correctly; I *cannot* reproduce the fault you report in (3).
----------------------------------------------------------------------
Comment By: Keith Marshall (keithmarshall)
Date: 2008-09-19 11:10
Message:
Case (1) clearly isn't an issue, for the result is correct.
Case (2) is purely an issue of discriminating between positive and
negative zero[1]. I agree with your assessment, that `return (z > 0.0 ? z
> -z);' is incorrect, for it must *always* return a zero as negative zero.
Similarly, `return (z >= 0.0 ? z : -z);' is incorrect, for it must always
return zero as *positive* zero. The correct solution is to either check
for `if( x == 0.0 ) return x;' on entry, or to always `return copysign( z,
x );'
Case (3) is *not* a MinGW bug, (or at least I cannot reproduce it[2]). I
am confused by your references to native vs. emulated environment; do you
mean, perhaps, that you get incorrect results running on GNU/Linux under
Wine? If so, then surely this problem lies in Wine, and you should follow
up on their ML.
Also note that uncommenting the code to avoid setting the FPU underflow
exception flag would not be expected to have any effect in case (3), for it
affects only very *small* values of `x', and case (3) has a fairly *large*
(negative) value of `x'.
[1] Using the MSVCRT implementation of printf(), I appear to see no
distinction between positive and negative zero anyway; it only becomes
apparent when using the mingwex printf() functions.
[2] Although the current mingwex implementation appears to produce correct
results for me, in each of the test cases given, it does use what seems a
rather suspect method of guarding against overflow, in its internal
computation of `x * x', (or `z * z' as it is actually coded); I believe
that it may be worthwhile replacing this with a more mathematically robust
formulation:
long double my_asinhl( long double x )
{
if( isfinite( x ) && (x != 0.0L) )
{
long double z = fabsl( x ), zz = z * z;
if( isfinite( zz = z * z ) )
/*
* `z' has been squared without overflow...
* Compute the inverse sinh, using the analytically correct
formula,
* (using log1p() for greater precision at very small `z', than
* can be achieved using log()).
*/
return copysign( log1pl( z + sqrtl( zz + 1.0L ) - 1.0L ), x );
/* Computation of `z squared' results in overflow...
* Here we may employ the approximation that, for very large `z',
* `sqrt( z * z + 1 ) ~= z', yielding the approximate result
*/
return copysign( logl( z ) + log1pl( 1.0L ), x );
}
return x;
}
double my_asinh( double x )
{
return (double)(my_asinhl( (long double)(x) ));
}
----------------------------------------------------------------------
Comment By: Roumen Petrov (rumen)
Date: 2008-09-18 13:43
Message:
more tests:
If we change current code from "return ( x > 0.0 ? z : -z);" to "return (
x >= 0.0 ? z : -z);" the function result is not changed.
If we replace return statement with "return copysign(z,x)" the result for
{+/-}0.0 argument is as expected in native and emulated environment. But if
we try to use function _copysign the result is ok in native environment but
fail in emulated.
Also with similar changes for functions asinhf/asinhl with respective
copysign, i.e. copysignf/copysignl, I see expected result.
Did someone know how to resolve problem with big exponent ?
----------------------------------------------------------------------
Comment By: Roumen Petrov (rumen)
Date: 2008-09-18 12:13
Message:
more test vectors:
[-]1.0000000000000002e+99 ->[-]228.64907138697046 //ok
[-]1.0000000000000001e+199->[-]458.90758068637501 //but mingwex-nan,
native - ok
[-]1.0000000000000002e+299->[-]689.16608998577965 //but mingwex-nan,
native - ok
[-]1.6025136110019349e+308->[-]710.3609292261076 //but mingwex-nan,
native - ok
----------------------------------------------------------------------
Comment By: Roumen Petrov (rumen)
Date: 2008-09-18 10:53
Message:
also asinhl/asinhf return -0.0 too for 0.0 argument.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=102435&aid=2117590&group_id=2435
------------------------------
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
------------------------------
_______________________________________________
MinGW-notify mailing list
MinGW-notify@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-notify
End of MinGW-notify Digest, Vol 28, Issue 12
********************************************
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic