summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
* [tests/tmul_ui.c] Added an overflow check that fails in MPFR_RNDZ withvlefevre2020-06-091-1/+29
| | | | | | mini-gmp and mp_limb_t < long (e.g. "-DMINI_GMP_LIMB_TYPE=short"). git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13953 280ebfd0-de03-0410-8827-d642c229c3f4
* [tests/tgeneric.c] In the MPFR_SUSPICIOUS_OVERFLOW case, output yprec.vlefevre2020-06-091-4/+5
| | | | git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13952 280ebfd0-de03-0410-8827-d642c229c3f4
* [src/mpfr-impl.h] Changed the code that defines MPFR_LONG_WITHIN_LIMBvlefevre2020-06-091-4/+11
| | | | | | in order to support mini-gmp with -DMINI_GMP_LIMB_TYPE=... git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13951 280ebfd0-de03-0410-8827-d642c229c3f4
* [src/get_ld.c] Fixed build failure with GMP_NUMB_BITS == 8 due to thevlefevre2020-06-091-1/+1
| | | | | | | | | | | | use of uint64_t in src/get_ld.c, while <stdint.h> was not included: replaced it by "unsigned long long", which does not need a specific header (an exact 64-bit type is not needed, we just need at least a 64-bit width, which unsigned long long is guaranteed to have). Note: unsigned long long may not be available with a pre-C99 compiler, but this is not worse than uint64_t. This limitation is currently OK as GMP_NUMB_BITS == 8 support is just for testing. git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13950 280ebfd0-de03-0410-8827-d642c229c3f4
* [acinclude.m4] Make MPFR_CHECK_MP_LIMB_T_VS_LONG andvlefevre2020-06-091-4/+12
| | | | | | | | | | | | | | | | MPFR_CHECK_MP_LIMB_T_VS_INTMAX similar: * Use AC_LINK_IFELSE in MPFR_CHECK_MP_LIMB_T_VS_LONG too: this is safer than AC_COMPILE_IFELSE, as it will detect undefined function-like macros. * Define MPFR_USE_STATIC_ASSERT in MPFR_CHECK_MP_LIMB_T_VS_INTMAX too in order to make sure that a static assertion is used (not the MPFR_ASSERTN fallback). Note: These constitute redundant safeguards because if MPFR_ASSERTN is used, it will be regarded as a function since the macro is not defined in this context, and linking will fail as a consequence. But this redundancy will protect more against MPFR code evolution. git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13949 280ebfd0-de03-0410-8827-d642c229c3f4
* [acinclude.m4] Fixed MPFR_CHECK_MP_LIMB_T_VS_LONG macro by forcingvlefevre2020-06-091-19/+10
| | | | | | | | | | | | | | | | | | | | MPFR_USE_STATIC_ASSERT to 1 before including mpfr-sassert.h, i.e. by requiring static assertions: because AC_COMPILE_IFELSE is used (i.e. just compiling, no linking), the test could incorrectly succeed when MPFR_USE_STATIC_ASSERT was not defined, i.e. whatever the value of "(mp_limb_t) -1 >= (unsigned long) -1"; indeed, in this case, MPFR_ASSERTN() was used instead of a static assertion, and since the macro was not defined here, MPFR_ASSERTN was regarded as a function (without a prototype), which was fine for compiling (except when the compiler is configured to regard warnings such as missing prototype as errors). In short, one could get "yes" while long was larger than mp_limb_t. Note: In uncommon cases (non-standard compiler...), one can still get "no" while a long fits in mp_limb_t, but this isn't much an issue as the MPFR code should work in such a case. Moreover, src/mpfr-impl.h will also have the chance to set MPFR_LONG_WITHIN_LIMB in practice. git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13948 280ebfd0-de03-0410-8827-d642c229c3f4
* Removed MPFR_DECL_STATIC_ASSERT macro as it was buggy, unused, rathervlefevre2020-06-093-12/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | useless, and it had drawbacks. Details: * In src/mpfr-sassert.h, the default definition of this macro in the MPFR_USE_STATIC_ASSERT case ended with a spurious ";". Since this macro was unused, this wasn't noticeable... except in the configure test for static assertions, which failed in some cases (e.g. with CFLAGS="-std=c99 -pedantic-errors -Wno-error=overlength-strings") for this reason, which had the effect to let MPFR_USE_STATIC_ASSERT undefined, while static assertions were actually working. * Still in src/mpfr-sassert.h, but when MPFR_USE_STATIC_ASSERT is not defined, the MPFR_DECL_STATIC_ASSERT(c) expanded to nothing, which would yield invalid code as MPFR_DECL_STATIC_ASSERT(some_assertion); would yield an extra ";" (about the same issue as above). Given the fact that the portable MPFR_USE_STATIC_ASSERT code does not work with this compiler, it is not clear whether this is fixable in a completely reliable way. * MPFR_DECL_STATIC_ASSERT can be replaced by MPFR_STAT_STATIC_ASSERT after moving it to the statement section of a function, with almost no drawbacks (just a bit readability in some cases?). * When MPFR_USE_STATIC_ASSERT is not defined, MPFR_STAT_STATIC_ASSERT will check the assertion at run time (for free, since the result is known at compile time), while MPFR_DECL_STATIC_ASSERT would not be able to do anything useful. Changes: * acinclude.m4: removed the test of MPFR_DECL_STATIC_ASSERT. * src/mpfr-sassert.h: removed MPFR_DECL_STATIC_ASSERT definitions. * tune/tuneup.c: removed MPFR_DECL_STATIC_ASSERT redefinition. git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13947 280ebfd0-de03-0410-8827-d642c229c3f4
* [acinclude.m4] MPFR_CHECK_MP_LIMB_T_VS_LONG: updated comment to sayvlefevre2020-06-081-1/+3
| | | | | | | that using MPFR_ASSERTN (as the code tries to do if static assertions are not supported, but currently fails) would be incorrect. git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13946 280ebfd0-de03-0410-8827-d642c229c3f4
* [acinclude.m4] In MPFR_CHECK_MP_LIMB_T_VS_INTMAX, do the test only ifvlefevre2020-06-081-0/+2
| | | | | | intmax_t is defined (assuming that it is iff uintmax_t is defined). git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13945 280ebfd0-de03-0410-8827-d642c229c3f4
* [tests/tversion.c] Also output the results of the detection ofvlefevre2020-06-081-0/+34
| | | | | | "long within limb" and "intmax_t within limb". git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13944 280ebfd0-de03-0410-8827-d642c229c3f4
* [configure.ac] Removed an obsolete FIXME, which is probably wrong.vlefevre2020-06-041-1/+0
| | | | git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13942 280ebfd0-de03-0410-8827-d642c229c3f4
* [configure.ac] Updated a comment, replacing a resolved FIXME.vlefevre2020-06-041-9/+19
| | | | git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13941 280ebfd0-de03-0410-8827-d642c229c3f4
* [acinclude.m4] MPFR_CHECK_DBL2INT_BUG test: avoid potentially reservedvlefevre2020-06-041-4/+6
| | | | | | exit status. git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13940 280ebfd0-de03-0410-8827-d642c229c3f4
* [acinclude.m4] Fixed r13938: the new MPFR_C_REALFP_FORMAT macro alsovlefevre2020-06-041-5/+6
| | | | | | needs to take the printf length modifier in argument. git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13939 280ebfd0-de03-0410-8827-d642c229c3f4
* [acinclude.m4] Improved the code to determine the format of double,vlefevre2020-06-041-119/+88
| | | | | | | | | | | | | | | resolving the FIXME. The issue was that it used an AC_RUN_IFELSE, so that the format could not be determined when cross-compiling. The code to determine the format of long double did not have such an issue: the object file was analyzed by an awk script. Since a long double can have the same format as a double, this code was already able to recognize a double, in particular. So the change consisted in slightly adapting this code to accept the tested type as an argument ("double" or "long double", the mpfr_cv_… variable name being obtained thanks to AS_VAR_PUSHDEF) and reusing it for the detection of the format of double. git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13938 280ebfd0-de03-0410-8827-d642c229c3f4
* [acinclude.m4] MPFR_C_LONG_DOUBLE_FORMAT cleanup:vlefevre2020-06-041-11/+1
| | | | | | | * Removed an unused AH_VERBATIM. * Removed "not available" condition, no longer possible since r13936. git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13937 280ebfd0-de03-0410-8827-d642c229c3f4
* [acinclude.m4] Fix concerning r13935: also removed code that testedvlefevre2020-06-041-19/+15
| | | | | | | | | | the availability of long double. This code was useless since it was just outputting "not available" if long double was missing, and one would get an error later since MPFR requires long double. But since long double is in ISO C89, it is useless to add a test just to return an error for pre-C89 compilers. git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13936 280ebfd0-de03-0410-8827-d642c229c3f4
* [acinclude.m4] Removed "AC_CHECK_TYPES([long double])", whose onlyvlefevre2020-06-042-3/+1
| | | | | | | | purpose is to define a HAVE_LONG_DOUBLE macro. [configure.ac] Removed HAVE_LONG_DOUBLE from the cleanup: no longer needed with the change in acinclude.m4. git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13935 280ebfd0-de03-0410-8827-d642c229c3f4
* [configure.ac] Minor change in a comment.vlefevre2020-06-031-1/+1
| | | | git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13934 280ebfd0-de03-0410-8827-d642c229c3f4
* Cleanup about the function detection by autoconf.vlefevre2020-06-032-17/+16
| | | | | | | | | | | | | | * acinclude.m4: removed the detection of memmove, memset and strtol, which was not used (a macro "HAVE_..." was defined... to be removed in configure.ac!); for AC_CHECK_FUNCS, remove options starting with "-Werror" as they can yield a spurious failure due to the way this test is done (this occurred on memmove and memset with GCC due to builtins, and similar issues could still occur in practice with the remaining functions in the AC_CHECK_FUNCS list). * configure.ac: removed HAVE_STRTOL from the macro cleanup: no longer needed since strtol has been removed from the AC_CHECK_FUNCS list. git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13933 280ebfd0-de03-0410-8827-d642c229c3f4
* [acinclude.m4] Minor improvement: in the MPFR_CHECK_GMP test, changedvlefevre2020-06-031-3/+3
| | | | | | | the exit status values 1..3 to 81..83 in order to avoid confusion, as low values can typically be returned in case of compile or link error. git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13932 280ebfd0-de03-0410-8827-d642c229c3f4
* [tests/memory.c] Updated a comment.vlefevre2020-06-021-1/+2
| | | | git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13931 280ebfd0-de03-0410-8827-d642c229c3f4
* [src/mpfr-longlong.h] Added code to check that mpfr-longlong.h is notvlefevre2020-06-021-0/+4
| | | | | | included directly; MPFR_NEED_LONGLONG_H must be defined instead. git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13930 280ebfd0-de03-0410-8827-d642c229c3f4
* [acinclude.m4] To complete r13928, one also needs to definevlefevre2020-06-021-2/+2
| | | | | | MPFR_NEED_INTMAX_H here when mpfr-intmax.h is used. git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13929 280ebfd0-de03-0410-8827-d642c229c3f4
* [src/{mpfr-impl.h,mpfr-intmax.h}] Added code to check that mpfr-intmax.hvlefevre2020-06-022-2/+10
| | | | | | is not included directly; MPFR_NEED_INTMAX_H must be defined instead. git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13928 280ebfd0-de03-0410-8827-d642c229c3f4
* Bug fixes and cleanup related to "src/mpfr-intmax.h" by introducingvlefevre2020-06-0117-63/+32
| | | | | | | | | | | | | | | | a new macro MPFR_NEED_INTMAX_H, which should be defined instead of using: #include "mpfr-intmax.h" Details on the bugs fixed: * The code added in r13916 forgot a #include <limits.h> since this code does a test on ULLONG_MAX. With the cleanup, <limits.h> is already always included by mpfr-impl.h (early enough). * In src/get_str.c and tests/memory.c, a #include "config.h" was missing before #include "mpfr-intmax.h"; this issue would affect platforms where "config.h" is needed and where <inttypes.h> or <stdint.h> does not exist or does not work. git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13923 280ebfd0-de03-0410-8827-d642c229c3f4
* [tests/tgamma.c] For the non-regression test added in r13907, onevlefevre2020-06-011-1/+10
| | | | | | | also needs to temporarily increase the memory limit, thus require MPFR_CHECK_LARGEMEM too. git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13922 280ebfd0-de03-0410-8827-d642c229c3f4
* [acinclude.m4] If decimal floats are explicitly disabled, do not dovlefevre2020-05-261-38/+41
| | | | | | the check of the bit-field ordering for _Decimal128. git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13920 280ebfd0-de03-0410-8827-d642c229c3f4
* [acinclude.m4] Fixed detection of bit-field ordering for _Decimal128:vlefevre2020-05-261-8/+13
| | | | | | a compiler error with exit status 1 was mixed up with little endian. git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13919 280ebfd0-de03-0410-8827-d642c229c3f4
* [src/mpfr-intmax.h] Added support for Silicon Graphics IRIX 6.5 (1998)vlefevre2020-05-241-0/+13
| | | | | | | with native /usr/bin/cc, which knows the long long type but defines ULONGLONG_MAX, etc. instead of ULLONG_MAX, etc. git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13916 280ebfd0-de03-0410-8827-d642c229c3f4
* [tests/tget_ld_2exp.c] Reverted r13914 as we still need to supportvlefevre2020-05-241-1/+1
| | | | | | | | pre-C99 compilers (and this change was useless). If C99 syntax is needed, there should be a configure test, and the code should be conditional. git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13915 280ebfd0-de03-0410-8827-d642c229c3f4
* [tests/tget_ld_2exp.c] put expected value in hex in bug20180904()zimmerma2020-05-231-1/+1
| | | | git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13914 280ebfd0-de03-0410-8827-d642c229c3f4
* [doc/README.dev] "To make a release": mention MPFR_CHECK_EXPENSIVE.vlefevre2020-05-201-1/+2
| | | | git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13913 280ebfd0-de03-0410-8827-d642c229c3f4
* [tests/tgamma.c] added comment about bug fixzimmerma2020-05-191-1/+6
| | | | git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13912 280ebfd0-de03-0410-8827-d642c229c3f4
* [src/bernoulli.c] improve initial precision in mpfr_bernoulli_internal()zimmerma2020-05-191-2/+3
| | | | | | | (avoid failures for n <= 10000) git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13911 280ebfd0-de03-0410-8827-d642c229c3f4
* [src/bernoulli.c] fix bug with non-regression test added in r13907zimmerma2020-05-191-2/+1
| | | | git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13910 280ebfd0-de03-0410-8827-d642c229c3f4
* [src/bernoulli.c] temporary fix for the bug in mpfr_gamma, something must bezimmerma2020-05-191-2/+2
| | | | | | | wrong in the error analysis of mpfr_bernoulli_internal() git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13909 280ebfd0-de03-0410-8827-d642c229c3f4
* [doc/README.dev] added MPFR_CHECK_EXPENSIVEzimmerma2020-05-192-2/+5
| | | | | | | [tests/tgamma.c] use MPFR_CHECK_EXPENSIVE git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13908 280ebfd0-de03-0410-8827-d642c229c3f4
* added non-regression test for bug reported by Frithjof Blomquistzimmerma2020-05-191-0/+32
| | | | git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13907 280ebfd0-de03-0410-8827-d642c229c3f4
* [tools/mpfrlint] Use of codespell: better workaround to python ugliness.vlefevre2020-05-041-10/+15
| | | | git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13906 280ebfd0-de03-0410-8827-d642c229c3f4
* [doc/mpfr.texi] Section "Rounding" / even-rounding rule: the oddvlefevre2020-04-271-5/+5
| | | | | | | radices β are actually not concerned since in such radices, β^k is always odd, so that the exponent does not matter. git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13898 280ebfd0-de03-0410-8827-d642c229c3f4
* [doc/mpfr.texi] In Section "Rounding", for MPFR_RNDN, added a notevlefevre2020-04-271-0/+8
| | | | | | | | | | | about the even-rounding rule in particular cases: 1-digit precision and odd radices. Note: A short explanation was already in the mpfr_get_str description, which is where the issue could occur at the time the minimum precision of MPFR numbers was 2. Now that the minimum precision is 1, this rule in such special cases is more general. git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13897 280ebfd0-de03-0410-8827-d642c229c3f4
* [doc/mpfr.texi] + "than": also in a comment.vlefevre2020-04-271-3/+3
| | | | git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13896 280ebfd0-de03-0410-8827-d642c229c3f4
* [doc/mpfr.texi] Corrected a typo. Changed "{less,greater} or equal to"vlefevre2020-04-271-10/+10
| | | | | | to the more common "{less,greater} than or equal to". git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13895 280ebfd0-de03-0410-8827-d642c229c3f4
* [doc/mpfr.texi] In the paragraph on mpfr_rnd_t, give a referencevlefevre2020-04-261-2/+2
| | | | | | to Section "Rounding". git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13893 280ebfd0-de03-0410-8827-d642c229c3f4
* [doc/mpfr.texi] s/can not/cannot/vlefevre2020-04-261-2/+2
| | | | git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13892 280ebfd0-de03-0410-8827-d642c229c3f4
* [doc/mpfr.texi] Improved Section "Rounding" even more:vlefevre2020-04-261-4/+27
| | | | | | | | * Added a note about the sign of the result (important for 0). * Described the directed rounding modes (BTW, this notion of "directed rounding modes" was used but never defined). git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13891 280ebfd0-de03-0410-8827-d642c229c3f4
* [doc/mpfr.texi] Improved the description of the rounding modes:vlefevre2020-04-261-10/+18
| | | | | | | | | * Be more clear that MPFR_RNDN uses the even rounding rule. * In "two representable numbers", add "consecutive". * Be more general than radix 2 (due to conversions to a string). * Consistent typography. git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13890 280ebfd0-de03-0410-8827-d642c229c3f4
* [doc/mpfr.texi]vlefevre2020-04-251-4/+7
| | | | | | | | | * mpfr_init2: mention mpfr_prec_round; added a note about memory allocation. * mpfr_prec_round: clarification ("new allocation" could be surprising since one needs less memory). git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13889 280ebfd0-de03-0410-8827-d642c229c3f4
* [doc/mpfr.texi] document that mpfr_prec_round does no new allocationzimmerma2020-04-251-1/+2
| | | | | | | in case the allocated memory is enough git-svn-id: svn://scm.gforge.inria.fr/svn/mpfr/trunk@13888 280ebfd0-de03-0410-8827-d642c229c3f4
View Lorry Controller Status