Announce: GNU MPFR 4.2.2 is released

GNU MPFR 4.2.2 ("fondue savoyarde", 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.2.2/ and from the GNU FTP site: https://ftp.gnu.org/gnu/mpfr/ Thanks ve

GNU MPFR 4.2.2 Release Candidate

The release of GNU MPFR 4.2.2 ("fondue savoyarde", 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.2.2/mpfr-4.2.2-rc1.tar.xz https://www.mpfr.org/mpfr-4.2.2/mpfr-4.2.2-rc1.tar.bz2 https

Announce: GNU MPFR 4.2.1 is released

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 ve

GNU MPFR 4.2.1 Release Candidate

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

Announce: GNU MPFR 4.2.0 is released

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 thos

GNU MPFR 4.2.0 Release Candidate

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/

Announce: GNU MPFR 4.1.1 is released

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

GNU MPFR 4.1.1 Release Candidate

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 ht

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

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 > >> > rememb

GCC, standard library functions/builtins and POSIX conformance

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

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

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 parag

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

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 th

Announce: GNU MPFR 4.1.0 is released

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 s

GNU MPFR 4.1.0 Release Candidate 2

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.o

GNU MPFR 4.1.0 Release Candidate

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.o

Re: Test GCC conversion with reposurgeon available

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 ha

Re: Test GCC conversion with reposurgeon available

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 usef

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

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

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

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

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

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 defau

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

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 behavio

Announce: GNU MPFR 4.0.2 is released

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

GNU MPFR 4.0.2 Release Candidate 2

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

GNU MPFR 4.0.2 Release Candidate

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

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

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

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

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

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

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

Re: "file name" vs "filename"

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

ASAN status and glibc 2.27

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 -

Announce: GNU MPFR 4.0.1 is released

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 t

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

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).

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

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 n

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

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. > Bu

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

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

Re: extern const initialized warns in C

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-

Announce: GNU MPFR 4.0.0 is released

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

Re: GNU MPFR 4.0.0 Release Candidate

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

GNU MPFR 4.0.0 Release Candidate

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/mp

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

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. > > > > T

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

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 M

Announce: GNU MPFR 3.1.6 is released

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 t

GNU MPFR 3.1.6 Release Candidate

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://

GCJ wiki page

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:

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

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, fun

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

On 2016-11-28 18:49:55 +, Yuri Gribov wrote: > On Mon, Nov 28, 2016 at 4:03 PM, Vincent Lefevre > 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__ > > c

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

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 m

Announce: GNU MPFR 3.1.5 is released

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 t

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

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

GNU MPFR 3.1.5 Release Candidate

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://

Announce: GNU MPFR 3.1.4 is released

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 t

GNU MPFR 3.1.4 Release Candidate 2

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://

GNU MPFR 3.1.4 Release Candidate

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://

Re: UTF-8 quotation marks in diagnostics

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 in

Announce: GNU MPFR 3.1.3 is released

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 t

GNU MPFR 3.1.3 Release Candidate

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://w

Re: Undefined behavior due to 6.5.16.1p3

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; > >

Re: Undefined behavior due to 6.5.16.1p3

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 { ch

Re: Undefined behavior due to 6.5.16.1p3

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

Re: Undefined behavior due to 6.5.16.1p3

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 - Web: 100% accessible validated (X)HTML - Blog:

Re: Undefined behavior due to 6.5.16.1p3

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

Re: Undefined behavior due to 6.5.16.1p3

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: > > &g

Re: Undefined behavior due to 6.5.16.1p3

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 wit

Re: fast-math optimization question

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 intermedi

Re: FloatingPointMath and transformations

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 - Web: 100% accessible validated (X)HTML - Blog:

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

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 i

Re: FloatingPointMath and transformations

On 2014-06-02 17:34:31 +0200, Andreas Schwab wrote: > Jakub Jelinek 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

FloatingPointMath and transformations

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 t

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

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 rou

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

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 r

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

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/Lefevre2

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

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 function

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

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 I

Announce: GNU MPFR 3.1.2 is released

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 u

GNU MPFR 3.1.2 Release Candidate

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://w

Re: not-a-number's

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

Re: not-a-number's

On 2013-01-17 15:01:20 +0100, Andreas Schwab wrote: > Andreas Schwab 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, th

Re: not-a-number's

On 2013-01-17 13:08:17 +0100, Gabriel Paubert wrote: > Hmm, are you sure that this part is properly implemented in gcc, using > unordered compare versus ordered compare instructions depending on > the operator you use? > > At least on PPC, floating point compares always use the unordered > instr

Re: not-a-number's

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) ... e

Re: not-a-number's

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 termina

Re: not-a-number's

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

Re: not-a-number's

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 co

Re: Are Decimal operations are fully implemented/tested ?

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

Re: Are Decimal operations are fully implemented/tested ?

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 G

Re: Are Decimal operations are fully implemented/tested ?

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 mac

Re: Are Decimal operations are fully implemented/tested ?

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 IE

Re: GCC's Decimal Floating Point extension problem

On 2012-09-11 11:34:58 -0700, H.J. Lu wrote: > On Tue, Sep 11, 2012 at 11:31 AM, Mohamed Abou Samra > 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

Announce: GNU MPFR 3.1.1 is released

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 u

GNU MPFR 3.1.1 Release Candidate

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://w

Re: RFC: -Wall by default

On 2012-04-09 13:03:38 -0500, Gabriel Dos Reis wrote: > On Mon, Apr 9, 2012 at 12:44 PM, Robert Dewar 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 warnin

Re: RFC: -Wall by default

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 f

Re: RFC: -Wall by default

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:

Re: RFC: -Wall by default

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. > > In

Re: RFC: -Wall by default

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

Re: RFC: -Wall by default

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 li

Re: RFC: -Wall by default

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

Re: RFC: -Wall by default

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 uncomm

Re: RFC: -Wall by default

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

Re: RFC: -Wall by default

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,

Re: RFC: -Wall by default

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 - Web:

Re: The state of glibc libm

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

  1   2   3   4   >