X-Authentication-Warning: delorie.com: mail set sender to djgpp-workers-bounces using -f From: Kbwms AT aol DOT com Message-ID: <7c.404a24f2.2d15e30d@aol.com> Date: Sat, 20 Dec 2003 12:38:21 EST Subject: Fwd: isnanf et al To: rich AT phekda DOT gotadsl DOT co DOT uk, djgpp-workers AT delorie DOT com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="part1_7c.404a24f2.2d15e30d_boundary" X-Mailer: 8.0 for Windows sub 6021 Reply-To: djgpp-workers AT delorie DOT com --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 Rich:

Re: RESEND: Re: e_pow.c

In a message dated 12/20/2003 10:55:15 AM Eastern Standard Time, rich AT phekda= .gotadsl.co.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=3Dpow(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=20=
>floating point precisions.  The same problem existed for the float=20=
>version and was easily fixed.
>
>For testing the double precision case, the parameters are:
>
>x =3D 1-DBL_EPSILON
>y =3D log(DBL_MIN)/log(1-DBL_EPSILON)

Could you send a patch for DJGPP 2.04, please?

Thanks, bye, Rich =3D]


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.

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.


KB Williams --part1_7c.404a24f2.2d15e30d_alt_boundary-- --part1_7c.404a24f2.2d15e30d_boundary Content-Type: message/rfc822 Content-Disposition: inline Return-path: 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 *************** *** 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 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 t= o modify
>the source files, some of them incorrectly, so that they now invoke the=20= 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?

<= BR>
The macros at issue from ../include/ieeefp.h are:

#define isnanf(x) (((*(long *)&(x) & 0x7f800000L)=3D=3D0x7f800000L)= && \
            &nbs= p;      ((*(long *)&(x) & 0x007fffffL)!=3D0= 000000000L))

#define isinff(x) (((*(long *)&(x) & 0x7f800000L)=3D=3D0x7f800000L)=20= && \
            &nbs= p;      ((*(long *)&(x) & 0x007fffffL)=3D= =3D0000000000L))

#define finitef(x) (((*(long *)&(x) & 0x7f800000L)!=3D0x7f800000L))<= BR> <= BR>
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 fil= e
../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__ >=3D 199901L= ) \
-   || !defined(__STRICT_ANSI__)
-
- #endif /* (__STDC_VERSION__ >=3D 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.<= BR>
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 =3D x;
!       ufn.f =3D fn;
!
!       if (isnanf(ux.l)||isnanf(ufn.l)) retur= n 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=20= 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-- --part1_7c.404a24f2.2d15e30d_boundary--