Re: gmp and mpfr in infrastructure

On 2006-10-23 10:48:18 +0200, Benjamin Kosnik wrote: > I've found the GMP website to be quite unresponsive. FYI, the problem seems to be a router that is incompatible with Linux. So, as a workaround, either use another OS (no problem under Mac OS X) or change the TCP window scaling[*] if you can.

Re: gmp and mpfr in infrastructure

On 2006-10-24 12:27:39 +0200, Vincent Lefevre wrote: > On 2006-10-23 10:48:18 +0200, Benjamin Kosnik wrote: > > I've found the GMP website to be quite unresponsive. > > FYI, the problem seems to be a router that is incompatible with Linux. > So, as a workaround, either use

Re: Bootstrap failure on trunk on linux? (libgmp.so.3 exists, but not found)

On 2006-11-04 14:21:39 -0500, Daniel Jacobowitz wrote: > It's doing exactly what it ought to, though unintuitive. If you tell a > -compiler to use L/usr/local/lib, you're responsible for also setting > up either an rpath or LD_LIBRARY_PATH to point at /usr/local/lib; doing > it by default causes a

MPFR 2.2.1 Release Candidate

Hi, I'm posting this announce to this list as GCC now uses MPFR... The release of MPFR 2.2.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-2.2.1/mpfr-2.2.1-rc1.tar.bz2 http://www.mpfr.org/mpfr-2.2.1/m

Announce: MPFR 2.2.1 is released

MPFR 2.2.1 is now available for download from the MPFR web site: http://www.mpfr.org/mpfr-2.2.1/ Thanks very much to those who tested the release candidates. The MD5's: 40bf06f8081461d8db7d6f4ad5b9f6bd mpfr-2.2.1.tar.bz2 662bc38c75c9857ebbbc34e3280053cd mpfr-2.2.1.tar.gz 93a2bf9dc66f81caa57c

Re: Build problem on hpxw 4300 running fc6 x86_64

Hi, On 2006-11-28 10:39:20 -0800, George R Goffe wrote: > I'm trying to build the latest svn version of gcc on my hp xw 4300 > system running fedora core 6 and am seeing a problem with mpfr. I > got the latest mpfr and applied their patch before attempting this > build. I have a complete build log

Re: Announce: MPFR 2.2.1 is released

On 2006-12-02 10:16:31 -0800, Bruce Korb wrote: > Requiring this is a bit of a nuisance. mpfr requires gmp so I had to > go pull and build that only to find: > > checking if gmp.h version and libgmp version are the same... > (4.2.1/4.1.4) no Note that this test was really buggy in MPFR 2.2.0. I f

Re: Announce: MPFR 2.2.1 is released

On 2006-12-02 11:41:48 -0800, Bruce Korb wrote: > Anyway, the whole deal about gmp-config is that mpfr should be doing > the equivalent of --with-gmp=`gmp-config --libdir` so that you > *don't* have the /usr/local headers and the /usr binary. Assuming a gmp-config program is provided, the user can

Re: Announce: MPFR 2.2.1 is released

On 2006-12-04 15:34:32 -0500, DJ Delorie wrote: > Joe Buck <[EMAIL PROTECTED]> writes: > > The ordinary user who builds gcc from source does not need *any* > > version of automake, autoconf, etc., so any strict requirements that > > are imposed on these tools have an impact only on gcc developers.

Re: GCC optimizes integer overflow: bug or feature?

On 2006-12-20 23:40:45 +0100, Marcin Dalecki wrote: > However it's a quite common mistake to forget how > "bad" floats "model" real numbers. It depends on what you are doing. For instance, thanks to the IEEE-754 standard, it is possible to perform exact computations with floats. By doing unsafe

Re: GCC optimizes integer overflow: bug or feature?

On 2006-12-21 17:42:15 -0500, Robert Dewar wrote: > Marcin Dalecki wrote: > > >Of course I didn't think about a substitute for ==. Not! However I think > >that checks for |x-y| < epsilion, could be really given a significant > >speed edge > >if done in a single go in hardware. > > One thing to

Re: GCC optimizes integer overflow: bug or feature?

On 2006-12-19 10:44:25 -0800, Paul Eggert wrote: > Sure, but that is trickier. In many cases code operates on > types like time_t that are signed on some platforms and > unsigned on others. It's easy for such code to test for > overflow if you assume wraparound arithmetic, as code like > { sum =

Re: GCC optimizes integer overflow: bug or feature?

On 2006-12-29 00:55:18 -0800, Paul Eggert wrote: [...] > Obviously this code is buggy, at least in theory, due to the signed > integer overflows. But rewriting it is not so easy, since we have no > INT_MAX to rescue us as we did in the bigtime_test loop. Here's what > I eventually came up with: >

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On 2006-12-28 23:11:08 -0800, Paul Eggert wrote: > 2006-12-28 Paul Eggert <[EMAIL PROTECTED]> > > * NEWS: AC_PROG_CC, AC_PROG_CXX, and AC_PROG_OBJC now take an > optional second argument specifying the default optimization > options for GCC. These optimizations now default to

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On 2006-12-30 19:29:58 -0500, Robert Dewar wrote: > Richard Kenner wrote: > >I can't speak for any other GCC developer, but I personally am > >quite comfortable viewing any code that assumes wrapping semantics > >as broken and needing fixing with the exception of these cases of > >checking for over

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On 2006-12-30 20:07:09 -0500, Robert Dewar wrote: > In my view, this comparison optimization should not have been put in > without justification given that it clearly does affect the semantics > of real code. Indeed if you really see code like > >if (a - 10 < 20) > > in place of > >i

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On 2006-12-31 08:06:56 -0500, Robert Dewar wrote: > Vincent Lefevre wrote: > >On 2006-12-30 20:07:09 -0500, Robert Dewar wrote: > >> In my view, this comparison optimization should not have been put in > >> without justification given that it clearly does affect the

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On 2006-12-31 08:25:23 -0500, Richard Kenner wrote: > > > > I suppose there is > > > > > > > > *hv = (HOST_WIDE_INT) -(unsigned HOST_WIDE_INT) h1; > > > > > > > > to make it safe. > > > > > > Can't that conversion overflow? > > > > Not on a two's complement machine, > > Then I'm confuse

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On 2006-12-31 09:03:17 -0500, Richard Kenner wrote: > > And I doubt that GCC (or any compiler) could reliably detect code > > that checks for overflow. > > It doesn't need to "detect" all such code: all it needs to do is > ensure that it doesn't BREAK such code. And that's a far easier > condition

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On 2006-12-31 09:08:21 -0500, Richard Kenner wrote: > > In fact the wrap around range test is a standard idiom for "hand > > optimization" of range tests. > > It's also one that GCC uses internally, but you do it in *unsigned* > to avoid the undefined overflow. If done in unsigned, this won't lea

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On 2006-12-31 09:22:22 -0500, Robert Dewar wrote: > Vincent Lefevre wrote: > >>My point was that if you see this in a source program, it is in > >>fact a possible candidiate for code that can be destroyed by > >>the optimization. > > > >Well, only for non-

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On 2006-12-31 09:27:21 -0500, Robert Dewar wrote: > As I said earlier in this thread, people seem to think that the > standards committee invented something new here in making overflow > undefined, but I don't think that's the case. I personally would > have thought it more judicious to make it imp

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On 2006-12-31 10:07:44 -0500, Robert Dewar wrote: > Vincent Lefevre wrote: > >If done in unsigned, this won't lead to any optimization, as unsigned > >arithmetic doesn't have overflows. So, if you write "a - 10" where a > >is unsigned, the compiler can

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On 2006-12-31 10:08:32 -0500, Richard Kenner wrote: > > Well, that's not equivalent. For instance, MPFR has many conditions > > that evaluate to TRUE or FALSE on some/many implementations (mainly > > because the type sizes depend on the implementation), even without > > the assumption that an overf

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On 2006-12-31 10:19:59 -0500, Richard Kenner wrote: > > If done in unsigned, this won't lead to any optimization, as unsigned > > arithmetic doesn't have overflows. So, if you write "a - 10" where a > > is unsigned, the compiler can't assume anything, whereas is a is > > signed, the compiler can as

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On 2006-12-31 11:01:45 -0500, Robert Dewar wrote: > The issues are > > a) are these optimizations valuable? (and if so, in all cases, >or only in practice for loop invariants?). Even if they aren't valuable today, you don't know what will happen in future code. So, there's another issue: is i

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

On 2006-12-31 11:37:21 -0500, Richard Kenner wrote: > Certainly. Indeed I think that's the whole point of this thread: that if > you want to catch ALL potential optimizations opportunities given to you > by the standard, you must assume that signed overflows are undefined. > > However, what's bei

Re: mpfr issues when Installing gcc 3.4 on fedora core

On 2007-01-03 20:11:35 -0500, drizzle drizzle wrote: > Installed mpfr and gmp and verified mpfr.h and gmp.h exist in > /usr/local/include and libmpfr.a , libgmp.so etc exists in > /usr/local/lib I assume you got MPFR 2.2.1. You can try to rebuild MPFR with --enable-shared, in case you have another

Re: mpfr issues when Installing gcc 3.4 on fedora core

On 2007-01-03 22:19:16 -0500, drizzle drizzle wrote: > Not 4.3 but 3.4 yes the older version. And I built and installed mpfr > and gmp. gmp4.1 and mpfr 2.2. I dont have a /usr/local/lib64 on my > system. Did my mpfr/gmp install incorrecly ? I don't think MPFR install libs in .../lib64 (everytime

Re: mpfr issues when Installing gcc 3.4 on fedora core

On 2007-01-04 12:54:34 -0500, drizzle drizzle wrote: > I am wondering if my all my troubles stem from mpfr not being > installed properly .. > When I configure mpfr I get the following warning. Cud this be an issue ? > > checking if gmp.h version and libgmp version are the same... (4.2.1/4.1.4) >

Re: mpfr issues when Installing gcc 3.4 on fedora core

On 2007-01-04 19:09:23 +0100, Vincent Lefevre wrote: > On 2007-01-04 12:54:34 -0500, drizzle drizzle wrote: > [configure warning due to different libgmp and gmp.h versions] > > Yes (now this test is much more reliable in MPFR 2.2.1). You may have > the following problem (quo

Re: mpfr issues when Installing gcc 3.4 on fedora core

On 2007-01-04 10:42:35 -0800, Joe Buck wrote: > It is an annoying problem that MPFR and GMP follow inconsistent rules. Yes, but this problem is not only between MPFR and GMP. Even if MPFR chose the GMP rules, there would be problems with other software. I don't know any software other than GMP tha

Re: Miscompilation of remainder expressions

On 2007-01-16 12:31:00 -0500, Robert Dewar wrote: > Roberto Bagnara wrote: > >Reading the thread "Autoconf manual's coverage of signed integer > >overflow & portability" I was horrified to discover about GCC's > >miscompilation of the remainder expression that causes INT_MIN % -1 > >to cause a SIGF

Re: Miscompilation of remainder expressions

On 2007-01-16 15:50:09 +, Andrew Haley wrote: > This is a disgreement about interpretation of the langauge in the > standard, which is: > > "The result of the / operator is the quotient from the division of the > first operand by the second; the result of the % operator is the > remainder. In

Re: Miscompilation of remainder expressions

On 2007-01-16 13:08:18 -0800, David Daney wrote: > The difference is that your program didn't get killed by SIGFPE, it > just gave incorrect results. An incorrect result is worse, but being killed by SIGFPE is still very bad. But I was mainly answering the claim "hard to believe this case appears

Re: Miscompilation of remainder expressions

On 2007-01-16 21:27:42 +, Andrew Haley wrote: > Ian Lance Taylor writes: > > I suspect that the best fix, in the sense of generating the best > > code, would be to do this at the tree level. That will give loop > > and VRP optimizations the best chance to eliminate the test for -1. > > Doi

Re: Miscompilation of remainder expressions

On 2007-01-16 13:41:16 -0800, Ian Lance Taylor wrote: > To be clear, in my opinion, this should always be selected by an > option, it should never be default behaviour for any target. I disagree. One should get correct results by default. -- Vincent Lefèvre <[EMAIL PROTECTED]> - Web:

Re: __builtin_cpow((0,0),(0,0))

On 2005-03-07 17:09:46 +0100, Duncan Sands wrote: > Mathematically speaking zero^zero is undefined, so it should be NaN. [...] Mathematically, this is just about conventions. But the main problem here is that the power function is overloaded. For instance, you can use pow() to compute x^i, where i

Re: __builtin_cpow((0,0),(0,0))

On 2005-03-09 12:45:57 +0100, Duncan Sands wrote: > The problem is x^0.0 (real exponent), not x^0 (integer exponent). Well, mathematically, you can distinguish these two functions: powrr: RxR -> R (not defined on (0,0) in particular) and powrz: RxZ -> R (where powint(0,0) = 1) and even oth

Re: __builtin_cpow((0,0),(0,0))

On 2005-03-09 17:37:59 +0100, Gabriel Dos Reis wrote: > Vincent Lefevre <[EMAIL PROTECTED]> writes: > | Well, mathematically, you can distinguish these two functions: > | > | powrr: RxR -> R (not defined on (0,0) in particular) > | > | and > | > | powrz

Re: __builtin_cpow((0,0),(0,0))

On 2005-03-10 01:01:18 +0100, Gabriel Dos Reis wrote: > No. I mean when I call powi() either through built-ins or appropriate > overload (several programming languages do so), I expect sane semantics. What is powi()? I couldn't find it in the C standard. It isn't in the Linux man pages either. >

Re: __builtin_cpow((0,0),(0,0))

On 2005-03-10 15:54:03 +0100, Gabriel Dos Reis wrote: > The C standard is not the holy bible and certainly does not define > everything. We're talking about compiler construction, here. This isn't just compiler construction. __builtin_cpow is equivalent to the C99 cpow (as said in gcc/doc/extend.

Re: __builtin_cpow((0,0),(0,0))

On 2005-03-10 15:29:49 +0100, Paolo Carlini wrote: > Vincent Lefevre wrote: > >What is powi()? I couldn't find it in the C standard. It isn't > >in the Linux man pages either. > > > ;) It's just a new builtin that we have in mainline, very useful for >

Re: __builtin_cpow((0,0),(0,0))

On 2005-03-10 18:05:24 +0100, Paolo Carlini wrote: > Vincent Lefevre wrote: > >BTW, couldn't it be used when compiling C programs too? > >Is there anything planned? > > > Can be used as any other __builtin_*: just call it ;) But this wouldn't be portable. I mea

Re: __builtin_cpow((0,0),(0,0))

On 2005-03-12 02:59:46 +0100, Gabriel Dos Reis wrote: > You probably noticed that in the polynomial expansion, you are using > an integer power -- which everybody agrees on yield 1 at the limit. > > I'm tlaking about 0^0, when you look at the limit of function x^y > -- which is closer to cpow() tg

Re: __builtin_cpow((0,0),(0,0))

On 2005-03-13 15:26:05 +0100, Gabriel Dos Reis wrote: > Vincent Lefevre <[EMAIL PROTECTED]> writes: > | When one uses the power notation in mathematics, one (almost) never > | says when the context is a function R x R -> R or R x Z -> R or > | whatever. > > Tha

Re: Inline round for IA64

On 2005-04-07 08:08:15 -0400, Geert Bosch wrote: > On platforms such as x86, where GCC implicitly widens intermediate > results for IEEE double, This depends on the FPU configuration, so... > the rounding to integer should be performed entirely in long double > mode, using the long double predece

Re: Processor-specific code

On 2005-04-14 10:35:06 -0700, Richard Henderson wrote: > All that said, C99 has to control just about anything you > could want about the fpu. It is not possible to change the rounding precision with . -- Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 100% accessible valida

Re: Processor-specific code

On 2005-04-15 18:56:23 +0100, Paul Brook wrote: > On Friday 15 April 2005 18:43, Vincent Lefevre wrote: > > It is not possible to change the rounding precision with . > > That's because it's an x86/m68k specific implementation detail and > the compiler should be sett

Re: Processor-specific code

On 2005-04-17 19:34:40 -0700, Brooks Moses wrote: > Yes, the standard refers to changing the rounding mode "if the processor > supports [it]" -- but consider what the standard means by "processor": > "The combination of a computing system and the means by which programs > are transformed for use on

Re: New gcc 4.0.0 warnings seem spurious

On 2005-04-26 13:15:43 -0700, Zack Weinberg wrote: > The initializer thus tries to give a variable with type unsigned:8 > a value that it cannot hold. The diagnostic is correct. However it is correct to store any integer to an unsigned variable, even if the original value cannot be represented. Th

Re: New gcc 4.0.0 warnings seem spurious

On 2005-04-27 03:37:15 -0700, Zack Weinberg wrote: > Vincent Lefevre <[EMAIL PROTECTED]> writes: > > However it is correct to store any integer to an unsigned variable, > > even if the original value cannot be represented. > > If that operation occurs at runtime it has

Re: New gcc 4.0.0 warnings seem spurious

On 2005-04-27 11:37:51 +0100, Andrew Haley wrote: > Warnings are to help the programmer see where there is some code that, > although not necessarily an error, may require some attention. This > is a classic case of such a warning. This warning really does > indicate to the programmer that there

Re: New gcc 4.0.0 warnings seem spurious

On 2005-04-27 12:29:53 +0100, Andrew Haley wrote: > Vincent Lefevre writes: > > The only two constraints in 6.6 are: > > > >[#3] Constant expressions shall not contain assignment, > >increment, decrement, function-call, or comma operators, &

Re: New gcc 4.0.0 warnings seem spurious

On 2005-04-27 12:34:14 +0100, Andrew Haley wrote: > You said "if they are never modified, they evaluate to constants, > right?" To which the correct answer is "no, they don't". Why not? -- Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 100% accessible validated (X)HTML - Bl

Re: New gcc 4.0.0 warnings seem spurious

On 2005-04-27 15:41:06 +0200, Gabriel Dos Reis wrote: > Vincent Lefevre <[EMAIL PROTECTED]> writes: > | It is said "constant expressions", not "integer constant expressions". > > And an integer constant expression is not a constant expression in > your cop

Re: New gcc 4.0.0 warnings seem spurious

On 2005-04-27 15:30:39 +0200, Gabriel Dos Reis wrote: > Vincent Lefevre <[EMAIL PROTECTED]> writes: > > [...] > > | > > But if they are never modified, they evaluate to constants, right? > | > > > | > > The fact that they are not considered as co

Re: New gcc 4.0.0 warnings seem spurious

On 2005-04-27 15:44:12 +0200, Gabriel Dos Reis wrote: > Vincent Lefevre <[EMAIL PROTECTED]> writes: > > | On 2005-04-27 12:34:14 +0100, Andrew Haley wrote: > | > You said "if they are never modified, they evaluate to constants, > | > right?" To which

Re: New gcc 4.0.0 warnings seem spurious

On 2005-04-27 15:26:39 +0200, Gabriel Dos Reis wrote: > Vincent Lefevre <[EMAIL PROTECTED]> writes: > > | On 2005-04-27 03:37:15 -0700, Zack Weinberg wrote: > | > Vincent Lefevre <[EMAIL PROTECTED]> writes: > | > > However it is correct to store any integer t

Re: New gcc 4.0.0 warnings seem spurious

On 2005-04-27 17:30:25 +0200, Gabriel Dos Reis wrote: > Vincent Lefevre <[EMAIL PROTECTED]> writes: > > | On 2005-04-27 15:30:39 +0200, Gabriel Dos Reis wrote: > | > Vincent Lefevre <[EMAIL PROTECTED]> writes: > | > > | > [...] > | > > | > | &g

Re: New gcc 4.0.0 warnings seem spurious

On 2005-04-27 15:44:15 +0100, Dave Korn wrote: > Original Message > >From: Vincent Lefevre > >Sent: 27 April 2005 14:59 > > > On 2005-04-27 15:30:39 +0200, Gabriel Dos Reis wrote: > >> Vincent Lefevre <[EMAIL PROTECTED]> writes: > >>

Re: New gcc 4.0.0 warnings seem spurious

On 2005-04-27 18:38:52 +0200, Gabriel Dos Reis wrote: > It has been answered, but I do not believe you made the effort to > understand the answer. Now, let me asnwer it one more time. The vocabulary is important, and I find the gcc diagnostic (cited by Bruce) quite confusing. Then it is not surpr

Re: New gcc 4.0.0 warnings seem spurious

On 2005-04-27 14:30:01 -0700, Mike Stump wrote: > On Apr 27, 2005, at 5:15 AM, Neil Booth wrote: > >Even better, you can turn of the warning with a cast, making your > >intent explicit to the compiler, so there's every reason to have > >it on by default. > > And, if you don't like casts, you can (

Re: GCC and Floating-Point

On 2005-05-24 09:04:11 +0200, Uros Bizjak wrote: > I would like to point out that for applications that crunch data > from real world (no infinites or nans, where precision is not > critical) such as various simulations, -ffast-math is something that > can speed up application a lot. But note th

Re: GCC and Floating-Point

On 2005-05-23 11:14:52 -0400, Scott Robert Ladd wrote: [...] > Naturally, due to hardware availability, I'll be focusing on x86 and > x86_64 systems. > > I'd appreciate comments, ideas, and suggestions from the folk on this > mailing list. You may be interested in my web page "Linux and the Exten

Re: GCC and Floating-Point

On 2005-05-25 15:22:31 +0100, chris jefferson wrote: > On the other hand, in general using != and == on floating point > numbers is always dangerous if you do not know all the consequences. > For example, on your above program if I use 30.1 and 90.3, the > program fails without -ffast-math. Yes, b

Re: GCC and Floating-Point

On 2005-05-25 15:59:28 +0100, Dave Korn wrote: > Original Message > >From: chris jefferson > >Sent: 25 May 2005 15:23 > > On the other hand, in general using != and == on floating point numbers > > is always dangerous if you do not know all the consequences. For > > example, on your above p

Re: GCC and Floating-Point

On 2005-05-25 19:27:21 +0200, Allan Sandfeld Jensen wrote: > Yes. I still don't understand why gcc doesn't do -ffast-math by > default like all other compilers. No! And I really don't think that other compilers do that. It would be very bad, would not conform to the C standard[*] and would make lo

Re: GCC and Floating-Point

On 2005-05-26 09:14:40 -0400, Daniel Berlin wrote: > On Thu, 26 May 2005, Vincent Lefevre wrote: > >On 2005-05-25 19:27:21 +0200, Allan Sandfeld Jensen wrote: > >>Yes. I still don't understand why gcc doesn't do -ffast-math by > >>default like all other com

Re: GCC and Floating-Point

On 2005-05-26 20:49:13 +0200, Allan Sandfeld Jensen wrote: > I can't speak of all compilers, only the ones I've tried. ICC > enables it always, Sun CC, Dec CXX, and HP CC at certain levels of > optimizations (equivalent to -O2). I've tried with "cc: Sun WorkShop 6 2000/04/07 C 5.1", and there does

Re: Sine and Cosine Accuracy

On 2005-05-26 12:04:04 -0400, Scott Robert Ladd wrote: > I've never quite understood the necessity for performing trig > operations on excessively large values, but perhaps my problem > domain hasn't included such applications. This can happen in some numerical applications (the same expressions a

Re: GCC and Floating-Point (A proposal)

On 2005-05-26 14:40:33 +0100, Paul Brook wrote: > I thought the x86 sin/cos intrinsics were unsafe. ie. they don't > gave accurate results in all cases. Yes, and here, this is a bug. See: http://web.archive.org/web/20040409144725/http://www.naturalbridge.com/floatingpoint/intelfp.html -- Vincen

Re: GCC and Floating-Point

On 2005-05-27 07:58:28 -0400, Scott Robert Ladd wrote: > Vincent Lefevre wrote: > > So, yes, -ffast-math by default would really be a bad idea and would > > make gcc much worse than other compilers. > > Who has advocated making -ffast-math the default? I certainly haven'

Re: Sine and Cosine Accuracy

On 2005-05-26 16:33:00 -0500, Menezes, Evandro wrote: > Keep in mind that x87 transcendentals are not the most accurate > around, but all x86 processors from any manufacturer produce roughly > the same results for any argument as the 8087 did way back when, > even if the result is hundreds of ulps

Re: Sine and Cosine Accuracy

On 2005-05-27 15:36:51 +0200, Olivier Galibert wrote: > If you're evaluating it at the floating point value 2^90 you're just > evaluating a fancy prng. Floating point values represent intervals, They don't. Have you never heard of correlation? -- Vincent Lefèvre <[EMAIL PROTECTED]> - Web:

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

On 2005-05-28 17:17:32 +0200, Uros Bizjak wrote: > At this point, I wonder what is wrong with Bugzilla, that those > programmers don't fill a proper bug report. If there is a problem with > GCC, that is so annoying to somebody, I think that at least developers > could be informed about it via th

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

On 2005-05-30 00:31:44 -0400, Daniel Berlin wrote: [http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21809] > Compiling the code there with icc gives us: > > [EMAIL PROTECTED]:~> icc icca.c > icca.c(7): warning #1572: floating-point equality and inequality > comparisons are unreliable > assert(a ==

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

On 2005-05-29 23:59:39 -0400, Daniel Berlin wrote: > On Sun, 2005-05-29 at 18:19 +0300, Michael Veksler wrote: > > If more than 50 people report it, independently, as a bug then it > > sure is a bug. > > Which is why it's still open! It isn't (it was marked as INVALID). > The problem with 323 is

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

On 2005-05-29 13:22:55 +0300, Michael Veksler wrote: > Two examples come in mind: > 1. Non conformance of x86 to the standard FP due to >its extra precision. Wrong. The IEEE-754 standard allows extended precision. >This includes different results between -O2 and -O0 even with >-fsave-

Re: Sine and Cosine Accuracy

ttp://web.archive.org/web/20040409144725/http://www.naturalbridge.com/floatingpoint/intelfp.html I mentioned it here: Date: Fri, 27 May 2005 14:42:32 +0200 From: Vincent Lefevre <[EMAIL PROTECTED]> To: gcc@gcc.gnu.org Subject: Re: GCC and Floating-Point (A proposal) Message-ID: <[EMAIL PROTECTED]>

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

On 2005-05-29 18:19:19 +0300, Michael Veksler wrote: > If more than 50 people report it, independently, as a bug then it > sure is a bug. You might argue whether technically it is a bug, but > from user's perspective it is a bug (and you have over 50 duplicates > as an evidence). As such it has to

Re: GCC and Floating-Point

On 2005-05-29 19:22:57 +0200, Marc Espie wrote: > In article <[EMAIL PROTECTED]> you write: > > http://csdl.computer.org/dl/mags/co/2005/05/r5091.pdf > > "An Open Question to Developers of Numerical Software", by > > W. Kahan and D. Zuras > > Doesn't look publically accessible from my machine..

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

On 2005-05-30 16:12:07 -0400, Robert Dewar wrote: > Haren Visavadia wrote: > >--- Robert Dewar wrote: > > >I would expect the seem behaviour for both cases. > > why? You have some inaccurate model of computation, > which in the absence of switches, is not guaranteed. > Floating-point semantics ar

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

On 2005-05-30 22:18:14 +0200, Toon Moene wrote: > Vincent Lefevre wrote: [...] > >First there is a bug in GCC concerning casts and assignments > >(see ISO/IEC 9899: 5.1.2.3#13, 6.3.1.5#2 and 6.3.1.8#2). > > > >But even this were fixed, many users would still complain.

Re: Sine and Cosine Accuracy

On 2005-05-30 11:51:59 -0400, Scott Robert Ladd wrote: > The fact that trigonometric functions can extended beyond 2D geometry in > no way invalidates their use in their original domain. I've written many > 2D and 3D applications over the years without need for a sine outside > the range [0, 2*PI]

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

On 2005-05-31 13:16:55 +0100, Andrew Haley wrote: > Vincent Lefevre writes: > > According to 5.1.2.3#13, 6.3.1.5#2 and 6.3.1.8#2, the assert should > > not fail (unless the division yields a NaN, but that would be a very > > bad implementation anyway). > > I have re

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

On 2005-05-31 14:27:01 +0200, Andreas Schwab wrote: > Vincent Lefevre <[EMAIL PROTECTED]> writes: > > But as I said on my page, this isn't much a problem since users > > who really need *extended* precision can still set the rounding > > precision to extended pre

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

On 2005-05-31 13:16:55 +0100, Andrew Haley wrote: > Vincent Lefevre writes: > > According to 5.1.2.3#13, 6.3.1.5#2 and 6.3.1.8#2, the assert should > > not fail (unless the division yields a NaN, but that would be a very > > bad implementation anyway). > > I have re

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

On 2005-05-31 15:33:48 +0200, Andreas Schwab wrote: > Vincent Lefevre <[EMAIL PROTECTED]> writes: > > On 2005-05-31 14:27:01 +0200, Andreas Schwab wrote: > >> Vincent Lefevre <[EMAIL PROTECTED]> writes: > >> > But as I said on my page, this isn't mu

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

On 2005-05-31 16:07:53 +0200, Andreas Schwab wrote: > Vincent Lefevre <[EMAIL PROTECTED]> writes: > > > On 2005-05-31 15:33:48 +0200, Andreas Schwab wrote: > >> Vincent Lefevre <[EMAIL PROTECTED]> writes: > >> > On 2005-05-31 14:27:01 +0200, Andreas

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

On 2005-05-31 10:30:52 -0400, Scott Robert Ladd wrote: > If you follow Standard C, you are guaranteed source code portability, in > the program compiles and produce the "same" results with any Standard C > compiler. > > When we start talking about floating-point code, however, we enter the > realm

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

On 2005-05-31 17:10:58 +0200, Andreas Schwab wrote: > Scott Robert Ladd <[EMAIL PROTECTED]> writes: > > "Portability" means different things to different people. There's a > > difference between source code portability and "result" portability. > > But making round to double the default makes it o

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

On 2005-05-31 09:56:31 -0700, Mike Stump wrote: > On Tuesday, May 31, 2005, at 06:43 AM, Vincent Lefevre wrote: > >No, this is not portable, since if extended precision is necessary to > >get correct results for some application, the same application run on > >PowerPC, where

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

On 2005-05-31 19:30:48 +0200, Jakub Jelinek wrote: > IEEE 754 is not mandated by the ISO C{90,99} standards and there are indeed > platforms where float and double are not using IEEE 754 single resp. double > precision formats. But without IEEE-754 support, the ISO C99 standard is just a big joke

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

On 2005-05-31 11:39:39 -0700, Mike Stump wrote: > On May 31, 2005, at 10:25 AM, Vincent Lefevre wrote: > >Well, there is no extended precision with GCC under Linux/PPC. > > Hum, I do wonder about even that; why do: > > 2004-02-07 Alan Modra <[EMAIL PROTECTED]> >

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

On 2005-05-31 21:16:19 +0200, Andreas Schwab wrote: > Vincent Lefevre <[EMAIL PROTECTED]> writes: > > The "long double" type is required, but it is not required to be > > extended precision. > > But it can be. So what? > > Once you change the rou

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

On 2005-05-31 22:11:36 +0200, Andreas Schwab wrote: > Vincent Lefevre <[EMAIL PROTECTED]> writes: > > On 2005-05-31 21:16:19 +0200, Andreas Schwab wrote: > >> Vincent Lefevre <[EMAIL PROTECTED]> writes: > >> > The "long double" type is re

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

On 2005-06-01 00:58:25 +0200, Andreas Schwab wrote: > You are mistaken. No, I don't see any problem. > #include > #include > > long double one = 1.0; > long double one_plus_eps; > > int > main (void) > { > long double one_plus_eps; > > one_plus_eps = one + LDBL_EPSILON; > assert (one !

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

On 2005-06-01 15:29:37 +0930, Alan Modra wrote: > On Tue, May 31, 2005 at 09:53:05PM +0200, Vincent Lefevre wrote: > > Under the 32-bit version, there's no extended precision. > > No. powerpc-linux has 128-bit IEEE soft-float long double. > > $ cat > fadd.c &l

Re: What is wrong with Bugzilla? [Was: Re: GCC and Floating-Point]

On 2005-06-06 19:23:06 -0400, Robert Dewar wrote: > Laurent GUERBY wrote: > > >Such algorithm usually require a very detailed control of what's > >going on at the machine level, given current high level programming > >languages that means using assembler. > > No, that's not true, you might want t

  1   2   3   4   >