Mail Archives: djgpp-workers/2003/12/20/12:38:54
--part1_7c.404a24f2.2d15e30d_boundary
Content-Type: multipart/alternative;
boundary="part1_7c.404a24f2.2d15e30d_alt_boundary"
--part1_7c.404a24f2.2d15e30d_alt_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Rich:
Re: RESEND: Re: e_pow.c
In a message dated 12/20/2003 10:55:15 AM Eastern Standard Time,
rich AT phekda DOT gotadsl DOT co DOT uk writes:
> Hello.
>
> Kbwms AT aol DOT com wrote:
> >Kudos to the person who put a note in a patch for e_pow.c concerning
> >cases where, for z=pow(x,y), when x is very near 1 and y is very large,
> >z would vanish. It prompted me to create test cases for all three
> >floating point precisions. The same problem existed for the float
> >version and was easily fixed.
> >
> >For testing the double precision case, the parameters are:
> >
> >x = 1-DBL_EPSILON
> >y = log(DBL_MIN)/log(1-DBL_EPSILON)
>
> Could you send a patch for DJGPP 2.04, please?
>
> Thanks, bye, Rich =]
>
Until the problem described in the forwarded email is resolved, no changes to
sources in libm will be submitted. The problem involves the use of macros in
libm sources of type float that have the same names as functions in libm.a.
My proposal is to eliminate the use of the macros.
Ostensibly, the changes were made to avoid type punning; they fail to do so
because the type punning is done in the macros regardless of what the caller
does. The macros use illegal aliasing and are the sort of code that should
never be employed under any circumstances. Moreover, the macros are not needed
because there are functions in libm that do the job quite nicely.
KB Williams
--part1_7c.404a24f2.2d15e30d_alt_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
<HTML><FONT FACE=3Darial,helvetica><HTML><FONT SIZE=3D3 PTSIZE=3D12 FAMILY=
=3D"SERIF" FACE=3D"Georgia" LANG=3D"0">Rich:<BR>
<BR>
Re: RESEND: Re: e_pow.c<BR>
<BR>
In a message dated 12/20/2003 10:55:15 AM Eastern Standard Time, rich AT phekda=
.gotadsl.co.uk writes:<BR>
<BR>
<BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT=
: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px"></FONT><FONT COLOR=3D"#000000"=
BACK=3D"#ffffff" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D2 PTSIZE=3D10 F=
AMILY=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0">Hello.<BR>
<BR>
Kbwms AT aol DOT com wrote:<BR>
>Kudos to the person who put a note in a patch for e_pow.c concerning <BR=
>
>cases where, for z=3Dpow(x,y), when x is very near 1 and y is very large=
, <BR>
>z would vanish. It prompted me to create test cases for all three=20=
<BR>
>floating point precisions. The same problem existed for the float=20=
<BR>
>version and was easily fixed.<BR>
><BR>
>For testing the double precision case, the parameters are:<BR>
><BR>
>x =3D 1-DBL_EPSILON<BR>
>y =3D log(DBL_MIN)/log(1-DBL_EPSILON)<BR>
<BR>
Could you send a patch for DJGPP 2.04, please?<BR>
<BR>
Thanks, bye, Rich =3D]<BR>
</BLOCKQUOTE></FONT><FONT COLOR=3D"#000000" BACK=3D"#ffffff" style=3D"BACKG=
ROUND-COLOR: #ffffff" SIZE=3D3 PTSIZE=3D12 FAMILY=3D"SERIF" FACE=3D"Georgia"=
LANG=3D"0"><BR>
<BR>
Until the problem described in the forwarded email is resolved, no changes t=
o sources in libm will be submitted. The problem involves the use of m=
acros in libm sources of type float that have the same names as functions in=
libm.a. My proposal is to eliminate the use of the macros.<BR>
<BR>
Ostensibly, the changes were made to avoid type punning; they fail to do so=20=
because the type punning is done in the macros regardless of what the caller=
does. The macros use illegal aliasing and are the sort of code that s=
hould never be employed under any circumstances. Moreover, the macros=20=
are not needed because there are functions in libm that do the job quite nic=
ely.<BR>
<BR>
<BR>
KB Williams</FONT></HTML>
--part1_7c.404a24f2.2d15e30d_alt_boundary--
--part1_7c.404a24f2.2d15e30d_boundary
Content-Type: message/rfc822
Content-Disposition: inline
Return-path: <Kbwms AT aol DOT com>
From: Kbwms AT aol DOT com
Full-name: Kbwms
Message-ID: <12b DOT 377ae9cb DOT 2d0f43bc AT aol DOT com>
Date: Mon, 15 Dec 2003 12:05:00 EST
Subject: Re: isnanf et al
To: djgpp-workers AT delorie DOT com
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="part2_7c.404a24f2.2d0f43bc_boundary"
X-Mailer: 8.0 for Windows sub 6021
--part2_7c.404a24f2.2d0f43bc_boundary
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
In a message dated 12/15/2003 1:17:15 AM Eastern Standard Time,
eliz AT elta DOT co DOT il writes:
> >From: Kbwms AT aol DOT com
> >Date: Sun, 14 Dec 2003 17:09:37 EST
> >
> >The library at issue at the moment is libm. Someone has seen fit to modify
>
> >the source files, some of them incorrectly, so that they now invoke the is*
>
> >macros in ieeefp.h.
>
> Can you please show an example of a source from libm that was changed
> like that, including the diffs between the previous and the current
> versions?
>
The macros at issue from ../include/ieeefp.h are:
#define isnanf(x) (((*(long *)&(x) & 0x7f800000L)==0x7f800000L) && \
((*(long *)&(x) & 0x007fffffL)!=0000000000L))
#define isinff(x) (((*(long *)&(x) & 0x7f800000L)==0x7f800000L) && \
((*(long *)&(x) & 0x007fffffL)==0000000000L))
#define finitef(x) (((*(long *)&(x) & 0x7f800000L)!=0x7f800000L))
These macros enable an improper form of aliasing when parameter x is not a
type compatible with one of type long.
In v204 of the source for libm, 24 files were modified to include header file
../include/libc/ieee.h which had been modified. The files are:
ef_hypot.c wf_hypot.c
ef_scalb.c wf_j0.c
sf_ldexp.c wf_j1.c
wf_acos.c wf_jn.c
wf_acosh.c wf_lgamma.c
wf_asin.c wf_log.c
wf_atan2.c wf_log10.c
wf_atanh.c wf_pow.c
wf_cosh.c wf_remainder.c
wf_exp.c wf_scalb.c
wf_fmod.c wf_sinh.c
wf_gamma.c wf_sqrt.c
The diffs in ieee.h are:
*** ieee.h Mon Jun 30 16:38:16 2003
--- ieee_old.h Fri Apr 28 21:01:28 1995
***************
*** 1 ****
- /* Copyright (C) 2003 DJ Delorie, see COPYING.DJ for details */
--- 0 ----
***************
*** 12,16 ****
- #if (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 199901L) \
- || !defined(__STRICT_ANSI__)
-
- #endif /* (__STDC_VERSION__ >= 199901L) || !__STRICT_ANSI__ */
-
--- 10 ----
***************
*** 41,59 ****
-
- typedef union
- {
- double d;
- double_t dt;
- } _double_union_t;
-
- typedef union
- {
- long double ld;
- long_double_t ldt;
- } _longdouble_union_t;
-
- typedef union
- {
- float f;
- long l;
- } _float_long_union;
-
--- 34 ----
The 24 files listed previously were modified to use type _float_long_union.
Here are the diffs for the code in ef_scalb.c:
*** ef_scalb.c Tue Apr 15 04:39:46 1997
--- c:/djgpp/src/libm/libm204/ef_scalb.c Sun Jun 29 10:24:18 2003
***************
*** 17 ****
--- 18 ----
+ #include <libc/ieee.h>
***************
*** 38,39 ****
! if (isnanf(x)||isnanf(fn)) return x*fn;
! if (!finitef(fn)) {
--- 39,46 ----
! _float_long_union ux;
! _float_long_union ufn;
!
! ux.f = x;
! ufn.f = fn;
!
! if (isnanf(ux.l)||isnanf(ufn.l)) return x*fn;
! if (!finitef(ufn.f)) {
Note that macro isnanf() is invoked with a parameter of type long while
macro finitef() is invoked with a parameter of type float.
The point here is that the source files listed need never have been modified.
Since the functions are already defined in math.h, the simple act of
undefining the macros by placing #undefs in ../src/libm/math/fdlibm.h will do the job
quite nicely:
*** c:/djgpp.204/src/libm/math/fdlibm.h Sun Oct 4 06:48:42 1998
--- c:/djgpp/src/libm/math/fdlibm.h Mon Dec 15 11:44:02 2003
***************
*** 24 ****
--- 25,28 ----
+ #undef isnanf
+ #undef isinff
+ #undef finitef
+
This change has already been checked out.
--part2_7c.404a24f2.2d0f43bc_boundary
Content-Type: text/html; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
<HTML><FONT FACE=3Darial,helvetica><HTML><FONT SIZE=3D3 PTSIZE=3D12 FAMILY=
=3D"SERIF" FACE=3D"Georgia" LANG=3D"0">In a message dated 12/15/2003 1:17:15=
AM Eastern Standard Time, eliz AT elta DOT co DOT il writes:<BR>
<BR>
<BLOCKQUOTE TYPE=3DCITE style=3D"BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT=
: 5px; MARGIN-RIGHT: 0px; PADDING-LEFT: 5px"></FONT><FONT COLOR=3D"#000000"=
BACK=3D"#ffffff" style=3D"BACKGROUND-COLOR: #ffffff" SIZE=3D2 PTSIZE=3D10 F=
AMILY=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0">>From: Kbwms AT aol DOT com<BR>
>Date: Sun, 14 Dec 2003 17:09:37 EST<BR>
><BR>
>The library at issue at the moment is libm. Someone has seen fit t=
o modify <BR>
>the source files, some of them incorrectly, so that they now invoke the=20=
is* <BR>
>macros in ieeefp.h.<BR>
<BR>
Can you please show an example of a source from libm that was changed<BR>
like that, including the diffs between the previous and the current<BR>
versions?<BR>
</BLOCKQUOTE><BR>
</FONT><FONT COLOR=3D"#000000" BACK=3D"#ffffff" style=3D"BACKGROUND-COLOR:=20=
#ffffff" SIZE=3D3 PTSIZE=3D12 FAMILY=3D"SERIF" FACE=3D"Georgia" LANG=3D"0"><=
BR>
<BR>
The macros at issue from ../include/ieeefp.h are:<BR>
<BR>
</FONT><FONT COLOR=3D"#000000" BACK=3D"#ffffff" style=3D"BACKGROUND-COLOR:=20=
#ffffff" SIZE=3D2 PTSIZE=3D10 FAMILY=3D"SANSSERIF" FACE=3D"Arial" LANG=3D"0"=
>#define isnanf(x) (((*(long *)&(x) & 0x7f800000L)=3D=3D0x7f800000L)=
&& \<BR>
&nbs=
p; ((*(long *)&(x) & 0x007fffffL)!=3D0=
000000000L))<BR>
<BR>
#define isinff(x) (((*(long *)&(x) & 0x7f800000L)=3D=3D0x7f800000L)=20=
&& \<BR>
&nbs=
p; ((*(long *)&(x) & 0x007fffffL)=3D=
=3D0000000000L))<BR>
<BR>
#define finitef(x) (((*(long *)&(x) & 0x7f800000L)!=3D0x7f800000L))<=
BR>
</FONT><FONT COLOR=3D"#000000" BACK=3D"#ffffff" style=3D"BACKGROUND-COLOR:=20=
#ffffff" SIZE=3D3 PTSIZE=3D12 FAMILY=3D"SERIF" FACE=3D"Georgia" LANG=3D"0"><=
BR>
<BR>
These macros enable an improper form of aliasing when parameter x is not a<B=
R>
type compatible with one of type long.<BR>
<BR>
In v204 of the source for libm, 24 files were modified to include header fil=
e<BR>
../include/libc/ieee.h which had been modified. The files are:<BR>
<BR>
ef_hypot.c wf_hypot.c<BR>
ef_scalb.c wf_j0.c<BR>
sf_ldexp.c wf_j1.c<BR>
wf_acos.c wf_jn.c<BR>
wf_acosh.c wf_lgamma.c<BR>
wf_asin.c wf_log.c<BR>
wf_atan2.c wf_log10.c<BR>
wf_atanh.c wf_pow.c<BR>
wf_cosh.c wf_remainder.c<BR>
wf_exp.c wf_scalb.c<BR>
wf_fmod.c wf_sinh.c<BR>
wf_gamma.c wf_sqrt.c<BR>
<BR>
<BR>
The diffs in ieee.h are:<BR>
<BR>
*** ieee.h Mon Jun 30 16:38:16 2003<BR>
--- ieee_old.h Fri Apr 28 21:01:28 1995<BR>
***************<BR>
*** 1 ****<BR>
- /* Copyright (C) 2003 DJ Delorie, see COPYING.DJ for details */<BR>
--- 0 ----<BR>
***************<BR>
*** 12,16 ****<BR>
- #if (defined(__STDC_VERSION__) && __STDC_VERSION__ >=3D 199901L=
) \<BR>
- || !defined(__STRICT_ANSI__)<BR>
-<BR>
- #endif /* (__STDC_VERSION__ >=3D 199901L) || !__STRICT_ANSI__ */<BR>
-<BR>
--- 10 ----<BR>
***************<BR>
*** 41,59 ****<BR>
-<BR>
- typedef union<BR>
- {<BR>
- double d;<BR>
- double_t dt;<BR>
- } _double_union_t;<BR>
-<BR>
- typedef union<BR>
- {<BR>
- long double ld;<BR>
- long_double_t ldt;<BR>
- } _longdouble_union_t;<BR>
-<BR>
- typedef union<BR>
- {<BR>
- float f;<BR>
- long l;<BR>
- } _float_long_union;<BR>
-<BR>
--- 34 ----<BR>
<BR>
The 24 files listed previously were modified to use type _float_long_union.<=
BR>
<BR>
Here are the diffs for the code in ef_scalb.c:<BR>
<BR>
*** ef_scalb.c Tue Apr 15 04:39:46 1997<BR>
--- c:/djgpp/src/libm/libm204/ef_scalb.c =
Sun Jun 29 10:24:18 2003<BR>
***************<BR>
*** 17 ****<BR>
--- 18 ----<BR>
+ #include <libc/ieee.h><BR>
***************<BR>
*** 38,39 ****<BR>
! if (isnanf(x)||isnanf(fn)) return x*fn=
;<BR>
! if (!finitef(fn)) {<BR>
--- 39,46 ----<BR>
! _float_long_union ux;<BR>
! _float_long_union ufn;<BR>
!<BR>
! ux.f =3D x;<BR>
! ufn.f =3D fn;<BR>
!<BR>
! if (isnanf(ux.l)||isnanf(ufn.l)) retur=
n x*fn;<BR>
! if (!finitef(ufn.f)) {<BR>
<BR>
Note that macro isnanf() is invoked with a parameter of type long while<BR>
macro finitef() is invoked with a parameter of type float.<BR>
<BR>
The point here is that the source files listed need never have been modified=
. Since the functions are already defined in math.h, the simple act of=
undefining the macros by placing #undefs in ../src/libm/math/fdlibm.h will=20=
do the job quite nicely:<BR>
<BR>
*** c:/djgpp.204/src/libm/math/fdlibm.h Sun Oct 4 06:48:42 1998<BR>
--- c:/djgpp/src/libm/math/fdlibm.h Mon Dec 15 11:44:02 2003<BR>
***************<BR>
*** 24 ****<BR>
--- 25,28 ----<BR>
+ #undef isnanf<BR>
+ #undef isinff<BR>
+ #undef finitef<BR>
+ <BR>
<BR>
This change has already been checked out.</FONT></HTML>
--part2_7c.404a24f2.2d0f43bc_boundary--
--part1_7c.404a24f2.2d15e30d_boundary--
- Raw text -