Diego Novillo <[EMAIL PROTECTED]> writes:
> On Wed, May 25, 2005 at 03:37:29PM -0600, Jeffrey A Law wrote:
>
>> So, if I wanted to be able to bootstrap Ada, what I do I need
>> to do? Disable VRP?
>>
> Applying the patches in the PRs I mentioned. If that doesn't
> work, try with VRP disabled.
D
"Kaveh R. Ghazi" <[EMAIL PROTECTED]> writes:
| > > Now we have e.g. XNEW* and all we need is a new -W* flag to catch
| > > things like using C++ keywords and it should be fairly automatic to
| > > keep incompatibilities out of the sources.
| >
| > Why not this?
| >
| > #ifndef __cplusplus
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
Allan Sandfeld Jensen wrote:
>>Yes. I still don't understand why gcc doesn't do -ffast-math by
>>default like all other compilers.
Vincent Lefevre wrote:
> 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 lot
On 5/26/05, Scott Robert Ladd <[EMAIL PROTECTED]> wrote:
> Allan Sandfeld Jensen wrote:
> >>Yes. I still don't understand why gcc doesn't do -ffast-math by
> >>default like all other compilers.
>
> Vincent Lefevre wrote:
> > No! And I really don't think that other compilers do that.
> > It would b
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 compilers.
No! And I really don't think that other compilers do that.
Have you looked, or are you j
Scott Robert Ladd <[EMAIL PROTECTED]> wrote:
>>May I be so bold as to suggest that -funsafe-math-optimizations be
>>reduced in scope to perform exactly what it's name implies:
>>transformations that may slightly alter the meanding of code. Then move
>>the use of hardware intrinsics to a new -fhardw
On Thursday 26 May 2005 14:25, Scott Robert Ladd wrote:
> Scott Robert Ladd <[EMAIL PROTECTED]> wrote:
> >>May I be so bold as to suggest that -funsafe-math-optimizations be
> >>reduced in scope to perform exactly what it's name implies:
> >>transformations that may slightly alter the meanding of c
Paul Brook <[EMAIL PROTECTED]> writes:
| On Thursday 26 May 2005 14:25, Scott Robert Ladd wrote:
| > Scott Robert Ladd <[EMAIL PROTECTED]> wrote:
| > >>May I be so bold as to suggest that -funsafe-math-optimizations be
| > >>reduced in scope to perform exactly what it's name implies:
| > >>transfo
Paul Brook wrote:
> I thought the x86 sin/cos intrinsics were unsafe. ie. they don't gave
> accurate
> results in all cases.
If memory serves, Intel's fsin (for example) has an error > 1 ulp for
value flose to multiples of pi (2pi, for example).
Now, I'm not certain this is true for the K8 and
Let's consider the accuracy of sice and cosine. I've run tests as
follows, using a program provided at the end of this message.
On the Opteron, using GCC 4.0.0 release, the command lines produce these
outputs:
-lm -O3 -march=k8 -funsafe-math-optimizations -mfpmath=387
generates:
fsincos
Scott Robert Ladd writes:
>
> The program used is below. I'm very open to suggestions about this
> program, which is a subset of a larger accuracy benchmark I'm writing
> (Subtilis).
Try this:
public class trial
{
static public void main (String[] argv)
{
System.out.println(Math.sin(
Andrew Haley wrote:
> Try this:
>
> public class trial
> {
> static public void main (String[] argv)
> {
> System.out.println(Math.sin(Math.pow(2.0, 90.0)));
> }
> }
>
> zapata:~ $ gcj trial.java --main=trial -ffast-math -O
> zapata:~ $ ./a.out
> 1.2379400392853803E27
> zapata:~ $ gcj
Andrew Haley wrote
> zapata:~ $ gcj trial.java --main=trial -ffast-math -O
^^
Ok, maybe those people that are accusing the Free Software philosophy of
being akin to communisn are wrong, but it looks like revolutionaries are
lurking around, at least... ;) ;)
Paolo.
Scott Robert Ladd writes:
> Andrew Haley wrote:
> > Try this:
> >
> > public class trial
> > {
> > static public void main (String[] argv)
> > {
> > System.out.println(Math.sin(Math.pow(2.0, 90.0)));
> > }
> > }
> >
> > zapata:~ $ gcj trial.java --main=trial -ffast-math -O
On Thu, May 26, 2005 at 10:34:14AM -0400, Scott Robert Ladd wrote:
> static const double range = PI; // * 2.0;
> static const double incr = PI / 100.0;
The trig insns fail with large numbers; an argument
reduction loop is required with their use.
r~
Richard Henderson wrote:
> On Thu, May 26, 2005 at 10:34:14AM -0400, Scott Robert Ladd wrote:
>
>>static const double range = PI; // * 2.0;
>>static const double incr = PI / 100.0;
>
>
> The trig insns fail with large numbers; an argument
> reduction loop is required with their use.
Ye
> "Scott" == Scott Robert Ladd <[EMAIL PROTECTED]> writes:
Scott> Richard Henderson wrote:
>> On Thu, May 26, 2005 at 10:34:14AM -0400, Scott Robert Ladd wrote:
>>
>>> static const double range = PI; // * 2.0; static const double
>>> incr = PI / 100.0;
>>
>>
>> The trig insns fail w
Paul Koning wrote:
> Scott> Yes, but within the defined mathematical ranges for sine and
> Scott> cosine -- [0, 2 * PI) -- the processor intrinsics are quite
> Scott> accurate.
>
> Huh? Sine and consine are mathematically defined for all finite
> inputs.
Defined, yes. However, I'm speaking a
Original Message
>From: Scott Robert Ladd
>Sent: 26 May 2005 17:32
> Paul Koning wrote:
>> Scott> Yes, but within the defined mathematical ranges for sine and
>> Scott> cosine -- [0, 2 * PI) -- the processor intrinsics are quite
>> Scott> accurate.
>>
>> Huh? Sine and consine are mat
Paul Koning wrote:
"Scott" == Scott Robert Ladd <[EMAIL PROTECTED]> writes:
Scott> Richard Henderson wrote:
>> On Thu, May 26, 2005 at 10:34:14AM -0400, Scott Robert Ladd wrote:
>>
>>> static const double range = PI; // * 2.0; static const double
>>> incr = PI / 100.0;
>>
>>
>
Dave Korn wrote:
" Identities such as
sin(x)^2 + cos(x)^2 === 1
are only valid when 0 <= x <= 2*PI"
It's been a while since I studied math, but isn't that particular
identity is true for any x real or complex?
David Daney,
Dave Korn wrote:
> It's difficult to tell from that quote, which lacks sufficient context,
> but you *appear* at first glance to be conflating the fundamental
> trignometric *functions* with the trignometric *identities* that are
> generally built up from those functions. That is to say, you ap
> "Kevin" == Kevin Handy <[EMAIL PROTECTED]> writes:
Kevin> But, you are using a number in the range of 2^90, only have 64
Kevin> bits for storing the floating point representation, and some
Kevin> of that is needed for the exponent.
Fair enough, so with 64 bit floats you have no right to
> Yes, but within the defined mathematical ranges for sine and cosine --
> [0, 2 * PI) -- the processor intrinsics are quite accurate.
If you were to look up a serious math book like Abramowitz&Stegun1965
you would see a definition like
sin z = ((exp(iz)-exp(-iz))/2i [4.3.1]
I'm pleased to announce that GCC 3.3.6 has been released.
This version is a minor release, fixing regressions in GCC 3.3.5
with respect to previous versions of GCC. It can be downloaded from
the FTP serves listed here
http://www.gnu.org/order/ftp.html
The list of change
Original Message
>From: David Daney
>Sent: 26 May 2005 18:23
> Dave Korn wrote:
>
>> " Identities such as
>> sin(x)^2 + cos(x)^2 === 1
>> are only valid when 0 <= x <= 2*PI"
>>
>
> It's been a while since I studied math, but isn't that particular
> identity is true for any
Morten Welinder wrote:
> If you were to look up a serious math book like Abramowitz&Stegun1965
> you would see a definition like
>
> sin z = ((exp(iz)-exp(-iz))/2i [4.3.1]
Very true. However, the processor doesn't implement intrinsics for
complex functions -- well, maybe som
> "Scott" == Scott Robert Ladd <[EMAIL PROTECTED]> writes:
Scott> Dave Korn wrote:
>> It's difficult to tell from that quote, which lacks sufficient
>> context, but you *appear* at first glance to be conflating the
>> fundamental trignometric *functions* with the trignometric
>> *identiti
Original Message
>From: Scott Robert Ladd
>Sent: 26 May 2005 18:36
> I am simply lobbying for the separation of hardware intrinsics from
> -funsafe-math-optimizations.
Well, as long as they're under the control of a flag that also makes it
clear that they are *also* unsafe math optimi
I wonder what best to do about rtl-optimization/21767.
We sometimes have REG_EQUAL notes that are only true when
the instruction stays exactly where it is, like:
(insn 11 10 12 0 (set (reg:SI 147 t)
(eq:SI (reg/v:SI 159 [ i ])
(reg:SI 161))) 1 {cmpeqsi_t} (nil)
(expr_list:RE
Paul Koning wrote:
> I'm really puzzled by that comment, partly because the text book quote
> you gave doesn't match any math I ever learned. Does "knowing your
> math" translates to "believing that trig functions should be applied
> only to arguments in the range 0 to 2pi"? If so, I must object.
> But, you are using a number in the range of 2^90, only
> have 64 bits for storing the floating point representation, and
> some of that is needed for the exponent.
> 2^90 would require 91 bits for the base alone (as an integer
> value), plus a couple more for the '*PI' portion, and then
> more fo
Dave Korn wrote:
> Well, as long as they're under the control of a flag that also makes it
> clear that they are *also* unsafe math optimisations, I wouldn't object.
But they are *not* unsafe for *all* applications.
An ignorant user may not understand the ramifications of "unsafe" math
-- howev
After some off-line exchanges with Dave Korn, it seems to me that part
of the problem is that the documentation for
-funsafe-math-optimizations is so vague as to have no discernable
meaning.
For example, does the wording of the documentation convey the
limitation that one should only invoke math
On May 26, 2005, at 2:12 PM, Paul Koning wrote:
What does (b) mean? What if anything are its limitations? Is
returning 1.2e27 as the result for a sin() call authorized by (b)? I
would not have expected that, but I can't defend that expectation
based on a literal reading of the text...
b) m
Original Message
>From: Scott Robert Ladd
>Sent: 26 May 2005 19:09
> Dave Korn wrote:
>> Well, as long as they're under the control of a flag that also makes it
>> clear that they are *also* unsafe math optimisations, I wouldn't object.
>
> But they are *not* unsafe for *all* applicatio
Andrew Pinski wrote:
> b) means that (-a)*(b-c) can be changed to a*(c-b) and other reassociation
> opportunities.
This is precisely the sort of transformation that, in my opinion, should
be separate from the hardware intrinsics. I mentioned this specific case
earlier in the thread (I think; maybe
On Thu, 26 May 2005, Paul Koning wrote:
> > "Kevin" == Kevin Handy <[EMAIL PROTECTED]> writes:
>
> Kevin> But, you are using a number in the range of 2^90, only have 64
> Kevin> bits for storing the floating point representation, and some
> Kevin> of that is needed for the exponent.
>
> F
On Thursday 26 May 2005 10:15, 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 compilers.
>
> No! And I really don't think that other compilers do that.
I can't speak
Morten Welinder writes:
> > But, you are using a number in the range of 2^90, only
> > have 64 bits for storing the floating point representation, and
> > some of that is needed for the exponent.
> > 2^90 would require 91 bits for the base alone (as an integer
> > value), plus a couple more fo
Allan Sandfeld Jensen wrote:
> Basically any compiler that cares about benchmarks have it enabled by default.
>
> Many of them however have multiple levels of relaxed floating point. The
> lowest levels will try to be as accurate as possible, while the higher will
> loosen the accuracy and just
Scott Robert Ladd <[EMAIL PROTECTED]> writes:
| Richard Henderson wrote:
| > On Thu, May 26, 2005 at 10:34:14AM -0400, Scott Robert Ladd wrote:
| >
| >>static const double range = PI; // * 2.0;
| >>static const double incr = PI / 100.0;
| >
| >
| > The trig insns fail with large number
Gabriel Dos Reis wrote:
> Scott Robert Ladd <[EMAIL PROTECTED]> writes:
> | 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.
>
> The world is flat; I never quite understood
On Thu, May 26, 2005 at 12:04:04PM -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.
Whether you think it necessary or not, the ISO C functions
Scott Robert Ladd <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > Scott Robert Ladd <[EMAIL PROTECTED]> writes:
| > | I've never quite understood the necessity for performing trig operations
| > | on excessively large values, but perhaps my problem domain hasn't
| > | included such appli
Hello!
Fair enough, so with 64 bit floats you have no right to expect an
accurate answer for sin(2^90). However, you DO have a right to expect
an answer in the range [-1,+1] rather than the 1.2e+27 that Richard
quoted. I see no words in the description of
-funsafe-math-optimizations to lead me
> "Uros" == Uros Bizjak <[EMAIL PROTECTED]> writes:
Uros> Hello!
>> Fair enough, so with 64 bit floats you have no right to expect an
>> accurate answer for sin(2^90). However, you DO have a right to
>> expect an answer in the range [-1,+1] rather than the 1.2e+27 that
>> Richard quoted.
Uros Bizjak <[EMAIL PROTECTED]> writes:
[...]
| Out of curiosity, where could sin(2^90) be needed? It looks rather
| big angle to me.
If it was and angle! Not everything that is an argument to sin or cos
is an angle. They are just functions! Suppose you're evaluating an
approximation of a F
On Friday 27 May 2005 00:26, Gabriel Dos Reis wrote:
> Uros Bizjak <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | Out of curiosity, where could sin(2^90) be needed? It looks rather
> | big angle to me.
>
> If it was and angle! Not everything that is an argument to sin or cos
> is an angle. They ar
Uros,
> However, the argument to fsin can be reduced to an
> acceptable range by using fmod builtin. Internally, this
> builtin is implemented as a very tight loop that check for
> insufficient reduction, and could reduce whatever finite
> value one wishes.
Keep in mind that x87 transcende
Richard Henderson wrote:
> On Thu, May 26, 2005 at 12:04:04PM -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.
>
>
> Whether you think it
Gabriel Dos Reis wrote:
> Yeah, the problem with people who work only with angles is that they
> tend to forget that sin (and friends) are defined as functions on
> *numbers*, not just angles or whatever, and happen to appear in
> approximations of functions as series (e.g. Fourier series) and ther
Scott,
> For a wide variety of applications, the hardware intrinsics
> provide both faster and more accurate results, when compared
> to the library functions.
This is not true. Compare results on an x86 systems with those on an x86_64 or
ppc. As I said before, shortcuts were taken in x87 t
Scott Robert Ladd <[EMAIL PROTECTED]> writes:
| Richard Henderson wrote:
| > On Thu, May 26, 2005 at 12:04:04PM -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
|
Snapshot gcc-4.0-20050526 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20050526/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 CVS branch
with the following options: -rgcc-ss-4_0-20050526
You'll
Scott Robert Ladd <[EMAIL PROTECTED]> writes:
| Gabriel Dos Reis wrote:
| > Yeah, the problem with people who work only with angles is that they
| > tend to forget that sin (and friends) are defined as functions on
| > *numbers*, not just angles or whatever, and happen to appear in
| > approximati
Menezes, Evandro wrote:
> This is not true. Compare results on an x86 systems with those on an
> x86_64 or ppc. As I said before, shortcuts were taken in x87 that
> sacrificed accuracy for the sake of speed initially and later of
> compatibility.
It *is* true for the case where the argument is i
Scott,
> > This is not true. Compare results on an x86 systems with
> those on an
> > x86_64 or ppc. As I said before, shortcuts were taken in x87 that
> > sacrificed accuracy for the sake of speed initially and later of
> > compatibility.
>
> It *is* true for the case where the argument is
Gabriel Dos Reis wrote:
> Scott Robert Ladd <[EMAIL PROTECTED]> writes:
> | Then, as someone else said, why doesn't the compiler enforce -ansi
> | and/or -pedantic by default?
>
> Care submitting a ptach?
Would a strictly ansi default be accepted on principle? Given the
existing code base of non-
Menezes, Evandro wrote:
> Besides, you're also comparing 80-bit calculations with 64-bit
> calculations, not only the accuracy of sin and cos. Try using
> -ffloat-store along with -mfpmath=387 and see yet another set of
> results. At the end of the day, which one do you trust? I wouldn't
> trust
There are 163 regressions open against 4.0.1. Of these, 42 are
critical, in the sense that they are wrong-code, ICE-on-valid, or
rejects-valid. That's rather worse than we've done with previous
releases; in part because we're carrying along bugs that we never get
around to fixing from release to
On 2005-05-23, at 08:15, Gabriel Dos Reis wrote:
Sixth, there is a real "mess" about name spaces. It is true that
every C programmers knows the rule saying tags inhabit different name
space than variable of functions. However, all the C coding standards
I've read so far usually suggest
t
On 2005-05-24, at 09:09, Zack Weinberg wrote:
Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
[dropping most of the message - if I haven't responded, assume I don't
agree but I also don't care enough to continue the argument. Also,
rearranging paragraphs a bit so as not to have to repeat myself]
On 2005-05-24, at 06:00, Andrew Pinski wrote:
On May 24, 2005, at 12:01 AM, Zack Weinberg wrote:
Use of bare 'inline' is just plain wrong in our source code; this has
nothing to do with C++, no two C compilers implement bare 'inline'
alike. Patches to add 'static' to such functions (AND MAK
On 2005-05-24, at 18:06, Diego Novillo wrote:
On Mon, May 23, 2005 at 01:15:17AM -0500, Gabriel Dos Reis wrote:
So, if various components maintainers (e.g. C and C++, middle-end,
ports, etc.) are willing to help quickly reviewing patches we can
have this done for this week (assuming mainlin
On 2005-05-25, at 08:06, Christoph Hellwig wrote:
On Tue, May 24, 2005 at 05:14:42PM -0700, Zack Weinberg wrote:
I'm not sure what the above may imply for your ongoing
discussion, tough...
Well, if I were running the show, the 'clock' would only start
running
when it was consensus amo
On 2005-05-26, at 21:34, Scott Robert Ladd wrote:
For many practical problems, the world can be considered flat. And
I do
plenty of spherical geometry (GPS navigation) without requiring the
sin
of 2**90. ;)
Yes right. I guess your second name is ignorance.
On 2005-05-27, at 00:00, Gabriel Dos Reis wrote:
Yeah, the problem with people who work only with angles is that they
tend to forget that sin (and friends) are defined as functions on
*numbers*,
The problem with people who work only with angles is that they are
without sin.
On 2005-05-26, at 22:39, Gabriel Dos Reis wrote:
Scott Robert Ladd <[EMAIL PROTECTED]> writes:
| Richard Henderson wrote:
| > On Thu, May 26, 2005 at 10:34:14AM -0400, Scott Robert Ladd wrote:
| >
| >>static const double range = PI; // * 2.0;
| >>static const double incr = PI / 100.0;
I did a checkin using ../ in one of the files and cvs screwed up.
The ChangeLog file came out ok, but, all the others were created
someplace else. I'm thinking those ,v files should just be rmed off
the server... but, would rather someone else do that. Thanks.
I was in gcc/testsuite/obj
Mike Stump <[EMAIL PROTECTED]> writes:
> I did a checkin using ../ in one of the files and cvs screwed up.
> The ChangeLog file came out ok, but, all the others were created
> someplace else. I'm thinking those ,v files should just be rmed off
> the server... but, would rather someone else do th
On May 26, 2005, at 8:47 PM, Ian Lance Taylor wrote:
I have removed these files from the server.
Much thanks.
73 matches
Mail list logo
