Announce: GNU MPFR 4.2.1 is released

[Vincent Lefevre]

GNU MPFR 4.2.1 ("fondue savoyarde", patch level 1), a C library for
multiple-precision floating-point computations with correct rounding,
is now available for download from the MPFR web site:

  https://www.mpfr.org/mpfr-4.2.1/

and from the GNU FTP site:

  https://ftp.gnu.org/gnu/mpfr/

Thanks very much to those who sent us bug reports and/or tested the
release candidate.

The SHA1 digests:
f9dbe49b092e4c8e0a039e6d46c059696cc2f51c  mpfr-4.2.1.tar.bz2
ca7a96560f09b548855f7f97b20cba8106f2f203  mpfr-4.2.1.tar.gz
31ffb4244cb469e2b4937cce1f50150300971dfb  mpfr-4.2.1.tar.xz
8e1d9b1c4260dfb172b294997c1b133df2cff188  mpfr-4.2.1.zip

The SHA256 digests:
b9df93635b20e4089c29623b19420c4ac848a1b29df1cfd59f26cab0d2666aa0  
mpfr-4.2.1.tar.bz2
116715552bd966c85b417c424db1bbdf639f53836eb361549d1f8d6ded5cb4c6  
mpfr-4.2.1.tar.gz
277807353a6726978996945af13e52829e3abd7a9a5b7fb2793894e18f1fcbb2  
mpfr-4.2.1.tar.xz
0c2e85bef65070897bd4fd9647e4dcfc850619b6bacefe769ce5592f21f42f0b  mpfr-4.2.1.zip

The signatures:
https://www.mpfr.org/mpfr-4.2.1/mpfr-4.2.1.tar.xz.asc
https://www.mpfr.org/mpfr-4.2.1/mpfr-4.2.1.tar.bz2.asc
https://www.mpfr.org/mpfr-4.2.1/mpfr-4.2.1.tar.gz.asc
https://www.mpfr.org/mpfr-4.2.1/mpfr-4.2.1.zip.asc

Each tarball is signed by Vincent Lefèvre. This can be verified using
the GPG key ID 5831D11A0D4DB02A; this key can be retrieved with:

  gpg --recv-keys 5831D11A0D4DB02A

or by downloading it from .
The key fingerprint is:

  A534 BE3F 83E2 41D9 1828  0AEB 5831 D11A 0D4D B02A

The signatures can be verified with: gpg --verify 
You should check that the key fingerprint matches.

Changes from version 4.2.0 to version 4.2.1:
- Bug fixes (see  and/or the
  ChangeLog file).
- Improved MPFR manual.
- Configure tests: replaced the test of the link with GMP, in order to
  avoid the use of a function without a prototype (Autoconf issue), as
  this is obsolescent in ISO C. The new test should be more robust.

You can send success and failure reports to , and give
us the canonical system name (by running the "./config.guess" script),
the processor and the compiler version, in order to complete the
"Platforms Known to Support MPFR" section of the MPFR 4.2.1 web page.

Regards,

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

GNU MPFR 4.2.1 Release Candidate

[Vincent Lefevre]

The release of GNU MPFR 4.2.1 ("fondue savoyarde", patch level 1)
is imminent.  Please help to make this release as good as possible
by downloading and testing this release candidate:

https://www.mpfr.org/mpfr-4.2.1/mpfr-4.2.1-rc1.tar.xz
https://www.mpfr.org/mpfr-4.2.1/mpfr-4.2.1-rc1.tar.bz2
https://www.mpfr.org/mpfr-4.2.1/mpfr-4.2.1-rc1.tar.gz
https://www.mpfr.org/mpfr-4.2.1/mpfr-4.2.1-rc1.zip

The SHA1 digests:
8ebaf639ef9fbf854b192eb9ab8c38b5c4d74071  mpfr-4.2.1-rc1.tar.bz2
d7a1fa595480a23ecc34a435098ff2681f0e33ad  mpfr-4.2.1-rc1.tar.gz
caa864b0dfad17e014d5c0d99900ec64ebbf2b22  mpfr-4.2.1-rc1.tar.xz
2a3a06e8045a0e10160196ff9295d7db3a829ee8  mpfr-4.2.1-rc1.zip

The SHA256 digests:
b0273645e443633074f13ff79ae91ea741575a98cf5c9c5c1c8f3a997be2e671  
mpfr-4.2.1-rc1.tar.bz2
e4859180c86ec409b54941185732333a2ad34ead245379dcd453f31dba856717  
mpfr-4.2.1-rc1.tar.gz
14f87f24a5434ecbe103b1104f93d260b08651dadc3c5c00c2421ee29dc37cda  
mpfr-4.2.1-rc1.tar.xz
b0fede3afd82567e73dff43a5762bcc2546b96598a812de08bad1fd29a95d5b8  
mpfr-4.2.1-rc1.zip

The signatures:
https://www.mpfr.org/mpfr-4.2.1/mpfr-4.2.1-rc1.tar.xz.asc
https://www.mpfr.org/mpfr-4.2.1/mpfr-4.2.1-rc1.tar.bz2.asc
https://www.mpfr.org/mpfr-4.2.1/mpfr-4.2.1-rc1.tar.gz.asc
https://www.mpfr.org/mpfr-4.2.1/mpfr-4.2.1-rc1.zip.asc

Each tarball is signed by Vincent Lefèvre. This can be verified using
the GPG key ID 5831D11A0D4DB02A; this key can be retrieved with:

  gpg --recv-keys 5831D11A0D4DB02A

or by downloading it from .
The key fingerprint is:

  A534 BE3F 83E2 41D9 1828  0AEB 5831 D11A 0D4D B02A

The signatures can be verified with: gpg --verify 
You should check that the key fingerprint matches.

Changes from version 4.2.0 to version 4.2.1:
- Bug fixes (see  and/or the
  ChangeLog file).
- Improved MPFR manual.
- Configure tests: replaced the test of the link with GMP, in order to
  avoid the use of a function without a prototype (Autoconf issue), as
  this is obsolescent in ISO C. The new test should be more robust.

Please send success and failure reports with "./config.guess" output
to .

If no problems are found, GNU MPFR 4.2.1 should be released on 2023-08-22.

Regards,

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Announce: GNU MPFR 4.2.0 is released

[Vincent Lefevre]

GNU MPFR 4.2.0 ("fondue savoyarde"), a C library for
multiple-precision floating-point computations with correct rounding,
is now available for download from the MPFR web site:

  https://www.mpfr.org/mpfr-4.2.0/

and from the GNU FTP site:

  https://ftp.gnu.org/gnu/mpfr/

Thanks very much to those who sent us bug reports and/or tested the
release candidate.

The SHA1 digests:
08390d482ffcb198329632c0bf76dace53016dd8  mpfr-4.2.0.tar.bz2
114083f1ff2cbfdc09864d240449eae382a38223  mpfr-4.2.0.tar.gz
4f734ca3ebceac28e2f944b131a47133b19e2c5e  mpfr-4.2.0.tar.xz
3bd321bf4be97012967ea7a6cf000b175725b4de  mpfr-4.2.0.zip

The SHA256 digests:
691db39178e36fc460c046591e4b0f2a52c8f2b3ee6d750cc2eab25f1eaa999d  
mpfr-4.2.0.tar.bz2
f1cc1c6bb14d18f0c61cc416e083f5e697b6e0e3cf9630b9b33e8e483fc960f0  
mpfr-4.2.0.tar.gz
06a378df13501248c1b2db5aa977a2c8126ae849a9d9b7be2546fb4a9c26d993  
mpfr-4.2.0.tar.xz
f1a72de4bb157326ecfd82b52a9781313e07d5a82fe8f17a27d425ed4e7727a7  mpfr-4.2.0.zip

The signatures:
https://www.mpfr.org/mpfr-4.2.0/mpfr-4.2.0.tar.xz.asc
https://www.mpfr.org/mpfr-4.2.0/mpfr-4.2.0.tar.bz2.asc
https://www.mpfr.org/mpfr-4.2.0/mpfr-4.2.0.tar.gz.asc
https://www.mpfr.org/mpfr-4.2.0/mpfr-4.2.0.zip.asc

Each tarball is signed by Vincent Lefèvre. This can be verified using
the GPG key ID 5831D11A0D4DB02A; this key can be retrieved with:

  gpg --recv-keys 5831D11A0D4DB02A

or by downloading it from .
The key fingerprint is:

  A534 BE3F 83E2 41D9 1828  0AEB 5831 D11A 0D4D B02A

The signatures can be verified with: gpg --verify 
You should check that the key fingerprint matches.

Changes from versions 4.1.* to version 4.2.0:
- The "fondue savoyarde" release.
- Binary compatible with MPFR 4.0.* and 4.1.*, though some minor changes in
  the behavior of the formatted output functions may be visible, regarded
  as underspecified behavior or bug fixes (see below).
- New functions mpfr_cosu, mpfr_sinu, mpfr_tanu, mpfr_acosu, mpfr_asinu,
  mpfr_atanu and mpfr_atan2u.
- New functions mpfr_cospi, mpfr_sinpi, mpfr_tanpi, mpfr_acospi, mpfr_asinpi,
  mpfr_atanpi and mpfr_atan2pi.
- New functions mpfr_log2p1, mpfr_log10p1, mpfr_exp2m1, mpfr_exp10m1 and
  mpfr_compound_si.
- New functions mpfr_fmod_ui, mpfr_powr, mpfr_pown, mpfr_pow_uj, mpfr_pow_sj
  and mpfr_rootn_si (mpfr_pown is actually a macro defined as an alias for
  mpfr_pow_sj).
- Bug fixes.
  In particular, for the formatted output functions (mpfr_printf, etc.),
  the case where the precision consists only of a period has been fixed
  to be like ".0" as specified in the ISO C standard, and the manual has
  been corrected and clarified.
  The macros of the custom interface have also been fixed: they now behave
  like functions (except a minor limitation for mpfr_custom_init_set).

You can send success and failure reports to , and give
us the canonical system name (by running the "./config.guess" script),
the processor and the compiler version, in order to complete the
"Platforms Known to Support MPFR" section of the MPFR 4.2.0 web page.

Regards,

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

GNU MPFR 4.2.0 Release Candidate

[Vincent Lefevre]

The release of GNU MPFR 4.2.0 ("fondue savoyarde") is imminent.
Please help to make this release as good as possible by downloading
and testing this release candidate:

https://www.mpfr.org/mpfr-4.2.0/mpfr-4.2.0-rc1.tar.xz
https://www.mpfr.org/mpfr-4.2.0/mpfr-4.2.0-rc1.tar.bz2
https://www.mpfr.org/mpfr-4.2.0/mpfr-4.2.0-rc1.tar.gz
https://www.mpfr.org/mpfr-4.2.0/mpfr-4.2.0-rc1.zip

The SHA1 digests:
72b03404b996494c79c13060fea6c9df68d4d99d  mpfr-4.2.0-rc1.tar.bz2
6123e3495501f3d1f45368cf85dcab18fc6e9784  mpfr-4.2.0-rc1.tar.gz
00fa7c1ec1c5dd23cea3692b5351ab4e81e8ca27  mpfr-4.2.0-rc1.tar.xz
7f8e17d2c71e45fdba0d0547db68e8d37c8ad077  mpfr-4.2.0-rc1.zip

The SHA256 digests:
acb9c23e84ba946e974ef21c2afb8c6dd8017cdeb199f61741123f5393b150b8  
mpfr-4.2.0-rc1.tar.bz2
50e34f8c7835c8fe66d7aa16d0f9b9c354df6bfb0d4ead780263f0a39ff14d8f  
mpfr-4.2.0-rc1.tar.gz
1f89ef8631753c50118ec5273ab2fd0d70fbb0e6f33c36a6b673e7e8c51cf5ef  
mpfr-4.2.0-rc1.tar.xz
eb0de4bdbcb9b8b2b28b130aa053e3ad105ceed3ae0392c599b149a07b20  
mpfr-4.2.0-rc1.zip

The signatures:
https://www.mpfr.org/mpfr-4.2.0/mpfr-4.2.0-rc1.tar.xz.asc
https://www.mpfr.org/mpfr-4.2.0/mpfr-4.2.0-rc1.tar.bz2.asc
https://www.mpfr.org/mpfr-4.2.0/mpfr-4.2.0-rc1.tar.gz.asc
https://www.mpfr.org/mpfr-4.2.0/mpfr-4.2.0-rc1.zip.asc

Each tarball is signed by Vincent Lefèvre. This can be verified using
the GPG key ID 5831D11A0D4DB02A; this key can be retrieved with:

  gpg --recv-keys 5831D11A0D4DB02A

or by downloading it from .
The key fingerprint is:

  A534 BE3F 83E2 41D9 1828  0AEB 5831 D11A 0D4D B02A

The signatures can be verified with: gpg --verify 
You should check that the key fingerprint matches.

Changes from versions 4.1.* to version 4.2.0:
- The "fondue savoyarde" release.
- Binary compatible with MPFR 4.0.* and 4.1.*, though some minor changes in
  the behavior of the formatted output functions may be visible, regarded
  as underspecified behavior or bug fixes (see below).
- New functions mpfr_cosu, mpfr_sinu, mpfr_tanu, mpfr_acosu, mpfr_asinu,
  mpfr_atanu and mpfr_atan2u.
- New functions mpfr_cospi, mpfr_sinpi, mpfr_tanpi, mpfr_acospi, mpfr_asinpi,
  mpfr_atanpi and mpfr_atan2pi.
- New functions mpfr_log2p1, mpfr_log10p1, mpfr_exp2m1, mpfr_exp10m1 and
  mpfr_compound_si.
- New functions mpfr_fmod_ui, mpfr_powr, mpfr_pown, mpfr_pow_uj, mpfr_pow_sj
  and mpfr_rootn_si (mpfr_pown is actually a macro defined as an alias for
  mpfr_pow_sj).
- Bug fixes.
  In particular, for the formatted output functions (mpfr_printf, etc.),
  the case where the precision consists only of a period has been fixed
  to be like ".0" as specified in the ISO C standard, and the manual has
  been corrected and clarified.
  The macros of the custom interface have also been fixed: they now behave
  like functions (except a minor limitation for mpfr_custom_init_set).

Please send success and failure reports with "./config.guess" output
to .

If no problems are found, GNU MPFR 4.2.0 should be released
around 2022-12-25.

Regards,

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Announce: GNU MPFR 4.1.1 is released

[Vincent Lefevre]

GNU MPFR 4.1.1 ("épinards à la crème", patch level 1), a C library for
multiple-precision floating-point computations with correct rounding,
is now available for download from the MPFR web site:

  https://www.mpfr.org/mpfr-4.1.1/

and from the GNU FTP site:

  https://ftp.gnu.org/gnu/mpfr/

Thanks very much to those who sent us bug reports and/or tested the
release candidate.

The SHA1 digests:
2d1f9c56ca2f0b02e7cf604a0c055edfd6a1e000  mpfr-4.1.1.tar.bz2
d57ccbe1bb6a5fa69538abcf56684cf95a63b162  mpfr-4.1.1.tar.gz
2355e921d6c97c898cfe7a57dd7e72725f1fded4  mpfr-4.1.1.tar.xz
83bf6696d281820cfc33b3ae55d7ff8781a2dd58  mpfr-4.1.1.zip

The SHA256 digests:
85fdf11614cc08e3545386d6b9c8c9035e3db1e506211a45f4e108117fe3c951  
mpfr-4.1.1.tar.bz2
9cbed5d0af0d9ed5e9f8dd013e17838eb15e1db9a6ae0d371d55d35f93a782a7  
mpfr-4.1.1.tar.gz
ffd195bd567dbaffc3b98b23fd00aad0537680c9896171e44fe3ff79e28ac33d  
mpfr-4.1.1.tar.xz
05ac5e3aeecc1840fa3c2b7e65e502273c92c4b50cc422460d4eba927b6939a6  mpfr-4.1.1.zip

The signatures:
https://www.mpfr.org/mpfr-4.1.1/mpfr-4.1.1.tar.xz.asc
https://www.mpfr.org/mpfr-4.1.1/mpfr-4.1.1.tar.bz2.asc
https://www.mpfr.org/mpfr-4.1.1/mpfr-4.1.1.tar.gz.asc
https://www.mpfr.org/mpfr-4.1.1/mpfr-4.1.1.zip.asc

Each tarball is signed by Vincent Lefèvre. This can be verified using
the GPG key ID 5831D11A0D4DB02A; this key can be retrieved with:

  gpg --recv-keys 5831D11A0D4DB02A

or by downloading it from .
The key fingerprint is:

  A534 BE3F 83E2 41D9 1828  0AEB 5831 D11A 0D4D B02A

The signatures can be verified with: gpg --verify 
You should check that the key fingerprint matches.

Changes from version 4.1.0 to version 4.1.1:
- Bug fixes (see  and/or the
  ChangeLog file), in particular for macros implementing functions.
- Improved manual formatting.

You can send success and failure reports to , and give
us the canonical system name (by running the "./config.guess" script),
the processor and the compiler version, in order to complete the
"Platforms Known to Support MPFR" section of the MPFR 4.1.1 web page.

Regards,

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

GNU MPFR 4.1.1 Release Candidate

[Vincent Lefevre]

The release of GNU MPFR 4.1.1 ("épinards à la crème", patch level 1)
is imminent.  Please help to make this release as good as possible
by downloading and testing this release candidate:

https://www.mpfr.org/mpfr-4.1.1/mpfr-4.1.1-rc1.tar.xz
https://www.mpfr.org/mpfr-4.1.1/mpfr-4.1.1-rc1.tar.bz2
https://www.mpfr.org/mpfr-4.1.1/mpfr-4.1.1-rc1.tar.gz
https://www.mpfr.org/mpfr-4.1.1/mpfr-4.1.1-rc1.zip

The SHA1 digests:
1a01a100d91f91760f116c1f3efb77fc87ebab28  mpfr-4.1.1-rc1.tar.bz2
f8097f9cdd10312a9b554012aec3230bdc719a17  mpfr-4.1.1-rc1.tar.gz
903d59de1b6e08b8570f3673080f8e2a1129c94c  mpfr-4.1.1-rc1.tar.xz
a371751f71cef3874c91fdc81b4d41bd61dd0311  mpfr-4.1.1-rc1.zip

The SHA256 digests:
0da78120b10d2f51265fc7da2786f5a8cea960ae2e91e55865a0e7b2a5ab56e4  
mpfr-4.1.1-rc1.tar.bz2
ecb2045d9cab07290c02a5a70a37f0be822f679b3ba276628e2a6ba08cf97295  
mpfr-4.1.1-rc1.tar.gz
7b78560f8101825fde2ff22cda292917f022c862232da71062307f015f0b3942  
mpfr-4.1.1-rc1.tar.xz
d932a61386e2d1e69a1445f6f6794c19e42c6751c3c34845183c408b277a6e21  
mpfr-4.1.1-rc1.zip

The signatures:
https://www.mpfr.org/mpfr-4.1.1/mpfr-4.1.1-rc1.tar.xz.asc
https://www.mpfr.org/mpfr-4.1.1/mpfr-4.1.1-rc1.tar.bz2.asc
https://www.mpfr.org/mpfr-4.1.1/mpfr-4.1.1-rc1.tar.gz.asc
https://www.mpfr.org/mpfr-4.1.1/mpfr-4.1.1-rc1.zip.asc

Each tarball is signed by Vincent Lefèvre. This can be verified using
the GPG key ID 5831D11A0D4DB02A; this key can be retrieved with:

  gpg --recv-keys 5831D11A0D4DB02A

or by downloading it from .
The key fingerprint is:

  A534 BE3F 83E2 41D9 1828  0AEB 5831 D11A 0D4D B02A

The signatures can be verified with: gpg --verify 
You should check that the key fingerprint matches.

Changes from version 4.1.0 to version 4.1.1:
- Bug fixes (see  and/or the
  ChangeLog file), in particular for macros implementing functions.
- Improved manual formatting, by using a recent texinfo.tex file.

Please send success and failure reports with "./config.guess" output
to .

If no problems are found, GNU MPFR 4.1.1 should be released
around 2022-10-15.

Note: InriaForge closed last year, so some URLs on the MPFR website
(those at gforge.inria.fr) no longer work. I have converted the links
to commits, as those at .
I'll try to do additional changes in the next few days.

Regards,

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

[PATCH] Update pathname for IBM long double description.

[Vincent Lefevre]

Update due to file moved to libgcc/config/rs6000/ibm-ldouble-format
in commit aca0b0b315f6e5a0ee60981fd4b0cbc9a7f59096.

Signed-off-by: Vincent Lefevre 
---
 include/floatformat.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/floatformat.h b/include/floatformat.h
index 5f9c14361f5..288aedda192 100644
--- a/include/floatformat.h
+++ b/include/floatformat.h
@@ -91,7 +91,7 @@ struct floatformat
 
   /* Is the format actually the sum of two smaller floating point
  formats (IBM long double, as described in
- gcc/config/rs6000/darwin-ldouble-format)?  If so, this is the
+ libgcc/config/rs6000/ibm-ldouble-format)?  If so, this is the
  smaller format in question, and the fields sign_start through
  intbit describe the first half.  If not, this is NULL.  */
   const struct floatformat *split_half;
-- 
2.33.0

Re: Suboptimal code generated for __buitlin_trunc on AMD64 without SS4_4.1

[Vincent Lefevre]

On 2021-08-07 14:32:32 +0200, Stefan Kanthak wrote:
> Joseph Myers  wrote:
> > On Fri, 6 Aug 2021, Stefan Kanthak wrote:
> 
> PLEASE DON'T STRIP ATTRIBUTION LINES: I did not write the following paragraph!
> 
> >> > I don't know what the standard says about NaNs in this case, I seem to
> >> > remember that arithmetic instructions typically produce QNaN when one of
> >> > the inputs is a NaN, whether signaling or not. 
> >> 
> >> 
> >> and its cousins as well as the C standard say
> >> 
> >> | If x is NaN, a NaN shall be returned.
> >> 
> >> That's why I mentioned that the code GCC generates also doesn't
> >> quiet SNaNs.
> > 
> > You should be looking at TS 18661-3 / C2x Annex F for sNaN handling;
> 
> I'll do so as soon as GCC drops support for all C dialects before C2x!
> 
> Unless you use a time machine and fix the POSIX and ISO C standards
> written in the past you CAN'T neglect all software written before C2x
> modified sNaN handling that relies on the documented behaviour at the
> time it was written.

Before C2x:

  This specification does not define the behavior of signaling NaNs.365)
  It generally uses the term NaN to denote quiet NaNs.

  365) Since NaNs created by IEC 60559 operations are always quiet,
  quiet NaNs (along with infinities) are sufficient for closure of
  the arithmetic.

(in Annex F).

You can't create signaling NaNs with C operations, but you may get
them when reading data from memory. So, IMHO, they should really be
supported in practice, at least in some sense. I would expect that
when a sNaN occurs as an input, it is handled either like a sNaN
(see IEC 60559 / IEEE 754) or like a qNaN. Propagating the
signaling status (forbidden in IEEE 754 for almost all operations)
could be acceptable (this means that an implementation may ignore
whether a NaN is quiet or signaling), but should be avoided.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

GCC, standard library functions/builtins and POSIX conformance

[Vincent Lefevre]

The GCC manual says:

 If you need a Standard compliant library, then you need to find one, as
GCC does not provide one.  The GNU C library (called 'glibc') provides
ISO C, POSIX, BSD, SystemV and X/Open compatibility for GNU/Linux and
HURD-based GNU systems; no recent version of it supports other systems,
though some very old versions did.  Version 2.2 of the GNU C library
includes nearly complete C99 support.  You could also ask your operating
system vendor if newer libraries are available.

However, even if the GNU C library is used, GCC also provides some
builtins, and it is not clear whether when there is a difference
between ISO C and POSIX (e.g. an undefined behavior in C and some
defined behavior in POSIX), the GCC builtin just conforms to ISO C,
or also conforms to POSIX. So, IMHO, some clarification is needed.

An example is remquo(x,y,*quo) when y ≠ 0 and the result is NaN. ISO C
currently fails to define the behavior concerning *quo, making this call
undefined behavior. But in POSIX, this call is valid and *quo just takes
an (implicitly) unspecified value[*].

[*] https://austingroupbugs.net/view.php?id=713

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: [PATCH v2 1/2] system_data_types.7: Add 'void *'

[Vincent Lefevre]

On 2020-10-12 11:36:57 +0200, Michael Kerrisk (man-pages) via Gcc wrote:
> Hello Vincent,
> 
> On Thu, 8 Oct 2020 at 15:52, Vincent Lefevre  wrote:
> >
> > On 2020-10-01 18:55:04 +0200, Alejandro Colomar via Gcc wrote:
[...]
> > > The most explicit paragraph in dlsym is the following:
> > >
> > > [[
> > > Note that conversion from a void * pointer to a function pointer as in:
> > >
> > > fptr = (int (*)(int))dlsym(handle, "my_function");
> > >
> > > is not defined by the ISO C standard.
> > > This standard requires this conversion to work correctly
> > > on conforming implementations.
> > > ]]
> >
> > I think that "this conversion" applies only to the dlsym context,
> > and the conversion isn't defined in general. Imagine that the
> > void * pointer to function pointer conversion requires the compiler
> > to generate additional code. The compiler may be able to detect
> > that dlsym will not be used in some contexts (e.g. because of
> > always false condition) and do not generate such additional code,
> > making the conversion to have undefined behavior.
> 
> Thanks. It's a good point that you raise.
> 
> I agree that the wording in the standard is not too clear. But I
> believe the intent really is to allow
> [void *] <==> [function pointer] casts.

In this case, this should be standardized. In particular, there
is an issue with the rationale...

> The most relevant pieces I can find are as follows:
> 
> In the current standard, in CHANGE HISTORY for dlsum():
> 
> [[
> Issue 6
> IEEE Std 1003.1-2001/Cor 1-2002, item XSH/TC1/D6/14 is applied,
> correcting an example, and
> adding text to the RATIONALE describing issues related to conversion
> of pointers to functions
> and back again.
> Issue 7
> POSIX.1-2008, Technical Corrigendum 1, XSH/TC1-2008/0074 [74] is applied.
> ]]
> 
> https://www.austingroupbugs.net/view.php?id=74
> This is a little thin. The initial report says:
> "The intent is simply to permit dlsym to use a void * as its return type."
> and no one seems to have questioned that.
> 
> And then in https://pubs.opengroup.org/onlinepubs/7899949299/toc.pdf
> (TC1 for POSIXX.1-2001)
> 
> there is:
> 
> [[
> Change Number: XSH/TC1/D6/14 [XSH ERN 13]
> On Page: 259  Line: 8566,8590  Section: dlsym
> In the EXAMPLES section, change from:
> fptr = (int (*)(int))dlsym(handle, "my_function");
> to:
> *(void **)() = dlsym(handle, "my_function");
> In the RATIONALE section on Page 260, Line 8590, change from:
> "None."
> to:
> "The C Standard does not require that pointers to functions can be
> cast back and forth to pointers to data. Indeed, the C Standard
> does not require that an object of type void* can hold a pointer
> to a function.  Systems supporting the X/Open System Interfaces
> Extension, however, do require that an object of type void* can
> hold a pointer to a function.  The result of converting a pointer
> to a function into a pointer to another data type (except void*)
> is still undefined, however.
> ]]

The last sentence is rather strange. This means that conversion
between pointers would not be transitive, contrary to the intent
of ISO C (via the transitivity of "correctly aligned").

In ISO C, the conversion of a void * to a pointer to another data type
is undefined only if the resulting pointer is not correctly aligned.

In particular, my interpretation of ISO C is that a conversion of
a void * to a char * is always defined. So, if the conversion of
a function pointer to void * is well-defined as a general rule, I
expect that the conversion of a function pointer to char * is also
well-defined, contrary to what the rationale says.

> And one finds the above text in POSIX.1-2001 TC1 spec for dlsym(),
> although it was removed in POSIX.1-2008, and now we have just the
> smaller text that is present in the dlsym() page. But along the way, I
> can find nothing that speaks against the notion that POSIX was aiming
> to allow the more general cast of [void *] <==> [function pointer].
> Your thoughts?

The equivalence of representation between function pointers and void *
may seem natural on von Neumann architectures, but what if functions,
or at least *some* functions (not those returned by dlsym), are from
a separate addressing model? For instance, one could think that some
compilers might implement particular standard functions only as
builtins, with some special handling when pointers to such functions
are used.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: [PATCH v2 1/2] system_data_types.7: Add 'void *'

[Vincent Lefevre]

On 2020-10-01 18:55:04 +0200, Alejandro Colomar via Gcc wrote:
> On 2020-10-01 18:38, Michael Kerrisk (man-pages) wrote:
> > > +According to the C language standard,
> > > +a pointer to any object type may be converted to a pointer to
> > > +.I void
> > > +and back.
> > > +POSIX further requires that any pointer,
> > > +including pointers to functions,
> > > +may be converted to a pointer to
> > > +.I void
> > > +and back.
> > I know you are correct about POSIX, but which part of the
> > standard did you find this information in? The only
> > reference that I find in POSIX is the dlsym() spec. Is it
> > covered also somewhere else in the standrd?
[...]
> I've bean searching, and dlsym is the only one:
[...]
> The most explicit paragraph in dlsym is the following:
> 
> [[
> Note that conversion from a void * pointer to a function pointer as in:
> 
> fptr = (int (*)(int))dlsym(handle, "my_function");
> 
> is not defined by the ISO C standard.
> This standard requires this conversion to work correctly
> on conforming implementations.
> ]]

I think that "this conversion" applies only to the dlsym context,
and the conversion isn't defined in general. Imagine that the
void * pointer to function pointer conversion requires the compiler
to generate additional code. The compiler may be able to detect
that dlsym will not be used in some contexts (e.g. because of
always false condition) and do not generate such additional code,
making the conversion to have undefined behavior.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Announce: GNU MPFR 4.1.0 is released

[Vincent Lefevre]

GNU MPFR 4.1.0 ("épinards à la crème"), a C library for
multiple-precision floating-point computations with correct rounding,
is now available for download from the MPFR web site:

  https://www.mpfr.org/mpfr-4.1.0/

from InriaForge:

  https://gforge.inria.fr/projects/mpfr/

and from the GNU FTP site:

  https://ftp.gnu.org/gnu/mpfr/

Thanks very much to those who sent us bug reports and/or tested the
release candidate.

The SHA1 digests:
877d35a8a81a4d2d9446252e9b4ae944754d8ceb  mpfr-4.1.0.tar.bz2
154a34083cb3a114ed9e687afafea38aa38c8737  mpfr-4.1.0.tar.gz
159c3a58705662bfde4dc93f2617f3660855ead6  mpfr-4.1.0.tar.xz
a48d9e5866a1549ee298357cac7e488ff0dc  mpfr-4.1.0.zip

The SHA256 digests:
feced2d430dd5a97805fa289fed3fc8ff2b094c02d05287fd6133e7f1f0ec926  
mpfr-4.1.0.tar.bz2
3127fe813218f3a1f0adf4e8899de23df33b4cf4b4b3831a5314f78e65ffa2d6  
mpfr-4.1.0.tar.gz
0c98a3f1732ff6ca4ea690552079da9c597872d30e96ec28414ee23c95558a7f  
mpfr-4.1.0.tar.xz
7cc03bcb6db6e7b0f1f8aa5c9c704155b74ba69af139e9b1e859b905618cf88b  mpfr-4.1.0.zip

The signatures:
https://www.mpfr.org/mpfr-4.1.0/mpfr-4.1.0.tar.xz.asc
https://www.mpfr.org/mpfr-4.1.0/mpfr-4.1.0.tar.bz2.asc
https://www.mpfr.org/mpfr-4.1.0/mpfr-4.1.0.tar.gz.asc
https://www.mpfr.org/mpfr-4.1.0/mpfr-4.1.0.zip.asc

Each tarball is signed by Vincent Lefèvre. This can be verified using
the DSA key ID 980C197698C3739D; this key can be retrieved with:

  gpg --recv-keys 980C197698C3739D

or by downloading it from .
The key fingerprint is:

  07F3 DBBE CC1A 3960 5078  094D 980C 1976 98C3 739D

The signatures can be verified with: gpg --verify 
You should check that the key fingerprint matches.

Changes from versions 4.0.* to version 4.1.0:
- The "épinards à la crème" release.
- Binary compatible with MPFR 4.0.*, though some minor changes in the
  behavior of the formatted output functions may be visible, regarded
  as underspecified behavior or bug fixes (see below).
- New --enable-formally-proven-code configure option, to use (when available)
  formally proven code.
- Improved __GMP_CC and __GMP_CFLAGS retrieval (in particular for MS Windows).
- Option -pedantic is now always removed from __GMP_CFLAGS (see INSTALL).
- Changed __float128 to the type _Float128 specified in ISO/IEC TS 18661.
  __float128 is used as a fallback if _Float128 is not supported.
- New function mpfr_get_str_ndigits about conversion to a string of digits.
- New function mpfr_dot for the dot product (incomplete, experimental).
- New functions mpfr_get_decimal128 and mpfr_set_decimal128 (available only
  when MPFR has been built with decimal float support).
- New function mpfr_cmpabs_ui.
- New function mpfr_total_order_p for the IEEE 754 totalOrder predicate.
- The mpfr_out_str function now accepts bases from -2 to -36, in order to
  follow mpfr_get_str and GMP's mpf_out_str functions (these cases gave an
  assertion failure, as with other invalid bases).
- Shared caches: cleanup; really detect lock failures (abort in this case).
- The behavior of the formatted output functions (mpfr_printf, etc.) with
  an empty precision field has improved: trailing zeros are kept in a way
  similar to the formatted output functions from C.
- Improved mpfr_add and mpfr_sub when all operands have a precision equal to
  twice the number of bits per word, e.g., 128 bits on a 64-bit platform.
- Optimized the tuning parameters for various architectures.
- Improved test coverage to 98.6% of code for x86_64.
- Bug fixes.
- MPFR manual: corrected/completed the mpfr_get_str description in order to
  follow the historical behavior and GMP's mpf_get_str function.
- New: optional "make check-exported-symbols", mainly for the MPFR developers
  and binary distributions, to check that MPFR does not define symbols with a
  GMP reserved prefix (experimental).
- Mini-gmp support: replaced --enable-mini-gmp configure option by
  --with-mini-gmp (still experimental, read doc/mini-gmp).
- A GCC bug on Sparc (present at least in old GCC 4.5.3 and 5.5.0 versions),
  which made several tests fail when TLS was enabled, is now avoided in the
  tests. The MPFR library itself was not affected and normal code using the
  MPFR library should not be affected either. Users and distributions that
  disabled TLS just because of the test failures can safely re-enable it.

You can send success and failure reports to , and give
us the canonical system name (by running the "./config.guess" script),
the processor and the compiler version, in order to complete the
"Platforms Known to Support MPFR" section of the MPFR 4.1.0 web page.

Regards,

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

GNU MPFR 4.1.0 Release Candidate 2

[Vincent Lefevre]

The release of GNU MPFR 4.1.0 ("épinards à la crème") is imminent.
Please help to make this release as good as possible by downloading
and testing this release candidate:

https://www.mpfr.org/mpfr-4.1.0/mpfr-4.1.0-rc2.tar.xz
https://www.mpfr.org/mpfr-4.1.0/mpfr-4.1.0-rc2.tar.bz2
https://www.mpfr.org/mpfr-4.1.0/mpfr-4.1.0-rc2.tar.gz
https://www.mpfr.org/mpfr-4.1.0/mpfr-4.1.0-rc2.zip

The SHA1 digests:
f6320390ed7e79c5310bc1249b4b821c20669033  mpfr-4.1.0-rc2.tar.bz2
e589b42226d80227f8662eed5202e10961337526  mpfr-4.1.0-rc2.tar.gz
2ec87a25c9ed866c2864137f533de4d86b7a8d8f  mpfr-4.1.0-rc2.tar.xz
a8aec8a2a70c83e384a7173617030ec46139bdb8  mpfr-4.1.0-rc2.zip

The SHA256 digests:
468cc2ab74caf97ab1f35c5f015297bc3be2dd26e8854f4314d8dacdd6631928  
mpfr-4.1.0-rc2.tar.bz2
2fd45c229022d07487c1b5c58e241f4a281dd14d2eefacb9063bf66b1a7c57f4  
mpfr-4.1.0-rc2.tar.gz
8ff1252a89de8fc33dc8c147f6e56ee7e971787d5ce4291c9e0f0605ac51b384  
mpfr-4.1.0-rc2.tar.xz
41538322aa5fb54cc4c412e80864fab47eba226f9dac362547bd8e5ff9b4bbb3  
mpfr-4.1.0-rc2.zip

The signatures:
https://www.mpfr.org/mpfr-4.1.0/mpfr-4.1.0-rc2.tar.xz.asc
https://www.mpfr.org/mpfr-4.1.0/mpfr-4.1.0-rc2.tar.bz2.asc
https://www.mpfr.org/mpfr-4.1.0/mpfr-4.1.0-rc2.tar.gz.asc
https://www.mpfr.org/mpfr-4.1.0/mpfr-4.1.0-rc2.zip.asc

Each tarball is signed by Vincent Lefèvre. This can be verified using
the DSA key ID 980C197698C3739D; this key can be retrieved with:

  gpg --recv-keys 980C197698C3739D

or by downloading it from .
The key fingerprint is:

  07F3 DBBE CC1A 3960 5078  094D 980C 1976 98C3 739D

The signatures can be verified with: gpg --verify 
You should check that the key fingerprint matches.

Changes from versions 4.0.* to version 4.1.0:
- The "épinards à la crème" release.
- Binary compatible with MPFR 4.0.*, though some minor changes in the
  behavior of the formatted output functions may be visible, regarded
  as underspecified behavior or bug fixes (see below).
- New --enable-formally-proven-code configure option, to use (when available)
  formally proven code.
- Improved __GMP_CC and __GMP_CFLAGS retrieval (in particular for MS Windows).
- Option -pedantic is now always removed from __GMP_CFLAGS (see INSTALL).
- Changed __float128 to the type _Float128 specified in ISO/IEC TS 18661.
  __float128 is used as a fallback if _Float128 is not supported.
- New function mpfr_get_str_ndigits about conversion to a string of digits.
- New function mpfr_dot for the dot product (incomplete, experimental).
- New functions mpfr_get_decimal128 and mpfr_set_decimal128 (available only
  when MPFR has been built with decimal float support).
- New function mpfr_cmpabs_ui.
- New function mpfr_total_order_p for the IEEE 754 totalOrder predicate.
- The mpfr_out_str function now accepts bases from -2 to -36, in order to
  follow mpfr_get_str and GMP's mpf_out_str functions (these cases gave an
  assertion failure, as with other invalid bases).
- Shared caches: cleanup; really detect lock failures (abort in this case).
- The behavior of the formatted output functions (mpfr_printf, etc.) with
  an empty precision field has improved: trailing zeros are kept in a way
  similar to the formatted output functions from C.
- Improved mpfr_add and mpfr_sub when all operands have a precision equal to
  twice the number of bits per word, e.g., 128 bits on a 64-bit platform.
- Optimized the tuning parameters for various architectures.
- Improved test coverage to 98.6% of code for x86_64.
- Bug fixes.
- MPFR manual: corrected/completed the mpfr_get_str description in order to
  follow the historical behavior and GMP's mpf_get_str function.
- New: optional "make check-exported-symbols", mainly for the MPFR developers
  and binary distributions, to check that MPFR does not define symbols with a
  GMP reserved prefix (experimental).
- Mini-gmp support: replaced --enable-mini-gmp configure option by
  --with-mini-gmp (still experimental, read doc/mini-gmp).
- A GCC bug on Sparc (present at least in old GCC 4.5.3 and 5.5.0 versions),
  which made several tests fail when TLS was enabled, is now avoided in the
  tests. The MPFR library itself was not affected and normal code using the
  MPFR library should not be affected either. Users and distributions that
  disabled TLS just because of the test failures can safely re-enable it.

Please send success and failure reports with "./config.guess" output
to .

If no problems are found, GNU MPFR 4.1.0 should be released
around 2020-07-10.

Regards,

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

GNU MPFR 4.1.0 Release Candidate

[Vincent Lefevre]

The release of GNU MPFR 4.1.0 ("épinards à la crème") is imminent.
Please help to make this release as good as possible by downloading
and testing this release candidate:

https://www.mpfr.org/mpfr-4.1.0/mpfr-4.1.0-rc1.tar.xz
https://www.mpfr.org/mpfr-4.1.0/mpfr-4.1.0-rc1.tar.bz2
https://www.mpfr.org/mpfr-4.1.0/mpfr-4.1.0-rc1.tar.gz
https://www.mpfr.org/mpfr-4.1.0/mpfr-4.1.0-rc1.zip

The SHA1 digests:
82cd76ae13311375f9ce0ff949d818717e7941b8  mpfr-4.1.0-rc1.tar.bz2
4669a5eda286546b3d11e3e5a207cfdd324ab9a4  mpfr-4.1.0-rc1.tar.gz
633a221f1e4649684624d08d081ceafd29090a9d  mpfr-4.1.0-rc1.tar.xz
1b221d7180c8d72575d362268639f1f1a18c0da3  mpfr-4.1.0-rc1.zip

The SHA256 digests:
4e91be229a413257a32deb6c859c1793471ce4bd277b0db4785ba7ba10da94f4  
mpfr-4.1.0-rc1.tar.bz2
7391b0e4dbf256cf1fac04cc14f3b7920831513956c08ecf16788b8432fa9e43  
mpfr-4.1.0-rc1.tar.gz
327c7c6b06546289e6d379e4f47c2fc7246a1913c27b670a58f03791eb61a8a9  
mpfr-4.1.0-rc1.tar.xz
a82db837cda6d1fbb36cc5231d3012344978de216ea2dba750a7cfbd97bca84b  
mpfr-4.1.0-rc1.zip

The signatures:
https://www.mpfr.org/mpfr-4.1.0/mpfr-4.1.0-rc1.tar.xz.asc
https://www.mpfr.org/mpfr-4.1.0/mpfr-4.1.0-rc1.tar.bz2.asc
https://www.mpfr.org/mpfr-4.1.0/mpfr-4.1.0-rc1.tar.gz.asc
https://www.mpfr.org/mpfr-4.1.0/mpfr-4.1.0-rc1.zip.asc

Each tarball is signed by Vincent Lefèvre. This can be verified using
the DSA key ID 980C197698C3739D; this key can be retrieved with:

  gpg --recv-keys 980C197698C3739D

or by downloading it from .
The key fingerprint is:

  07F3 DBBE CC1A 3960 5078  094D 980C 1976 98C3 739D

The signatures can be verified with: gpg --verify 
You should check that the key fingerprint matches.

Changes from versions 4.0.* to version 4.1.0:
- The "épinards à la crème" release.
- Binary compatible with MPFR 4.0.*, though some minor changes in the
  behavior of the formatted output functions may be visible, regarded
  as underspecified behavior or bug fixes (see below).
- New --enable-formally-proven-code configure option, to use (when available)
  formally proven code.
- Improved __GMP_CC and __GMP_CFLAGS retrieval (in particular for MS Windows).
- Option -pedantic is now always removed from __GMP_CFLAGS (see INSTALL).
- Changed __float128 to the type _Float128 specified in ISO/IEC TS 18661.
  __float128 is used as a fallback if _Float128 is not supported.
- New function mpfr_get_str_ndigits about conversion to a string of digits.
- New function mpfr_dot for the dot product (incomplete, experimental).
- New functions mpfr_get_decimal128 and mpfr_set_decimal128 (available only
  when MPFR has been built with decimal float support).
- New function mpfr_cmpabs_ui.
- New function mpfr_total_order_p for the IEEE 754 totalOrder predicate.
- The mpfr_out_str function now accepts bases from -2 to -36, in order to
  follow mpfr_get_str and GMP's mpf_out_str functions (these cases gave an
  assertion failure, as with other invalid bases).
- Shared caches: cleanup; really detect lock failures (abort in this case).
- The behavior of the formatted output functions (mpfr_printf, etc.) with
  an empty precision field has improved: trailing zeros are kept in a way
  similar to the formatted output functions from C.
- Improved mpfr_add and mpfr_sub when all operands have a precision equal to
  twice the number of bits per word, e.g., 128 bits on a 64-bit platform.
- Optimized the tuning parameters for various architectures.
- Improved test coverage to 98.6% of code for x86_64.
- Bug fixes.
- MPFR manual: corrected/completed the mpfr_get_str description in order to
  follow the historical behavior and GMP's mpf_get_str function.
- New: optional "make check-exported-symbols", mainly for the MPFR developers
  and binary distributions, to check that MPFR does not define symbols with a
  GMP reserved prefix (experimental).
- Mini-gmp support: replaced --enable-mini-gmp configure option by
  --with-mini-gmp (still experimental, read doc/mini-gmp).

Please send success and failure reports with "./config.guess" output
to .

If no problems are found, GNU MPFR 4.1.0 should be released
around 2020-06-30.

Regards,

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Test GCC conversion with reposurgeon available

[Vincent Lefevre]

On 2019-12-26 16:30:15 -0500, Eric S. Raymond wrote:
> Vincent Lefevre :
> > > Here's why you want to get timezones right: there are going to be times
> > > when the order of commits is significant information for a developer's
> > > understanding of what happened.  But without a timezone you only know 
> > > the actual time of a commit to 24-hour resoltion.
> > 
> > I don't understand what you mean. What matters for the order of
> > commits is the global time, and this is what SVN stores. SVN does not
> > store timezone information, i.e. it has no idea of what local time of
> > the user had, but I don't think this is important information.
> 
> UTC time plus a timezone offset set is what git stores.  That's not the
> locus of the problem.
> 
> In Subversion-land there's newver any doubt about the sequence of commits;
> the revision numbers tell you that.  In Git-land you have to go by timestamps,
> and if a timezone entry is wrong it can skew the displayed time.

What matters is that the date is correct. I don't think the timezone
matters (that's why SVN doesn't store timezone information, I assume),
possibly except for the committer himself (?). For instance,

  2019-11-27 02:32:02 +0100

and

  2019-11-27 01:32:02 +

correspond to the same date. So, each one (as stored in the repository)
is fine if you want to be able to know the order of commits.

What is displayed then is actually a user-config issue. The conversion
utility can't solve this issue, since after conversion, committers will
be able to use any timezone they like.

> Me, I don't undertstand why version-control systems designed for distributed
> use don't ignore timezones entirely and display all times in UTC - relative
> time is surely more imoortant than the commit time's relationship to solar
> noon wherever the keyboard happened to be. But I don't make these decisions.

I agree, at least being able to display all times in a *fixed* timezone
(chosen by the user), as this could be easier for the user to know when
recent commits occur (by "recent", this can be less than 24 hours ago).

For UTC, you can use:

  TZ=UTC git log --date=iso-local

The date format can be stored in ~/.gitconfig, but unfortunately
not local timezone information.

In this case, the timezones of the commits chosen by the conversion
utility will not matter at all.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Test GCC conversion with reposurgeon available

[Vincent Lefevre]

On 2019-12-25 14:33:45 -0500, Eric S. Raymond wrote:
> Segher Boessenkool :
> > The goal is not to pretend we never used SVN.
> 
> One of *my* goals is that the illusion of git back to the beginning of
> time should be as consistent as possible.
> 
> > The goal is to have a Git repo that is as useful as possible for us.
> 
> Exactly.  I've already written about minimizing cognitive friction.
> 
> Here's why you want to get timezones right: there are going to be times
> when the order of commits is significant information for a developer's
> understanding of what happened.  But without a timezone you only know 
> the actual time of a commit to 24-hour resoltion.

I don't understand what you mean. What matters for the order of
commits is the global time, and this is what SVN stores. SVN does not
store timezone information, i.e. it has no idea of what local time of
the user had, but I don't think this is important information.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: GCC turns &~ into | due to undefined bit-shift without warning

[Vincent Lefevre]

On 2019-03-13 11:18:02 +0100, David Brown wrote:
> On 13/03/2019 03:25, Vincent Lefevre wrote:
> > On 2019-03-12 21:56:59 +0100, David Brown wrote:
> >> I disagree. To generate an unconditional error (rejecting the
> >> program), the compiler would need such proof - such as by tracing
> >> execution from main(). But to generate a warning activated
> >> specifically by the user, there is no such requirement. It's fine
> >> to give a warning based on the code written, rather than on code
> >> that the compiler knows without doubt will be executed.
> > 
> > There's already a bug about spurious warnings on shift counts:
> > 
> >   https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210
> > 
> 
> You can divide code into three groups (with the exact divisions varying
> by compiler switches and version):
> 
> 1. Code that the compiler knows for sure will run in every execution of
> the program, generally because it can track the code flow from main().
> 
> 2. Code that the compiler knows will /not/ run, due to things like
> constant propagation, inlining, etc.
> 
> 3. Code that the compiler does not know if it will run or not.

Actually more than the fact whether the code will be run or not,
what is important is the concept of reachability. This will give:

1. Code that the compiler knows for sure will run under some
conditions (e.g. particular values of inputs).

2. Code that the compiler knows will never run (what I called dead code).

3. Code for which the compile can't decide.

> Code in group 1 here is usually quite small.  Code in group 2 can be
> large, especially with C++ header libraries, templates, etc.  The
> compiler will often eliminate such code and avoid generating any object
> code.  gcc used to have a warning for when it found "group 2" code and
> eliminated it - that warning was removed as gcc got smarter, and the
> false positives were overwhelming.
> 
> Most code is in group 3.

It depends on how the code is written. The programmer could try
to avoid group 3 by giving hints to the compiler, e.g. with
__builtin_unreachable(). I wish this were standardized in C.

> I am arguing here that a warning like this should be applied to group 3
> code - you are suggesting it should only apply to group 1.

No, I was just suggesting that the compiler should be smart enough
to detect dead code (when possible). In the past, there was a similar
issue with -Wmaybe-uninitialized, which was rather useless (too many
false positives in complex code). Fortunetaly, this has improved a
lot.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: GCC turns &~ into | due to undefined bit-shift without warning

[Vincent Lefevre]

On 2019-03-12 21:56:59 +0100, David Brown wrote:
> I disagree.  To generate an unconditional error (rejecting the program), the
> compiler would need such proof - such as by tracing execution from main().
> But to generate a warning activated specifically by the user, there is no
> such requirement.  It's fine to give a warning based on the code written,
> rather than on code that the compiler knows without doubt will be executed.

There's already a bug about spurious warnings on shift counts:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: GCC turns &~ into | due to undefined bit-shift without warning

[Vincent Lefevre]

On 2019-03-11 13:51:21 +0100, David Brown wrote:
> On 11/03/2019 12:24, Vincent Lefevre wrote:
> > It already does by default:
> > 
> >-Wshift-count-negative
> >Warn if shift count is negative. This warning is enabled
> >by default.
> > 
> >-Wshift-count-overflow
> >Warn if shift count >= width of type. This warning is
> >enabled by default.
> > 
> > Of course, if the compiler cannot guess that there will be such
> > an issue, it will not emit the warning. You certainly don't want
> > a warning for each non-trivial shift just because the compiler
> > cannot know whether the constraint on the shift count will be
> > satisfied.
> 
> While the compiler clearly can't give a warning on calculated shifts
> without massive amounts of false positives, it is able to give warnings
> when there is a shift by a compile-time known constant value that is
> invalid.  In the case of the OP's test function, inlining and constant
> propagation means that the shift value /is/ known to the compiler - it
> uses it for optimisation (in this case, it uses the undefined behaviour
> to "simplify" the calculations).
> 
> Am I right in thinking that this is because the pass that checks the
> shift sizes for warnings here comes before the relevant inlining or
> constant propagation passes?  And if so, would it be possible to change
> the ordering here?

To generate a warning, the compiler would also have to make sure
that the inlined code with an out-of-range shift is actually not
dead code. In practice, it may happen that constraints are not
satisfied on some platforms, but the reason is that on such
platforms the code will never be executed (this is code written
to take care of other platforms).

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: GCC turns &~ into | due to undefined bit-shift without warning

[Vincent Lefevre]

On 2019-03-11 11:06:37 +, Moritz Strübe wrote:
> On 11.03.2019 at 10:14 Jakub Jelinek wrote:
> > The fact that negative or >= bit precision shifts are UB is widely known,
[...]

And even in the case where the compiler maps the shift directly to
the asm shift (without optimizations), the behavior may depend on
the processor.

> Thanks for that explanation. None the less, a compile time warning
> would be nice.

It already does by default:

   -Wshift-count-negative
   Warn if shift count is negative. This warning is enabled
   by default.

   -Wshift-count-overflow
   Warn if shift count >= width of type. This warning is
   enabled by default.

Of course, if the compiler cannot guess that there will be such
an issue, it will not emit the warning. You certainly don't want
a warning for each non-trivial shift just because the compiler
cannot know whether the constraint on the shift count will be
satisfied.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Announce: GNU MPFR 4.0.2 is released

[Vincent Lefevre]

GNU MPFR 4.0.2 ("dinde aux marrons", patch level 2), a C library for
multiple-precision floating-point computations with correct rounding,
is now available for download from the MPFR web site:

  https://www.mpfr.org/mpfr-4.0.2/

from InriaForge:

  https://gforge.inria.fr/projects/mpfr/

and from the GNU FTP site:

  https://ftp.gnu.org/gnu/mpfr/

Thanks very much to those who sent us bug reports and/or tested the
release candidate.

The SHA1 digests:
d6a313a3b1ceb9ff3be71cd18e45468837b7fd53  mpfr-4.0.2.tar.bz2
ade94aa28e181540763d6698c6c9fae795be8b75  mpfr-4.0.2.tar.gz
52c1f2a4c9a202f46cf3275a8d46b562aa584208  mpfr-4.0.2.tar.xz
194ea07b9df25203ae20b2be40c66ee70744edc6  mpfr-4.0.2.zip

The SHA256 digests:
c05e3f02d09e0e9019384cdd58e0f19c64e6db1fd6f5ecf77b4b1c61ca253acc  
mpfr-4.0.2.tar.bz2
ae26cace63a498f07047a784cd3b0e4d010b44d2b193bab82af693de57a19a78  
mpfr-4.0.2.tar.gz
1d3be708604eae0e42d578ba93b390c2a145f17743a744d8f3f8c2ad5855a38a  
mpfr-4.0.2.tar.xz
c956921dcf0df8d3bd84a3552ded6dc115a7d6e5224ad2982905c5e777db818d  mpfr-4.0.2.zip

The signatures:
https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2.tar.xz.asc
https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2.tar.bz2.asc
https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2.tar.gz.asc
https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2.zip.asc

Each tarball is signed by Vincent Lefèvre. This can be verified using
the DSA key ID 980C197698C3739D; this key can be retrieved with:

  gpg --recv-keys 980C197698C3739D

or by downloading it from .
The key fingerprint is:

  07F3 DBBE CC1A 3960 5078  094D 980C 1976 98C3 739D

The signatures can be verified with: gpg --verify 
You should check that the key fingerprint matches.

Changes from version 4.0.1 to version 4.0.2:
- Corrected minimal GMP version in the INSTALL file and the MPFR manual.
- Option -pedantic is now always removed from __GMP_CFLAGS (see INSTALL).
- Shared caches: cleanup; really detect lock failures (abort in this case).
- Improved MPFR manual. In particular, corrected/completed the
  mpfr_get_str description in order to follow the historical behavior
  and GMP's mpf_get_str function.
- Bug fixes (see ChangeLog file).

You can send success and failure reports to , and give
us the canonical system name (by running the "./config.guess" script),
the processor and the compiler version, in order to complete the
"Platforms Known to Support MPFR" section of the MPFR 4.0.2 web page.

Regards,

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

GNU MPFR 4.0.2 Release Candidate 2

[Vincent Lefevre]

The release of GNU MPFR 4.0.2 ("dinde aux marrons", patch level 2)
is imminent. Please help to make this release as good as possible
by downloading and testing this release candidate:

https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2-rc2.tar.xz
https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2-rc2.tar.bz2
https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2-rc2.tar.gz
https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2-rc2.zip

The SHA1 digests:
99f3a07e2de84aa171b6f6c798607525fd963cac  mpfr-4.0.2-rc2.tar.bz2
363bcb341a6e042fc0e5ae4b4b78bdbc3826274a  mpfr-4.0.2-rc2.tar.gz
1b6c6d258879fd6f2880e7f4f2be6348cccd4cc7  mpfr-4.0.2-rc2.tar.xz
747d7f46a82d951b4d1862c53a07b49e1bf19058  mpfr-4.0.2-rc2.zip

The SHA256 digests:
25fc8d93e4625f10fe13d1e3b968a72306f7c75217d28e69647400490094d877  
mpfr-4.0.2-rc2.tar.bz2
f4d1e0416bd8566c29aa9adfdfdd35b09b9f047485c15e5f5b107a1a047d5027  
mpfr-4.0.2-rc2.tar.gz
707f8c14d892d71668aebb269a63efaec387630cc8c6db4e27e4948af021  
mpfr-4.0.2-rc2.tar.xz
1380fe676548e241da316ca45da5f60e7ab0067d054ffb80ea67333738514f3e  
mpfr-4.0.2-rc2.zip

The signatures:
https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2-rc2.tar.xz.asc
https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2-rc2.tar.bz2.asc
https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2-rc2.tar.gz.asc
https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2-rc2.zip.asc

Each tarball is signed by Vincent Lefèvre. This can be verified using
the DSA key ID 980C197698C3739D; this key can be retrieved with:

  gpg --recv-keys 980C197698C3739D

or by downloading it from .
The key fingerprint is:

  07F3 DBBE CC1A 3960 5078  094D 980C 1976 98C3 739D

The signatures can be verified with: gpg --verify 
You should check that the key fingerprint matches.

Changes from version 4.0.1 to version 4.0.2:
- Corrected minimal GMP version in the INSTALL file and the MPFR manual.
- Shared caches: cleanup; really detect lock failures (abort in this case).
- Improved MPFR manual. In particular, corrected/completed the
  mpfr_get_str description in order to follow the historical behavior
  and GMP's mpf_get_str function.
- Bug fixes (see ChangeLog file).

Please send success and failure reports with "./config.guess" output
to .

If no problems are found, GNU MPFR 4.0.2 should be released
around 2019-01-31.

Regards,

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

GNU MPFR 4.0.2 Release Candidate

[Vincent Lefevre]

The release of GNU MPFR 4.0.2 ("dinde aux marrons", patch level 2)
is imminent. Please help to make this release as good as possible
by downloading and testing this release candidate:

https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2-rc1.tar.xz
https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2-rc1.tar.bz2
https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2-rc1.tar.gz
https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2-rc1.zip

The SHA1 digests:
c0b15940b703d55a05acdc61781962eb3d0bf857  mpfr-4.0.2-rc1.tar.bz2
fd4bc91650ad6cf549c9a036f036d62b26b47ac2  mpfr-4.0.2-rc1.tar.gz
535d06909eff58c8541250a222bd97a96aa5422c  mpfr-4.0.2-rc1.tar.xz
3295000419ca52ebbbd17fdb889bbe7d3e7242bf  mpfr-4.0.2-rc1.zip

The SHA256 digests:
60626832f47a51fe24dc366cadbf2157a085b62ac634526f0d03e5c987de59ae  
mpfr-4.0.2-rc1.tar.bz2
58b561c76b30e9ef14961345d16e532bea89e08e3590b5394cd396b1c17a8ce7  
mpfr-4.0.2-rc1.tar.gz
4fc4cee96878d2c947d488e8fc11b59877eb8d108c000634f39e6f3520ea04ea  
mpfr-4.0.2-rc1.tar.xz
a3e4ec355db75c88a132e19d1bd3c3bcb72db23a0a21272a64fb8ac0da4e484f  
mpfr-4.0.2-rc1.zip

The signatures:
https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2-rc1.tar.xz.asc
https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2-rc1.tar.bz2.asc
https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2-rc1.tar.gz.asc
https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2-rc1.zip.asc

Each tarball is signed by Vincent Lefèvre. This can be verified using
the DSA key ID 980C197698C3739D; this key can be retrieved with:

  gpg --recv-keys 980C197698C3739D

or by downloading it from .
The key fingerprint is:

  07F3 DBBE CC1A 3960 5078  094D 980C 1976 98C3 739D

The signatures can be verified with: gpg --verify 
You should check that the key fingerprint matches.

Changes from version 4.0.1 to version 4.0.2:
- Corrected minimal GMP version in the INSTALL file and the MPFR manual.
- Improved MPFR manual. In particular, corrected/completed the
  mpfr_get_str description in order to follow the historical behavior
  and GMP's mpf_get_str function.
- Bug fixes (see ChangeLog file).

Please send success and failure reports with "./config.guess" output
to .

If no problems are found, GNU MPFR 4.0.2 should be released
around 2019-01-23.

Regards,

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: warning: conversion from ‘int’ to ‘char’ may change value

[Vincent Lefevre]

On 2018-09-20 11:13:59 -0400, Jason Merrill wrote:
> Indeed, whether this sort of warning is a false positive depends on
> values, which the optimizers can always do better with.  We could
> build some logic into the front end, e.g. recognize that a &
> expression will always fit in the smallest of its operand types, but

This is not true with int & signed char, where the signed char
is negative.

> on the other hand that duplicates things that other parts of the
> compiler already deal with, so there's a question of how to share
> these rules between front and middle end, like we're doing more of
> with constant folding.  Perhaps we could use the folder somehow.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: warning: conversion from ‘int’ to ‘char’ may change value

[Vincent Lefevre]

On 2018-09-20 22:57:00 +0800, Liu Hao wrote:
> 在 2018/9/20 22:08, Vincent Lefevre 写道:
> >> In C++, declaring n1 const avoids the warning regardless of
> >> optimization levels.
> > 
> > If the constant propagation is done at -O0, this could explain
> > the behavior.
> > 
> > Or do you mean that GCC remembers the type the data come from,
> > i.e. assuming char is signed, if n1 is of type char, then ~n1
> > is necessarily representable in a char, thus can be regarded
> > as of being of type char in its analysis?
> > 
> 
> In C++ adding the `const` qualifier makes `~n1` a constant expression. 
> In C it never is, regardless of qualifiers.

What I meant is that since n1 is a constant, its value is known,
and GCC can deduce the value of ~n1 (this is not a constant
expression, but its value is known at compile time, which is
what matters here).

In the code here, even if n1 is not declared as const, the value
of ~n1 can also be deduced at compile time, but this requires code
analysis to detect whether n1 could have been modified. Thus this
is more complex.

> BTW, I am quite disappointed with such 'false' warnings, because by 
> performing a compound AND-and-ASSIGN operation on a `char` object I have 
> no interest in bits that don't fit into a `char`, be they ones or 
> zeroes. Perhaps there are scenarios where they shouldn't be ignored, but 
> I can't think of any.

Then you can disable the warning, or use optimization to enable
further code analysis (but by doing that, you can get new false
positives). In doubt, GCC cannot guess what you have in mind in
general.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: warning: conversion from ‘int’ to ‘char’ may change value

[Vincent Lefevre]

On 2018-09-17 10:03:48 -0600, Martin Sebor wrote:
> On 09/17/2018 06:00 AM, Umesh Kalappa wrote:
> > Hi All,
> > 
> > When we try to compile the below case from trunk gcc we get the below
> > warning (-Wconversion) i.e
> > 
> > void start(void) {
> >  char n = 1;
> >  char n1 = 0x01;
> >  n &=  ~n1;
> > }
> > 
> > $xgcc -S  warn.c -nostdinc -Wconversion
> >  warning: conversion from ‘int’ to ‘char’ may change value [-Wconversion]
> >   n &=  ~n1;
[...]
> It looks like a bug to me.
> 
> Declaring n1 const avoids the warning at -O2 but in C but not
> at -O0.

Perhaps at some optimization level, GCC determines that the
expression is safe (thus no longer emits the warning), i.e.
that n & ~n1 is necessarily representable in a char.

> That doesn't seem quite right -- GCC determines the
> type of the bitwise AND expression to be different between
> the optimization levels.

No, the type of this AND expression is always int. The question
is whether this int is necessarily representable in a char.

> In C++, declaring n1 const avoids the warning regardless of
> optimization levels.

If the constant propagation is done at -O0, this could explain
the behavior.

Or do you mean that GCC remembers the type the data come from,
i.e. assuming char is signed, if n1 is of type char, then ~n1
is necessarily representable in a char, thus can be regarded
as of being of type char in its analysis?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: "file name" vs "filename"

[Vincent Lefevre]

On 2018-04-02 12:11:33 +, Joseph Myers wrote:
> On Sun, 1 Apr 2018, Gerald Pfeifer wrote:
> 
> > And now to the most important question of all. ;-)  Should we use
> > "file name" or "filename" when referring to the name of a file?
> 
> See the GNU Coding Standards:
> 
>   Please do not use the term ``pathname'' that is used in Unix
>   documentation; use ``file name'' (two words) instead.  We use the term
>   ``path'' only for search paths, which are lists of directory names.

IMHO, "file name" is bad as it is ambiguous if its goal is to mean
either "filename" (in the POSIX sense) or "pathname". At least,
"filename" and "pathname" have been standardized by POSIX.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

ASAN status and glibc 2.27

[Vincent Lefevre]

Hi,

Any news about the ASAN compatibility with glibc 2.27 on x86?
Will this be fixed soon? This is important as this is a blocker.

FYI, I had reported:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84761

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Announce: GNU MPFR 4.0.1 is released

[Vincent Lefevre]

GNU MPFR 4.0.1 ("dinde aux marrons", patch level 1), a C library for
multiple-precision floating-point computations with correct rounding,
is now available for download from the MPFR web site:

  http://www.mpfr.org/mpfr-4.0.1/

from InriaForge:

  https://gforge.inria.fr/projects/mpfr/

and from the GNU FTP site:

  https://ftp.gnu.org/gnu/mpfr/

Thanks very much to those who sent us bug reports and/or tested the
release candidate.

The SHA1 digests:
fcbbafb37c683898e585b926608d540ed037609e  mpfr-4.0.1.tar.bz2
655e3cf416a0cc9530d9cb3c38dc8839504f0e98  mpfr-4.0.1.tar.gz
ae555c56a6fccd21a0ffe3dd3bdc5eb5cc1a5fce  mpfr-4.0.1.tar.xz
8194e79f639c8b7c4a2bf63dc5e9945780497eb8  mpfr-4.0.1.zip

The SHA256 digests:
a4d97610ba8579d380b384b225187c250ef88cfe1d5e7226b89519374209b86b  
mpfr-4.0.1.tar.bz2
e650f8723bfc6eca4f222c021db3d5d4cebe2e21c82498329bb9e6815b99c88c  
mpfr-4.0.1.tar.gz
67874a60826303ee2fb6affc6dc0ddd3e749e9bfcb4c8655e3953d0458a6e16e  
mpfr-4.0.1.tar.xz
a9f955d2e4ff59e001c4bf2283a0a77bd7a9f3cbdfce77a05a8249847453cfea  mpfr-4.0.1.zip

The signatures:
http://www.mpfr.org/mpfr-4.0.1/mpfr-4.0.1.tar.xz.asc
http://www.mpfr.org/mpfr-4.0.1/mpfr-4.0.1.tar.bz2.asc
http://www.mpfr.org/mpfr-4.0.1/mpfr-4.0.1.tar.gz.asc
http://www.mpfr.org/mpfr-4.0.1/mpfr-4.0.1.zip.asc

Each tarball is signed by Vincent Lefèvre. This can be verified using
the DSA key ID 980C197698C3739D; this key can be retrieved with:

  gpg --recv-keys 980C197698C3739D

or by downloading it from .
The key fingerprint is:

  07F3 DBBE CC1A 3960 5078  094D 980C 1976 98C3 739D

The signatures can be verified with: gpg --verify 
You should check that the key fingerprint matches.

Changes from version 4.0.0 to version 4.0.1:
- Improved MPFR manual.
- Improved __GMP_CC and __GMP_CFLAGS retrieval (in particular for MS Windows).
- Fixed a build failure on some platforms when --with-gmp-build is used.
- Bug fixes (see ChangeLog file), in particular in mpfr_div_ui, which
  could yield an incorrectly rounded result to nearest when using
  different precisions; this bug had been present since the introduction
  of mpfr_div_ui, and in MPFR 4.0.0, it was affecting mpfr_div too.
- New: optional "make check-exported-symbols", mainly for the MPFR developers
  and binary distributions, to check that MPFR does not define symbols with a
  GMP reserved prefix (experimental).

You can send success and failure reports to , and give
us the canonical system name (by running the "./config.guess" script),
the processor and the compiler version, in order to complete the
"Platforms Known to Support MPFR" section of the MPFR 4.0.1 web page.

Regards,

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

[Vincent Lefevre]

On 2018-02-06 17:34:23 +, Joseph Myers wrote:
> Use -ffp-contract=off to disable all contraction, or -ffp-contract=on to 
> disable it between statements (which currently actually disables all 
> contraction, as the FMA generation doesn't know what was originally a 
> single source expression).  The default in the absence of such -std 
> options is -ffp-contract=fast (allowing contraction including between 
> different statements).

An environment variable to specify default GCC options would be very
useful. It is too easy to forget such an option.

Note: In the long term, -std=c99 or -std=c11 is better, as if one day,
GCC supports the STDC FP_CONTRACT pragma, contraction could be partly
enabled.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

[Vincent Lefevre]

On 2018-02-06 17:32:30 +, Joseph Myers wrote:
> GCC doesn't use mpfr_div at all; it uses MPFR to fold calls to a range of 
> libm functions with constant arguments (input and output precisions should 
> always be the same, since GCC doesn't yet support built-in functions for 
> the TS 18661-1 narrowing functions such as fsqrtl), and for correctly 
> rounding conversions of decimal strings to binary floating point.  The + - 
> * / operations are handled directly in real.c without use of MPFR.  Of 
> course MPFR functions called might use mpfr_div indirectly.

Yes, it might be possible to get an error via a call to mpfr_div
inside MPFR. And perhaps mpfr_div_ui too (with any MPFR version).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

[Vincent Lefevre]

On 2018-02-06 17:14:38 +0100, Vincent Lefevre wrote:
> Now, I've just found a "regression" when comparing Sipe results with
> MPFR results, but it is the Sipe result with SIPE_FLOAT equal to 1
> (float) or 2 (double) that is incorrect, 3 (long double) being OK.
> Bug triggered with -O2 -march=native on an Intel Xeon E5-2609 v3
> machine. At least from 4.9 to 8.0.1 20180124 [trunk revision 257009]
> are affected. I'll try to find a simple test case for a bug report.
> I suspect that the regression comes from the fact this is a new
> machine + the use (as in the past) of -march=native.

Well, if I add -std=c99 or -std=c11, the failure disappears. The
reason is that GCC generates a FMA (indeed, this new machine has
a FMA), but this occurs across different C statements. So, maybe
not a bug, but a bad feature, IMHO.

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: GCC 8.0.0 Status Report (2018-01-15), Trunk in Regression and Documentation fixes only mode

[Vincent Lefevre]

On 2018-02-06 10:49:48 +0100, Matthias Klose wrote:
> I have seen some issues with mpfr 4.0.0 on 32bit platforms, however
> not in GCC itself yet. These are all fixed in 4.0.1 rc2, so maybe
> document 4.0.1 instead of 4.0.0 once it is released.

The issues were also present on 64-bit platforms and were due to
a bug in mpfr_div_ui, which has always been present, since 1999.
With MPFR 4.0.0, they are also visible with mpfr_div just because
mpfr_div now uses mpfr_div_ui in some simple cases. I don't think
that GCC could be affected because AFAIK, a failure can only occur
when the input and output precisions are different, or is this
possible with GCC?

Now, I've just found a "regression" when comparing Sipe results with
MPFR results, but it is the Sipe result with SIPE_FLOAT equal to 1
(float) or 2 (double) that is incorrect, 3 (long double) being OK.
Bug triggered with -O2 -march=native on an Intel Xeon E5-2609 v3
machine. At least from 4.9 to 8.0.1 20180124 [trunk revision 257009]
are affected. I'll try to find a simple test case for a bug report.
I suspect that the regression comes from the fact this is a new
machine + the use (as in the past) of -march=native.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: extern const initialized warns in C

[Vincent Lefevre]

On 2018-01-22 10:53:55 +0100, David Brown wrote:
> On 22/01/2018 10:31, Jay K wrote:
> > 
> > By this argument there is a missing warning for the equivalent:
> > 
> >    const int foo = 123;
> > 
> > with no previous extern declaration.
> 
> I would like to see such a warning.  There is "-Wmissing-declarations",
> but that applies only to functions and not to objects.

I would like such a warning too. FYI, a few days I fixed in bug in
MPFR, which was defining an exported symbol outside of its prefix
under some conditions and could yield problems with multiple defined
symbols once linked with GMP. This remained undetected since this
was internal to some file and was related to code obtained from GMP
(with the preprocessor involved too). Such a warning would have
detected a potential issue via automated tests since the symbol
isn't pre-declared in .h files.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Announce: GNU MPFR 4.0.0 is released

[Vincent Lefevre]

GNU MPFR 4.0.0 ("dinde aux marrons"), a C library for
multiple-precision floating-point computations with correct rounding,
is now available for download from the MPFR web site:

  http://www.mpfr.org/mpfr-4.0.0/

from InriaForge:

  https://gforge.inria.fr/projects/mpfr/

and from the GNU FTP site:

  https://ftp.gnu.org/gnu/mpfr/

Thanks very much to those who sent us bug reports and/or tested the
release candidate.

The SHA1 digests:
799245347044c8f0da9e513f86bb5e4c07974931  mpfr-4.0.0.tar.bz2
1bf74ee8dba8c5cc6be1e36c9cff8e45fce25460  mpfr-4.0.0.tar.gz
01cb1ad6514757236859d75fe1ff00c00ed22df2  mpfr-4.0.0.tar.xz
bcfb77334d77dce052f8b0d1fc8265a0453711b4  mpfr-4.0.0.zip

The SHA256 digests:
6aa31fbf3bd1f9f95bcfa241590a9d11cb0f874e2bb93b99c9e2de8eaea6d5fd  
mpfr-4.0.0.tar.bz2
f65bb6c295c8716ea06adc3c2aab2f0e6e410464ba5a86bfd10c6259e64876a2  
mpfr-4.0.0.tar.gz
fbe2cd1418b321f5c899ce4f0f0f4e73f5ecc7d02145b0e1fd096f5c3afb8a1d  
mpfr-4.0.0.tar.xz
51971443c8170193d540d87515ce368c2d91c80f07d63fffa1bf22ee8c4b8500  mpfr-4.0.0.zip

The signatures:
http://www.mpfr.org/mpfr-4.0.0/mpfr-4.0.0.tar.xz.asc
http://www.mpfr.org/mpfr-4.0.0/mpfr-4.0.0.tar.bz2.asc
http://www.mpfr.org/mpfr-4.0.0/mpfr-4.0.0.tar.gz.asc
http://www.mpfr.org/mpfr-4.0.0/mpfr-4.0.0.zip.asc

Each tarball is signed by Vincent Lefèvre. This can be verified using
the DSA key ID 980C197698C3739D; this key can be retrieved with:

  gpg --recv-keys 980C197698C3739D

or by downloading it from .
The key fingerprint is:

  07F3 DBBE CC1A 3960 5078  094D 980C 1976 98C3 739D

The signatures can be verified with: gpg --verify 
You should check that the key fingerprint matches.

Changes from versions 3.1.* to version 4.0.0:
- The "dinde aux marrons" release.
- MPFR now depends on GMP 5.0+ instead of 4.1+.
- API change:
  Applications that call GMP's mp_set_memory_functions function to change
  the allocators must first call the new function mpfr_mp_memory_cleanup
  in all threads where MPFR is potentially used; this new function is
  currently equivalent to mpfr_free_cache.
  The reason is that the way memory allocation is done by MPFR has changed
  (again), so that the current GMP allocators are used (since for some
  applications, the old allocators may become invalid).
  Note: Freeing the caches like this might have a performance impact on some
  particular applications; if this is an issue, this could be handled for a
  future MPFR version.
- Mini-gmp support via the --enable-mini-gmp configure option (experimental).
- The minimum precision MPFR_PREC_MIN is now 1, with rounding defined as
  in the errata of IEEE 754-2008 and in the following IEEE 754 revision
  (ties rounded away from zero).
- Shared caches for multithreaded applications.
  New function mpfr_free_cache2.
- Partial support of MPFR_RNDF (faithful rounding).
- New functions: mpfr_fpif_export and mpfr_fpif_import to export and import
  numbers in a floating-point interchange format, independent both on the
  number of bits per word and on the endianness.
- New function mpfr_fmodquo to return the low bits of the quotient
  corresponding to mpfr_fmod.
- New functions mpfr_flags_clear, mpfr_flags_set, mpfr_flags_test,
  mpfr_flags_save and mpfr_flags_restore to operate on groups of flags.
- New functions mpfr_set_float128 and mpfr_get_float128 to convert from/to
  the __float128 type (requires --enable-float128 and compiler support).
- New functions mpfr_buildopt_float128_p and mpfr_buildopt_sharedcache_p.
- New functions mpfr_rint_roundeven and mpfr_roundeven, completing the
  other similar round-to-integer functions for rounding to nearest with
  the even-rounding rule.
- New macro mpfr_round_nearest_away to add partial emulation of the
  rounding to nearest-away (as defined in IEEE 754-2008).
- New functions mpfr_nrandom and mpfr_erandom to generate random numbers
  following normal and exponential distributions respectively.
- New functions mpfr_fmma and mpfr_fmms to compute a*b+c*d and a*b-c*d.
- New function mpfr_rootn_ui, similar to mpfr_root, but agreeing with the
  rootn function of the IEEE 754-2008 standard.
- New functions mpfr_log_ui to compute the logarithm of an integer,
  mpfr_gamma_inc for the incomplete Gamma function.
- New function mpfr_beta for the Beta function (incomplete, experimental).
- New function mpfr_get_q to convert a floating-point number into rational.
- The mpfr_dump function is now described in the manual; its output format
  has slightly changed.
- The mpfr_eint function now returns the value of the E1/eint1 function
  for negative argument.
- The behavior of the mpfr_set_exp function changed, as it could easily
  yield undefined behavior in some cases (this modifies both the API and
  the ABI).
- In function mpfr_urandom, the next random state no longer depends on the
  current exponent range and the rounding mode. The exceptions due to the
  rounding of the random number are now correctly generated, following the
  uniform 

Re: GNU MPFR 4.0.0 Release Candidate

[Vincent Lefevre]

On 2017-12-09 11:59:41 +, Andrew Roberts wrote:
> MPFR 4.0.0-rc1 causes in-tree build of gcc to fail (error building mpc)
[...]
> I've also sent additional info to mpfr at inria.fr, but that was possibly
> rejected (sent to moderators), so this is just a heads up.

It was just an informational message because only subscribers can
post without needing moderation (to avoid spam).

> And yes I know its not an officially supported combination etc etc...

As it was said later in the mpfr list, this is a bug in mpc, which
unconditionally took the mpfr namespace.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

GNU MPFR 4.0.0 Release Candidate

[Vincent Lefevre]

The release of GNU MPFR 4.0.0 ("dinde aux marrons")
is imminent. Please help to make this release as good as possible
by downloading and testing this release candidate:

http://www.mpfr.org/mpfr-4.0.0/mpfr-4.0.0-rc1.tar.xz
http://www.mpfr.org/mpfr-4.0.0/mpfr-4.0.0-rc1.tar.bz2
http://www.mpfr.org/mpfr-4.0.0/mpfr-4.0.0-rc1.tar.gz
http://www.mpfr.org/mpfr-4.0.0/mpfr-4.0.0-rc1.zip

The SHA1 digests:
28ad8b9d40c43c9ad18b16e222b8addfbd83ba2e  mpfr-4.0.0-rc1.tar.bz2
cc8b56d998d5512e46209fea08d906f923367307  mpfr-4.0.0-rc1.tar.gz
717faa1896ccb7dc99f7ee6053452f5258ad53a8  mpfr-4.0.0-rc1.tar.xz
aa7a4a154e761f71fce65011e195f873cac60a22  mpfr-4.0.0-rc1.zip

The SHA256 digests:
944fb955c5cca1873fcf2343e7a1edfb56645e7b003d8eecc8fb768d86b564c3  
mpfr-4.0.0-rc1.tar.bz2
abbc893738d2df8120e615b2745a07646a5879d3be51f2f941c0057ce791aaca  
mpfr-4.0.0-rc1.tar.gz
ef98fd9b6cb98a3d4b15963bdeecb3e6f9a003a5e6ce94fa4a4c37a518085a11  
mpfr-4.0.0-rc1.tar.xz
69e665daa00a0a7214b3893d5c5f1ab6f475872b7c39f6a5b3999ad4b752e6e3  
mpfr-4.0.0-rc1.zip

The signatures:
http://www.mpfr.org/mpfr-4.0.0/mpfr-4.0.0-rc1.tar.xz.asc
http://www.mpfr.org/mpfr-4.0.0/mpfr-4.0.0-rc1.tar.bz2.asc
http://www.mpfr.org/mpfr-4.0.0/mpfr-4.0.0-rc1.tar.gz.asc
http://www.mpfr.org/mpfr-4.0.0/mpfr-4.0.0-rc1.zip.asc

Each tarball is signed by Vincent Lefèvre. This can be verified using
the DSA key ID 980C197698C3739D; this key can be retrieved with:

  gpg --recv-keys 980C197698C3739D

or by downloading it from .
The key fingerprint is:

  07F3 DBBE CC1A 3960 5078  094D 980C 1976 98C3 739D

The signatures can be verified with: gpg --verify 
You should check that the key fingerprint matches.

Changes from versions 3.1.* to version 4.0.0:
- The "dinde aux marrons" release.
- MPFR now depends on GMP 5.0+ instead of 4.1+.
- API change:
  Applications that call GMP's mp_set_memory_functions function to change
  the allocators must first call the new function mpfr_mp_memory_cleanup
  in all threads where MPFR is potentially used; this new function is
  currently equivalent to mpfr_free_cache.
  The reason is that the way memory allocation is done by MPFR has changed
  (again), so that the current GMP allocators are used (since for some
  applications, the old allocators may become invalid).
  Note: Freeing the caches like this might have a performance impact on some
  particular applications; if this is an issue, this could be handled for a
  future MPFR version.
- Mini-gmp support via the --enable-mini-gmp configure option (experimental).
- The minimum precision MPFR_PREC_MIN is now 1, with rounding defined as
  in the next IEEE 754 revision (ties rounded away from zero).
- Shared caches for multithreaded applications.
  New function mpfr_free_cache2.
- Partial support of MPFR_RNDF (faithful rounding).
- New functions: mpfr_fpif_export and mpfr_fpif_import to export and import
  numbers in a floating-point interchange format, independent both on the
  number of bits per word and on the endianness.
- New function mpfr_fmodquo to return the low bits of the quotient
  corresponding to mpfr_fmod.
- New functions mpfr_flags_clear, mpfr_flags_set, mpfr_flags_test,
  mpfr_flags_save and mpfr_flags_restore to operate on groups of flags.
- New functions mpfr_set_float128 and mpfr_get_float128 to convert from/to
  the __float128 type (requires --enable-float128 and compiler support).
- New functions mpfr_buildopt_float128_p and mpfr_buildopt_sharedcache_p.
- New functions mpfr_rint_roundeven and mpfr_roundeven, completing the
  other similar round-to-integer functions for rounding to nearest with
  the even-rounding rule.
- New macro mpfr_round_nearest_away to add partial emulation of the
  rounding to nearest-away (as defined in IEEE 754-2008).
- New functions mpfr_nrandom and mpfr_erandom to generate random numbers
  following normal and exponential distributions respectively.
- New functions mpfr_fmma and mpfr_fmms to compute a*b+c*d and a*b-c*d.
- New function mpfr_rootn_ui, similar to mpfr_root, but agreeing with the
  rootn function of the IEEE 754-2008 standard.
- New functions mpfr_log_ui to compute the logarithm of an integer,
  mpfr_gamma_inc for the incomplete Gamma function.
- New function mpfr_beta for the Beta function (incomplete, experimental).
- New function mpfr_get_q to convert a floating-point number into rational.
- The mpfr_dump function is now described in the manual; its output format
  has slightly changed.
- The mpfr_eint function now returns the value of the E1/eint1 function
  for negative argument.
- The behavior of the mpfr_set_exp function changed, as it could easily
  yield undefined behavior in some cases (this modifies both the API and
  the ABI).
- In function mpfr_urandom, the next random state no longer depends on the
  current exponent range and the rounding mode. The exceptions due to the
  rounding of the random number are now correctly generated, following the
  uniform distribution.
- Functions mpfr_grandom and 

Re: Infering that the condition of a for loop is initially true?

[Vincent Lefevre]

On 2017-09-18 19:20:33 +0200, Niels Möller wrote:
> Joseph Myers  writes:
> 
> > On Mon, 18 Sep 2017, Niels Möller wrote:
> 
> >> I'm suggesting that with -DNDEBUG, assert(x) should let the compiler
> >> assume that x is true, but without producing any code to evaluate it at
> >> runtime.
> >
> > There's no requirement that x is even a valid expression with -DNDEBUG.  
> > Consider code that does
> >
> >   int x;
> > #ifndef NDEBUG
> >   int other_variable_used_in_assertion = something ();
> > #endif
> >   /* ... */
> >   assert (other_variable_used_in_assertion == x);
> 
> Ouch, didn't think about that case. And I'd expect there's a lot of real
> code like that out there.
> 
> That makes extending the standard assert facility more difficult.

Anyway, one may want both assert and assume features, depending
on the context, such as in MPFR, which has MPFR_ASSERTN(), which
are assertions that are normally always checked (though it is also
possible to disable them), and MPFR_ASSERTD(), which can either
be the assume feature (normal mode) or assertions (debug mode).

And if the user chooses not to check assertions, this does not
mean that he would want the assume on these expressions, as it
could break things even more. Some assertions could be security
ones (e.g. for detection of potential issues), but the code may
work even if the assertions are not satisfied.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Infering that the condition of a for loop is initially true?

[Vincent Lefevre]

On 2017-09-14 22:36:34 +0200, Geza Herman wrote:
> Do you plan adding something like __builtin_assume to GCC? It is useful,
> because of this idiom to help the compiler to optimize better:
> 
> #ifdef MY_DEBUG
> #define MY_ASSERT(assertion) do { if (!(assertion)) ... } while (0)
> #else
> #define MY_ASSERT(assertion) __builtin_assume(assertion)
> #endif
> 
> It is not the same as "if (!(assertion)) __builtin_unreachable();" because
> __builtin_assume discards any side effects of "assertion".

Yes, that would be better. Because of possible side effects with
condition + __builtin_unreachable(), MPFR currently has:

#if defined(MPFR_HAVE_BUILTIN_UNREACHABLE) && __MPFR_GNUC(4, 8)
# define MPFR_ASSUME(x) \
(! __builtin_constant_p (!!(x) || !(x)) || (x) ?\
 (void) 0 : __builtin_unreachable())
#elif defined(_MSC_VER)
# define MPFR_ASSUME(x) __assume(x)
#else
# define MPFR_ASSUME(x) ((void) 0)
#endif

(and the MPFR_ASSERTD() macro does either an assertion checking
or does MPFR_ASSUME(), depending on whether or not one wants
full assertions).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Announce: GNU MPFR 3.1.6 is released

[Vincent Lefevre]

GNU MPFR 3.1.6 ("canard à l'orange", patch level 6), a C library for
multiple-precision floating-point computations with correct rounding,
is now available for download from the MPFR web site:

  http://www.mpfr.org/mpfr-3.1.6/

from InriaForge:

  https://gforge.inria.fr/projects/mpfr/

and from the GNU FTP site:

  http://ftp.gnu.org/gnu/mpfr/

Thanks very much to those who sent us bug reports and/or tested the
release candidate.

The SHA1 digests:
c207aada1c0af969d800c16f25e0a78e15b9c9cc  mpfr-3.1.6.tar.bz2
e6ac324627196370f5fe5a415fff931157da4b23  mpfr-3.1.6.tar.gz
f9178ddc0c470faa2e063b3185c4488ad0f74df8  mpfr-3.1.6.tar.xz
4dba04d35eed61f912c70c3301517bf94287510f  mpfr-3.1.6.zip

The SHA256 digests:
cf4f4b2d80abb79e820e78c8077b67254e8f41896783c899087be0e94068  
mpfr-3.1.6.tar.bz2
569ceb418aa935317a79e93b87eeb3f956cab1a97dfb2f3b5fd8ac2501011d62  
mpfr-3.1.6.tar.gz
7a62ac1a04408614fccdc506e4844b10cf0ad2c2b1677097f8f35d3a1344a950  
mpfr-3.1.6.tar.xz
c0ad6c88f0aaeb83a0a2ed069713acb3be22ffa1413467a3a08025573add6b2f  mpfr-3.1.6.zip

The signatures:
http://www.mpfr.org/mpfr-3.1.6/mpfr-3.1.6.tar.xz.asc
http://www.mpfr.org/mpfr-3.1.6/mpfr-3.1.6.tar.bz2.asc
http://www.mpfr.org/mpfr-3.1.6/mpfr-3.1.6.tar.gz.asc
http://www.mpfr.org/mpfr-3.1.6/mpfr-3.1.6.zip.asc

Each tarball is signed by Vincent Lefèvre. This can be verified using
the DSA key ID 980C197698C3739D; this key can be retrieved with:

  gpg --recv-keys 980C197698C3739D

or by downloading it from .
The key fingerprint is:

  07F3 DBBE CC1A 3960 5078  094D 980C 1976 98C3 739D

The signatures can be verified with: gpg --verify 
You should check that the key fingerprint matches.

Changes from version 3.1.5 to version 3.1.6:
- Improved MPFR manual.
- Bug fixes (see  and ChangeLog file).
- Autotools: Under Linux, make sure that the old dtags (when supported)
  are used if LD_LIBRARY_PATH is defined; otherwise "make check" would
  check an installed, compatible MPFR library found in LD_LIBRARY_PATH
  instead of the one that has been built with "make".

You can send success and failure reports to , and give
us the canonical system name (by running the "./config.guess" script),
the processor and the compiler version, in order to complete the
"Platforms Known to Support MPFR" section of the MPFR 3.1.6 web page.

Regards,

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

GNU MPFR 3.1.6 Release Candidate

[Vincent Lefevre]

The release of GNU MPFR 3.1.6 ("canard à l'orange", patch level 6)
is imminent. Please help to make this release as good as possible
by downloading and testing this release candidate:

http://www.mpfr.org/mpfr-3.1.6/mpfr-3.1.6-rc1.tar.xz
http://www.mpfr.org/mpfr-3.1.6/mpfr-3.1.6-rc1.tar.bz2
http://www.mpfr.org/mpfr-3.1.6/mpfr-3.1.6-rc1.tar.gz
http://www.mpfr.org/mpfr-3.1.6/mpfr-3.1.6-rc1.zip

The SHA1 digests:
f21b4fd387ff8100a22d7b405761e327dcdee20d  mpfr-3.1.6-rc1.tar.bz2
aaa97d68cb740f1126c87f0fe4c4f9aff70e5447  mpfr-3.1.6-rc1.tar.gz
3a822d45edf871198a9cb5832b7f60e4c2aba9d0  mpfr-3.1.6-rc1.tar.xz
b49a991e85a09f97cf65a4375540f87a2b03e533  mpfr-3.1.6-rc1.zip

The SHA256 digests:
58da15a1604a1c3595109af79def6050256fe4b7406fe36e01573767298134c9  
mpfr-3.1.6-rc1.tar.bz2
5be1b8279b4514071c139a35f85369c6168a3da6f17bda98072ba9499b7c4d04  
mpfr-3.1.6-rc1.tar.gz
df943ffd58a46280599d83ce7583d83829d23e9c38b5d37244eec310d6c9bcf6  
mpfr-3.1.6-rc1.tar.xz
52dbe13dcba01989ae28eb4b5b26c3a25a220e3ebfc84d756968b68c4422d8ab  
mpfr-3.1.6-rc1.zip

The signatures:
http://www.mpfr.org/mpfr-3.1.6/mpfr-3.1.6-rc1.tar.xz.asc
http://www.mpfr.org/mpfr-3.1.6/mpfr-3.1.6-rc1.tar.bz2.asc
http://www.mpfr.org/mpfr-3.1.6/mpfr-3.1.6-rc1.tar.gz.asc
http://www.mpfr.org/mpfr-3.1.6/mpfr-3.1.6-rc1.zip.asc

Each tarball is signed by Vincent Lefèvre. This can be verified using
the DSA key ID 980C197698C3739D; this key can be retrieved with:

  gpg --recv-keys 980C197698C3739D

or by downloading it from .
The key fingerprint is:

  07F3 DBBE CC1A 3960 5078  094D 980C 1976 98C3 739D

The signatures can be verified with: gpg --verify 
You should check that the key fingerprint matches.

Changes from version 3.1.5 to version 3.1.6:
- Improved MPFR manual.
- Bug fixes (see  and ChangeLog file).
- Autotools: Under Linux, make sure that the old dtags (when supported)
  are used if LD_LIBRARY_PATH is defined; otherwise "make check" would
  check an installed, compatible MPFR library found in LD_LIBRARY_PATH
  instead of the one that has been built with "make".

Please send success and failure reports with "./config.guess" output
to .

If no problems are found, GNU MPFR 3.1.6 should be released
around 2017-09-07.

Regards,

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

GCJ wiki page

[Vincent Lefevre]

Hi,

The GCJ wiki page https://gcc.gnu.org/wiki/GCJ appears to be very
obsolete. According to this page, GCJ is part of GCC, but AFAIK,
GCJ has been removed from GCC.

Regards,

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: [RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates

[Vincent Lefevre]

On 2017-05-12 15:59:44 -0500, Daniel Santos wrote:
> [...] But from a conceptual standpoint, I believe the term
> "constant-expression" would be incorrect because the C standard
> defines this constraint: (6.6.3 of C11) "Constant expressions shall
> not contain assignment, increment, decrement, function-call, or
> comma operators, except when they are contained within a
> subexpression that is not evaluated." I definitely do need to study
> the C specs more carefully to make sure I fully understand how this
> is used and how it's changed over different revisions of the spec.

GCC already regards some function calls are acceptable in
constant expressions, when builtins are used, e.g. fabs (2.0),
contrary to Clang. The builtin is even used when  is
not included (note that Clang has the same behavior here). So,
there may be several issues. I've reported:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80756

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: [PING][RFC] Assertions as optimization hints

[Vincent Lefevre]

On 2016-11-28 18:49:55 +, Yuri Gribov wrote:
> On Mon, Nov 28, 2016 at 4:03 PM, Vincent Lefevre <vincent+...@vinc17.org> 
> wrote:
> > Concerning the "per-project decision", I'm not sure that's a good
> > idea: as soon as one includes a header file, __ASSUME_ASSERTS__
> > could potentially break code.
> 
> Sorry, not sure I understood. __ASSUME_ASSERTS__ is supplied via
> cmdline when compiling project's shared libraries and executables to
> treat assertions as hints (effectively similar to MS __assume
> directives). It does not propagate to project's public header files.

What I was thinking of is that header files can contain calls to
assert(), e.g. via macros or inlined function (or classes in C++). For
instance, I can see the use of assert() in the following header files:

  /usr/include/ncursesw/cursesf.h
  /usr/include/ncursesw/cursesm.h

So, if the behavior of assert() is globally changed for a project that
uses ncursesw, this is bad as this would affect ncursesw too. Now, if
__ASSUME_ASSERTS__ does not propagate to "external" header files,
that's fine. But I wonder how this is implemented, i.e. to know which
header files should be affected which of them shouldn't, and how macro
definitions are affected, so that macros are expanded with the
expected behavior. This doesn't seem to be simple.

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: [PING][RFC] Assertions as optimization hints

[Vincent Lefevre]

On 2016-11-23 16:03:44 +, Yuri Gribov wrote:
> Definitely, aggressively abusing assertions like this should be a
> per-project decision. E.g. I've seen code which parallels assertions
> with error checking i.e. something like
>   FILE *p = fopen(...);
>   assert(p);  // Quickly abort in debug mode
>   if (!p)
> return ERROR;
> Enabling __ASSUME_ASSERTS__ for such code would effectively disable
> all safety checks.

Yes, the problem comes from the fact that ISO C provides only one
form of assertions. In GNU MPFR, we have two kinds of assertions
(different from the one used above), but they are not based on
assert():

   MPFR_ASSERTN(expr): assertions that should normally be checked,
 otherwise give a hint to the compiler.

   MPFR_ASSERTD(expr): assertions that should be checked when testing,
 otherwise give a hint to the compiler.

Basically, MPFR_ASSERTN() will be used to do some checks on data
provided by the caller (e.g. to detect some API misuse), and
MPFR_ASSERTD() is there to detect internal inconsistencies (i.e.
bugs in MPFR).

IMHO, this is the correct way to do, as one can then enables hints
without breaking code like the above one.

Concerning the "per-project decision", I'm not sure that's a good
idea: as soon as one includes a header file, __ASSUME_ASSERTS__
could potentially break code. Said otherwise, if the user wants
optimization hints, it should not be based on assert().

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Announce: GNU MPFR 3.1.5 is released

[Vincent Lefevre]

GNU MPFR 3.1.5 ("canard à l'orange", patch level 5), a C library for
multiple-precision floating-point computations with correct rounding,
is now available for download from the MPFR web site:

  http://www.mpfr.org/mpfr-3.1.5/

from InriaForge:

  https://gforge.inria.fr/projects/mpfr/

and from the GNU FTP site:

  http://ftp.gnu.org/gnu/mpfr/

Thanks very much to those who sent us bug reports and/or tested the
release candidate.

The SHA1 digests:
874e84bb5959fd5a19c032cfb5d673dded4b5cff  mpfr-3.1.5.tar.bz2
2a2118179f8f3c682389dcddc800d30132e8794a  mpfr-3.1.5.tar.gz
c0fab77c6da4cb710c81cc04092fb9bea11a9403  mpfr-3.1.5.tar.xz
4527506f6f915add129fe769e36b82e7b4814d44  mpfr-3.1.5.zip

The SHA256 digests:
ca498c1c7a74dd37a576f353312d1e68d490978de4395fa28f1cbd46a364e658  
mpfr-3.1.5.tar.bz2
f4eb5070883aee3fd8b927751ea63ff95aebe24418cde852439ce74c3dd2513c  
mpfr-3.1.5.tar.gz
015fde82b3979fbe5f83501986d328331ba8ddf008c1ff3da3c238f49ca062bc  
mpfr-3.1.5.tar.xz
83f6dbf4e5a07459c03c9075d781e06b235852cfb234d108e70b0749c83b10f4  mpfr-3.1.5.zip

The signatures:
http://www.mpfr.org/mpfr-3.1.5/mpfr-3.1.5.tar.xz.asc
http://www.mpfr.org/mpfr-3.1.5/mpfr-3.1.5.tar.bz2.asc
http://www.mpfr.org/mpfr-3.1.5/mpfr-3.1.5.tar.gz.asc
http://www.mpfr.org/mpfr-3.1.5/mpfr-3.1.5.zip.asc

Each tarball is signed by Vincent Lefèvre. This can be verified using
the DSA key ID 980C197698C3739D; this key can be retrieved with:

  gpg --recv-keys 980C197698C3739D

or by downloading it from .
The key fingerprint is:

  07F3 DBBE CC1A 3960 5078  094D 980C 1976 98C3 739D

The signatures can be verified with: gpg --verify 
You should check that the key fingerprint matches.

Changes from version 3.1.4 to version 3.1.5:
- C++11 compatibility.
- Bug fixes (see  and ChangeLog file).
- More tests.

You can send success and failure reports to , and give
us the canonical system name (by running the "./config.guess" script),
the processor and the compiler version, in order to complete the
"Platforms Known to Support MPFR" section of the MPFR 3.1.5 web page.

Regards,

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Is this FE bug or am I missing something?

[Vincent Lefevre]

On 2016-09-14 08:35:34 +0100, Andrew Haley wrote:
> On 12/09/16 20:41, Igor Shevlyakov wrote:
> > It would be beneficial to make the behaviour consistent between
> > those 2 cases.
> 
> You've got two cases of undefined behaviour.  What benefit
> is there from making two cases of UB consistent with each other?

Since this is UB and detected as UB, shouldn't this be regarded as
dead code, so shouldn't the generated code be removed to save memory
and improve locality?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

GNU MPFR 3.1.5 Release Candidate

[Vincent Lefevre]

The release of GNU MPFR 3.1.5 ("canard à l'orange", patch level 5)
is imminent. Please help to make this release as good as possible
by downloading and testing this release candidate:

http://www.mpfr.org/mpfr-3.1.5/mpfr-3.1.5-rc1.tar.xz
http://www.mpfr.org/mpfr-3.1.5/mpfr-3.1.5-rc1.tar.bz2
http://www.mpfr.org/mpfr-3.1.5/mpfr-3.1.5-rc1.tar.gz
http://www.mpfr.org/mpfr-3.1.5/mpfr-3.1.5-rc1.zip

The SHA1 digests:
7a0e51e732fb035a58ad0c8d13a95ea85b4dbdb3  mpfr-3.1.5-rc1.tar.bz2
e14126711c7541b166051d735f86e360a8f76d34  mpfr-3.1.5-rc1.tar.gz
b301a4dfa3ed1303077ee1b2777b2db8210a8876  mpfr-3.1.5-rc1.tar.xz
ebf8a873d07625d990abd323d3c972136659334a  mpfr-3.1.5-rc1.zip

The SHA256 digests:
e857a6dcaed69414952f6d74eea1de9147b9c60744ff34465e55927123c0fcf2  
mpfr-3.1.5-rc1.tar.bz2
358a2f8845b4a5886ea1fda76fe04043e8f023edc3b107f6375bd56eccfbafa7  
mpfr-3.1.5-rc1.tar.gz
cbe7fec47c60786e786e9c0bc6ef3e904ee113be19afc8fe653ab63f26119d08  
mpfr-3.1.5-rc1.tar.xz
f778cffef410729f2aa51709d69fb8c3b80bcb835e8481466d262f4c143f9be2  
mpfr-3.1.5-rc1.zip

The signatures:
http://www.mpfr.org/mpfr-3.1.5/mpfr-3.1.5-rc1.tar.xz.asc
http://www.mpfr.org/mpfr-3.1.5/mpfr-3.1.5-rc1.tar.bz2.asc
http://www.mpfr.org/mpfr-3.1.5/mpfr-3.1.5-rc1.tar.gz.asc
http://www.mpfr.org/mpfr-3.1.5/mpfr-3.1.5-rc1.zip.asc

Each tarball is signed by Vincent Lefèvre. This can be verified using
the DSA key ID 980C197698C3739D; this key can be retrieved with:

  gpg --recv-keys 980C197698C3739D

or by downloading it from .
The key fingerprint is:

  07F3 DBBE CC1A 3960 5078  094D 980C 1976 98C3 739D

The signatures can be verified with: gpg --verify 
You should check that the key fingerprint matches.

Changes from version 3.1.4 to version 3.1.5:
- C++11 compatibility.
- Bug fixes (see  and ChangeLog file).
- More tests.

Please send success and failure reports with "./config.guess" output
to .

If no problems are found, GNU MPFR 3.1.5 should be released
around 2016-09-20.

Regards,

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Announce: GNU MPFR 3.1.4 is released

[Vincent Lefevre]

GNU MPFR 3.1.4 ("canard à l'orange", patch level 4), a C library for
multiple-precision floating-point computations with correct rounding,
is now available for download from the MPFR web site:

  http://www.mpfr.org/mpfr-3.1.4/

from InriaForge:

  https://gforge.inria.fr/projects/mpfr/

and from the GNU FTP site:

  http://ftp.gnu.org/gnu/mpfr/

Thanks very much to those who sent us bug reports and/or tested the
release candidate.

The SHA1 digests:
e3b0af77f18505184410d621fe0aae179e229dba  mpfr-3.1.4.tar.bz2
272212c889d0ad6775ab6f315d668f3d01d1eaa3  mpfr-3.1.4.tar.gz
cedc0055d55b6ee4cd17e1e6119ed412520ff81a  mpfr-3.1.4.tar.xz
8bad43f51fd9f4710e79fa7a274ccae7ca72a38c  mpfr-3.1.4.zip

The SHA256 digests:
d3103a80cdad2407ed581f3618c4bed04e0c92d1cf771a65ead662cc397f7775  
mpfr-3.1.4.tar.bz2
0d4de7e1476f79d24c38d5bc04a06fcc9a1bb9cf35fd654ceada29af03ad1844  
mpfr-3.1.4.tar.gz
761413b16d749c53e2bfd2b1dfaa3b027b0e793e404b90b5fbaeef60af6517f5  
mpfr-3.1.4.tar.xz
81285def6be6d7aae6dba1944e5fad3f016752fc6a7ceede8a6f2a22fc36f1dd  mpfr-3.1.4.zip

The signatures:
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4.tar.xz.asc
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4.tar.bz2.asc
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4.tar.gz.asc
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4.zip.asc

Each tarball is signed by Vincent Lefèvre. This can be verified
using the DSA key ID 98C3739D; this key can be retrieved with:

  gpg --recv-keys 98C3739D

or by downloading it from .
The key fingerprint is:

  07F3 DBBE CC1A 3960 5078  094D 980C 1976 98C3 739D

The signatures can be verified with: gpg --verify 
You should check that the key fingerprint matches.

Changes from version 3.1.3 to version 3.1.4:
- Improved MPFR manual.
- Bug fixes (see  and ChangeLog file).
- MinGW (MS Windows): Added support for thread-safe DLL (shared library).

You can send success and failure reports to , and give
us the canonical system name (by running the "./config.guess" script),
the processor and the compiler version, in order to complete the
"Platforms Known to Support MPFR" section of the MPFR 3.1.4 web page.

Regards,

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

GNU MPFR 3.1.4 Release Candidate 2

[Vincent Lefevre]

The release of GNU MPFR 3.1.4 ("canard à l'orange", patch level 4)
is imminent. Please help to make this release as good as possible
by downloading and testing this release candidate:

http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4-rc2.tar.xz
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4-rc2.tar.bz2
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4-rc2.tar.gz
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4-rc2.zip

The SHA1 digests:
cb51ad47aeed9f4261cb1d2b71dd1e5d07303a23  mpfr-3.1.4-rc2.tar.bz2
df3a6d8ce6bc8ec9166f102e267223629210e7ce  mpfr-3.1.4-rc2.tar.gz
a5b77eea480675aef0b2655ea8c137361dd1a396  mpfr-3.1.4-rc2.tar.xz
b59f0ca5a05f7aba6448bbc68d00aad3249878ec  mpfr-3.1.4-rc2.zip

The SHA256 digests:
b98e116590642dcf64b4d82206703569c2a1ac5e004e4a2567324fa7c7b524ce  
mpfr-3.1.4-rc2.tar.bz2
cb0f85717fd32e59f02cc5745587bd2b2f6d6b5d5e591026c39002b409061d8a  
mpfr-3.1.4-rc2.tar.gz
9c7415c407bb6b510916230515b818a1cf1e3fa66c2837c7ebf7f50cc9b236f1  
mpfr-3.1.4-rc2.tar.xz
69345e587ba8977a434992f20095c21199aafc8fe4e04f9804222aa154fc1b08  
mpfr-3.1.4-rc2.zip

The signatures:
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4-rc2.tar.xz.asc
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4-rc2.tar.bz2.asc
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4-rc2.tar.gz.asc
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4-rc2.zip.asc

Each tarball is signed by Vincent Lefèvre. This can be verified
using the DSA key ID 98C3739D; this key can be retrieved with:

  gpg --recv-keys 98C3739D

or by downloading it from .
The key fingerprint is:

  07F3 DBBE CC1A 3960 5078  094D 980C 1976 98C3 739D

The signatures can be verified with: gpg --verify 
You should check that the key fingerprint matches.

Changes from version 3.1.3 to version 3.1.4:
- Improved MPFR manual.
- Bug fixes (see  and ChangeLog file).
- MinGW (MS Windows): Added support for thread-safe DLL (shared library).

Please send success and failure reports with "./config.guess" output
to .

If no problems are found, GNU MPFR 3.1.4 should be released
around 2016-03-05.

Regards,

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

GNU MPFR 3.1.4 Release Candidate

[Vincent Lefevre]

The release of GNU MPFR 3.1.4 ("canard à l'orange", patch level 4)
is imminent. Please help to make this release as good as possible
by downloading and testing this release candidate:

http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4-rc1.tar.xz
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4-rc1.tar.bz2
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4-rc1.tar.gz
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4-rc1.zip

The SHA1 digests:
c4b149a6e077974b11203f08c64122e0025730ba  mpfr-3.1.4-rc1.tar.bz2
29d7dfaa2d31d38256f430d40a5514ba1953d2d6  mpfr-3.1.4-rc1.tar.gz
28116be85b2875a1c8ca6c12c84a2efd44db0322  mpfr-3.1.4-rc1.tar.xz
85fbadfb19be45f8f9745316a55f35ca9e9cfe59  mpfr-3.1.4-rc1.zip

The SHA256 digests:
f42d3b38237b62e9c8d15affd971c6833910538a716e6684f9e11f9860e65e76  
mpfr-3.1.4-rc1.tar.bz2
71813f92c0d73b4f8e551ea4d10c0ccb93c62d9b6d2667a76570300f812a018c  
mpfr-3.1.4-rc1.tar.gz
e9b216906625cacdcbe9d89e0895609f6d990020746b4f22917c40f4bdef7ea7  
mpfr-3.1.4-rc1.tar.xz
90b685dd5ed738b5aa2a11ec4dcfc2dfc136632d0bfcf2a14e4726642daa1a56  
mpfr-3.1.4-rc1.zip

The signatures:
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4-rc1.tar.xz.asc
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4-rc1.tar.bz2.asc
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4-rc1.tar.gz.asc
http://www.mpfr.org/mpfr-3.1.4/mpfr-3.1.4-rc1.zip.asc

Each tarball is signed by Vincent Lefèvre. This can be verified
using the DSA key ID 98C3739D; this key can be retrieved with:

  gpg --recv-keys 98C3739D

or by downloading it from .
The key fingerprint is:

  07F3 DBBE CC1A 3960 5078  094D 980C 1976 98C3 739D

The signatures can be verified with: gpg --verify 
You should check that the key fingerprint matches.

Changes from version 3.1.3 to version 3.1.4:
- Improved MPFR manual.
- Bug fixes (see  and ChangeLog file).

Please send success and failure reports with "./config.guess" output
to .

If no problems are found, GNU MPFR 3.1.4 should be released
around 2016-03-02.

Regards,

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: UTF-8 quotation marks in diagnostics

[Vincent Lefevre]

On 2015-10-22 20:11:15 +, Joseph Myers wrote:
> LC_CTYPE should affect the interpretation of multibyte character sequences 
> as characters, including on output.  That's the standard semantics.

That's only for the recommended default behavior. There are many
contexts where different charset information is provided.

Other than that, LC_CTYPE is assumed to correspond to the charset
of the terminal.

> That's what all C library functions involving interpretation of multibyte 
> character sequences do.  Straightforward use of POSIX library interfaces 
> does not support producing output in a character set other than that 
> specified with LC_CTYPE; e.g. printf expects a format string (possibly 
> resulting from a message catalog) in the LC_CTYPE character set, and does 
> not convert the bytes to another character set.
[...]

Only when a setlocale() with appropriate arguments is done.
A C program is free to use other locales than declared by
the LC_* environment variables when this makes sense.

> Again, LC_CTYPE does *not* affect source file interpretation.
[...]

> You could write your "c99" program wrapper to add a -finput-charset= 
> option based on the locale's character set if you so wish (it also needs 
> to do things such as option reordering and handling -O with separate 
> argument - the "gcc" driver deliberately processes -D and -U options in 
> the order they appear on the command line, not following the POSIX rule 
> that -U options take precedence over -D - so you should not expect the 
> "gcc" driver to be usable as "c99" without such adaptation for deliberate 
> differences).
> 
> I think we should clearly update the documentation to reflect reality 
> regarding source file encoding, and leave it strictly for wrappers such as 
> "c99" to specify -finput-charset= options rather than leaving open the 
> possibility that GCC's own default might change in future.

The documentation should also say whether LC_CTYPE affects the
command-line arguments (e.g. macro values via -D) and in what way
it affects the output (e.g. messages and output of "gcc -E").

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Announce: GNU MPFR 3.1.3 is released

[Vincent Lefevre]

GNU MPFR 3.1.3 (canard à l'orange, patch level 3), a C library for
multiple-precision floating-point computations with correct rounding,
is now available for download from the MPFR web site:

  http://www.mpfr.org/mpfr-3.1.3/

from InriaForge:

  https://gforge.inria.fr/projects/mpfr/

and from the GNU FTP site:

  http://ftp.gnu.org/gnu/mpfr/

Thanks very much to those who sent us bug reports and/or tested the
release candidate.

The MD5's:
5fdfa3cfa5c86514ee4a241a1affa138  mpfr-3.1.3.tar.bz2
7b650781f0a7c4a62e9bc8bdaaa0018b  mpfr-3.1.3.tar.gz
6969398cd2fbc56a6af570b5273c56a9  mpfr-3.1.3.tar.xz
d21b855a5d49c91a7a2d265e32342fa3  mpfr-3.1.3.zip

The SHA1's:
3e46c5ce43701f2f36f9d01f407efe081700da80  mpfr-3.1.3.tar.bz2
b48bec6fcc9c0458e38150778f2be85d1665aadc  mpfr-3.1.3.tar.gz
383303f9de5ebe055b03b94642b03465baf9e6c7  mpfr-3.1.3.tar.xz
29fa44b9345e9d16c88c2f809d53e0df290037e2  mpfr-3.1.3.zip

The signatures:
http://www.mpfr.org/mpfr-3.1.3/mpfr-3.1.3.tar.xz.asc
http://www.mpfr.org/mpfr-3.1.3/mpfr-3.1.3.tar.bz2.asc
http://www.mpfr.org/mpfr-3.1.3/mpfr-3.1.3.tar.gz.asc
http://www.mpfr.org/mpfr-3.1.3/mpfr-3.1.3.zip.asc

Each tarball is signed by Vincent Lefèvre. This can be verified
using the DSA key ID 98C3739D; this key can be retrieved with:

  gpg --recv-keys 98C3739D

or by downloading it from https://www.vinc17.net/pgp.html.
The key fingerprint is:

  07F3 DBBE CC1A 3960 5078  094D 980C 1976 98C3 739D

The signatures can be verified with: gpg --verify file.asc
You should check that the key fingerprint matches.

Changes from version 3.1.2 to version 3.1.3:
- Better support for Automake 1.13+ (now used to generate the tarball).
- Improved MPFR manual.
- Bug fixes (see http://www.mpfr.org/mpfr-3.1.2/#fixed and ChangeLog file).

You can send success and failure reports to m...@inria.fr, and give
us the canonical system name (by running the ./config.guess script),
the processor and the compiler version, in order to complete the
Platforms Known to Support MPFR section of the MPFR 3.1.3 web page.

Regards,

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

GNU MPFR 3.1.3 Release Candidate

[Vincent Lefevre]

The release of GNU MPFR 3.1.3 (canard à l'orange patch level 3)
is imminent. Please help to make this release as good as possible
by downloading and testing this release candidate:

http://www.mpfr.org/mpfr-3.1.3/mpfr-3.1.3-rc1.tar.xz
http://www.mpfr.org/mpfr-3.1.3/mpfr-3.1.3-rc1.tar.bz2
http://www.mpfr.org/mpfr-3.1.3/mpfr-3.1.3-rc1.tar.gz
http://www.mpfr.org/mpfr-3.1.3/mpfr-3.1.3-rc1.zip

The MD5's:
f8a0180c2b31c0f9ce32dc44e1035fae  mpfr-3.1.3-rc1.tar.bz2
b1a32a83549164b0aa7ffd6678449ac2  mpfr-3.1.3-rc1.tar.gz
e7f64614e5b080bcfccdaf8c9c3d972d  mpfr-3.1.3-rc1.tar.xz
f57a88396cba13bef4cb2f80c70390c5  mpfr-3.1.3-rc1.zip

The SHA1's:
515131a35a93e699c4f7de272f9fb509703e0179  mpfr-3.1.3-rc1.tar.bz2
005021d9b167b5f94f23a7983a5f24719a714166  mpfr-3.1.3-rc1.tar.gz
625010d3617c653b2f0caf87e7d9391baedad5a1  mpfr-3.1.3-rc1.tar.xz
0ac3edc7446fe3ab31e105a83d6aa93744516049  mpfr-3.1.3-rc1.zip

The signatures:
http://www.mpfr.org/mpfr-3.1.3/mpfr-3.1.3-rc1.tar.xz.asc
http://www.mpfr.org/mpfr-3.1.3/mpfr-3.1.3-rc1.tar.bz2.asc
http://www.mpfr.org/mpfr-3.1.3/mpfr-3.1.3-rc1.tar.gz.asc
http://www.mpfr.org/mpfr-3.1.3/mpfr-3.1.3-rc1.zip.asc

Each tarball is signed by Vincent Lefèvre. This can be verified
using the DSA key ID 98C3739D; this key can be retrieved with:

  gpg --recv-keys 98C3739D

or by downloading it from https://www.vinc17.net/pgp.html.
The key fingerprint is:

  07F3 DBBE CC1A 3960 5078  094D 980C 1976 98C3 739D

The signatures can be verified with: gpg --verify file.asc
You should check that the key fingerprint matches.

Changes from version 3.1.2 to version 3.1.3:
- Better support for Automake 1.13+ (now used to generate the tarball).
- Improved MPFR manual.
- Bug fixes (see http://www.mpfr.org/mpfr-3.1.2/#fixed and ChangeLog file).

Please send success and failure reports with ./config.guess output
to m...@inria.fr.

If no problems are found, GNU MPFR 3.1.3 should be released
around 2015-06-20.

Regards,

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Undefined behavior due to 6.5.16.1p3

[Vincent Lefevre]

On 2015-03-12 13:55:50 -0600, Martin Sebor wrote:
 On 03/12/2015 03:10 AM, Vincent Lefevre wrote:
 Well, this depends on the interpretation of effective types in the
 case of a union. For instance, when writing
 
union { char a[16]; int b; } u;
u.b = 1;
 
 you don't set the member only (an int), but the whole union object is
 affected, even bytes that are not parts of the int. So, one may see
 the effective type as being the union type.
 
 The purpose of the term /effective type/ is to make it possible
 to talk about types of allocated objects (those with no declared
 type). In the example above, u.b is declared to have the type
 int and assigning to it doesn't change the type of other members
 of the union. But because u.a has a character type the value of
 u.b can be accessed via u.a (or any other lvalue of that type).

But if an object is declared with type T, the effective type of this
object is T, right? So, above, the effective type of u is the union
{ char a[16]; int b; } type.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Undefined behavior due to 6.5.16.1p3

[Vincent Lefevre]

On 2015-03-11 17:39:31 +0100, Jakub Jelinek wrote:
 On Wed, Mar 11, 2015 at 05:31:01PM +0100, Vincent Lefevre wrote:
   (in C only one union member can be active at any time,
   we as extension allow type punning through unions etc.)
  
  I disagree that it is an extension. The standard does not say
  that one union member can be active at any time.
 
 That is not a standard wording, but what I meant is
 6.2.6.1p7 - that when you store some union member other union members take
 unspecified values.

Well, the values are unspecified, but the value can sometimes be
deduced from what is stored.

BTW, the C11 draft I have says:

  When a value is stored in a member of an object of union type, the
  bytes of the object representation that do not correspond to that
  member but do correspond to other members take unspecified values.

Note the that do not correspond to that member but do correspond to
other members.

This means that on a machine where an int takes 4 bytes, if one has:

  union { unsigned char a[8]; int b; } u = { .a = { 0 } };
  u.b = 1;

Then the last 4 bytes of u.a take unspecified values. But the first
4 bytes depend on the representation of the int 1, and if this
representation is well-specified by the implementation (e.g. no
padding bits...), which can sometimes be deduced, then the first
4 bytes of u.a are known and one can access them via u.a.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Undefined behavior due to 6.5.16.1p3

[Vincent Lefevre]

BTW, the following is forbidden (and makes no sense), but is accepted
by GCC without a warning:

int foo (void)
{
  union { char a[8]; int b; } u = { .a = { 0 }, .b = 1 };
  return u.b;
}

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Undefined behavior due to 6.5.16.1p3

[Vincent Lefevre]

On 2015-03-12 00:19:55 +0100, Robbert Krebbers wrote:
 On 03/11/2015 05:31 PM, Vincent Lefevre wrote:
 I disagree that it is an extension. The standard does not say
 that one union member can be active at any time.
 
 The interpretation under which this is allowed in confirmed by
 Note 95 of 6.5.2.3p3.
 Effective types disallow to access a union member other than the current one
 arbitrarily, so naively effective types contradict note 95 of 6.5.2.3p3.

Well, this depends on the interpretation of effective types in the
case of a union. For instance, when writing

  union { char a[16]; int b; } u;
  u.b = 1;

you don't set the member only (an int), but the whole union object is
affected, even bytes that are not parts of the int. So, one may see
the effective type as being the union type.

The item an aggregate or union type that includes one of the
aforementioned types among its members (including, recursively,
a member of a subaggregate or contained union), or about aliasing
is also very unclear.

If you think that something contradicts note 95, you should write a
defect report.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Undefined behavior due to 6.5.16.1p3

[Vincent Lefevre]

On 2015-03-12 01:05:42 +, Joseph Myers wrote:
 On Wed, 11 Mar 2015, Vincent Lefevre wrote:
 
  BTW, the following is forbidden (and makes no sense), but is accepted
  by GCC without a warning:
  
  int foo (void)
  {
union { char a[8]; int b; } u = { .a = { 0 }, .b = 1 };
return u.b;
  }
 
 What constraint do you think forbids it?  It looks like an ordinary case 
 of overriding with designated initializers.

It seems that the standard doesn't specify the behavior.

Concerning the override, I could only see 6.7.9p19, which says:

  The initialization shall occur in initializer list order, each
  initializer provided for a particular subobject overriding any
  previously listed initializer for the same subobject;151)

but in the case of a union, .a and .b are not the same subobject
since they don't have the same type (and not necessarily the same
size).

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Undefined behavior due to 6.5.16.1p3

[Vincent Lefevre]

On 2015-03-11 17:11:55 +0100, Jakub Jelinek wrote:
 On Wed, Mar 11, 2015 at 05:08:16PM +0100, Vincent Lefevre wrote:
  On 2015-03-11 14:27:25 +0100, Robbert Krebbers wrote:
   But what about long long on 32 bits machines. For example:
   
   union {
 long long a;
 struct { char b1; long long b2; } b;
   } u;
   
   Will GCC perform similar optimizations as for the case of big structs? I
   tried to play around with long long in Martin's example, but failed to
   trigger unexpected behaviors in GCC.
  
  I've not tried, but how about something like:
  
  struct S { long a, b, c, d; };
  union U {
struct S a;
struct { char b1; struct S b2; } b;
  };
  u.b.b2 = u.a;
  
  or: u.a = u.b.b2;
  
  IMHO, struct S should be large enough to avoid using registers as
  a temporary area (just in case...).
 
 There is some PR about it in our bugzilla, and the conclusion is that
 it is both invalid

I agree that this is invalid, but Robbert wanted such an example
of 6.5.16.1p3 showing that it was indeed undefined behavior.

 (in C only one union member can be active at any time,
 we as extension allow type punning through unions etc.)

I disagree that it is an extension. The standard does not say
that one union member can be active at any time.

The interpretation under which this is allowed in confirmed by
Note 95 of 6.5.2.3p3.

 and we really don't want to support it.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Undefined behavior due to 6.5.16.1p3

[Vincent Lefevre]

On 2015-03-11 14:27:25 +0100, Robbert Krebbers wrote:
 But what about long long on 32 bits machines. For example:
 
 union {
   long long a;
   struct { char b1; long long b2; } b;
 } u;
 
 Will GCC perform similar optimizations as for the case of big structs? I
 tried to play around with long long in Martin's example, but failed to
 trigger unexpected behaviors in GCC.

I've not tried, but how about something like:

struct S { long a, b, c, d; };
union U {
  struct S a;
  struct { char b1; struct S b2; } b;
};
u.b.b2 = u.a;

or: u.a = u.b.b2;

IMHO, struct S should be large enough to avoid using registers as
a temporary area (just in case...).

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: fast-math optimization question

[Vincent Lefevre]

On 2014-10-10 11:07:52 +0200, Jakub Jelinek wrote:
 Though, is such optimization desirable even for fast-math?

I wonder whether fast-math has a well-defined spec, but it should be
noted that because of possible cancellations, even if the final result
is a float, it may be better to keep intermediate results in double
if the user has used double types (explicitly or implicitly via a
function that returns a double). For instance, if x is a double,
(float) sin(x) and (float) sin((float) x) can give very different
results if x is large compared to the period (2*pi).

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

FloatingPointMath and transformations

[Vincent Lefevre]

I've looked at

  https://gcc.gnu.org/wiki/FloatingPointMath

and there may be some mistakes or missing info.

First, it is said that x / C is replaced by x * (1.0 / C) when C is
a power of two. But this condition is not sufficient: if 1.0 / C
overflows, the transformation is incorrect. From some testing,
it seems that GCC detects the overflow case, so that it behaves
correctly. In this case I think that the wiki should say:
When C is a power of two and 1.0 / C doesn't overflow.

It is also said that x / 1.0 and x / -1.0 are respectively replaced
by x and -x. But what about x * 1.0 and x * -1.0?

Ditto with -(a / b) - a / -b and -(a / b) - -a / b. Is there
anything similar with multiplication?

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: FloatingPointMath and transformations

[Vincent Lefevre]

On 2014-06-02 17:34:31 +0200, Andreas Schwab wrote:
 Jakub Jelinek ja...@redhat.com writes:
 
  If C is a power of two, then 1.0 / C should IMHO never overflow,
 
 It does if C is subnormal.

More precisely, in case of double precision, if C = DBL_MIN / 2,
1.0 / C doesn't overflow, but if C = DBL_MIN / 4 (or is smaller),
1.0 / C overflows.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: PowerPC IEEE 128-bit floating point: Internal GCC types

[Vincent Lefevre]

On 2014-06-02 21:20:57 +, Joseph S. Myers wrote:
 ([...] Conversion from __float128 to __ibm128 would presumably be
 done in the usual way of converting to double, and, if the result is
 finite, subtracting the double from the __float128 value, converting
 the remainder, and renormalizing in case the low part you get that
 way is exactly 0.5ulp of the high part and the high part has its low
 bit set.)

This is not as simple, depending on how you decide to handle the
largest values. This is important if FP-model related data are
provided, such as LDBL_MANT_DIG (the precision) and LDBL_MAX_EXP
(the maximum exponent). The __ibm128 implementation as long double
is currently buggy / inconsistent, and I've reported the following
bug:

  https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61399

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: FloatingPointMath and transformations

[Vincent Lefevre]

On 2014-06-02 10:33:37 -0400, Geert Bosch wrote:
 It should, or it would be a bug. Please feel free to add/correct
 anything on this page.

I am not a member of EditorGroup.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Draft C bindings for IEEE 754-2008 part 4 now available

[Vincent Lefevre]

On 2014-01-07 16:45:49 +, Joseph S. Myers wrote:
 Sure, such a correctly rounded function is useful just like correctly 
 rounded versions of other functions.  The proposed C bindings reserve cr* 
 names *only* for the specific functions listed in 9.2 where IEEE 754 
 recommends correctly rounded functions, not for other existing ISO C 
 functions (e.g. erf, tgamma) or functions added by the C bindings by 
 analogy with other IEEE 754 functions (e.g. tanpi), but I think correctly 
 rounded versions of other functions (with the same naming convention) 
 could reasonably be added to glibc if anyone wishes to implement them.

New CR functions may be added in future revisions of IEEE 754, so
that I think that cr* names should be reserved for all functions.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Draft C bindings for IEEE 754-2008 part 4 now available

[Vincent Lefevre]

On 2014-01-08 13:31:40 +, Joseph S. Myers wrote:
 I advise making such suggestions direct to WG14.  (I don't know if such 
 names should be reserved for correctly rounded complex arithmetic as well 
 - where ordinary complex multiplication and division are not expected to 
 be correctly rounded at present.)
 
 (I'm currently chasing up possible issues with mail from some people not 
 getting through to the WG14 list - the only floating-point TS comments 
 I've seen there so far are mine and Paul Eggert's, so if anyone else 
 reading this discussion has sent comments on the drafts, please let me 
 know.)

OK, I've just sent comments to the reflector.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Draft C bindings for IEEE 754-2008 part 4 now available

[Vincent Lefevre]

On 2014-01-07 14:36:58 +, Joseph S. Myers wrote:
 (As far as I know, the state of the art on exhaustive searches for
 worst cases for correct rounding - as needed to implement correctly
 rounded transcendental functions with bounded resource use - does
 not make such searches feasible for IEEE binary128, which is a clear
 reason not to require such functions to be provided.)

Well, an implementation can still provide very accurate versions
(say, with a guaranteed 512 bits accuracy), and the functions will
be correctly rounded with a very high probability. In practice, the
proof of correct rounding can be obtained only with an exhaustive
search (well there is some hope to obtain a proof if the maximum
precision of the implementation is around several thousands bits).
The exhaustive search also allows one to optimize code even more.

On 2014-01-07 14:55:31 +, Andrew Haley wrote:
 On 01/07/2014 02:48 PM, Joseph S. Myers wrote:
  On Tue, 7 Jan 2014, Joseph S. Myers wrote:
  
  The IEEE 754 operations are corrected rounded.  However, the C bindings 
  
  (Except that the IEEE 754 reduction operations - subclause 9.4 - return 
  an implementation-defined approximation.  But 9.2 is Recommended 
  correctly rounded functions, e.g. exp and sin, for which the strictly 
  corresponding C functions are crexp and crsin.)
 
 Has anyone found a way to do it?  Even crlibm only provides routines
 that are probably correctly rounded.  Although I'll grant you that the
 probability of incorrect rounding is very low.

For some of them, this is proved. Here's a summary of the current
status:

  http://tamadiwiki.ens-lyon.fr/tamadiwiki/images/c/c1/Lefevre2013.pdf

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Draft C bindings for IEEE 754-2008 part 4 now available

[Vincent Lefevre]

On 2014-01-07 14:48:01 +, Joseph S. Myers wrote:
 (Except that the IEEE 754 reduction operations - subclause 9.4 - return 
 an implementation-defined approximation.  But 9.2 is Recommended 
 correctly rounded functions, e.g. exp and sin, for which the strictly 
 corresponding C functions are crexp and crsin.)

Some of the reduction operations may be standardized with the
correct rounding requirement in the future IEEE 1788 standard
on interval arithmetic (even though I think that such operations
do not belong to IEEE 1788), if it passes. In any case, they
should also have their own correctly rounded version.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Draft C bindings for IEEE 754-2008 part 4 now available

[Vincent Lefevre]

On 2014-01-07 16:18:48 +, Joseph S. Myers wrote:
 On Tue, 7 Jan 2014, Vincent Lefevre wrote:
 
  For some of them, this is proved. Here's a summary of the current
  status:
  
http://tamadiwiki.ens-lyon.fr/tamadiwiki/images/c/c1/Lefevre2013.pdf
 
 Thanks for the details.  What's the current state of the art on the 
 asymptotic cost of the exhaustive searches?

The theoretical bound is O(N^(2/3+epsilon)), where N is the number
of inputs. In practice, for binary128 (N ~ 2^128), this is already
unfeasible.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Announce: GNU MPFR 3.1.2 is released

[Vincent Lefevre]

GNU MPFR 3.1.2 (canard à l'orange, patch level 2) is now available
for download from the MPFR web site:

  http://www.mpfr.org/mpfr-3.1.2/

from INRIAGForge:

  https://gforge.inria.fr/projects/mpfr/

and from the GNU FTP site:

  http://ftp.gnu.org/gnu/mpfr/

Thanks very much to those who sent us bug reports and/or tested the
release candidate.

The MD5's:
ee2c3ac63bf0c2359bf08fc3ee094c19  mpfr-3.1.2.tar.bz2
181aa7bb0e452c409f2788a4a7f38476  mpfr-3.1.2.tar.gz
e3d203d188b8fe60bb6578dd3152e05c  mpfr-3.1.2.tar.xz
a25a48ed1b776f0cdc480338f1034617  mpfr-3.1.2.zip

The SHA1's:
46d5a11a59a4e31f74f73dd70c5d57a59de2d0b4  mpfr-3.1.2.tar.bz2
5ef83b835fe0a8bf29b7929394633252673e0d67  mpfr-3.1.2.tar.gz
03e593cc6e26639ef5e60be1af8dc527209e5172  mpfr-3.1.2.tar.xz
ed99cfc74a1df58953f3c2543e235587231a88ed  mpfr-3.1.2.zip

The signatures:
http://www.mpfr.org/mpfr-3.1.2/mpfr-3.1.2.tar.xz.asc
http://www.mpfr.org/mpfr-3.1.2/mpfr-3.1.2.tar.bz2.asc
http://www.mpfr.org/mpfr-3.1.2/mpfr-3.1.2.tar.gz.asc
http://www.mpfr.org/mpfr-3.1.2/mpfr-3.1.2.zip.asc

Each tarball is signed by Vincent Lefèvre. This can be verified
using the DSA key ID 98C3739D; this key can be retrieved with:

  gpg --recv-keys 98C3739D

or by downloading it from https://www.vinc17.net/pgp.html.
The key fingerprint is:

  07F3 DBBE CC1A 3960 5078  094D 980C 1976 98C3 739D

The signatures can be verified with: gpg --verify file.asc
You should check that the key fingerprint matches.

Changes from version 3.1.1 to version 3.1.2:
- Bug fixes (see http://www.mpfr.org/mpfr-3.1.1/#fixed or ChangeLog file).
- Updated examples to the MPFR 3.x API.

Note: The official tarballs for MPFR up to 3.1.1 were affected by a
vulnerability for make distcheck due to a bug in old GNU Automake
versions: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3386
One of the purposes of this release is to provide tarballs without
this vulnerability.

You can send success and failure reports to m...@inria.fr, and give
us the canonical system name (by running the ./config.guess script),
the processor and the compiler version, in order to complete the
Platforms Known to Support MPFR section of the MPFR 3.1.2 web page.

Regards,

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

GNU MPFR 3.1.2 Release Candidate

[Vincent Lefevre]

The release of GNU MPFR 3.1.2 (canard à l'orange patch level 2)
is imminent. Please help to make this release as good as possible
by downloading and testing this release candidate:

http://www.mpfr.org/mpfr-3.1.2/mpfr-3.1.2-rc1.tar.xz
http://www.mpfr.org/mpfr-3.1.2/mpfr-3.1.2-rc1.tar.bz2
http://www.mpfr.org/mpfr-3.1.2/mpfr-3.1.2-rc1.tar.gz
http://www.mpfr.org/mpfr-3.1.2/mpfr-3.1.2-rc1.zip

The MD5's:
3a95e02c8dc2897638eb998da837e63a  mpfr-3.1.2-rc1.tar.bz2
a273dd7752039b8753e09afdd9f0506b  mpfr-3.1.2-rc1.tar.gz
d8019782b2d3007c60fd292856a59104  mpfr-3.1.2-rc1.tar.xz
abb2a2fde5109219ab1bef2d55cb5742  mpfr-3.1.2-rc1.zip

The SHA1's:
38b1cd6f6ab0190d4b991d4bcdb24d112c9f  mpfr-3.1.2-rc1.tar.bz2
9a64b70a3d55c7f8a7faf81cf8f1ad74453dab3b  mpfr-3.1.2-rc1.tar.gz
36d0de647a00527f88c762363e449fcfc6be1375  mpfr-3.1.2-rc1.tar.xz
fc1b9df7a3779c115d1b4eb1aff5cc0f42b5307a  mpfr-3.1.2-rc1.zip

The signatures:
http://www.mpfr.org/mpfr-3.1.2/mpfr-3.1.2-rc1.tar.xz.asc
http://www.mpfr.org/mpfr-3.1.2/mpfr-3.1.2-rc1.tar.bz2.asc
http://www.mpfr.org/mpfr-3.1.2/mpfr-3.1.2-rc1.tar.gz.asc
http://www.mpfr.org/mpfr-3.1.2/mpfr-3.1.2-rc1.zip.asc

Each tarball is signed by Vincent Lefèvre. This can be verified
using the DSA key ID 98C3739D; this key can be retrieved with:

  gpg --recv-keys 98C3739D

or by downloading it from https://www.vinc17.net/pgp.html.
The key fingerprint is:

  07F3 DBBE CC1A 3960 5078  094D 980C 1976 98C3 739D

The signatures can be verified with: gpg --verify file.asc
You should check that the key fingerprint matches.

Changes from version 3.1.1 to version 3.1.2:
- Bug fixes (see http://www.mpfr.org/mpfr-3.1.1/#fixed or ChangeLog file).
- Updated examples to the MPFR 3.x API.

Note: The official tarballs for MPFR up to 3.1.1 were affected by a
vulnerability for make distcheck due to a bug in old GNU Automake
versions: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-3386
One of the purposes of this release is to provide tarballs without
this vulnerability.

Please send success and failure reports with ./config.guess output
to m...@inria.fr.

If no problems are found, GNU MPFR 3.1.2 should be released
around 2013-03-13.

Regards,

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: not-a-number's

[Vincent Lefevre]

On 2013-01-17 06:53:45 +0100, Mischa Baars wrote:
 Also this was not what I intended to do, I was trying to work with quiet
 not-a-numbers explicitly to avoid the 'invalid operation' exception to be
 triggered, so that my program can work it's way through the calculations
 without being terminated by the intervention of a signal handler. When any
 not-a-number shows up in results after execution, then you know something
 went wrong. When the program does what it is supposed to do, you could
 remove any remaining debug code, such as the boundary check in the
 trigonometric functions.

Checking whether a (final) result is NaN is not always the correct way
to detect whether something was wrong, because a NaN can disappear.
For instance, pow(NaN,0) gives 0, not NaN. You need to check the
invalid operation exception flag (if you don't want a trap). And
this flag will also be set by the =, , , = comparisons when one
of the operands is NaN, which should be fine for you.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: not-a-number's

[Vincent Lefevre]

On 2013-01-17 06:57:12 +0100, Mischa Baars wrote:
 What exactly do you mean by terminate the if??  Do you mean skip the
 whole compound statement, including any else clause?
 Yes, exactly. Skip it, including the 'else'.

This is not how C works. Perhaps instead of

  if (x  y)
...
  else
...

(where else means in any other case), you want:

  if (x  y)
...
  else if (x = y)
...

Then if x is NaN and/or y is NaN, neither the if nor the else
will be executed.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: not-a-number's

[Vincent Lefevre]

On 2013-01-17 15:01:20 +0100, Andreas Schwab wrote:
 Andreas Schwab sch...@suse.de writes:
  The C standard does not place any requirement on  wrt. exceptions or
  lack thereof.

Agreed, this is a may (7.12.14), but...

 But IEC 559 does, of course.

and in particular, if __STDC_IEC_559__ is defined, then raising
the exception is required.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: not-a-number's

[Vincent Lefevre]

On 2013-01-17 16:33:56 +0100, Mischa Baars wrote:
 Actually it is the correct way, as long as you stick to the
 conventions. A QNaN is not supposed to change into anything, also
 not with the pow(). Only the other way around. Normal numbers can
 change into QNaN's.

The C standard specified pow(NaN,0) = 1, pow(1,NaN) = 1, and
hypot(inf,NaN) = +inf. You may consider that these are bad choices
(I don't like them much either), but this is how these cases have
been specified. You are free to write wrappers for your own programs
and never call pow and hypot directly...

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: not-a-number's

[Vincent Lefevre]

On 2013-01-16 12:47:46 +0100, Mischa Baars wrote:
 On 01/16/2013 12:07 PM, Andrew Haley wrote:
 Comparisons with NaN don't terminate a statement, and they don't
 return a NaN.  They return a boolean.
 They shouldn't return anything, the comparison should be terminated.

This depends on the comparison and the context. You have quiet and
signaling comparisons. != and == are quiet comparisons: they never
generate an exception on quiet NaN operands. , =, =,  are
signaling comparisons: they generate an exception on quiet NaN
operands; but the comparison will be interrupted only if you trap
the invalid operation exception.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: not-a-number's

[Vincent Lefevre]

On 2013-01-16 14:53:42 +0100, Richard Biener wrote:
 You can enable FP exceptions via fpsetexceptflag and friends (it's
 disabled in the FPU by default) and if you then make sure to compile
 with -fsignalling-nans (that's not the default) you will get the
 desired behavior (program termination via an exception).

By enable FP exceptions, I think you mean set a trap for these
exceptions (documents often mix exception and trap). But there
doesn't seem to be standard support for traps in C. The Glibc
provides feenableexcept, fedisableexcept and fegetexcept functions
for that.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Are Decimal operations are fully implemented/tested ?

[Vincent Lefevre]

On 2012-09-14 16:17:43 +, Joseph S. Myers wrote:
 On Fri, 14 Sep 2012, Vincent Lefevre wrote:
 
  round-to-odd would be a good solution if it were provided directly
  in hardware. Otherwise a direct implementation would probably be
  more efficient (in particular when the implementation of the usual
  operation is done in software, like for decimal arithmetic).
 
 It's the case for a lot of libm operations that the best implementation 
 for software floating point is not the same as for hardware floating point 
 (anything implemented using Dekker's algorithms or similar precision 
 extension techniques would probably better use higher precision more 
 directly on integers, for example).

The main difference is that most processors have hardware FP, so
that FP expansions are better in general to implement libm math
functions (a hardware FMA is very useful for that too, but most
processors will have one in the near future), while round-to-odd
is not provided in hardware, not in IEEE 754-2008, and probably
won't be provided in hardware at least before a distant future.
So, there is work to do in software...

Then, between implementing round-to-odd and implementing a direct
formatOf operation, I don't think there is much difference concerning
the work to do (I would even say that round-to-odd could require more
work).

 It's also the case that there hasn't been any actual interest in
 optimal software implementations for these cases in glibc (I guess
 people concerned about floating-point performance are generally
 using hardware floating point).

If people really need decimal (e.g. for financial applications),
they would use it instead of hardware binary FP.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Are Decimal operations are fully implemented/tested ?

[Vincent Lefevre]

On 2012-09-13 16:46:04 +, Joseph S. Myers wrote:
 On Thu, 13 Sep 2012, Vincent Lefevre wrote:
  But if you want an example, I don't think that the formatOf
  arithmetic operations (IEEE 754-2008 §5.4.1 -- that's a shall)
  are implemented by GCC, either for binary or for decimal, say
  add two _Decimal128 numbers and round to _Decimal64 directly
  (with a single rounding).
 
 For binary floating point, the draft C bindings (I'm looking at WG14 
 N1605, which is just a draft of the first part of what's supposed to end 
 up as a five-part document) defines such operations as library operations 
 (e.g. float fadd(double x, double y);) rather than compiler ones (although 
 of course the compiler might have corresponding built-in functions).  

Note however that efficiency is important. If one had to choose to
spend time on compiling/implementing these operations, the focus
should be on the compiler first (actually, that's particularly
true for binary on IA-64, where these operations are part of the
instruction set and implemented in hardware on the Itanium).

Also if the (software) implementation of _Decimal64 operations and
_Decimal128 operations is done by GCC, it would be better to have
the implementation of the corresponding formatOf operations done
by GCC too (keep similar code at the same place).

 (Implementing fadd itself probably isn't hard; given exception and 
 rounding mode support you should be able to do it with round-to-odd as 
 described by Boldo and Melquiond

round-to-odd would be a good solution if it were provided directly
in hardware. Otherwise a direct implementation would probably be
more efficient (in particular when the implementation of the usual
operation is done in software, like for decimal arithmetic).

Note: What makes round-to-odd work is that one gets a good enough
approximation to the exact result, and the sign of the error w.r.t.
a format with less precision is encoded in the result itself;
and all this information is kept in a single floating-point number.
But if you need to implement a formatOf operation and round-to-odd
isn't directly available, it may be better to get the approximation
and the error (or just its sign) in some more usual way, and work
with them without packing them in a single floating-point number.

 - and some processors (ia64?) may have direct support for it.

In binary only (because it doesn't have decimal support at all).

 But there are lots of new functions, that's just one.)

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Are Decimal operations are fully implemented/tested ?

[Vincent Lefevre]

On 2012-09-12 15:55:16 +0300, Hesham Moustafa wrote:
 If exist, what are the known bugs in the current implementation of
 Decimal / IEEE 754-2008 standard ?

I don't know any reported bug of the decimal implementation (though
PR 37845 about the FP_CONTRACT pragma, which affects binary on some
machines, might also affect decimal in some distant future if it is
still not fixed).

But if you want an example, I don't think that the formatOf
arithmetic operations (IEEE 754-2008 §5.4.1 -- that's a shall)
are implemented by GCC, either for binary or for decimal, say
add two _Decimal128 numbers and round to _Decimal64 directly
(with a single rounding).

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: GCC's Decimal Floating Point extension problem

[Vincent Lefevre]

On 2012-09-11 11:34:58 -0700, H.J. Lu wrote:
 On Tue, Sep 11, 2012 at 11:31 AM, Mohamed Abou Samra
 my_abousa...@yahoo.com wrote:
   Hi All,
 
  I'm trying to write a small program to check the decimal floating
  point gcc extension but I encountered some problems
 
  The program just converts a _Decimal64 number to double to print
  it and I used the function (double __bid_truncdddf (_Decimal64 a)
  as the gnu online docs show)

If you cast the decimal64 value to double (whatever the method),
the printed value may be incorrect (see below).

  #include stdio.h
 
  int main ()
  {
 _Decimal64 d = 12.5DD;
  printf (%lf\n,__bid_truncdddf(d) );
 
  return 0;
  }
 
  $ gcc test.c -Wall -g
  test.c: In function ‘main’:
  test.c:23: warning: implicit declaration of function ‘__bid_truncdddf’
  test.c:23: warning: format ‘%lf’ expects type ‘double’, but argument 2 has 
  type ‘int’
 
  $ ./a.out
  0.00
 
  I don't know why the result is zero and why the second warning
  appears although I wrote the function properly!
 
 ,__bid_truncdddf is a libgcc internal function.  Don't ever use it
 in user programs.  Just cast DFP to double.

A double has 53 bits in general (always with GCC, AFAIK), so that
it doesn't have enough precision to guarantee that the output in
decimal (with the exact precision of _Decimal64) will be correct.
There has recently been a related discussion in the MPFR list.
See:

  https://sympa.inria.fr/sympa/arc/mpfr/2012-08/msg00027.html
  https://sympa.inria.fr/sympa/arc/mpfr/2012-08/msg00028.html
  https://sympa.inria.fr/sympa/arc/mpfr/2012-09/msg00011.html

So, if long double has at least 55 bits, a solution would be to
cast the _Decimal64 to long double.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Are Decimal operations are fully implemented/tested ?

[Vincent Lefevre]

On 2012-09-12 11:29:41 +0300, Hesham Moustafa wrote:
 I want to inquire about the state of decimal floating point operations
 at gcc low-level library.
 Does gcc fully implement IEEE 754-2008 standard ?

No. Even for binary-only it doesn't (though it almost does). Also
note that some parts of IEEE 754-2008 are (should be) implemented
on the C library side (e.g. glibc).

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Announce: GNU MPFR 3.1.1 is released

[Vincent Lefevre]

GNU MPFR 3.1.1 (canard à l'orange, patch level 1) is now available
for download from the MPFR web site:

  http://www.mpfr.org/mpfr-3.1.1/

from INRIAGForge:

  https://gforge.inria.fr/projects/mpfr/

and from the GNU FTP site:

  http://ftp.gnu.org/gnu/mpfr/

Thanks very much to those who sent us bug reports and/or tested the
release candidate.

The MD5's:
e90e0075bb1b5f626c6e31aaa9c64e3b  mpfr-3.1.1.tar.bz2
769411e241a3f063ae1319eb5fac2462  mpfr-3.1.1.tar.gz
91d51c41fcf2799e4ee7a7126fc95c17  mpfr-3.1.1.tar.xz
8ad54e5d236e6ae3be58c6e3196f6bed  mpfr-3.1.1.zip

The SHA1's:
f632d43943ff9f13c184fa13b9a6e8c7f420f4dd  mpfr-3.1.1.tar.bz2
8b7e35d244ee4d4144cb8d4d17b0c5ba7288dff4  mpfr-3.1.1.tar.gz
7527c322b91fe8e6055ead551e1b46b9f1712ccd  mpfr-3.1.1.tar.xz
c649e01e911b2dff5f21b6eaf88041fa6f071b47  mpfr-3.1.1.zip

The signatures:
http://www.mpfr.org/mpfr-3.1.1/mpfr-3.1.1.tar.xz.asc
http://www.mpfr.org/mpfr-3.1.1/mpfr-3.1.1.tar.bz2.asc
http://www.mpfr.org/mpfr-3.1.1/mpfr-3.1.1.tar.gz.asc
http://www.mpfr.org/mpfr-3.1.1/mpfr-3.1.1.zip.asc

Changes from version 3.1.0 to version 3.1.1:
- Improved MPFR manual.
- Test coverage: 96.5% lines of code.
- Bug fixes (see http://www.mpfr.org/mpfr-3.1.0/#fixed or ChangeLog file).

You can send success and failure reports to m...@inria.fr, and give
us the canonical system name (by running the ./config.guess script),
the processor and the compiler version, in order to complete the
Platforms Known to Support MPFR section of the MPFR 3.1.1 web page.

Regards,

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

GNU MPFR 3.1.1 Release Candidate

[Vincent Lefevre]

The release of GNU MPFR 3.1.1 (canard à l'orange patch level 1)
is imminent. Please help to make this release as good as possible
by downloading and testing this release candidate:

http://www.mpfr.org/mpfr-3.1.1/mpfr-3.1.1-rc1.tar.xz
http://www.mpfr.org/mpfr-3.1.1/mpfr-3.1.1-rc1.tar.bz2
http://www.mpfr.org/mpfr-3.1.1/mpfr-3.1.1-rc1.tar.gz
http://www.mpfr.org/mpfr-3.1.1/mpfr-3.1.1-rc1.zip

The MD5's:
a1a0abb6f2611a9cc388261b12304ecb  mpfr-3.1.1-rc1.tar.bz2
15399799f44d30e53d4700a4df5e8b5f  mpfr-3.1.1-rc1.tar.gz
edb139ab0b51160de54b611b33f3be57  mpfr-3.1.1-rc1.tar.xz
7b005bc1877db361f29224f42f1c07b8  mpfr-3.1.1-rc1.zip

The SHA1's:
59a005cb515e42a604d791c4dcdc1865b5951ccb  mpfr-3.1.1-rc1.tar.bz2
a93d0764b6f71dcf2259e6d26cc8cb8f715fd545  mpfr-3.1.1-rc1.tar.gz
46ec98c1a3ed352336036e35517032140ee421db  mpfr-3.1.1-rc1.tar.xz
9385d07e18f69cade3d0ca1157cd1f1d67fd92fe  mpfr-3.1.1-rc1.zip

The signatures:
http://www.mpfr.org/mpfr-3.1.1/mpfr-3.1.1-rc1.tar.xz.asc
http://www.mpfr.org/mpfr-3.1.1/mpfr-3.1.1-rc1.tar.bz2.asc
http://www.mpfr.org/mpfr-3.1.1/mpfr-3.1.1-rc1.tar.gz.asc
http://www.mpfr.org/mpfr-3.1.1/mpfr-3.1.1-rc1.zip.asc

Changes from version 3.1.0 to version 3.1.1:
- Bug fixes (see http://www.mpfr.org/mpfr-3.1.0/#fixed or ChangeLog file).

Please send success and failure reports with ./config.guess output
to m...@inria.fr.

If no problems are found, GNU MPFR 3.1.1 should be released
around 2012-07-03.

Regards,

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: RFC: -Wall by default

[Vincent Lefevre]

On 2012-04-05 16:44:28 -0400, Robert Dewar wrote:
 On 4/5/2012 4:24 PM, Russ Allbery wrote:
 Personally, as a matter of *style*, I eliminate such cases either by
 initializing the variable or restructuring the function.  But this is very
 much a question of style, not of correctness.
 
 Indeed, and for me, when you are forced to do an initialization like
 this, it is mandatory to comment why you are initializing it, otherwise
 it obscures the code (why is this being initialized, where is that
 value used?) and that ends up junky IMO. The Ada front end unfortunately
 has quite a few such commented junk initializations.

And moreover, perhaps in such a case, other compilers and/or future
GCC versions would give a warning because a value is set but not used.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: RFC: -Wall by default

[Vincent Lefevre]

On 2012-04-10 14:48:05 +0100, Andrew Haley wrote:
 On 04/05/2012 12:30 PM, Vincent Lefevre wrote:
  On 2012-04-05 11:55:45 +0100, Andrew Haley wrote:
  On 04/05/2012 11:50 AM, Vincent Lefevre wrote:
  On 2012-04-04 20:01:27 +0100, Andrew Haley wrote:
  On 04/04/2012 07:11 PM, Gabriel Dos Reis wrote:
  Really?  Such as what?
 
  Such as I wrote a perfectly legal C program, and gcc spewed out
  a ton of messages.
 
  What's a legal C program?
 
  It's generally used to mean one that is fully defined by the
  specifications in effect, often some combination of POSIX and ISO C,
  with perhaps some vendor extensions.  Why do you ask?
  
  Because: What if the specifications in effect say (as some vendor
  extension) that some construct will generate some warning?
 
 Interesting.  I had not considered that, but I have never seen such a
 specification.  Usually warnings are for things that are permitted by
 a specification, but not good in some way.  That's why warnings are
 usually optional, AFAIK; the program is well-defined, but has some
 properties that are, in the opinion of the compiler writer,
 undesirable.

There's also the case where the program is well-defined for some
specifications, but will have a different behavior with other
specifications, e.g. a newer standard (like C99 vs C89) or a
different one (like C++ vs C -- e.g. with MPFR, one allows it
to be built with a C++ compiler). In particular in the former
case, it's just C in both standards, but the concept of a
legal C program will vary (note that the broken[*] -std cannot
be used to tell GCC that the user wants to support both C89 and
C99).

[*] because it is not possible to distinguish between what GCC
supports and what GCC allows (there have already been discussions
about this).

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: RFC: -Wall by default

[Vincent Lefevre]

On 2012-04-08 18:56:27 +0100, Jonathan Wakely wrote:
 Anyway, GCC prints the option that controls a warning as part of the
 diagnostic, so it's trivial to find which options control the
 diagnostics that are annoying you.

And it's fine that using the -Wno-... form doesn't make the
compilation fail if the option is not supported (e.g. with older
GCC versions). It doesn't seem to be documented, though.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: RFC: -Wall by default

[Vincent Lefevre]

On 2012-04-09 13:03:38 -0500, Gabriel Dos Reis wrote:
 On Mon, Apr 9, 2012 at 12:44 PM, Robert Dewar de...@adacore.com wrote:
  On 4/9/2012 1:36 PM, Jonathan Wakely wrote:
 
  Maybe -Wstandard isn't the best name though, as standard usually
  means something quite specific for compilers, and the warning switch
  wouldn't have anything to do with standards conformance.
 
  -Wdefault
 
  might be better
 
 except if people want warnings about defaults in C++11 (which can mean
 lot of things).

How about a warning level?

-W0: no warnings (equivalent to -w)
-W1: default
-W2: equivalent to the current -Wall
-W3: equivalent to the current -Wall -Wextra

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: RFC: -Wall by default

[Vincent Lefevre]

On 2012-04-04 20:01:27 +0100, Andrew Haley wrote:
 On 04/04/2012 07:11 PM, Gabriel Dos Reis wrote:
  Really?  Such as what?
 
 Such as I wrote a perfectly legal C program, and gcc spewed out
 a ton of messages.

What's a legal C program?

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: RFC: -Wall by default

[Vincent Lefevre]

On 2012-04-05 10:48:29 +0100, Pedro Alves wrote:
 On 04/05/2012 10:39 AM, Richard Guenther wrote:
 
 ... [-Wall + -Werror] ...
 
  Btw, it would be more reasonable to enable a subset of warnings that
  we enable at -Wall by default.  Notably those that if they were not
  false positives, would lead to undefined behavior at runtime.  Specifically
  I don't think we should warn about unused static functions or variables
  by default.
 
 Yes, I would agree more with something like that.

Ditto. I sometimes get such warnings just because of the use of the
preprocessor. However taking the preprocessor into account would
mean that some useful warnings (perhaps even with currently default
ones, but I'm not sure because I always use -Wall) could not be
included. The best solution is sometimes to modify the source. For
instance, I had to do the following change (not sure whether this
is the best way) in MPFR a few days ago:

Index: src/const_euler.c
===
--- src/const_euler.c   (revision 8123)
+++ src/const_euler.c   (revision 8124)
@@ -118,7 +118,7 @@
   int inex;
   MPFR_BLOCK_DECL (flags);
 
-  MPFR_BLOCK (flags, inex = mpfr_get_z (P, n, MPFR_RNDN));
+  MPFR_BLOCK (flags, MPFR_DBGRES (inex = mpfr_get_z (P, n, MPFR_RNDN)));
   MPFR_ASSERTD (inex == 0  ! MPFR_ERANGEFLAG (flags));
   if (a  1)
 mpz_mul_si (P, P, 1 - (long) a);
Index: src/mpfr-impl.h
===
--- src/mpfr-impl.h (revision 8123)
+++ src/mpfr-impl.h (revision 8124)
@@ -388,12 +388,18 @@
 #define MPFR_ASSERTN(expr)  \
((void) ((MPFR_UNLIKELY(expr)) || MPFR_UNLIKELY( (ASSERT_FAIL(expr),0) )))
 
-/* MPFR_ASSERTD(expr): assertions that should be checked when testing */
+/* MPFR_ASSERTD(expr): assertions that should be checked when testing.
+   MPFR_DBGRES(assignment): to be used when the result is tested only
+ in an MPFR_ASSERTD expression (in order to avoid a warning, e.g.
+ with GCC's -Wunused-but-set-variable, in non-debug mode).
+ */
 #ifdef WANT_ASSERT
 # define MPFR_EXP_CHECK 1
 # define MPFR_ASSERTD(expr)  MPFR_ASSERTN (expr)
+# define MPFR_DBGRES(A)  (A)
 #else
 # define MPFR_ASSERTD(expr)  ((void) 0)
+# define MPFR_DBGRES(A)  ((void) (A))
 #endif
 
 /* Code to deal with impossible

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: RFC: -Wall by default

[Vincent Lefevre]

On 2012-04-05 11:55:45 +0100, Andrew Haley wrote:
 On 04/05/2012 11:50 AM, Vincent Lefevre wrote:
  On 2012-04-04 20:01:27 +0100, Andrew Haley wrote:
  On 04/04/2012 07:11 PM, Gabriel Dos Reis wrote:
  Really?  Such as what?
 
  Such as I wrote a perfectly legal C program, and gcc spewed out
  a ton of messages.
  
  What's a legal C program?
 
 It's generally used to mean one that is fully defined by the
 specifications in effect, often some combination of POSIX and ISO C,
 with perhaps some vendor extensions.  Why do you ask?

Because: What if the specifications in effect say (as some vendor
extension) that some construct will generate some warning?

Note that warnings in general are not forbidden by ISO C, so that
there is nothing wrong as far as ISO C is concerned.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: RFC: -Wall by default

[Vincent Lefevre]

On 2012-04-05 06:26:43 -0400, Robert Dewar wrote:
 Well a lot of users have been burned by using optimization
 options, either becausae of compiler bugs, or because of bugs
 in their own code triggered by optimization. So the requirement
 of not using any optimization options is not that uncommon.

But no-optimizations (-O0) should not necessarily be the default
for these reasons.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: RFC: -Wall by default

[Vincent Lefevre]

On 2012-04-05 06:42:02 -0400, Robert Dewar wrote:
 c) warnings about things that are not errors but seem like
 sloppy or unnecessary code (e.g. unused variables).

This is sometimes an error, e.g. a variable name is used in the code
instead another one (but of course, such warnings won't be able to
detect all similar errors).

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: RFC: -Wall by default

[Vincent Lefevre]

On 2012-04-05 08:17:57 -0400, Robert Dewar wrote:
 On 4/5/2012 8:06 AM, Vincent Lefevre wrote:
 But no-optimizations (-O0) should not necessarily be the default
 for these reasons.
 
 I think it is a problem that even at -O1 the debugger is
 seriously limited, especially for an inexperienced user.

OK.

Now, AFAIK, compiling and running programs occurs much more often
than debugging them. So, I would say that -O1 should be the default.
The user can still recompile his program with -O0 (or future better
option) if he needs to run the debugger on it; if he doesn't know
that, there should be some feature in the debugger to tell the user
what to do.

 What is missing to me is a reasonable cleanup of the code that
 would remove some of the junk at -O0 but not impact debugging.
 In fact a reasonable criterion would be all the optimization
 that is cheap to do and does not affect debugging.

I think that for debugging, there should be a single option to
disable optimizations that are unsafe for the debugger and that
would add debugging information (such as what -g does). In short,
the user would just have to add this option, which should do all
the magic for debugging.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: RFC: -Wall by default

[Vincent Lefevre]

On 2012-04-05 15:09:32 +0200, Erik Trulsson wrote:
 Better would be to improve the output from -O1 so it is usable by a
 debugger, even if this might require generating slightly less optimized
 code at -O1 than is done now.

This contradicts what you say below.

   What is missing to me is a reasonable cleanup of the code that
   would remove some of the junk at -O0 but not impact debugging.
   In fact a reasonable criterion would be all the optimization
   that is cheap to do and does not affect debugging.
  
  I think that for debugging, there should be a single option to
  disable optimizations that are unsafe for the debugger and that
  would add debugging information (such as what -g does). In short,
  the user would just have to add this option, which should do all
  the magic for debugging.
 
 No, absolutely not. Turning on debugging should not change what the
 generated code looks like.

For instance, the effect of a bug appears only with -O3.
Then you have 2 possibilities:
1. The debugger can cope with such optimization levels. So, -O1
   doesn't need to be modified.
2. The debugger cannot cope with such optimization levels, and you
   are forced anyway to change what the generated code looks like
   in order to try to debug it (or improve the debugger to be in
   case 1, if possible).

 Depending on the bug it is quite possible for changes in
 optimization to hide the symptoms of the bug, thereby making it more
 difficult to track down the bug.

I agree, but this is not by removing some default optimizations
that you would solve the problems due to a bug that appears when
the user chooses to use a higher optimization level.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: The state of glibc libm

[Vincent Lefevre]

On 2012-03-26 11:15:37 -0500, Steven Munroe wrote:
 On Mon, 2012-03-26 at 12:26 +0200, Vincent Lefevre wrote:
  Then concerning double-double vs quad (binary128) for the long double
  type, I think that quad would be more useful, in particular because
  it has been standardized and it is a true FP format. If need be (for
  efficiency reasons), double-double could still be implemented using
  the double type, via a library or ad-hoc code (that does something
  more clever, taking the context into account). And the same code (with
  just a change of the base type) could be reused to get a double-quad
  (i.e. quad + quad) arithmetic, that can be useful to implement the
  long double versions of the math functions (expl, and so on).
  
 This is much easier said then done. In practice it is a major ABI change
 and would have to be staged over multiple (7-10) years.

Yes, I meant in the long term.

So, in the long term, the ABI should probably be changed to have
long double = quadruple precision (binary128).
   
   The ABI for Power Architecture changed away from quad precision to using 
   IBM long double (the original SysV ABI for PowerPC used quad precision, 
   the current ABI uses IBM long double)
  
  Perhaps they could change back to quad precision.
  
 That is not the feedback we get from our customers. No one will use
 software IEEE binary128 and we don't have hardware binary128. So far
 there is abstract interest but no strong demand for this. So there is no
 incentive to change.

But perhaps one reason why there is no hardware binary128 is that
there is no software that uses it.

BTW, what is the feedback from your customers concerning the
long double math functions (expl, etc.)?

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: The state of glibc libm

[Vincent Lefevre]

On 2012-03-22 16:29:00 +, Joseph S. Myers wrote:
 On Thu, 22 Mar 2012, Vincent Lefevre wrote:
  For the same reason, if the user chose long double instead of
  double, this may be because he wanted more precision than double.
 
 You mean range?  IBM long double provides more precision, but not more 
 range.

Well, precision and/or range. If double precision format is sufficient
for his application, the user can just choose the double type. So,
I don't think that it is useful to have long double = double.

Then concerning double-double vs quad (binary128) for the long double
type, I think that quad would be more useful, in particular because
it has been standardized and it is a true FP format. If need be (for
efficiency reasons), double-double could still be implemented using
the double type, via a library or ad-hoc code (that does something
more clever, taking the context into account). And the same code (with
just a change of the base type) could be reused to get a double-quad
(i.e. quad + quad) arithmetic, that can be useful to implement the
long double versions of the math functions (expl, and so on).

  So, in the long term, the ABI should probably be changed to have
  long double = quadruple precision (binary128).
 
 The ABI for Power Architecture changed away from quad precision to using 
 IBM long double (the original SysV ABI for PowerPC used quad precision, 
 the current ABI uses IBM long double)

Perhaps they could change back to quad precision.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: The state of glibc libm

[Vincent Lefevre]

On 2012-03-15 10:52:05 -0500, Steven Munroe wrote:
 On Thu, 2012-03-15 at 03:07 +0100, Vincent Lefevre wrote:
  On 2012-03-14 14:40:06 +, Joseph S. Myers wrote:
   On Wed, 14 Mar 2012, Vincent Lefevre wrote:
   
For double-double (IBM long double), I don't think the notion of
correct rounding makes much sense anyway. Actually the double-double
arithmetic is mainly useful for the basic operations in order to be
able to implement elementary functions accurately (first step in
Ziv's strategy, possibly a second step as well). IMHO, on such a
platform, if expl() (for instance) just calls exp(), this is OK.
   
 Why would that be OK? If we have higher precision long double then the
 libm should deliver that higher precision.

I initially thought that the only goal of a double-double format
(instead of the standard quadruple precision) was to get an
accurate implementation of the elementary functions in double
precision (BTW, that's probably why expl() and so on didn't
exist before C99).

Now, since expl() now exists, if the user calls it, perhaps his
goal is to get more precision, so finally I agree that expl()
should really have an accuracy close to LDBL_MANT_DIG. However
this is quite useless in portable programs, where long double
can have the same precision as double (as this is the case on
ARM).

For the same reason, if the user chose long double instead of
double, this may be because he wanted more precision than double.
So, in the long term, the ABI should probably be changed to have
long double = quadruple precision (binary128).

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)