[PATCH] define WIDEST_HARDWARE_FP_SIZE on mips

[PATCH] define WIDEST_HARDWARE_FP_SIZE on mips

[Olivier Hainque]

[-- Attachment #1: Type: text/plain, Size: 837 bytes --]

Hello,

The attached patch defines WIDEST_HARDWARE_FP_SIZE on mips.

This is used by the Ada front end to determine the widest efficient
floating point type on the target. If not defined, we fallback on
LONG_DOUBLE_TYPE_SIZE and observe various mishaps if this requires
software support.

For instance, the test below is expected to output " +Inf*******".

On Irix 6.5, it currently raises a constraint_error exception from a
runtime library unit instead.

  << with Ada.Text_IO;

     procedure T is
       N : Float := 2.0;
     begin
       N := N ** 256;
       Ada.Text_IO.Put_Line(Float'Image(N));
     end;
  >>

Bootstrapped and regtested for languages=c,c++,ada on mips-sgi-irix6.5.

Thanks in advance,

Olivier

1007-10-08  Olivier Hainque  <hainque@adacore.com>

	* config/mips/mips.h (WIDEST_HARDWARE_FP_SIZE): Define.







[-- Attachment #2: mips-widest_fp_reg.dif --]
[-- Type: text/plain, Size: 539 bytes --]

Index: config/mips/mips.h
===================================================================
*** config/mips/mips.h	(revision 128810)
--- config/mips/mips.h	(working copy)
*************** extern enum mips_code_readable_setting m
*** 1178,1183 ****
--- 1178,1184 ----
  
  /* For MIPS, width of a floating point register.  */
  #define UNITS_PER_FPREG (TARGET_FLOAT64 ? 8 : 4)
+ #define WIDEST_HARDWARE_FP_SIZE 64
  
  /* The number of consecutive floating-point registers needed to store the
     largest format supported by the FPU.  */

Re: [PATCH] define WIDEST_HARDWARE_FP_SIZE on mips

[Richard Sandiford]

Olivier Hainque <hainque@adacore.com> writes:
> The attached patch defines WIDEST_HARDWARE_FP_SIZE on mips.
>
> This is used by the Ada front end to determine the widest efficient
> floating point type on the target. If not defined, we fallback on
> LONG_DOUBLE_TYPE_SIZE and observe various mishaps if this requires
> software support.
>
> For instance, the test below is expected to output " +Inf*******".
>
> On Irix 6.5, it currently raises a constraint_error exception from a
> runtime library unit instead.
>
>   << with Ada.Text_IO;
>
>      procedure T is
>        N : Float := 2.0;
>      begin
>        N := N ** 256;
>        Ada.Text_IO.Put_Line(Float'Image(N));
>      end;
>   >>

Hmm.  Do you mean that GNAT doesn't support software floating point?
In other words, would this also happen on -msoft-float targets for
WIDEST_HARDWARE_FP_SIZE == 64?

(I hope this doesn't sound awkward.  I'm just trying to understand the
issue better.)

Richard

Re: [PATCH] define WIDEST_HARDWARE_FP_SIZE on mips

[Geert Bosch]

On Oct 9, 2007, at 16:01, Richard Sandiford wrote:
> Hmm.  Do you mean that GNAT doesn't support software floating point?
> In other words, would this also happen on -msoft-float targets for
> WIDEST_HARDWARE_FP_SIZE == 64?
>
> (I hope this doesn't sound awkward.  I'm just trying to understand the
> issue better.)

GNAT does support software floating point.
The WIDEST_HARDWARE_FP_SIZE is there to prevent implicit
use of software floating point for the widest FP types.
Most targets claiming support for 128-bit floating point
do so in ways that would make them unsuitable for use
by Ada programs.

A standard idiom in Ada is to declare types with the
maximum floating-point precision supported, like:

   type My_Float is new digits System.Max_Digits;

One of the reasons for declaring such a type is to prevent
implicit extra precision due to the FPU using wider
hardware registers such as happens with x87 and IEEE
single or double precision. Using the widest hardware
type, every operation is correctly rounded to a machine
number. This is an important property for numerical analysis.
Sometimes, 128-bit types are implemented using non-IEEE
semantics with very poor numerical properties ("double double").

Another reason is to use the widest HW FP type is get the
best accuracy that is still efficient. Many Ada applications
are used in  strict real-time environments, and it would
be disastrous to have performance of certain calculations
drop down a  cliff because the compiler decides to use
a 128-bit soft-float type, instead of a 64-bit or 80-bit hardware
type. The performance difference here would be about 2 to
3 orders of magnitude.

   -Geert

Re: [PATCH] define WIDEST_HARDWARE_FP_SIZE on mips

[Richard Sandiford]

Geert Bosch <bosch@adacore.com> writes:
> On Oct 9, 2007, at 16:01, Richard Sandiford wrote:
>> Hmm.  Do you mean that GNAT doesn't support software floating point?
>> In other words, would this also happen on -msoft-float targets for
>> WIDEST_HARDWARE_FP_SIZE == 64?
>>
>> (I hope this doesn't sound awkward.  I'm just trying to understand the
>> issue better.)
>
> GNAT does support software floating point.
> The WIDEST_HARDWARE_FP_SIZE is there to prevent implicit
> use of software floating point for the widest FP types.
> Most targets claiming support for 128-bit floating point
> do so in ways that would make them unsuitable for use
> by Ada programs.
>
> A standard idiom in Ada is to declare types with the
> maximum floating-point precision supported, like:
>
>    type My_Float is new digits System.Max_Digits;
>
> One of the reasons for declaring such a type is to prevent
> implicit extra precision due to the FPU using wider
> hardware registers such as happens with x87 and IEEE
> single or double precision. Using the widest hardware
> type, every operation is correctly rounded to a machine
> number. This is an important property for numerical analysis.
> Sometimes, 128-bit types are implemented using non-IEEE
> semantics with very poor numerical properties ("double double").
>
> Another reason is to use the widest HW FP type is get the
> best accuracy that is still efficient. Many Ada applications
> are used in  strict real-time environments, and it would
> be disastrous to have performance of certain calculations
> drop down a  cliff because the compiler decides to use
> a 128-bit soft-float type, instead of a 64-bit or 80-bit hardware
> type. The performance difference here would be about 2 to
> 3 orders of magnitude.

Your reply seems to be about why it's useful to have a macro that
provides the widest efficient floating-point type.  For avoidance
of doubt, I can certainly appreciate that such a thing is useful.
I'm just not sure why it's needed for correctness.  Olivier said:

-------------------------------------------------------------------
For instance, the test below is expected to output " +Inf*******".

On Irix 6.5, it currently raises a constraint_error exception from a
runtime library unit instead.

  << with Ada.Text_IO;

     procedure T is
       N : Float := 2.0;
     begin
       N := N ** 256;
       Ada.Text_IO.Put_Line(Float'Image(N));
     end;
  >>
-------------------------------------------------------------------

I was trying to understand why the runtime library raises a constraint
error.  Is it simply that the library only supports software floating
point for single and double precision (but supports hardware floating
point for wider types)?  Is it not possible to construct a version of the
Ada test above that forces the use of the equivalent of C "long double"?
If so, would that fail in the same way, or don't we care?

From a MIPS perspective, it's also counterintuitive for
WIDEST_HARDWARE_FP_SIZE to be 64 even for -msingle-float
and -msoft-float targets (rather than 32 and 0 respectively).
I can understand that 0 and 32 would be wrong given the way
the macro is used in ada/targtyps.c, but it seems that Ada is
using this macro for correctness -- and even to control an aspect
of the API and ABI -- whereas libgcc2.c is using it for optimisation.

It seems on the fact of it (to a non-Ada expert, of course) that given:

Pos
get_target_float_size (void)
{
  return fp_prec_to_size (FLOAT_TYPE_SIZE);
}

Pos
get_target_double_size (void)
{
  return fp_prec_to_size (DOUBLE_TYPE_SIZE);
}

Pos
get_target_long_double_size (void)
{
  return fp_prec_to_size (WIDEST_HARDWARE_FP_SIZE);
}

get_target_long_double_size really ought to be using something called
ADA_LONG_DOUBLE_TYPE_SIZE, given that it isn't always the same as
LONG_DOUBLE_TYPE_SIZE.

Richard

Re: [PATCH] define WIDEST_HARDWARE_FP_SIZE on mips

[Geert Bosch]

On Oct 10, 2007, at 08:25, Richard Sandiford wrote:
> Your reply seems to be about why it's useful to have a macro that
> provides the widest efficient floating-point type.  For avoidance
> of doubt, I can certainly appreciate that such a thing is useful.
> I'm just not sure why it's needed for correctness.  Olivier said:
...
> I was trying to understand why the runtime library raises a constraint
> error.  Is it simply that the library only supports software floating
> point for single and double precision (but supports hardware floating
> point for wider types)?  Is it not possible to construct a version  
> of the
> Ada test above that forces the use of the equivalent of C "long  
> double"?
> If so, would that fail in the same way, or don't we care?
As I'm travelling tomorrow, and don't have easy access to
a MIPS system right now, I won't have enough time
today to debug this issue in detail before next week.

There's one of two possibilities:
   - the GNAT run time doesn't handle 128-bit float properly
   - the 128-bit float doesn't have sane numerical semantics

As we haven't yet ported GNAT to a system with 128-bit hardware
floating point, it is very possible that some adaptations are
necessary. In fact, that's certainly the case.

>> From a MIPS perspective, it's also counterintuitive for
> WIDEST_HARDWARE_FP_SIZE to be 64 even for -msingle-float
> and -msoft-float targets (rather than 32 and 0 respectively).
> I can understand that 0 and 32 would be wrong given the way
> the macro is used in ada/targtyps.c, but it seems that Ada is
> using this macro for correctness -- and even to control an aspect
> of the API and ABI -- whereas libgcc2.c is using it for optimisation.

I definitely would be reasonable to set this to 32 and 0
for -msingle-float and -msoft-float targets. Yes, that would
mean we'd have to change targtypes.c, but that's fine.
Especially with -msingle-float this would seem a clear improvement.
> It seems on the fact of it (to a non-Ada expert, of course) that  
> given:
> get_target_long_double_size really ought to be using something called
> ADA_LONG_DOUBLE_TYPE_SIZE, given that it isn't always the same as
> LONG_DOUBLE_TYPE_SIZE.

Yes, there definitely is room for improvement here.
It's on my to do list.

   -Geert

Re: [PATCH] define WIDEST_HARDWARE_FP_SIZE on mips

[Laurent GUERBY]

Hi,

I'm bringing up this old discussion since I now have access
to mips64el hardware (gcc51 on the GCC Compile Farm).

Testing 4.4 Ada on abi=n32:
http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg00179.html

and on abi=64:
http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg00071.html

show some ACATS cxg test failing and these failures
seem to be linked to the use of 128 bits Long_Long_Float (long double)
on those two ABI. 

For reference abi=32 gets 100% clean ACATS and gnat.dg (with my patches)
but Long_Long_Float is 64 bits in this case:
http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg02620.html

The processor I'm using has only 64 bits in hardware (Loongson 2F), 128
bits is software is emulated.

I did not see Olivier patch commit, what was the choosen solution on
this issue? (grep WIDEST on config/mips return no result)

Thanks in advance,

Laurent

On Wed, 2007-10-10 at 13:05 -0400, Geert Bosch wrote:
> On Oct 10, 2007, at 08:25, Richard Sandiford wrote:
> > Your reply seems to be about why it's useful to have a macro that
> > provides the widest efficient floating-point type.  For avoidance
> > of doubt, I can certainly appreciate that such a thing is useful.
> > I'm just not sure why it's needed for correctness.  Olivier said:
> ...
> > I was trying to understand why the runtime library raises a constraint
> > error.  Is it simply that the library only supports software floating
> > point for single and double precision (but supports hardware floating
> > point for wider types)?  Is it not possible to construct a version  
> > of the
> > Ada test above that forces the use of the equivalent of C "long  
> > double"?
> > If so, would that fail in the same way, or don't we care?
> As I'm travelling tomorrow, and don't have easy access to
> a MIPS system right now, I won't have enough time
> today to debug this issue in detail before next week.
> 
> There's one of two possibilities:
>    - the GNAT run time doesn't handle 128-bit float properly
>    - the 128-bit float doesn't have sane numerical semantics
> 
> As we haven't yet ported GNAT to a system with 128-bit hardware
> floating point, it is very possible that some adaptations are
> necessary. In fact, that's certainly the case.
> 
> >> From a MIPS perspective, it's also counterintuitive for
> > WIDEST_HARDWARE_FP_SIZE to be 64 even for -msingle-float
> > and -msoft-float targets (rather than 32 and 0 respectively).
> > I can understand that 0 and 32 would be wrong given the way
> > the macro is used in ada/targtyps.c, but it seems that Ada is
> > using this macro for correctness -- and even to control an aspect
> > of the API and ABI -- whereas libgcc2.c is using it for optimisation.
> 
> I definitely would be reasonable to set this to 32 and 0
> for -msingle-float and -msoft-float targets. Yes, that would
> mean we'd have to change targtypes.c, but that's fine.
> Especially with -msingle-float this would seem a clear improvement.
> > It seems on the fact of it (to a non-Ada expert, of course) that  
> > given:
> > get_target_long_double_size really ought to be using something called
> > ADA_LONG_DOUBLE_TYPE_SIZE, given that it isn't always the same as
> > LONG_DOUBLE_TYPE_SIZE.
> 
> Yes, there definitely is room for improvement here.
> It's on my to do list.
> 
>    -Geert
> 

Re: [PATCH] define WIDEST_HARDWARE_FP_SIZE on mips

[Richard Sandiford]

Laurent GUERBY <laurent@guerby.net> writes:
> I did not see Olivier patch commit, what was the choosen solution on
> this issue? (grep WIDEST on config/mips return no result)

Right.  This probably isn't what you want to hear, but you
successfully found the last message on the issue. ;)

The open question (to me) is why Olivier's original testcase failed
with 128-bit long double.  I'm not sure anyone has really explained that.
If you're in a position to debug the failing tests and figure out what's
going wrong, that'd be a big help.

Richard

Re: [PATCH] define WIDEST_HARDWARE_FP_SIZE on mips

[Laurent GUERBY]

On Mon, 2009-03-02 at 20:09 +0000, Richard Sandiford wrote:
> Laurent GUERBY <laurent@guerby.net> writes:
> > I did not see Olivier patch commit, what was the choosen solution on
> > this issue? (grep WIDEST on config/mips return no result)
> 
> Right.  This probably isn't what you want to hear, but you
> successfully found the last message on the issue. ;)
> 
> The open question (to me) is why Olivier's original testcase failed
> with 128-bit long double.  

I don't know either.

> I'm not sure anyone has really explained that.
> If you're in a position to debug the failing tests and figure out what's
> going wrong, that'd be a big help.

I'm waiting a bit to see if AdaCore people did find a solution, if not
I'll investigate. As discussed in the old thread we don't really
want 128 bit Long_Long_Float anyway if not supported in hardware.

For reference, below ACATS log extract of the failing tests,
some of it is self-explanatory. To me most of the stuff seem
to be that 128 bit float software routines might just not be accurate
enough.

Laurent

,.,. CXG2001 ACATS 2.5 09-03-01 18:13:30
---- CXG2001 Check the attributes Model_Mantissa, Machine_Mantissa,
                Machine_Radix, and Machine_Rounds.
   - CXG2001 checking Standard.Float.
   - CXG2001 checking a digits 18 floating point type.
   * CXG2001 'Machine_Mantissa incorrectly reports 64.
   - CXG2001 computed Machine_Mantissa is 113.
   - CXG2001 computed Radix is 2.
   - CXG2001 computed Rounds is TRUE.
**** CXG2001 FAILED ****************************.

,.,. CXG2002 ACATS 2.5 09-03-01 18:13:42
---- CXG2002 Check the accuracy of the complex modulus function.
   * CXG2002 Constraint_Error raised in test 1.
   * CXG2002 Constraint_Error raised in test 2.
   * CXG2002 test 8 -- abs(1 + 1*i) actual:  1.41421356237309515E+00
                expected:  1.41421356237309505E+00 difference:
                -9.67108337857069955E-17 max_err:
                4.59988025005012224E-19.
**** CXG2002 FAILED ****************************.

,.,. CXG2003 ACATS 2.5 09-03-01 18:13:53
---- CXG2003 Check the accuracy of the sqrt function.
   * CXG2003 Constraint_Error raised in test 1.
   * CXG2003 test 6 -- sqrt(pi**2) actual:  3.14159265358979312E+00
                expected:  3.14159265358979324E+00 difference:
                -1.22514845490862001E-16 mre: 6.81224316017310918E-19.
   * CXG2003 test 7 - 1 of argument range actual: 
                7.07351888193769041E-01 expected: 
                7.07351888193768995E-01 difference: 
                4.58672105485885784E-17 mre: 3.25260651745651330E-19.
   * CXG2003 test 7 - 2 of argument range actual: 
                7.07597080163328007E-01 expected: 
                7.07597080163328052E-01 difference:
                -4.44642067116732454E-17 mre: 3.25260651745651330E-19.
...
   * CXG2003 test 7 - 999 of argument range actual: 
                9.99653486459409324E-01 expected: 
                9.99653486459409304E-01 difference: 
                1.99762544557940621E-17 mre: 3.25260651745651330E-19.
**** CXG2003 FAILED ****************************.


,.,. CXG2004 ACATS 2.5 09-03-01 18:14:07
---- CXG2004 Check the accuracy of the sin and cos functions.
   * CXG2004 test 2 cos(r) actual:  8.66025403784438597E-01 expected: 
                8.66025403784438647E-01 difference:
                -5.01985605860788553E-17 mre: 3.39452824996011974E-19.
   * CXG2004 test 2 cos(d,360) actual:  8.66025403784438708E-01
                expected:  8.66025403784438647E-01 difference: 
                6.08237418764367987E-17 mre: 3.25260651745651330E-19.
...
   * CXG2004 cos test of range7pi..7.5pi 1 actual:
                -9.99998766299703523E-01 expected:
                -9.99998766299703532E-01 difference: 
                8.77794598400815491E-18 mre: 6.50521303491302660E-19.
**** CXG2004 FAILED ****************************.

,.,. CXG2006 ACATS 2.5 09-03-01 18:14:34
---- CXG2006 Check the accuracy of the complex argument function.
   * CXG2006 test 5 argument(z) actual:  7.85398163397448279E-01
                expected:  7.85398163397448310E-01 difference:
                -3.06287113727155003E-17 mre: 5.42101086242752217E-19.
   * CXG2006 test 5 argument(z, 360) actual:  NaN********************
                expected:  4.50000000000000000E+01 difference:
                -1.75489589358094425E-15 mre: 2.43945488809238498E-17.
   * CXG2006 test 6 argument(z) actual: -7.85398163397448279E-01
                expected: -7.85398163397448310E-01 difference: 
                3.06287113727155003E-17 mre: 5.42101086242752217E-19.
...
   * CXG2006 test 16 argument(z, 360) actual:  NaN********************
                expected:  4.50000000000000000E+01 difference:
                -1.75489589358094425E-15 mre: 2.43945488809238498E-17.
**** CXG2006 FAILED ****************************.


,.,. CXG2007 ACATS 2.5 09-03-01 18:14:43
---- CXG2007 Check the accuracy of the Compose_From_Polar function.
   * CXG2007 test 5 compose_from_polar(m,r) real part actual: 
                1.00000000000000007E+00 expected: 
                1.00000000000000000E+00 difference: 
                6.83312867691599753E-17 max err:
                4.78589993413988738E-19.
   * CXG2007 test 5 compose_from_polar(m,r) imaginary part actual: 
                NaN******************** expected: 
                1.00000000000000000E+00 difference:
                -8.86779590992175306E-17 max err:
                4.78589993413988738E-19.
...
   * CXG2007 test 13 compose_from_polar(m,r) imaginary part actual:
                -1.22464679914735321E-16 expected: 
                0.00000000000000000E+00 difference:
                -1.22464679914735321E-16 max err:
                3.25260651745651330E-19.
**** CXG2007 FAILED ****************************.


,.,. CXG2010 ACATS 2.5 09-03-01 18:15:34
---- CXG2010 Check the accuracy of the exp function.
   * CXG2010 test 1 -- exp(1) actual:  2.71828182845904509E+00 expected:
                2.71828182845904524E+00 difference:
                -1.44632569809566291E-16 max err:
                1.17886682553726646E-18.
   * CXG2010 test 2 -- exp(16)*exp(-16) actual:  NaN********************
                expected:  1.00000000000000000E+00 difference:
                -4.26077577691081888E-17 max err:
                9.75781955236953991E-19.
   * CXG2010 test 3 -- exp(pi)*exp(-pi) actual:  1.00000000000000009E+00
                expected:  1.00000000000000000E+00 difference: 
                9.45809280458914814E-17 max err:
                9.75781955236953991E-19.
   * CXG2010 test 5 - 1 exp ( 7.07399674405360929E-01) actual: 
                1.90579581958160982E+00 expected: 
                1.90579581958160995E+00 difference:
                -1.27605390973616066E-16 max err:
                1.85964117111375656E-18.
   * CXG2010 test 6 - 1 exp ( 1.00041421356237310E+00) actual: 
                1.63313144965398116E-01 expected: 
                1.63313144965398124E-01 difference:
                -7.92625949448227974E-18 max err:
                9.75781955236953991E-19.
**** CXG2010 FAILED ****************************.

,.,. CXG2011 ACATS 2.5 09-03-01 18:15:49
---- CXG2011 Check the accuracy of the log function.
   * CXG2011 special value test 2 -- log(10) actual: 
                2.30258509299404590E+00 expected: 
                2.30258509299404568E+00 difference: 
                2.17057274931597988E-16 max err:
                9.98587104062752634E-19.
   * CXG2011 special value test 3 -- log(2) actual: 
                6.93147180559945286E-01 expected: 
                6.93147180559945309E-01 difference:
                -2.32019264911897949E-17 max err:
                4.33680868994201774E-19.
   * CXG2011 Taylor Series Test - 1 log ( NaN********************)
                actual:  0.00000000000000000E+00 expected:
                -5.41016884070266718E-18 difference: 
                5.41016884070266718E-18 max err:
                4.33680868994201774E-19.
   * CXG2011 Log Difference Identity - 1 log ( 7.07337174405360929E-01) 
                actual: -3.46247818134755969E-01 expected:
                -3.46247818134756011E-01 difference: 
                4.16333634234433703E-17 max err:
                4.33680868994201774E-19.
   * CXG2011 Log Product Identity - 3 log ( 1.66720000000000000E+01)
                actual:  5.62746133114191238E+00 expected: 
                5.62746133114191327E+00 difference:
                -8.88178419700125232E-16 max err:
                2.44052232032089241E-18.
   - CXG2011 log accuracy checked to 19 digits.
   * CXG2011 Log 10 Test - 1 log ( 3.16811538250821076E-01) actual:
                -4.99199009824301543E-01 expected:
                -4.99199009824301555E-01 difference: 
                1.19424763420159907E-17 max err:
                1.00000000000000000E-17.
**** CXG2011 FAILED ****************************.

,.,. CXG2012 ACATS 2.5 09-03-01 18:16:07
---- CXG2012 Check the accuracy of the ** operator.
   * CXG2012 2.0**0.5 actual:  1.41421356237309515E+00 expected: 
                1.41421356237309505E+00 difference: 
                9.67108337857069955E-17 max err:
                6.14977988562014017E-19.
   * CXG2012 Small range 1:  2.50500250000000000E-01 ** 1.5 actual: 
                1.25375375124999986E-01 expected: 
                1.25375375125000000E-01 difference:
                -1.37943128031281503E-17 max err:
                5.50895164585519003E-19.
   * CXG2012 Constraint_Error raised in Large Range Test 1A.
**** CXG2012 FAILED ****************************.


,.,. CXG2013 ACATS 2.5 09-03-01 18:16:18
---- CXG2013 Check the accuracy of the TAN and COT functions.
   * CXG2013 Tan_Test  1: tan(-7.83828936297753108E-01)  actual:
                -9.96866460463681214E-01 expected:
                -9.96866460463681237E-01 difference: 
                2.31224177246244545E-17 max err:
                1.04699823566755141E-18.
   * CXG2013 Tan_Test  1: tan( 2.74967818544091668E+00)  actual:
                -4.13294628883120685E-01 expected:
                -4.13294628883120678E-01 difference:
                -6.68811748865798892E-18 max err:
                1.04699823566755141E-18.
   * CXG2013 Cot_Test  1: cot( 1.88503405350886070E+01)  actual: 
                1.27451252274449186E+03 expected: 
                1.27451252274449192E+03 difference:
                -5.91541099664025638E-14 max err:
                1.33441236264968302E-15.
**** CXG2013 FAILED ****************************.

,.,. CXG2014 ACATS 2.5 09-03-01 18:16:32
---- CXG2014 Check the accuracy of the SINH and COSH functions.
   * CXG2014 sinh(1) actual:  NaN******************** expected: 
                1.17520119364380146E+00 difference:
                -4.25201193643801824E-01 max err:
                1.01932454980493402E-18.
   * CXG2014 cosh(1) actual:  NaN******************** expected: 
                1.54308063481524378E+00 difference:
                -2.93080634815243999E-01 max err:
                1.33840910126959889E-18.
   * CXG2014 sinh(2) actual:  NaN******************** expected: 
                3.62686040784701877E+00 difference: 
                3.10639592152978846E-01 max err:
                3.14579994679152032E-18.
   * CXG2014 cosh(2) actual:  NaN******************** expected: 
                3.76219569108363146E+00 difference: 
                3.00304308916366227E-01 max err:
                3.26318459327078156E-18.
   * CXG2014 sinh(-1) actual: NaN******************** expected:
                -1.17520119364380146E+00 difference: 
                4.25201193643801824E-01 max err:
                1.01932454980493402E-18.

raised CONSTRAINT_ERROR : s-imgrea.adb:319 explicit raise
(=> this one might be similar to Olivier original testcase)

,.,. CXG2015 ACATS 2.5 09-03-01 18:17:15
---- CXG2015 Check the accuracy of the ARCSIN and ARCCOS functions.
   * CXG2015 test 1 arcsin( 5.00000000000000000E-01) actual: 
                5.23598775598298927E-01 expected: 
                5.23598775598298873E-01 difference: 
                5.36137974294081943E-17 max err:
                5.42101086242752217E-19.
...
   * CXG2015 test 6 arccos(-7.07106781186547524E-01, 360) actual: 
                NaN******************** expected: 
                1.35000000000000000E+02 difference:
                -1.75489589358094425E-15 max err:
                7.31836466427715493E-17.
   * CXG2015 Taylor Series test 1: arcsin(-1.24750000000000000E-01) 
                actual: -1.25075858849556772E-01 expected:
                -1.25075858849556770E-01 difference:
                -1.99800906676059108E-18 max err:
                4.33680868994201774E-19.
   * CXG2015 Taylor Series test 1: arccos(-1.24750000000000000E-01) 
                actual:  1.69587218564445339E+00 expected: 
                1.69587218564445341E+00 difference:
                -2.00363883857575575E-17 max err:
                7.35467323173382830E-19.
**** CXG2015 FAILED ****************************.

,.,. CXG2016 ACATS 2.5 09-03-01 18:17:29
---- CXG2016 Check the accuracy of the ARCTAN function.
   * CXG2016 special value test 2 arctan( 5.77350269189625765E-01)
                actual:  5.23598775598298816E-01 expected: 
                5.23598775598298873E-01 difference:
                -5.74085050331074598E-17 max err:
                6.23416249179165050E-19.
   * CXG2016 special value test 2 arctan( 5.77350269189625765E-01,
                cycle=>360) actual:  NaN******************** expected:  
                3.00000000000000000E+01 difference:
                -3.29030038336297394E-15 max err:
                1.87024874753749515E-17.
   * CXG2016 special value test 3 arctan( 1.73205080756887729E+00)
                actual:  1.04719755119659780E+00 expected: 
                1.04719755119659775E+00 difference: 
                5.74627151417317350E-17 max err:
                5.96071276515147053E-19.
   * CXG2016 special value test 3 arctan( 1.73205080756887729E+00,
                cycle=>360) actual:  6.00000000000000033E+01 expected:  
                6.00000000000000000E+01 difference: 
                3.29030038336297394E-15 max err:
                3.41523684332933897E-17.
   * CXG2016 Taylor_Series_Test  0: arctan(-6.25000000000000000E-02) 
                actual: -6.24188099959573500E-02 expected:
                -6.24188099959573485E-02 difference:
                -1.54907493670945532E-18 max err:
                6.50521303491302660E-19.
**** CXG2016 FAILED ****************************.

,.,. CXG2017 ACATS 2.5 09-03-01 18:17:37
---- CXG2017 Check the accuracy of the TANH function.
   * CXG2017 tanh(1) actual:  7.61594155955764851E-01 expected: 
                7.61594155955764888E-01 difference:
                -3.70797142990042516E-17 max err:
                6.60577630751603494E-19.
   * CXG2017 tanh(2) actual:  9.64027580075816903E-01 expected: 
                9.64027580075816884E-01 difference: 
                1.94072188874905294E-17 max err:
                8.36160637323315404E-19.
**** CXG2017 FAILED ****************************.

,.,. CXG2018 ACATS 2.5 09-03-01 18:17:52
---- CXG2018 Check the accuracy of the complex EXP function.
   * CXG2018 exp(1+0i) real part actual:  2.71828182845904509E+00
                expected:  2.71828182845904524E+00 difference:
                -1.44632569809566291E-16 max err:
                2.06301694469021630E-18.
   * CXG2018 exp(pi/2*i) real part actual:  1.00000000000000006E+00
                expected:  1.00000000000000000E+00 difference: 
                6.12323399573676604E-17 max err:
                3.90312782094781596E-19.
...
   * CXG2018 Identity_2_Test  1 1: Exp(( 1.63875000000000000E+00, 
                1.63875000000000000E+00))  real part actual: 
                1.00000000000000005E+00 expected: 
                1.00000000000000000E+00 difference: 
                4.92758729287547301E-17 max err:
                2.16840434497100887E-18.
**** CXG2018 FAILED ****************************.

,.,. CXG2019 ACATS 2.5 09-03-01 18:18:10
---- CXG2019 Check the accuracy of the complex LOG function.
   * CXG2019 Identity_1_Test  1 1: Log(( 2.08000000000000000E+00, 
                1.00000000000000000E-01))  real part actual: 
                7.33522255402499934E-01 expected: 
                7.33522255402499823E-01 difference: 
                1.11022302462515654E-16 max err:
                2.81892564846231153E-18.
   * CXG2019 Identity_1_Test  1 1: Log(( 1.01000000000000000E+03,
                -3.97000000000000000E+03))  imaginary part actual:
                -1.32167322321704454E+00 expected:
                -1.32167322321704456E+00 difference: 
                2.77555756156289135E-17 max err:
                3.72569854781238076E-18.
   * CXG2019 Identity_1_Test  1 23: Log(( 2.50000000000000011E-03,
                -1.92500000000000000E-01))  real part actual:
                -1.64757480111209631E+00 expected:
                -1.64757480111209653E+00 difference: 
                2.22044604925031308E-16 max err:
                4.64439086461508066E-18.
**** CXG2019 FAILED ****************************.


,.,. CXG2020 ACATS 2.5 09-03-01 18:18:30
---- CXG2020 Check the accuracy of the complex SQRT function.
   * CXG2020 sqrt(-2)+1  imaginary part actual:  1.41421356237309515E+00
                expected:  1.41421356237309505E+00 difference: 
                9.67108337857069955E-17 max err:
                9.19976050010024449E-19.
   * CXG2020 Identity_1_Test  1 1: Sqrt(( 0.00000000000000000E+00, 
                2.00000000000000000E-02))  real part actual: 
                1.00000000000000006E-01 expected: 
                1.00000000000000000E-01 difference: 
                5.55111520584384396E-18 max err:
                9.21571846612678769E-19.
   * CXG2020 Identity_1_Test  1 1: Sqrt(( 0.00000000000000000E+00, 
                2.00000000000000000E-02))  imaginary part actual: 
                1.00000000000000006E-01 expected: 
                1.00000000000000000E-01 difference: 
                5.55111520584384396E-18 max err:
                9.21571846612678769E-19.
**** CXG2020 FAILED ****************************.

,.,. CXG2021 ACATS 2.5 09-03-01 18:18:49
---- CXG2021 Check the accuracy of the complex SIN and COS functions.
   * CXG2021 cos(pi/2+0i) real part actual:  6.12323399573676604E-17
                expected:  0.00000000000000000E+00 difference: 
                6.12323399573676604E-17 max err: 1.30104260698260532E-18
                efactor: 0.00000000000000000E+00.
   * CXG2021 Identity_1_Test  0 0: Sin(( 6.25000000000000000E-02, 
                6.25000000000000000E-02))  real part actual: 
                6.24593178423802006E-02 expected: 
                6.25813484132769356E-02 difference:
                -1.22030570896734958E-04 max err:
                1.34189725732436773E-18 efactor:
                1.06258389154469496E+00.
...   
   * CXG2021 Identity_2_Test  0 0: Cos(( 1.60000000000000000E+01, 
                1.60000000000000000E+01))  imaginary part actual: 
                1.20755403270153316E+06 expected: 
                1.28543457665469979E+06 difference:
                -7.78805439531666307E+04 max err:
                3.06608190217967514E-12 efactor:
                1.28543943055171073E+06.
**** CXG2021 FAILED ****************************.

,.,. CXG2024 ACATS 2.5 09-03-01 18:19:11
---- CXG2024 Check the accuracy of multiplication and division of mixed 
                decimal and binary fixed point numbers.
   * CXG2024 11 - expected -51.00  got -50.0.
   * CXG2024 12 - expected 51.00  got  50.0.
**** CXG2024 FAILED ****************************.

Re: [PATCH] define WIDEST_HARDWARE_FP_SIZE on mips

[Geert Bosch]

On Mar 2, 2009, at 16:46, Laurent GUERBY wrote:
> I'm waiting a bit to see if AdaCore people did find a solution, if not
> I'll investigate. As discussed in the old thread we don't really
> want 128 bit Long_Long_Float anyway if not supported in hardware.
>
> For reference, below ACATS log extract of the failing tests,
> some of it is self-explanatory. To me most of the stuff seem
> to be that 128 bit float software routines might just not be accurate
> enough.

The Ada standard requires support for the widest hardware floating point
format provided by the hardware. This type can be accessed by declaring
your type as "type My_Float is digits System.Max_Digits". Various  
routines
for printing and type conversions use this type as well.

Ada does not allow a "type My_Float is digits X" where X >  
System.Max_Digits,
except in some special cases where the type would provide more  
accuracy but
a restricted range. For that reason, we can't easily support a 128-bit
Long_Long_Float.

The way forward would be to dynamically build a table of all available  
types,
find out essential properties (basic arithmetic supported in hardware  
or not,
implicit extra precision (a la x87) or not, fused multiply-add or not)  
and
use that for type selection. Some work in this direction has been done  
in Gigi,
but to add support for all parts of the compiler, especially the  
required
exact static (compile-time) evaluation of expressions and such, is quite
hard and involves a serious chunk of development work.

So, even if "long long double" is 128 bits, Long_Long_Float not be wider
than WIDEST_HARDWARE_FP_SIZE.
   -Geert

Re: [PATCH] define WIDEST_HARDWARE_FP_SIZE on mips

[Laurent GUERBY]

Hi,

So for now the best way would be to define WIDEST_HARDWARE_FP_SIZE
on mips like it's done on other platforms? That is
commit Olivier original patch?

Richard would such a patch be approved? I'll do the testing.

Laurent

2007-10-08  Olivier Hainque  <hainque@adacore.com>

	* config/mips/mips.h (WIDEST_HARDWARE_FP_SIZE): Define.

Index: config/mips/mips.h
===================================================================
*** config/mips/mips.h	(revision 128810)
--- config/mips/mips.h	(working copy)
*************** extern enum mips_code_readable_setting m
*** 1178,1183 ****
--- 1178,1184 ----
  
  /* For MIPS, width of a floating point register.  */
  #define UNITS_PER_FPREG (TARGET_FLOAT64 ? 8 : 4)
+ #define WIDEST_HARDWARE_FP_SIZE 64
  
  /* The number of consecutive floating-point registers needed to store the
     largest format supported by the FPU.  */


gcc/config$ grep WIDEST_HARDWARE_FP_SIZE */*
alpha/alpha.h:#define WIDEST_HARDWARE_FP_SIZE 64
i386/i386.h:#define WIDEST_HARDWARE_FP_SIZE LONG_DOUBLE_TYPE_SIZE
pa/pa.h:#define WIDEST_HARDWARE_FP_SIZE 64
rs6000/rs6000.h:#define WIDEST_HARDWARE_FP_SIZE 64
s390/s390.h:#define WIDEST_HARDWARE_FP_SIZE 64
sparc/sparc.h:#define WIDEST_HARDWARE_FP_SIZE 64
gcc/config$ grep LONG_DOUBLE_TYPE_SIZE i386/*
i386/i386.h:#define LONG_DOUBLE_TYPE_SIZE 80
i386/i386.h:#define WIDEST_HARDWARE_FP_SIZE LONG_DOUBLE_TYPE_SIZE


On Tue, 2009-03-03 at 00:16 -0500, Geert Bosch wrote:
> On Mar 2, 2009, at 16:46, Laurent GUERBY wrote:
> > I'm waiting a bit to see if AdaCore people did find a solution, if not
> > I'll investigate. As discussed in the old thread we don't really
> > want 128 bit Long_Long_Float anyway if not supported in hardware.
> >
> > For reference, below ACATS log extract of the failing tests,
> > some of it is self-explanatory. To me most of the stuff seem
> > to be that 128 bit float software routines might just not be accurate
> > enough.
> 
> The Ada standard requires support for the widest hardware floating point
> format provided by the hardware. This type can be accessed by declaring
> your type as "type My_Float is digits System.Max_Digits". Various  
> routines
> for printing and type conversions use this type as well.
> 
> Ada does not allow a "type My_Float is digits X" where X >  
> System.Max_Digits,
> except in some special cases where the type would provide more  
> accuracy but
> a restricted range. For that reason, we can't easily support a 128-bit
> Long_Long_Float.
> 
> The way forward would be to dynamically build a table of all available  
> types,
> find out essential properties (basic arithmetic supported in hardware  
> or not,
> implicit extra precision (a la x87) or not, fused multiply-add or not)  
> and
> use that for type selection. Some work in this direction has been done  
> in Gigi,
> but to add support for all parts of the compiler, especially the  
> required
> exact static (compile-time) evaluation of expressions and such, is quite
> hard and involves a serious chunk of development work.
> 
> So, even if "long long double" is 128 bits, Long_Long_Float not be wider
> than WIDEST_HARDWARE_FP_SIZE.
>    -Geert
> 

Re: [PATCH] define WIDEST_HARDWARE_FP_SIZE on mips

[Richard Sandiford]

Laurent GUERBY <laurent@guerby.net> writes:
> So for now the best way would be to define WIDEST_HARDWARE_FP_SIZE
> on mips like it's done on other platforms? That is
> commit Olivier original patch?
>
> Richard would such a patch be approved? I'll do the testing.

Sorry, but no.  What I said in the original review still applies:

  http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00553.html

In other words:

  (a) this macro is used for two things:

      - an optimisation decision in libgcc2.c
      - a language conformance and ABI decision in ada/.

  (b) the natural definition of the macro is:

        #define WIDEST_HARDWARE_FP_SIZE \
          (UNITS_PER_HWFPVALUE * BITS_PER_UNIT)

      but this is presumably _not_ correct for Ada.  For -msingle-float,
      it would make Long_Long_Float (WIDEST_HARDWARE_FP_SIZE) smaller
      than Long_Float (DOUBLE_TYPE_SIZE), which certainly isn't right!
      And I shudder to think what would happen to Ada if we set
      WIDEST_HARDWARE_FP_SIZE to 0 for soft-float targets.

My point in that mesasge is that we're having to set WIDEST_HARDWARE_FP_SIZE
to a non-obvious value because it is argued that doing so is correct for Ada.
But IMO, if Ada's get_target_float_size, get_target_double_size and
get_target_long_double_size need to pick something different from
the C "float", "double" and "long double" types, they should have
specific macros to do that.

And I don't think we should commit anything until we know what the
correct behaviour for -msingle-float and -msoft-float is.  I'm not
sure anyone has said conclusively what they think that should be.
Geert said:

  The Ada standard requires support for the widest hardware floating point
  format provided by the hardware. This type can be accessed by declaring
  your type as "type My_Float is digits System.Max_Digits". Various  
  routines for printing and type conversions use this type as well.

  Ada does not allow a "type My_Float is digits X" where X >  
  System.Max_Digits, [...]

so how does that apply to systems that don't have hardware floating point?

(I'm somewhat surprised no "as-if" rule applies here.  Is software FP,
or running programs under a system emulator or application translator,
really not allowed?)

Richard

Re: [PATCH] define WIDEST_HARDWARE_FP_SIZE on mips

[Laurent GUERBY]

On Wed, 2009-03-04 at 20:24 +0000, Richard Sandiford wrote:
> (I'm somewhat surprised no "as-if" rule applies here.  Is software FP,
> or running programs under a system emulator or application translator,
> really not allowed?)

It's obviously allowed as long as the software routines are
implemented to the correct precision, which seems not the
case for 128 bits mips one if one believe the ACATS testsuite results
for the Numerics annex (cxgxxx), eg:

,.,. CXG2010 ACATS 2.5 09-03-01 18:15:34
---- CXG2010 Check the accuracy of the exp function.
   * CXG2010 test 1 -- exp(1) actual:  2.71828182845904509E+00 expected:
                2.71828182845904524E+00 difference:
                -1.44632569809566291E-16 max err:
                1.17886682553726646E-18.

If we check:

$ bc -l
scale = 18
e (1)
2.718281828459045235
Ada expects:
2.71828182845904524
which seems coherent with bc
128 bit mips soft fp seems to return:
2.71828182845904509
which seems wrong in the two last digits. Now I don't know
who provides the 128 bits soft FP code, and there
may be something wrong before we reach such code.

Then an Ada implementation has no obligation to provide 128 bits
Long_Long_Float, the RM only says:

                         Implementation Requirements

14    {Float} In an implementation that supports floating point types with 6
or more digits of precision, the requested decimal precision for Float shall
be at least 6.

15    {Long_Float} If Long_Float is predefined for an implementation, then its
requested decimal precision shall be at least 11.
...
                         Implementation Permissions

16    {Short_Float} {Long_Float} An implementation is allowed to provide
additional predefined floating point types[, declared in the visible part of
Standard], whose (unconstrained) first subtypes have names of the form
Short_Float, Long_Float, Short_Short_Float, Long_Long_Float, etc. Different
predefined floating point types are allowed to have the same base decimal
precision. However, the precision of Float should be no greater than that of
Long_Float. Similarly, the precision of Short_Float (if provided) should be no
greater than Float. Corresponding recommendations apply to any other
predefined floating point types. There need not be a named floating point type
corresponding to each distinct base decimal precision supported by an
implementation.

    16.a  Implementation defined: The predefined floating point types declared
          in Standard.


                            Implementation Advice

17    {Long_Float} An implementation should support Long_Float in addition to
Float if the target machine supports 11 or more digits of precision. No other
named floating point subtypes are recommended for package Standard. Instead,
appropriate named floating point subtypes should be provided in the library
package Interfaces (see B.2).

Now it's not unreasonable for an implementor to say that Long_Long_Float
is defined on all platforms and maps to the widest float implemented
in hardware.

Laurent

Re: [PATCH] define WIDEST_HARDWARE_FP_SIZE on mips

[Richard Sandiford]

Laurent GUERBY <laurent@guerby.net> writes:
> On Wed, 2009-03-04 at 20:24 +0000, Richard Sandiford wrote:
>> (I'm somewhat surprised no "as-if" rule applies here.  Is software FP,
>> or running programs under a system emulator or application translator,
>> really not allowed?)
>
> It's obviously allowed as long as the software routines are
> implemented to the correct precision, which seems not the
> case for 128 bits mips one if one believe the ACATS testsuite results
> for the Numerics annex (cxgxxx), eg:
>
> ,.,. CXG2010 ACATS 2.5 09-03-01 18:15:34
> ---- CXG2010 Check the accuracy of the exp function.
>    * CXG2010 test 1 -- exp(1) actual:  2.71828182845904509E+00 expected:
>                 2.71828182845904524E+00 difference:
>                 -1.44632569809566291E-16 max err:
>                 1.17886682553726646E-18.
>
> If we check:
>
> $ bc -l
> scale = 18
> e (1)
> 2.718281828459045235
> Ada expects:
> 2.71828182845904524
> which seems coherent with bc
> 128 bit mips soft fp seems to return:
> 2.71828182845904509

Thanks.  FWIW, this was exactly the kind of info I was hoping for.
(So far I've only seen reports of the form "this test fails for 128
bits, but passes if we change long double to 64 bits".  That's not
too surprisingly in itself really ;))

I think the next question is: is this a bug?  If so, is it a bug in
the Ada frontend, libada, the rest of gcc, or glibc?

> Now I don't know who provides the 128 bits soft FP code, and there may
> be something wrong before we reach such code.

libgcc and glibc provide the core 128-bit routines.  I don't claim to
know how Ada uses them though.

> Then an Ada implementation has no obligation to provide 128 bits
> Long_Long_Float,

Sure, I was never disputing that.  It just seems reasonable to assume
that, if the system defines C "long double" to be 128 bits, and goes
to the trouble to provide support for it, we should at least try to
figure out why it doesn't work for Ada before giving up and dropping
down to 64.

I can understand Olivier wanting to change it for IRIX, because IRIX
uses a paired-double representation.  I can well imagine that the
numerical properties of paired doubles aren't good enough for Ada.
But GNU/Linux uses a normal sign/exponent/significand representation.

Richard

Re: [PATCH] define WIDEST_HARDWARE_FP_SIZE on mips

[Joseph S. Myers]

On Wed, 4 Mar 2009, Laurent GUERBY wrote:

> $ bc -l
> scale = 18
> e (1)
> 2.718281828459045235
> Ada expects:
> 2.71828182845904524
> which seems coherent with bc
> 128 bit mips soft fp seems to return:
> 2.71828182845904509
> which seems wrong in the two last digits. Now I don't know
> who provides the 128 bits soft FP code, and there
> may be something wrong before we reach such code.

An obvious question would be whether you have a recent enough glibc 
version (2.5-ish or later) to provide 128-bit long double versions, and 
whether the libm function expl (rather than exp) is indeed being called.  
Also, if you do not have my patch

2007-05-23  Joseph Myers  <joseph@codesourcery.com>

        * sysdeps/mips/mips64/n32/Implies: Add mips/mips64/soft-fp.
        * sysdeps/mips/mips64/n64/Implies: Likewise.
        * sysdeps/mips/mips64/soft-fp/Makefile: New.
        * sysdeps/mips/mips64/soft-fp/e_sqrtl.c: New.
        * sysdeps/mips/mips64/soft-fp/sfp-machine.h: Include <fenv.h> and
        <fpu_control.h>.  Use hardware exception and rounding mode
        settings.

to provide sqrtl, this will affect several other functions that use sqrtl 
internally.

The only glibc math tests I see failing on MIPS64 for long double are 
tests for exceptions and rounding modes (the software floating-point long 
double does not support exceptions or rounding modes).  The tests do cover 
expl (1), so there is no unusual error in the result of that calculation.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH] define WIDEST_HARDWARE_FP_SIZE on mips

[Laurent GUERBY]

On Wed, 2009-03-04 at 23:19 +0000, Joseph S. Myers wrote:
> On Wed, 4 Mar 2009, Laurent GUERBY wrote:
> 
> > $ bc -l
> > scale = 18
> > e (1)
> > 2.718281828459045235
> > Ada expects:
> > 2.71828182845904524
> > which seems coherent with bc
> > 128 bit mips soft fp seems to return:
> > 2.71828182845904509
> > which seems wrong in the two last digits. Now I don't know
> > who provides the 128 bits soft FP code, and there
> > may be something wrong before we reach such code.
> 
> An obvious question would be whether you have a recent enough glibc 
> version (2.5-ish or later) to provide 128-bit long double versions, and 
> whether the libm function expl (rather than exp) is indeed being called.  
> Also, if you do not have my patch

I checked and GLIBC is 2.7-18 (debian) and the Ada RTS as currently
configured calls the C "exp" with a 64 bits args and results and not the
needed "expl" with 128 bits args which explains the cxg results.

I will do an experiment with a specific gcc/ada/a-numaux-longdouble.ads
when abi=64 and report what ACATS says but since the current GNAT will
call the same set of functions for all FP types it won't go into
production :).

Thanks for your help on this issue,

Laurent

Re: [PATCH] define WIDEST_HARDWARE_FP_SIZE on mips

[Geert Bosch]

On Mar 4, 2009, at 18:54, Laurent GUERBY wrote:

> I checked and GLIBC is 2.7-18 (debian) and the Ada RTS as currently
> configured calls the C "exp" with a 64 bits args and results and not  
> the
> needed "expl" with 128 bits args which explains the cxg results.
>
> I will do an experiment with a specific gcc/ada/a-numaux- 
> longdouble.ads
> when abi=64 and report what ACATS says but since the current GNAT will
> call the same set of functions for all FP types it won't go into
> production :).
>
> Thanks for your help on this issue,

Yes, a-numaux has to go. Still, a problem when interfacing to a C math
library is that there is no widely recognized way to identify  
functions for
different types. For example, IA-64 supports 32, 64 and 80-bit float  
types
in hardware. There also is some support for emulating 128-bit float  
types.
What functions am I going to call to get accurate implementations of the
sine function for all 4 floating-point types?

   -Geert

Re: [PATCH] define WIDEST_HARDWARE_FP_SIZE on mips

[Joseph S. Myers]

On Wed, 4 Mar 2009, Geert Bosch wrote:

> Yes, a-numaux has to go. Still, a problem when interfacing to a C math
> library is that there is no widely recognized way to identify functions for
> different types. For example, IA-64 supports 32, 64 and 80-bit float types
> in hardware. There also is some support for emulating 128-bit float types.
> What functions am I going to call to get accurate implementations of the
> sine function for all 4 floating-point types?

C90 defines the functions for double; C99 adds functions for float and 
long double (whose names were reserved in C90, but the functions weren't 
required) and a lot more functions for all the types.  So for types 
matching FLOAT_TYPE_SIZE, DOUBLE_TYPE_SIZE or LONG_DOUBLE_TYPE_SIZE you 
know what functions to use (subject to per-multilib autoconf checks for 
availability of the C99 functions, as used by libgfortran and libstdc++); 
it's only types that aren't standard C types (such as __float128) for 
which the functions may not be available and don't have standard names.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH] define WIDEST_HARDWARE_FP_SIZE on mips

[Geert Bosch]

On Mar 4, 2009, at 15:24, Richard Sandiford wrote:

> Geert said:
>
>  The Ada standard requires support for the widest hardware floating  
> point
>  format provided by the hardware. This type can be accessed by  
> declaring
>  your type as "type My_Float is digits System.Max_Digits". Various
>  routines for printing and type conversions use this type as well.
>
>  Ada does not allow a "type My_Float is digits X" where X >
>  System.Max_Digits, [...]
>
> so how does that apply to systems that don't have hardware floating  
> point?

This falls outside the language standard. The only requirement is that  
if Long_Float
is predefined, it is at least 11 digits (corresponds to double  
precision).
The interesting case is indeed when single precision floating-point is  
implemented
in hardware, while double precision is emulated.

As I indicated earlier, I think WIDEST_HARDWARE_FP_SIZE should indeed  
reflect the truth
(so, should be 0 for software float, or 32 if only single precision is  
supported in HW).
For Ada, we'll then replace uses of WIDEST_HARDWARE_FP_SIZE with an  
expression that takes
the maximum of long_float_type_size and WIDEST_HARDWARE_FP_SIZE for  
the size of Long_Long_Float.

   -Geert

Re: [PATCH] define WIDEST_HARDWARE_FP_SIZE on mips

[Richard Sandiford]

Geert Bosch <bosch@adacore.com> writes:
> As I indicated earlier, I think WIDEST_HARDWARE_FP_SIZE should indeed
> reflect the truth (so, should be 0 for software float, or 32 if only
> single precision is supported in HW).

OK, thanks.

> For Ada, we'll then replace uses of WIDEST_HARDWARE_FP_SIZE with an
> expression that takes the maximum of long_float_type_size and
> WIDEST_HARDWARE_FP_SIZE for the size of Long_Long_Float.

We're then back to the idea that "long double" can only be bigger
than "double" if the support is coming from some underlying "hardware".
But both you and Laurent seem to agree that this isn't actually a language
requirement, and I don't see how it makes sense in all cases.  Many 64-bit
MIPS processors lack an FPU, but can (and do) still provide an n32 and
n64 environment that has support for 32-bit, 64-bit _and_ 128-bit long
double.  If plain 64-bit double is implemented in software, why is it
automatically wrong to use the 128-bit long double support for
Long_Long_Float?

Please consider adding a new macro instead.  Like I say, I think it's a
really bad idea to have a part of the ABI (or at least the API) depend
indirectly on a tuning macro.  I.e. something like:

#ifndef ADA_LONG_DOUBLE_TYPE_SIZE
#define ADA_LONG_DOUBLE_TYPE_SIZE LONG_DOUBLE_TYPE_SIZE
#endif

Richard

Re: [PATCH] define WIDEST_HARDWARE_FP_SIZE on mips

[Geert Bosch]

On Mar 4, 2009, at 17:19, Richard Sandiford wrote:

> Please consider adding a new macro instead.  Like I say, I think  
> it's a
> really bad idea to have a part of the ABI (or at least the API) depend
> indirectly on a tuning macro.  I.e. something like:
>
> #ifndef ADA_LONG_DOUBLE_TYPE_SIZE
> #define ADA_LONG_DOUBLE_TYPE_SIZE LONG_DOUBLE_TYPE_SIZE
> #endif

Sure, that's fine with me.

My main point is that in Ada predefined types aren't nearly used
as much as in C and C++. A *lot* of Ada code declares its own float  
types
using System.Max_Digits as precision. If on a 64-bit SPARC system we'd
have this code use horribly slow 128-bit emulated floating point,
that would be *bad*.

Still, really we should find a way to support these 128-bit types,
even if only for use in the Interface.C packages. This will need
some additional development work in the run time and compiler though
for which we have found zero interest from our users so far.

   -Geert

Re: [PATCH] define WIDEST_HARDWARE_FP_SIZE on mips

[Richard Sandiford]

Geert Bosch <bosch@adacore.com> writes:
> On Mar 4, 2009, at 17:19, Richard Sandiford wrote:
>> Please consider adding a new macro instead.  Like I say, I think  
>> it's a
>> really bad idea to have a part of the ABI (or at least the API) depend
>> indirectly on a tuning macro.  I.e. something like:
>>
>> #ifndef ADA_LONG_DOUBLE_TYPE_SIZE
>> #define ADA_LONG_DOUBLE_TYPE_SIZE LONG_DOUBLE_TYPE_SIZE
>> #endif
>
> Sure, that's fine with me.

Thanks.  That looks like the way forward then.  My personal opinion
about the 128-bit stuff doesn't really count for much; the main issue
for me was the link between the Ada type and other parts of GCC.

If we have a macro like the above, then the choice of value is
entirely down to Ada folks such as yourself.  If you think that:

#define ADA_LONG_DOUBLE_TYPE_SIZE 64

is correct for MIPS, it's preapproved from a port perspective.

(It probably seems like we took the long road here, so for the record,
I did make the same suggestion in the original thread.)

Richard

Re: [PATCH] define WIDEST_HARDWARE_FP_SIZE on mips

[Olivier Hainque]

Richard Sandiford wrote:
> The open question (to me) is why Olivier's original testcase failed
> with 128-bit long double.  I'm not sure anyone has really explained that.

 My limited understanding is basically that anything > 64 bit isn't
 supported for a bunch of reasons shared between the compiler and the
 Ada runtime library. Geert could tell much more about this and provided
 a number of extra details already.

 I also understand there's no mandate to support wide formats that
 don't correspond to hardware capabilities, and that
 WIDEST_HARDWARE_FP_SIZE was introduced for this purpose.
 
 IIRC, the original thread suggested we refine the suggested
 definition, hmm, right:

 http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00587.html

 Richard S wrote:

 << From a MIPS perspective, it's also counterintuitive for 
    WIDEST_HARDWARE_FP_SIZE to be 64 even for -msingle-float
    and -msoft-float targets (rather than 32 and 0 respectively).
    I can understand that 0 and 32 would be wrong given the way
    the macro is used in ada/targtyps.c, but it seems that Ada is
    using this macro for correctness -- and even to control an aspect
    of the API and ABI -- whereas libgcc2.c is using it for optimisation.
 >>

 Geert replied:

 << It definitely would be reasonable to set this to 32 and 0
    for -msingle-float and -msoft-float targets. Yes, that would
    mean we'd have to change targtypes.c, but that's fine.
    Especially with -msingle-float this would seem a clear improvement.
 >>

 I could interepret WIDEST_HARDWARE_FP_SIZE in slightly different manners
 so either way (constant 64 or refined variant) is fine with me.

 Geert ?

Re: [PATCH] define WIDEST_HARDWARE_FP_SIZE on mips

[Laurent GUERBY]

FWIW your mips.h patch cured the cxg failures
I observed before:

http://gcc.gnu.org/ml/gcc-testresults/2009-03/msg00388.html

I restested only abi=n32 but the result should be similar
on abi=64.

Laurent

On Tue, 2009-03-03 at 10:45 +0100, Olivier Hainque wrote:
> Richard Sandiford wrote:
> > The open question (to me) is why Olivier's original testcase failed
> > with 128-bit long double.  I'm not sure anyone has really explained that.
> 
>  My limited understanding is basically that anything > 64 bit isn't
>  supported for a bunch of reasons shared between the compiler and the
>  Ada runtime library. Geert could tell much more about this and provided
>  a number of extra details already.
> 
>  I also understand there's no mandate to support wide formats that
>  don't correspond to hardware capabilities, and that
>  WIDEST_HARDWARE_FP_SIZE was introduced for this purpose.
>  
>  IIRC, the original thread suggested we refine the suggested
>  definition, hmm, right:
> 
>  http://gcc.gnu.org/ml/gcc-patches/2007-10/msg00587.html
> 
>  Richard S wrote:
> 
>  << From a MIPS perspective, it's also counterintuitive for 
>     WIDEST_HARDWARE_FP_SIZE to be 64 even for -msingle-float
>     and -msoft-float targets (rather than 32 and 0 respectively).
>     I can understand that 0 and 32 would be wrong given the way
>     the macro is used in ada/targtyps.c, but it seems that Ada is
>     using this macro for correctness -- and even to control an aspect
>     of the API and ABI -- whereas libgcc2.c is using it for optimisation.
>  >>
> 
>  Geert replied:
> 
>  << It definitely would be reasonable to set this to 32 and 0
>     for -msingle-float and -msoft-float targets. Yes, that would
>     mean we'd have to change targtypes.c, but that's fine.
>     Especially with -msingle-float this would seem a clear improvement.
>  >>
> 
>  I could interepret WIDEST_HARDWARE_FP_SIZE in slightly different manners
>  so either way (constant 64 or refined variant) is fine with me.
> 
>  Geert ?
> 
> 
> 
> 
> 
>