| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
flags, so they are not pure. Remove the __pure2 annotation from them.
I believe that the following routines and their float and long double
counterparts are the only ones here that can be __pure2:
copysign is* fabs finite fmax fmin fpclassify ilogb nan signbit
When gcc supports FENV_ACCESS, perhaps there will be a new annotation
that allows the other functions to be considered pure when FENV_ACCESS
is off.
Discussed with: bde
|
|
|
|
| |
Pointy hat to: das
|
|
|
|
|
|
| |
errno, replacing them with a discussion of IEEE exceptions where
appropriate. Cross-reference fenv(3) whenever exceptions are
mentioned.
|
|
|
|
|
|
| |
basically support this, subject to gcc's lack of FENV_ACCESS support.
In any case, the previous setting of math_errhandling to 0 is not
allowed by POSIX.
|
| |
|
| |
|
|
|
|
|
|
|
| |
registers as volatile. Instructions that *wrote* to FP state were
already marked volatile, but apparently gcc has license to move
non-volatile asms past volatile asms. This broke amd64's feupdateenv
at -O2 due to a WAR conflict between fnstsw and fldenv there.
|
|
|
|
| |
Obtained from: ru
|
|
|
|
|
|
|
| |
math routines that appear to be (a) correct and (b) faster than their
MI counterparts on my Pentium 4.
Obtained from: NetBSD
|
|
|
|
|
|
| |
round correctly.
Noticed by: stefanf
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
Discussed with: bde
|
| |
|
| |
|
|
|
|
|
| |
the only way to convince gcc that they read the MXCSR. The volatile
annotation may be needed elsewhere as well.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
- style
- remove unused variables
- de-support VAX
Inspired by: bin/42388
|
|
|
|
|
|
|
|
|
|
| |
- Make some minor rearrangements in the introduction.
- Mention the problem with argument reduction on i386.
- Add recently-implemented functions to the table.
- Un-document the error bounds that only apply to the old 4BSD math
library, and fill in the correct values where I know them. No
attempt has been made to document bounds lower than 1 ulp, although
smaller bounds are usually achievable in round-to-nearest mode.
|
| |
|
|
|
|
|
|
| |
Also be prepared for FP_ILOGBNAN != INT_MAX.
Reviewed by: md5
|
|
|
|
|
|
|
|
|
|
|
| |
/lib/{libm,libreadline}
/usr/lib/{libhistory,libopie,libpcap}
in preparation for doing the same thing to RELENG_5. HUGE amounts of
help for determining what to bump provided by kris.
Discussed on: freebsd-current
Approved by: re (not required for commit but something like this should be)
|
|
|
|
|
|
|
| |
- Simplify the logic by using __GNUC_PREREQ__.
Suggested by stefanf.
- Make math.h compile with old (pre-8.0) versions of icc.
Submitted by sf [sic].
|
| |
|
|
|
|
|
|
| |
in order to unbreak arm make world. The right way to do it with soft floats
will be figured out later.
Discussed with: das
|
|
|
|
|
|
|
| |
libc. The externally-visible effect of this is to add __isnanl() to
libm, which means that libm.so.2 can once again link against libc.so.4
when LD_BIND_NOW is set. This was broken by the addition of fdiml(),
which calls __isnanl().
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
- It was added to libc instead of libm. Hopefully no programs rely
on this mistake.
- It didn't work properly on large long doubles because its argument
was converted to type double, resulting in undefined behavior.
|
|
|
|
|
| |
nearbyint(), round() and trunc() shouldn't be visible when compiling with
-D_XOPEN_SOURCE=500.
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Unlike the builtin relational operators, builtin floating-point
constants were not available until gcc 3.3, so account for this.[1]
- Apparently some versions of the Intel C Compiler fallaciously define
__GNUC__ without actually being compatible with the claimed gcc
version. Account for this, too.[2]
[1] Noticed by: Christian Hiris <4711@chello.at>
[2] Submitted by: Alexander Leidinger <Alexander@Leidinger.net>
|
|
|
|
| |
needed as of math.h v1.40, and its prototype is incorrect here.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
isnormal() the hard way, rather than relying on fpclassify(). This is
a lose in the sense that we need a total of 12 functions, but it is
necessary for binary compatibility because we have never bumped libm's
major version number. In particular, isinf(), isnan(), and isnanf()
were BSD libc functions before they were C99 macros, so we can't
reimplement them in terms of fpclassify() without adding a dependency
on libc.so.5. I have tried to arrange things so that programs that
could be compiled in FreeBSD 4.X will generate the same external
references when compiled in 5.X. At the same time, the new macros
should remain C99-compliant.
The isinf() and isnan() functions remain in libc for historical
reasons; however, I have moved the functions that implement the macros
isfinite() and isnormal() to libm where they belong. Moreover,
half a dozen MD versions of isinf() and isnan() have been replaced
with MI versions that work equally well.
Prodded by: kris
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
builtins are available: HUGE_VAL, HUGE_VALF, HUGE_VALL, INFINITY,
and NAN. These macros now expand to floating-point constant
expressions rather than external references, as required by C99.
Other compilers will retain the historical behavior. Note that
it is not possible say, e.g.
#define HUGE_VAL 1.0e9999
because the above may result in diagnostics at translation time
and spurious exceptions at runtime. Hence the need for compiler
support for these features.
Also use builtins to implement the macros isgreater(),
isgreaterequal(), isless(), islessequal(), islessgreater(),
and isunordered() when such builtins are available.
Although the old macros are correct, the builtin versions
are much faster, and they avoid double-expansion problems.
|
|
|
|
|
|
|
| |
These trivial implementations are about 25 times slower than
rint{,f}() on x86 due to the FP environment save/restore.
They should eventually be redone in terms of fegetround() and
bit fiddling.
|
| |
|
| |
|
| |
|
| |
|