[Bug 1001539] New: Single precision floating point math library

[Bug 1001539] New: Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

           Summary: Single precision floating point math library
           Product: eCos
           Version: CVS
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: low
         Component: Patches and contributions
        AssignedTo: unassigned@bugs.ecos.sourceware.org
        ReportedBy: ilijak@siva.com.mk
                CC: ecos-patches@ecos.sourceware.org
             Class: Advice Request


Created an attachment (id=1656)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1656)
CDL and include files

Here we submit Single precision floating point math library. It has been ported
to eCos from Newlib.

Tests and feedback are welcome.

Visar & Ilija

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

--- Comment #1 from Ilija Kocho <ilijak@siva.com.mk> 2012-03-20 19:23:48 GMT ---
Created an attachment (id=1657)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1657)
Library sources

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

--- Comment #2 from Ilija Kocho <ilijak@siva.com.mk> 2012-03-20 19:26:11 GMT ---
Created an attachment (id=1658)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1658)
mathincl

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

--- Comment #3 from Ilija Kocho <ilijak@siva.com.mk> 2012-03-20 19:38:56 GMT ---
Created an attachment (id=1659)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1659)
Libm tests part 1

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

--- Comment #4 from Ilija Kocho <ilijak@siva.com.mk> 2012-03-20 19:39:40 GMT ---
Created an attachment (id=1660)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1660)
Libm tests part 2

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

--- Comment #5 from Ilija Kocho <ilijak@siva.com.mk> 2012-03-20 19:40:17 GMT ---
Created an attachment (id=1661)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1661)
Libm tests part 3

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

--- Comment #6 from Ilija Kocho <ilijak@siva.com.mk> 2012-03-20 19:41:14 GMT ---
Created an attachment (id=1662)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1662)
Libm tests part 4

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

--- Comment #7 from Ilija Kocho <ilijak@siva.com.mk> 2012-03-20 19:42:47 GMT ---
Created an attachment (id=1663)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1663)
Libm tests vector support

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1656|                            |assignment-
               Flag|                            |

--- Comment #8 from Ilija Kocho <ilijak@siva.com.mk> 2012-03-20 19:47:18 GMT ---
(From update of attachment 1656)
Copyright assignment by Visar Zejnullahu needed.

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

--- Comment #9 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-03-21 13:43:41 GMT ---
(In reply on comment #0)
> Here we submit Single precision floating point math library. It has
> been ported to eCos from Newlib.
> 
> Tests and feedback are welcome.
> 
> Visar & Ilija

Hi Visar,
and Ilija

Thank you for your contribution.

Unfortunately, I have no CORTEX-M4F CPU to get all benefits the library,
however, I guessed the library should not depend on any architecture. Is
it correct? If so, should I have something special in eCos config to
build f-tests? Why I ask? All f-tests fail on eCos synthetic target
(d-tests are okay). Thus, I thought that I missed something in eCos
configuration. Could you provide your ecm-file?

Thank you,
Sergei

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

--- Comment #10 from Ilija Kocho <ilijak@siva.com.mk> 2012-03-21 15:55:33 GMT ---
Hi Sergei

Thank you for testing libm.

(In reply to comment #9)
> (In reply on comment #0)
> Hi Visar,
> and Ilija
> 
> Thank you for your contribution.
> 
> Unfortunately, I have no CORTEX-M4F CPU to get all benefits the library,
> however, I guessed the library should not depend on any architecture. Is
> it correct? 

Library is not tied to any architecture, we took it from Newlib and merely
adapted to eCos by studying the differences between "double" libs.. My standard
testing is with Cortex-M3 settings -mcpu=cortex-m3 -mthumb -O2 which is default
even for Kinetis (until we switch to gcc-4.6).

>If so, should I have something special in eCos config to
> build f-tests?

Target is TWR-K60N512, Default template, just for practical reasons I'm
changing startup type from ROM to SRAM.

> Why I ask? All f-tests fail on eCos synthetic target
> (d-tests are okay). 

True some tests fail when the result is supposed to be NaN such as acosf(1.2)
The function returns 0 instad of NaN. I wander if it is a setting or the
compiler option. The same behavior with both 4.3.2 and 4.6.3.

I thought of some work-around but then decided to put it as-is - we need a
solution rather than workaround.

>Thus, I thought that I missed something in eCos
> configuration. Could you provide your ecm-file?

There isn't much for ecm file, only startup type.

It would be good if you could try with some ARM target. FYI, example tests that
fail on my platform are: asinf(x) |x| > 1, acosf(x) |x| > 1, logf(x) x < 0.
Pass: tanf(), expf(), cosf(), etc...

Thank you again
Ilija

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

--- Comment #11 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-03-21 18:36:01 GMT ---
(In reply to comment #10)
> (In reply to comment #9)

> Library is not tied to any architecture, we took it from Newlib and
> merely adapted to eCos by studying the differences between "double"
> libs.. My standard testing is with Cortex-M3 settings -mcpu=cortex-m3
> -mthumb -O2 which is default even for Kinetis (until we switch to
> gcc-4.6).

> >Thus, I thought that I missed something in eCos configuration. Could
> >you provide your ecm-file?
>
> There isn't much for ecm file, only startup type.
>
> It would be good if you could try with some ARM target. FYI, example
> tests that fail on my platform are: asinf(x) |x| > 1, acosf(x) |x| >
> 1, logf(x) x < 0.  Pass: tanf(), expf(), cosf(), etc...

Iljia, thanks for guidance. So, I got the same results for ARM7TDMI (LE)
target (default template, RAM startup, run in GDB, build with GCC 4.6.3)

  ECOS_GLOBAL_CFLAGS = -Wall -Wpointer-arith -Wstrict-prototypes -Wundef
-Woverloaded-virtual -Wno-write-strings -mno-thumb-interwork -mcpu=arm7tdmi -g
-O2 -ffunction-sections -fdata-sections -fno-rtti -fno-exceptions
  ECOS_GLOBAL_LDFLAGS = -mno-thumb-interwork -mcpu=arm7tdmi -Wl,--gc-sections
-Wl,-static -g -nostdlib
  ECOS_COMMAND_PREFIX = arm-eabi-

f-tests passed:

  PASS:<atan2f() is stable>
  PASS:<atanf() is stable>
  PASS:<ceilf() is stable>
  PASS:<cosf() is stable>
  PASS:<coshf() is stable>
  PASS:<expf() is stable>
  PASS:<fabsf() is stable>
  PASS:<floorf() is stable>
  PASS:<fmodf() is stable>
  PASS:<ldexpf() is stable>
  PASS:<powf() is stable>
  PASS:<sinf() is stable>
  PASS:<sinhf() is stable>
  PASS:<sqrtf() is stable>
  PASS:<tanf() is stable>
  PASS:<tanhf() is stable>

f-tests failed:

  FAIL:<acosf() failed tests> Line: 92, File: ... vectors/acosf.c
  FAIL:<asinf() failed tests> Line: 92, File: ... vectors/asinf.c
  FAIL:<frexpf() failed tests> Line: 92, File: ... vectors/frexpf.c
  FAIL:<log10f() failed tests> Line: 92, File: ... vectors/log10f.c
  FAIL:<logf() failed tests> Line: 92, File: ... vectors/logf.c

There were 42 warnings [-Wunused-function] in the build (otherwise, all
is clean). One fix would be to add a prototyping for doTestVec() and
doTestVecFloat() in tests/vector_support.h with GCC attribute unused

  static cyg_bool
  doTestVec(CYG_ADDRESS func_ptr,
            Cyg_libm_test_arg_type arg1_type,
            Cyg_libm_test_arg_type arg2_type,
            Cyg_libm_test_arg_type result_type,
            const Cyg_libm_test_double_vec_t * vectors,
            cyg_ucount32 num_vectors)
      CYGBLD_ATTRIB_UNUSED;

and the same for doTestVecFloat(), then build is silent.

Thanks. Be continue.

Sergei

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

--- Comment #12 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-03-21 19:52:31 GMT ---
(In comment #9 I wrote)

> All f-tests fail on eCos synthetic target

My fault (that was wrong grep GDB output)! I'm sorry. Only below fails:

  FAIL:<sqrtf() failed tests> Line: 92, File: tests/vectors/sqrtf.c
  FAIL:<log10f() failed tests> Line: 92, File: tests/vectors/log10f.c
  FAIL:<frexpf() failed tests> Line: 92, File: tests/vectors/frexpf.c
  FAIL:<acosf() failed tests> Line: 92, File: tests/vectors/acosf.c
  FAIL:<asinf() failed tests> Line: 92, File: tests/vectors/asinf.c
  FAIL:<logf() failed tests> Line: 92, File: tests/vectors/logf.c

So, I got the same results for eCos sythetic target as for ARM7 target.

Sergei

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1663|0                           |1
        is obsolete|                            |

--- Comment #13 from Ilija Kocho <ilijak@siva.com.mk> 2012-03-22 10:23:47 GMT ---
Created an attachment (id=1665)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1665)
Libm tests vector support float 120322

(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #9)

[snip]

> There were 42 warnings [-Wunused-function] in the build (otherwise, all
> is clean). One fix would be to add a prototyping for doTestVec() and
> doTestVecFloat() in tests/vector_support.h with GCC attribute unused
> 
>   static cyg_bool
>   doTestVec(CYG_ADDRESS func_ptr,
>             Cyg_libm_test_arg_type arg1_type,
>             Cyg_libm_test_arg_type arg2_type,
>             Cyg_libm_test_arg_type result_type,
>             const Cyg_libm_test_double_vec_t * vectors,
>             cyg_ucount32 num_vectors)
>       CYGBLD_ATTRIB_UNUSED;
> 
> and the same for doTestVecFloat(), then build is silent.
> 

Thank you for pointing this out.
I decided to revert tests_vect_support.h (i.e. leave it intact) and introduce
new header tests_vector_support_float.h for floats. There will be little
redundancy but probably it's better not to touch old code if we can avoid it.
As a side effect we got rid of warnings. (Yes it all started with warnings...)

Ilija

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1659|0                           |1
        is obsolete|                            |

--- Comment #14 from Ilija Kocho <ilijak@siva.com.mk> 2012-03-22 10:25:31 GMT ---
Created an attachment (id=1666)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1666)
Libm tests part 1 120321

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1660|0                           |1
        is obsolete|                            |

--- Comment #15 from Ilija Kocho <ilijak@siva.com.mk> 2012-03-22 10:26:19 GMT ---
Created an attachment (id=1667)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1667)
Libm tests part 2 120321

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1661|0                           |1
        is obsolete|                            |

--- Comment #16 from Ilija Kocho <ilijak@siva.com.mk> 2012-03-22 10:27:05 GMT ---
Created an attachment (id=1668)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1668)
Libm tests part 3 120321

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1662|0                           |1
        is obsolete|                            |

--- Comment #17 from Ilija Kocho <ilijak@siva.com.mk> 2012-03-22 10:28:17 GMT ---
Created an attachment (id=1669)
 --> (http://bugs.ecos.sourceware.org/attachment.cgi?id=1669)
Libm tests part 4 120321

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

--- Comment #18 from Ilija Kocho <ilijak@siva.com.mk> 2012-03-22 11:01:07 GMT ---
(In reply to comment #12)
> (In comment #9 I wrote)
> 
> > All f-tests fail on eCos synthetic target
> 
> My fault (that was wrong grep GDB output)! I'm sorry. Only below fails:
> 
>   FAIL:<sqrtf() failed tests> Line: 92, File: tests/vectors/sqrtf.c
>   FAIL:<log10f() failed tests> Line: 92, File: tests/vectors/log10f.c
>   FAIL:<frexpf() failed tests> Line: 92, File: tests/vectors/frexpf.c
>   FAIL:<acosf() failed tests> Line: 92, File: tests/vectors/acosf.c
>   FAIL:<asinf() failed tests> Line: 92, File: tests/vectors/asinf.c
>   FAIL:<logf() failed tests> Line: 92, File: tests/vectors/logf.c
> 
> So, I got the same results for eCos sythetic target as for ARM7 target.
> 
> Sergei

Tests expect NaN for out-of-domain arguments, but functions return something
else. For instance asinf(10) returns 0. Here is a little example:

int main(void)
{
    volatile float fla, flb, flc;
    volatile double dla, dlb, dlc;

    printf("Enter floats: ");
    scanf("%f %f", &fla, &flb);
    printf("Enter doubles: ");
    scanf ("%lf %lf", &dla, &dlb);

    flc = fla + flb;
    dlc = dla + dlb;
    printf("float:  %f + %f = %f\n", fla, flb, flc);
    printf("double: %f + %f = %f\n", dla, dlb, dlc);

    flc = fla / flb;
    dlc = dla / dlb;
    printf("float:   %f / %f = %f\n", fla, flb, flc);
    printf("double: %f / %f = %f\n", dla, dlb, dlc);

    flc = asinf(fla);
    dlc = asin(dla);
    printf("float:   asinf(%f) = %f\n", fla, flc);
    printf("double: asin(%f)  = %f\n", dla, dlc);

    return 0;
}

And some printouts:

Enter floats: 0 0
Enter doubles: 0 0
float:  0.000000 + 0.000000 = 0.000000
double: 0.000000 + 0.000000 = 0.000000
float:   0.000000 / 0.000000 = nan
double: 0.000000 / 0.000000 = nan
float:   asinf(0.000000) = 0.000000
double: asin(0.000000)  = 0.000000

Enter floats: 10 10
Enter doubles: 10 10
float:  10.000000 + 10.000000 = 20.000000
double: 10.000000 + 10.000000 = 20.000000
float:   10.000000 / 10.000000 = 1.000000
double: 10.000000 / 10.000000 = 1.000000
float:   asinf(10.000000) = 0.000000
double: asin(10.000000)  = 0.000000

As we can the same behavior is for double. I haven't check but I could imagine
that double's tests either don't contain these cases or expect 0.

I wander if this is some compatibility issue?! FYI Linux man pages say they
should return NaN.

Then next question: what to fix, functions or tests?

Ilija

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

--- Comment #19 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-03-22 13:42:17 GMT ---
(In reply to comment #18)
> (In reply to comment #12)
> > (In comment #9 I wrote)
> > 
> > > All f-tests fail on eCos synthetic target
> > 
> > My fault (that was wrong grep GDB output)! I'm sorry. Only below fails:
> > 
> >   FAIL:<sqrtf() failed tests> Line: 92, File: tests/vectors/sqrtf.c
> >   FAIL:<log10f() failed tests> Line: 92, File: tests/vectors/log10f.c
> >   FAIL:<frexpf() failed tests> Line: 92, File: tests/vectors/frexpf.c
> >   FAIL:<acosf() failed tests> Line: 92, File: tests/vectors/acosf.c
> >   FAIL:<asinf() failed tests> Line: 92, File: tests/vectors/asinf.c
> >   FAIL:<logf() failed tests> Line: 92, File: tests/vectors/logf.c
> > 
> > So, I got the same results for eCos sythetic target as for ARM7 target.
> > 
> > Sergei
> 
> Tests expect NaN for out-of-domain arguments, but functions return something
> else. For instance asinf(10) returns 0. Here is a little example:

IMO, it can depend on libm compatibility, look at libm compat. wrappers
(w_*.c), e.g.  at w_asin{,f}.c. Though, I think in our case it should be
a result of call __ieee754_asin{,f}().  And if libm compat mode is not
IEEE?  I'm looking at misc/standard.c (__kernel_standard)...

> int main(void)
> {
>     volatile float fla, flb, flc;
>     volatile double dla, dlb, dlc;
> 
>     printf("Enter floats: ");
>     scanf("%f %f", &fla, &flb);
>     printf("Enter doubles: ");
>     scanf ("%lf %lf", &dla, &dlb);
> 
>     flc = fla + flb;
>     dlc = dla + dlb;
>     printf("float:  %f + %f = %f\n", fla, flb, flc);
>     printf("double: %f + %f = %f\n", dla, dlb, dlc);
> 
>     flc = fla / flb;
>     dlc = dla / dlb;
>     printf("float:   %f / %f = %f\n", fla, flb, flc);
>     printf("double: %f / %f = %f\n", dla, dlb, dlc);
> 
>     flc = asinf(fla);
>     dlc = asin(dla);
>     printf("float:   asinf(%f) = %f\n", fla, flc);
>     printf("double: asin(%f)  = %f\n", dla, dlc);
> 
>     return 0;
> }
> 
> And some printouts:
> 
> Enter floats: 0 0
> Enter doubles: 0 0
> float:  0.000000 + 0.000000 = 0.000000
> double: 0.000000 + 0.000000 = 0.000000
> float:   0.000000 / 0.000000 = nan
> double: 0.000000 / 0.000000 = nan
> float:   asinf(0.000000) = 0.000000
> double: asin(0.000000)  = 0.000000
> 
> Enter floats: 10 10
> Enter doubles: 10 10
> float:  10.000000 + 10.000000 = 20.000000
> double: 10.000000 + 10.000000 = 20.000000
> float:   10.000000 / 10.000000 = 1.000000
> double: 10.000000 / 10.000000 = 1.000000
> float:   asinf(10.000000) = 0.000000
> double: asin(10.000000)  = 0.000000
> 
> As we can the same behavior is for double. I haven't check but I could
> imagine that double's tests either don't contain these cases or expect
> 0.

Thank you for the example.

> I wander if this is some compatibility issue?! FYI Linux man pages say
> they should return NaN.

Further I would refer to http://sourceware.org/newlib/libm.html and thus
to http://sourceware.org/newlib/libm.html#asin However, they also talk
about NaN, errno (EDOM), etc.

> Then next question: what to fix, functions or tests?

Do you trust your checkErrorAcceptableFloat() implementation? As I could
see asin*(10.0) should return N-a-N if libm compat is IEEE. IMHO, we have
to compare return values for d-implementations with f-ones and then test
(compare) behaviors of its checkers. I will try to investigate tonight.

Sergei

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

--- Comment #20 from Sergei Gavrikov <sergei.gavrikov@gmail.com> 2012-03-22 18:05:34 GMT ---
(In reply to comment #19)
> > Tests expect NaN for out-of-domain arguments, but functions return
> > something else. For instance asinf(10) returns 0. Here is a little
> > example:
> 
> IMO, it can depend on libm compatibility, look at libm compat.
> wrappers (w_*.c), e.g.  at w_asin{,f}.c. Though, I think in our case
> it should be a result of call __ieee754_asin{,f}().  And if libm
> compat mode is not IEEE?  I'm looking at misc/standard.c
> (__kernel_standard)...

Well, I understand what is wrong. Let's take `wf_asin.c', "i wonder"
hack:

  --- a/packages/language/c/libm/current/src/float/ieee754-api/wf_asin.c
  +++ b/packages/language/c/libm/current/src/float/ieee754-api/wf_asin.c
  @@ -88,8 +88,10 @@
   #ifdef CYGSEM_LIBM_COMPAT_IEEE_ONLY
       return __ieee754_asinf(x);
   #else
  -    double z;
  +    float z;
       z = __ieee754_asinf(x);
  +    printf("__ieee754_asinf(%f)=%f\n", x, z);
  +    return z;
       if(cyg_libm_get_compat_mode() == CYGNUM_LIBM_COMPAT_IEEE || isnanf(x))
return z;
       if(fabs(x)>1.0) {
           return __kernel_standard(x,x,2); /* asin(|x|>1) */

Then let's run `asinf' (a picture worth more than many words)

  INFO:<Still crunching, please wait...>
  __ieee754_asinf(-1.200000)=nan
  __ieee754_asinf(-1.190000)=nan
  ...
  __ieee754_asinf(-1.010000)=nan
  __ieee754_asinf(-1.000000)=-1.570796
  ...
  __ieee754_asinf(0.000000)=0.000000
  __ieee754_asinf(0.000000)=0.000000
  INFO:<Still crunching, please wait...>
  __ieee754_asinf(0.000000)=0.000000
  PASS:<asinf() is stable>
  EXIT:<Finished tests from testcase
/home/sg/repo/ecos-hg/packages/language/c/libm/current/tests/vectors/asinf.c
for Math library asinf() function>

Thus, IMHO, you have to implement own __kernel_standard_float() and
maybe another "float" wrappers to peace failed f-tests.

FYI, import

  cdl_option CYGSEM_LIBM_COMPAT_IEEE_ONLY {
      user_value 1
  };

breaks build of single precision tests. Some your headers have EDOM
used, but this value is not defined for such config conditions. Perhaps,
you need weak definition for that in `vector_support_float.h' header.

   // Not tested
   #ifdef CYGSEM_LIBM_COMPAT_IEEE_ONLY
   # ifndef EDOM
   #  define EDOM 33
   # endif
   #endif

Sergei

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

--- Comment #21 from Ilija Kocho <ilijak@siva.com.mk> 2012-03-22 23:52:49 GMT ---
(In reply to comment #20)
> (In reply to comment #19)
> > > Tests expect NaN for out-of-domain arguments, but functions return
> > > something else. For instance asinf(10) returns 0. Here is a little
> > > example:
> > 
> > IMO, it can depend on libm compatibility, look at libm compat.
> > wrappers (w_*.c), e.g.  at w_asin{,f}.c. Though, I think in our case
> > it should be a result of call __ieee754_asin{,f}().  And if libm
> > compat mode is not IEEE?  I'm looking at misc/standard.c
> > (__kernel_standard)...
> 
> Well, I understand what is wrong. Let's take `wf_asin.c', "i wonder"
> hack:
> 
>   --- a/packages/language/c/libm/current/src/float/ieee754-api/wf_asin.c
>   +++ b/packages/language/c/libm/current/src/float/ieee754-api/wf_asin.c
>   @@ -88,8 +88,10 @@
>    #ifdef CYGSEM_LIBM_COMPAT_IEEE_ONLY
>        return __ieee754_asinf(x);
>    #else
>   -    double z;
>   +    float z;
>        z = __ieee754_asinf(x);
>   +    printf("__ieee754_asinf(%f)=%f\n", x, z);
>   +    return z;
>        if(cyg_libm_get_compat_mode() == CYGNUM_LIBM_COMPAT_IEEE || isnanf(x))
> 

[snip]

> FYI, import
> 
>   cdl_option CYGSEM_LIBM_COMPAT_IEEE_ONLY {
>       user_value 1
>   };
> 
> breaks build of single precision tests. Some your headers have EDOM
> used, but this value is not defined for such config conditions. Perhaps,
> you need weak definition for that in `vector_support_float.h' header.
> 
>    // Not tested
>    #ifdef CYGSEM_LIBM_COMPAT_IEEE_ONLY
>    # ifndef EDOM
>    #  define EDOM 33
>    # endif
>    #endif
> 
> Sergei

Thank you for bringing this up Sergei.
Now I am considering exclusion of EDOM cases from test
for modes other than CYGSEM_LIBM_COMPAT_IEEE_ONLY. (tests/asin.h doesn't have
them at all).

Ilija

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

Visar Zejnullahu <visar@siva.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |visar@siva.mk

--- Comment #22 from Visar Zejnullahu <visar@siva.mk> 2012-08-08 12:48:01 BST ---
I have filled in and sent an copyright assignment request form to
assign@gnu.org but I have not received any answer from them. What should I do?
I followed the procedure described here: http://ecos.sourceware.org/assign.html

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

Jonathan Larmour <jifl@ecoscentric.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jifl@ecoscentric.com

--- Comment #23 from Jonathan Larmour <jifl@ecoscentric.com> ---
The assignment is now in place.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1656|assignment-                 |assignment+
              Flags|                            |

--- Comment #24 from Ilija Kocho <ilijak@siva.com.mk> ---
Comment on attachment 1656
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=1656
CDL and include files

(In reply to comment #23)
> The assignment is now in place.

Thank you Jifl.

So now let's prepare this for CVS. I am refreshing my memory, then I shall test
against current CVS (may we call it "Rolling Release"?) and come back with
report and comments.

Comments from any side are welcome.

Ilija

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

John Dallaway <john@dallaway.org.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |john@dallaway.org.uk

--- Comment #25 from John Dallaway <john@dallaway.org.uk> ---
Ilija, I have tested the current patches on the "psim" target (big-endian).

In the default configuration (CYGNUM_LIBM_COMPATIBILITY), I see 5 libm test
failures (out of tolerance):  frexpf, asinf, logf, acosf, log10f

In IEEE-only configuration (CYGSEM_LIBM_COMPAT_IEEE_ONLY), I get a build error
(EDOM undeclared). If I fix the build error by including <errno.h>
unconditionally from vector_support_float.h then I see 1 libm test failure (out
of tolerance):  frexpf

I hope this helps.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

--- Comment #26 from Ilija Kocho <ilijak@siva.com.mk> ---
John, thank you for the testing and comment. In meantime I have been working on
this bug and I am going to post patch(es) later today.


(In reply to comment #25)
> Ilija, I have tested the current patches on the "psim" target (big-endian).
> 
> In the default configuration (CYGNUM_LIBM_COMPATIBILITY), I see 5 libm test
> failures (out of tolerance):  frexpf, asinf, logf, acosf, log10f
> 
> In IEEE-only configuration (CYGSEM_LIBM_COMPAT_IEEE_ONLY), I get a build
> error (EDOM undeclared). If I fix the build error by including <errno.h>
> unconditionally from vector_support_float.h 

To be honest I don't know the implications for including errno.h on this
condition. This header is a copy of vector_support.h adapted for SP floats.
Note: An explanation is appreciated.

For the time being, to be on a safe side I would put:

 #ifndef CYGSEM_LIBM_COMPAT_IEEE_ONLY
 # include <errno.h>                // For Cyg_ErrNo
+#else
+# ifndef EDOM
+#   define EDOM 33
+# endif
 #endif

>then I see 1 libm test failure
> (out of tolerance):  frexpf
> 
> I hope this helps.

I do not recall such failures (It's been a long time when I last tested on
Cortex-M), but now I'll run the tests with both hard and soft FP.

Ilija

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

--- Comment #27 from Ilija Kocho <ilijak@siva.com.mk> ---
(In reply to comment #25)
> Ilija, I have tested the current patches on the "psim" target (big-endian).
> 
> In the default configuration (CYGNUM_LIBM_COMPATIBILITY), I see 5 libm test
> failures (out of tolerance):  frexpf, asinf, logf, acosf, log10f
> 
> In IEEE-only configuration (CYGSEM_LIBM_COMPAT_IEEE_ONLY), I get a build
> error (EDOM undeclared). If I fix the build error by including <errno.h>
> unconditionally from vector_support_float.h then I see 1 libm test failure
> (out of tolerance):  frexpf
> 
> I hope this helps.

I reproduced your tests and it come back to me. In case of default
CYGNUM_LIBM_COMPATIBILITY configuration the real error is EDOM, but POSIX model
doesn't seem to support it. The cases that test EDOM should be excluded for
POSIX. (Please see comment 21 and patch sample below.

frexpf on the other hand seem to fail and we need to check why.



--- patch sample -----------


--- logf.h    2013-06-07 20:56:07.943683244 +0200
+++ logf_new.h    2013-06-07 20:56:16.235683588 +0200
@@ -63,12 +63,12 @@
 #include <cyg/infra/cyg_type.h>    // Common type definitions and support
 #include "vectors/vector_support_float.h"// extra support for math tests

-//#define LOG_TOLERANCE 1.0E-04
-#define LOG_TOLERANCE 1.0E-05
+#define LOG_TOLERANCE 1.0E-04

 static const Cyg_libm_test_float_vec_t logf_vec[] = {

-// AUTOMATICALLY GENERATED VECTORS START
+    // AUTOMATICALLY GENERATED VECTORS START
+#if defined CYGNUM_LIBM_COMPATIBILITY_IEEE || defined
CYGSEM_LIBM_COMPAT_IEEE_ONLY
 {0, 3214514586u, 1115684864u, 2143289344u, EDOM, LOG_TOLERANCE, 0},
 {1, 3214430700u, 1115684864u, 2143289344u, EDOM, LOG_TOLERANCE, 0},
 {2, 3214346813u, 1115684864u, 2143289344u, EDOM, LOG_TOLERANCE, 0},
@@ -189,6 +189,7 @@
 {117, 3170222735u, 1115684864u, 2143289344u, EDOM, LOG_TOLERANCE, 0},
 {118, 3164854026u, 1115684864u, 2143289344u, EDOM, LOG_TOLERANCE, 0},
 {119, 3156465418u, 1115684864u, 2143289344u, EDOM, LOG_TOLERANCE, 0},
+#endif //defined CYGNUM_LIBM_COMPATIBILITY_IEEE || defined
CYGSEM_LIBM_COMPAT_IEEE_ONLY
 {120, 646742016u, 3255452089u, 3255452089u, 0, LOG_TOLERANCE, 0},
 {121, 1008981770u, 3230883214u, 3230883214u, 0, LOG_TOLERANCE, 0},
 {122, 1017370378u, 3229245078u, 3229245078u, 0, LOG_TOLERANCE, 0},
@@ -309,6 +310,7 @@
 {237, 1066779279u, 1042335124u, 1042335124u, 0, LOG_TOLERANCE, 0},
 {238, 1066863165u, 1042906267u, 1042906267u, 0, LOG_TOLERANCE, 0},
 {239, 1066947052u, 1043472596u, 1043472596u, 0, LOG_TOLERANCE, 0},
+#if defined CYGNUM_LIBM_COMPATIBILITY_IEEE || defined
CYGSEM_LIBM_COMPAT_IEEE_ONLY
 {240, 3234402267u, 1115684864u, 2143289344u, EDOM, LOG_TOLERANCE, 0},
 {241, 3231108068u, 1115684864u, 2143289344u, EDOM, LOG_TOLERANCE, 0},
 {242, 3226013659u, 1115684864u, 2143289344u, EDOM, LOG_TOLERANCE, 0},
@@ -335,6 +337,7 @@
 {263, 3230662656u, 1115684864u, 2143289344u, EDOM, LOG_TOLERANCE, 0},
 {264, 3224580915u, 1115684864u, 2143289344u, EDOM, LOG_TOLERANCE, 0},
 {265, 3213675725u, 1115684864u, 2143289344u, EDOM, LOG_TOLERANCE, 0},
+#endif // defined CYGNUM_LIBM_COMPATIBILITY_IEEE || defined
CYGSEM_LIBM_COMPAT_IEEE_ONLY
 {266, 1058642330u, 3204629879u, 3204629879u, 0, LOG_TOLERANCE, 0},
 {267, 1075000115u, 1062549896u, 1062549896u, 0, LOG_TOLERANCE, 0},
 {268, 1082130432u, 1068593688u, 1068593688u, 0, LOG_TOLERANCE, 0},

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

--- Comment #28 from Jonathan Larmour <jifl@ecoscentric.com> ---
(In reply to comment #27)
> 
> I reproduced your tests and it come back to me. In case of default
> CYGNUM_LIBM_COMPATIBILITY configuration the real error is EDOM, but POSIX
> model doesn't seem to support it. The cases that test EDOM should be
> excluded for POSIX. (Please see comment 21 and patch sample below.

I may not be following your reasoning, but POSIX behaviour does require EDOM.
For example:

http://pubs.opengroup.org/onlinepubs/9699919799/functions/asin.html

Jifl

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

--- Comment #29 from Ilija Kocho <ilijak@siva.com.mk> ---
(In reply to comment #28)
> (In reply to comment #27)
> > 
> > I reproduced your tests and it come back to me. In case of default
> > CYGNUM_LIBM_COMPATIBILITY configuration the real error is EDOM, but POSIX
> > model doesn't seem to support it. The cases that test EDOM should be
> > excluded for POSIX. (Please see comment 21 and patch sample below.
> 
> I may not be following your reasoning, but POSIX behaviour does require
> EDOM. For example:
> 
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/asin.html
> 
> Jifl

Thanks for reference.

I'm referring to actual code Ref:float/ieee754_api/wf_asinf.c
if (|x| > 1) POSIX mode sets errno = EDOM indeed, but returns 0 rather than
NaN.

Ilija

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

--- Comment #30 from Jonathan Larmour <jifl@ecoscentric.com> ---
(In reply to comment #29)
> 
> I'm referring to actual code Ref:float/ieee754_api/wf_asinf.c
> if (|x| > 1) POSIX mode sets errno = EDOM indeed, but returns 0 rather than
> NaN.

It's not required to return NaN. In fact the slightly older POSIX standard I've
got here (not online) says that more explicitly:

"If the value of x is not in the range [−1,1], and is not ±Inf or NaN, either
0.0 or NaN shall be returned and errno shall be set to [EDOM].

If x is NaN, NaN shall be returned and errno may be set to [EDOM].

If x is ±Inf, either 0.0 shall be returned and errno set to [EDOM], or NaN
shall be returned and errno may be set to [EDOM]."

I assume in the more recent standard they decided to make it more general - not
necessarily 0.0 but any value as long as it's implementation-defined. But that
can certainly be 0.0.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

--- Comment #31 from Ilija Kocho <ilijak@siva.com.mk> ---
(In reply to comment #30)
> (In reply to comment #29)
> > 
> > I'm referring to actual code Ref:float/ieee754_api/wf_asinf.c
> > if (|x| > 1) POSIX mode sets errno = EDOM indeed, but returns 0 rather than
> > NaN.
> 
> It's not required to return NaN. In fact the slightly older POSIX standard
> I've got here (not online) says that more explicitly:
> 
> "If the value of x is not in the range [−1,1], and is not ±Inf or NaN,
> either 0.0 or NaN shall be returned and errno shall be set to [EDOM].
> 
> If x is NaN, NaN shall be returned and errno may be set to [EDOM].
> 
> If x is ±Inf, either 0.0 shall be returned and errno set to [EDOM], or NaN
> shall be returned and errno may be set to [EDOM]."
> 
> I assume in the more recent standard they decided to make it more general -
> not necessarily 0.0 but any value as long as it's implementation-defined.
> But that can certainly be 0.0.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

--- Comment #32 from Ilija Kocho <ilijak@siva.com.mk> ---
(In reply to comment #31)
> (In reply to comment #30)
> > (In reply to comment #29)
> > > 
> > > I'm referring to actual code Ref:float/ieee754_api/wf_asinf.c
> > > if (|x| > 1) POSIX mode sets errno = EDOM indeed, but returns 0 rather than
> > > NaN.
... as expected by the test.

I should have been clearer, sorry.

> > 
> > It's not required to return NaN. In fact the slightly older POSIX standard
> > I've got here (not online) says that more explicitly:
> > 
> > "If the value of x is not in the range [−1,1], and is not ±Inf or NaN,
> > either 0.0 or NaN shall be returned and errno shall be set to [EDOM].
> > 
> > If x is NaN, NaN shall be returned and errno may be set to [EDOM].
> > 
> > If x is ±Inf, either 0.0 shall be returned and errno set to [EDOM], or NaN
> > shall be returned and errno may be set to [EDOM]."
> > 
> > I assume in the more recent standard they decided to make it more general -
> > not necessarily 0.0 but any value as long as it's implementation-defined.
> > But that can certainly be 0.0.

The code is OK, according to standard, nevertheless for non IEEE model tests do
fail on vectors testing EDOM. We can either change the test (perhaps test
errno), or exclude EDOM tests for non IEEE models. I proposed exclusion of EDOM
vectors for non IEEE model, because I didn't want to alter the test code, but
I'm open for suggestions.

Ilija

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

--- Comment #33 from Ilija Kocho <ilijak@siva.com.mk> ---
Created attachment 2255
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2255&action=edit
Inline some portable API functions for IEEE only option (incremental)

Here is a proposal for optimisation of some functions for both space and speed.
If CYGSEM_LIBM_COMPAT_IEEE_ONLY compatibility option is selected then portable
API (wrapper) functions became trivial and can be inlined. Inlining eliminates
one step of indirection, producing faster code. The generated code in total, is
also shorter. At present following portable APIs are inlined: atan2/atan2f and
hypot/hypotf. The reason for this selection is that they are used by basic
complex carg/cargf and cabs/cabsf operations respectively.
Inlining option is user selectable and is disabled by default in order to
preserve backward compatibility

Here we come to complex number support. My initial intention was to enable only
basic operations: argument, abs value, conjugation, real and imaginary parts
(some of them trivial/builtin). However it turned out that complete complex
library (taken from Newlib) compiled without warnings - almost verbatim.
Therefore I decided to submit complete complex library as well. Most functions
are unaltered - hence original copyright banners are preserved. The ones that I
have altered are (however trivial) different enough to publish them under eCos
licence. That includes: carg, cabs, conj, creal and cimag - all double and
float.
Arguably the complex support could be subject to a separate bug, but IMO it
fits here well in context of previous paragraph. It is easy to change the topic
of this bug accordingly.

Note: This attachment is incremental to 1656+1657+1658 patch collection. It
does not contain complex functions body. That will be posted in a patch that
follows.

Ilija

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

--- Comment #34 from Ilija Kocho <ilijak@siva.com.mk> ---
Created attachment 2256
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2256&action=edit
Complex function body (incremental)

Here is the complex function body referred in comment 33. This patch is
icremental to attachments 1656+1657+1658 and also needs attachment 2255.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

--- Comment #35 from Ilija Kocho <ilijak@siva.com.mk> ---
(In reply to comment #33)
> Created attachment 2255 [details]
> Inline some portable API functions for IEEE only option (incremental)
> 
> Here is a proposal for optimisation of some functions for both space and
> speed. If CYGSEM_LIBM_COMPAT_IEEE_ONLY compatibility option is selected then
> portable API (wrapper) functions became trivial and can be inlined. Inlining

Correction: it's ieee754-api, not portable-api!

> eliminates one step of indirection, producing faster code. The generated
> code in total, is also shorter. At present following portable APIs are
> inlined: atan2/atan2f and hypot/hypotf. The reason for this selection is
> that they are used by basic complex carg/cargf and cabs/cabsf operations
> respectively.
> Inlining option is user selectable and is disabled by default in order to
> preserve backward compatibility
> 
> Here we come to complex number support. My initial intention was to enable
> only basic operations: argument, abs value, conjugation, real and imaginary
> parts (some of them trivial/builtin). However it turned out that complete
> complex library (taken from Newlib) compiled without warnings - almost
> verbatim. Therefore I decided to submit complete complex library as well.
> Most functions are unaltered - hence original copyright banners are
> preserved. The ones that I have altered are (however trivial) different
> enough to publish them under eCos licence. That includes: carg, cabs, conj,
> creal and cimag - all double and float.
> Arguably the complex support could be subject to a separate bug, but IMO it
> fits here well in context of previous paragraph. It is easy to change the
> topic of this bug accordingly.
> 
> Note: This attachment is incremental to 1656+1657+1658 patch collection. It
> does not contain complex functions body. That will be posted in a patch that
> follows.
> 
> Ilija

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1656|0                           |1
        is obsolete|                            |

--- Comment #36 from Ilija Kocho <ilijak@siva.com.mk> ---
Created attachment 2286
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2286&action=edit
Math CDL

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1657|0                           |1
        is obsolete|                            |
   Attachment #2255|0                           |1
        is obsolete|                            |

--- Comment #37 from Ilija Kocho <ilijak@siva.com.mk> ---
Created attachment 2287
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2287&action=edit
Single precision floating point library

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1658|0                           |1
        is obsolete|                            |

--- Comment #38 from Ilija Kocho <ilijak@siva.com.mk> ---
Created attachment 2288
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2288&action=edit
Libm mathincl/misc

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1665|0                           |1
        is obsolete|                            |

--- Comment #39 from Ilija Kocho <ilijak@siva.com.mk> ---
Created attachment 2289
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2289&action=edit
Libm tests vector support float 130627

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1666|0                           |1
        is obsolete|                            |

--- Comment #40 from Ilija Kocho <ilijak@siva.com.mk> ---
Created attachment 2290
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2290&action=edit
Libm tests part 1 130627

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1667|0                           |1
        is obsolete|                            |

--- Comment #41 from Ilija Kocho <ilijak@siva.com.mk> ---
Created attachment 2291
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2291&action=edit
Libm tests part 2 130627

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1668|0                           |1
        is obsolete|                            |

--- Comment #42 from Ilija Kocho <ilijak@siva.com.mk> ---
Created attachment 2292
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2292&action=edit
Libm tests part 3 130627

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #1669|0                           |1
        is obsolete|                            |

--- Comment #43 from Ilija Kocho <ilijak@siva.com.mk> ---
Created attachment 2293
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2293&action=edit
Libm tests part 4 130627

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

Ilija Kocho <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Attachment #2256|0                           |1
        is obsolete|                            |

--- Comment #44 from Ilija Kocho <ilijak@siva.com.mk> ---
Created attachment 2294
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2294&action=edit
Complex

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

--- Comment #45 from Ilija Kocho <ilijak@siva.com.mk> ---
Created attachment 2295
  --> http://bugs.ecos.sourceware.org/attachment.cgi?id=2295&action=edit
Cortexm architectural specific builtin functions

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

--- Comment #46 from Ilija Kocho <ilijak@siva.com.mk> ---
I just posted a collection of patches that apply changes announced in comments
above.


Ref: Comment #33
The inlining option CYGSEM_LIBM_IEEE_API_INLINE is applied to most of
ieee754-api functions. This had an impact on math.h, but although it looks very
different, with default CDL settings, after macro expansion, the legacy
declarations are same as before.
The inlining may suppress generation of GCC builtin functions so there is an
override provision. The overriding is typically enforced by architecture HAL.
As an example, overriding is implemented in Cortex-M architecture (precidely
Cortex-M4F) for sqrtf() (Attachment 2295). For backward compatibility inlining
is disabled by default.


In reply to comment #25
John,
Now all tests pass for IEEE mode. With CYGOPT_LIBM_COMPAT_POSIX_IEEE option
enabled they pass for POSIX as well.
The problem with frexpf() was a wrong test vector (the exponent part). I got
the test generation program, adapted output to eCos port and generated correct
test vectors.


In reply to comment #28 and comment #30
Jifl,
I added option CYGOPT_LIBM_COMPAT_POSIX_IEEE so now user can select whether on
out-of-domain error functions return 0 or NaN. In order to provide same
behavior for all double and single precision functions, the code from
standard.c has moved in standard.inl, which is then included in bot standard.c
and standard_float.c
When CYGOPT_LIBM_COMPAT_POSIX_IEEE is enabled POSIX mode passes the test.
When CYGOPT_LIBM_COMPAT_POSIX_IEEE is disabled i.e. functions return 0.0 the
test fails. Following code snippet can make test pass (example acosf.h).
Please advise.

--- acosf.h------

+#if defined(CYGSEM_LIBM_COMPAT_IEEE_ONLY) ||
+    defined (CYGOPT_LIBM_COMPAT_POSIX_IEEE)
+#define EDOM_RETVAL (2143289344u)
+#else
+#define EDOM_RETVAL (0)
+#endif

 static const Cyg_libm_test_float_vec_t acosf_vec[] = {

-{0, 3214514586u, 1115684864u, 2143289344u, EDOM, ACOS_TOLERANCE, 0},
+{0, 3214514586u, 1115684864u, EDOM_RETVAL, EDOM, ACOS_TOLERANCE, 0},
 .....
 };

---END-----------


Ref comment #33 (again)
Complex functions are added in attachment 2294. I have nothing to add to my
discussion in comment 33 except a question: "Should we change the title of this
bug?"


Bottom line:
Considering the size of this patches, I would invite all who had already
commented (other people are welcome of course), to steal some time to do it
again. I am testing on Cortex-M4 and it would be good if somebody could test on
other platforms. Perhaps there may be interest to test this patches in a course
of Gnutools test release tests?

Ilija

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

--- Comment #47 from Ilija Kocho <ilijak@siva.com.mk> ---
The last patches have been exposed for a while, and I would like to finalize
this bug. My aim is to commit at end of August 2013 (week 34 or 35), unless
some objections arise.

Ilija

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

--- Comment #48 from Ilija Kocho [Илија Кочо] <ilijak@siva.com.mk> ---
Checked in.
Many thanks to Sergei, Jifl, and John for their comments.

Everybody is invited to checkout and test. You can report eventual problems
here or. I am leaving this bug open for for a while.

Ilija

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 1001539] Single precision floating point math library

[bugzilla-daemon]

Please do not reply to this email, use the link below.

http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001539

Ilija Kocho [Илија Кочо] <ilijak@siva.com.mk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |CURRENTRELEASE

--- Comment #49 from Ilija Kocho [Илија Кочо] <ilijak@siva.com.mk> ---
This was checked in a while ago.
Closing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.