On Sat, Nov 23, 2013 at 6:24 PM, Uros Bizjak wrote:
> On Sat, Nov 23, 2013 at 5:48 PM, Uros Bizjak wrote:
>
>>> Thanks for lookin at this. I am a real newcomer to 387, and it took me a
>>> long time perusing the Intel doc, as well as glibc sources, to come up with
>>> that. The “reference” impl
On Sat, Nov 23, 2013 at 5:48 PM, Uros Bizjak wrote:
>> Thanks for lookin at this. I am a real newcomer to 387, and it took me a
>> long time perusing the Intel doc, as well as glibc sources, to come up with
>> that. The “reference” implementation of these FPU functions, the one I am
>> confide
On Sat, Nov 23, 2013 at 4:30 PM, FX wrote:
> Thanks for lookin at this. I am a real newcomer to 387, and it took me a long
> time perusing the Intel doc, as well as glibc sources, to come up with that.
> The “reference” implementation of these FPU functions, the one I am confident
> in, is tha
Hi Uros!
Thanks for lookin at this. I am a real newcomer to 387, and it took me a long
time perusing the Intel doc, as well as glibc sources, to come up with that.
The “reference” implementation of these FPU functions, the one I am confident
in, is that in config/fpu-glibc.h: i.e., the function
On Nov 21 2013, Uros Bizjak wrote:
Indeed, 387/SSE has flush-to-zero modes. But other APIs do not (glibc,
SysV, AIX). I'm perfectly willing to add it, especially to 387/SSE, if
given a bit of help (someone to write the assembly code).
Just set FTZ bit in mxcsr. Please see
libgcc/config/i386/
On Nov 21 2013, FX wrote:
That's a reasonable decision, but it is actually used at least ten
times as much as everything else put together, possibly a hundred times
as much.
I believe we are in pretty different parts of the community. Around me I
rarely see it used, while people check for n
Hello!
>> However, it is used in the form of selecting hard underflow using a
>> compilation option, and not within the program. You certainly DO have
>> targets where it would work, even dynamically within the program, and I
>> think that it could be done even on x86. That isn't the same as it
On Nov 21 2013, Joseph S. Myers wrote:
On Thu, 21 Nov 2013, FX wrote:
Indeed, 387/SSE has flush-to-zero modes. But other APIs do not (glibc,
SysV, AIX).
Note that glibc libm functions may not work when called in a flush-to-zero
mode, only in modes that can be established by the functions.
On Thu, Nov 21, 2013 at 2:12 PM, N.M. Maclaren wrote:
> On Nov 21 2013, Uros Bizjak wrote:
>>>
>>>
>>> Indeed, 387/SSE has flush-to-zero modes. But other APIs do not (glibc,
>>> SysV, AIX). I'm perfectly willing to add it, especially to 387/SSE, if given
>>> a bit of help (someone to write the ass
On Thu, 21 Nov 2013, FX wrote:
> Indeed, 387/SSE has flush-to-zero modes. But other APIs do not (glibc,
> SysV, AIX).
Note that glibc libm functions may not work when called in a flush-to-zero
mode, only in modes that can be established by the functions.
If any argument to a function is subn
On Thu, Nov 21, 2013 at 1:19 PM, Uros Bizjak wrote:
>> Here’s my patch submission for adding IEEE intrinsic modules (following
>> Fortran 2003 and 2008
>> standards) to gfortran. It implements the item 1, and part of item 2, of my
>> initial plan [1]. All the
>> IEEE modules, types, named const
On Thu, 21 Nov 2013, N.M. Maclaren wrote:
> On Nov 21 2013, Joseph S. Myers wrote:
> > On Thu, 21 Nov 2013, FX wrote:
> >
> > > Indeed, 387/SSE has flush-to-zero modes. But other APIs do not (glibc,
> > > SysV, AIX).
> >
> > Note that glibc libm functions may not work when called in a flush-to-z
Hello!
> Here’s my patch submission for adding IEEE intrinsic modules (following
> Fortran 2003 and 2008
> standards) to gfortran. It implements the item 1, and part of item 2, of my
> initial plan [1]. All the
> IEEE modules, types, named constants, procedures are defined and fully
> working.
On Nov 21, 2013, at 3:58 AM, FX wrote:
>>> --- gcc/testsuite/lib/target-supports.exp (revision 205019)
>>> +++ gcc/testsuite/lib/target-supports.exp (working copy)
>>> proc add_options_for_ieee { flags } {
>> ...
>>> +set extra "-fno-unsafe-math-optimizations -frounding-math
>>> -fsignali
>> --- gcc/testsuite/lib/target-supports.exp(revision 205019)
>> +++ gcc/testsuite/lib/target-supports.exp(working copy)
>> proc add_options_for_ieee { flags } {
> ...
>> +set extra "-fno-unsafe-math-optimizations -frounding-math
>> -fsignaling-nans -fintrinsic-modules-path $specpath/l
Hi FX,
some first remarks.
FX wrote:
> I would like to get testing from:
> – a Solaris target (to test config/fpu-sysv.h)
> – an AIX target (to test config/fpu-aix.h)
For AIX, you could ask David Edelsohn for review.
For x87/SSE, you could ask Uros Bizjak for review.
For SysV you could ask
> That's a reasonable decision, but it is actually used at least ten times
> as much as everything else put together, possibly a hundred times as much.
I believe we are in pretty different parts of the community. Around me I rarely
see it used, while people check for nans, infinities, and excepti
On Nov 21 2013, FX wrote:
Note: Gradual underflow control is implemented as "not supported by the
processor" (its SUPPORT function returns false, and the GET and SET
procedures abort if you call them), because we probably don't have
targets where it would work (and I don't think people use it
18 matches
Mail list logo
