summaryrefslogtreecommitdiffstats
path: root/sys/i386/include/float.h
Commit message (Collapse)AuthorAgeFilesLines
* Copy amd64 float.h to x86 and merge with i386 float.h. Replacetijl2012-03-041-91/+3
| | | | amd64/i386/pc98 float.h with stubs.
* Add C11 macros describing subnormal numbers to float.h.das2012-01-231-0/+16
| | | | Reviewed by: bde
* Oops, back out previous commit since it was to the wrong file.bde2008-03-051-5/+4
|
* Change float_t and double_t to long double on i386. All floating pointbde2008-03-051-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | expressions on i386 are evaluated in the range of the long double type, so this is wrong in a different but hopefully less worse way than before. Since expressions are evaluated in long double registers, there is no runtime cost to using long double instead of double to declare intermediate values (except in cases where this avoids compiler bugs), and by careful use of float_t or double_t it is possible to avoid some of the compiler bugs in this area, provided these types are declared as long double. I was going to change float.h to be less broken and more usable in combination with the change here (in particular, it is more necessary to know the effective number of bits in a double_t when double_t != double, since DBL_MANT_DIG no longer logically gives this, and LDBL_MANT_DIG doesn't give it either with FreeBSD-i386's default rounding precision. However, this was too hard for now. In particular, LDBL_MANT_DIG is used a lot in libm, so it cannot be changed. One thing that is completely broken now is LDBL_MAX. This may have sort of worked when it was changed from DBL_MAX in 2002 (adding 0 to it at runtime gave +Inf, but you could at least compare with it), but starting with gcc-3.3.1 in 2003, it is always +Inf due to evaluating it at compile time in the default rounding precision.
* /* -> /*- for copyright notices, minor format tweaks as necessaryimp2005-01-061-1/+1
|
* Make FLT_ROUNDS correctly reflect the dynamic rounding mode.das2004-07-191-1/+5
|
* remove needless blanklineimp2004-06-281-1/+0
|
* Hide FLT_EVAL_METHOD and DECIMAL_DIG in pre-C99 compilationdas2004-04-251-0/+4
| | | | | | | environments. PR: 63935 Submitted by: Stefan Farfeleder <stefan@fafoe.narf.at>
* Remove advertising clause from University of California Regent'simp2004-04-071-4/+0
| | | | | | | license, per letter dated July 22, 1999 and email from Peter Wemm, Alan Cox and Robert Watson. Approved by: core, peter, alc, rwatson
* Implement fpclassify():mike2003-02-081-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | o Add a MD header private to libc called _fpmath.h; this header contains bitfield layouts of MD floating-point types. o Add a MI header private to libc called fpmath.h; this header contains bitfield layouts of MI floating-point types. o Add private libc variables to lib/libc/$arch/gen/infinity.c for storing NaN values. o Add __double_t and __float_t to <machine/_types.h>, and provide double_t and float_t typedefs in <math.h>. o Add some C99 manifest constants (FP_ILOGB0, FP_ILOGBNAN, HUGE_VALF, HUGE_VALL, INFINITY, NAN, and return values for fpclassify()) to <math.h> and others (FLT_EVAL_METHOD, DECIMAL_DIG) to <float.h> via <machine/float.h>. o Add C99 macro fpclassify() which calls __fpclassify{d,f,l}() based on the size of its argument. __fpclassifyl() is never called on alpha because (sizeof(long double) == sizeof(double)), which is good since __fpclassifyl() can't deal with such a small `long double'. This was developed by David Schultz and myself with input from bde and fenner. PR: 23103 Submitted by: David Schultz <dschultz@uclink.Berkeley.EDU> (significant portions) Reviewed by: bde, fenner (earlier versions)
* Use the correct values for LDBL_*. Libc doesn't completely supportimp2002-10-251-9/+10
| | | | | | | | | | | | | | long doubles at the moment (printf truncates them to doubles). However, long doubles to appear to work to the ranges listed in this commit on both -stable (4.5) and -current. There may be some slight rounding issues with long doubles, but that's an orthogonal issue to these constants. I've had this in my local tree for 3 months, and in my company's local tree for 15 months with no ill effects. Obtained from: NetBSD Not likely to like it: bde
* $Id$ -> $FreeBSD$peter1999-08-281-1/+1
|
* Back out part 1 of the MCFH that changed $Id$ to $FreeBSD$. We are notpeter1997-02-221-1/+1
| | | | ready for it yet.
* Make the long-awaited change from $Id$ to $FreeBSD$jkh1997-01-141-1/+1
| | | | | | | | This will make a number of things easier in the future, as well as (finally!) avoiding the Id-smashing problem which has plagued developers for so long. Boy, I'm glad we're not using sup anymore. This update would have been insane otherwise.
* Made all header files idempotent and moved incorrect common data fromwollman1993-11-071-1/+5
| | | | | headers into a related source file. Added cons.h as first step towards moving i386/i386/cons.h to machine/cons.h where it belongs.
* Removed all patch kit headers, sccsid and rcsid strings, put $Id$ in, somergrimes1993-10-161-1/+2
| | | | minor cleanup. Added $Id$ to files that did not have any version info, etc
* Added (protection) around negative constants, in case a program wantsnate1993-06-301-4/+4
| | | | | | | | | | to use the negative of that constant. #define NEG_NUM -3 #define SAFE_NEG_NUM (-3) i = -NEG_NUM; /* Error --3 */ j = -SAFE_NEG_NUM /* Okay -(-3) */
* Setting up for updated (usable) FPE atof/vfprintf/vfscanf fixesnate1993-06-291-9/+2
|
* Initial import, 0.1 + pk 0.2.4-B1rgrimes1993-06-121-0/+74
OpenPOWER on IntegriCloud