"Menezes, Evandro" <[EMAIL PROTECTED]> writes:
| > If this option makes it into GCC, maybe it could be named
| > -O3_unsafe.
|
| How about the popular -fast?
But, some transformations can both be valid and generate "faster"
code. One of the confusions is that people tend to equate
"fast" with
> If this option makes it into GCC, maybe it could be named
> -O3_unsafe.
How about the popular -fast?
--
___
Evandro MenezesAMD Austin, TX
On Thu, 16 Jun 2005, Geoffrey Keating wrote:
> Although it does do some of this, -ffloat-store also has some rather nasty
> side-effects, because of what it is actually documented to do:
>
> > @item -ffloat-store
> > @opindex ffloat-store
> > Do not store floating point variables in registers, an
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
> On Tue, 14 Jun 2005, Geoffrey Keating wrote:
>
> > So, what I think you want to do is to add another flag under
> > -ffast-math, perhaps called -fwiden-math, which specifically allows
> > the compiler to compute values in a wider mode (that would be
On Tue, 14 Jun 2005, Geoffrey Keating wrote:
> So, what I think you want to do is to add another flag under
> -ffast-math, perhaps called -fwiden-math, which specifically allows
> the compiler to compute values in a wider mode (that would be 80-bit
> x87 FP) even when ISO C doesn't allow it. You
Robert Dewar wrote:
I would avoid the words safe and unsafe, because
a) they are technical terms in the realm of high integrity programming
b) they are unnecessarily emotive (who wants unsafe code?)
I agree, but term "unsafe" is less important then fact that developer
will have only one gcc
Mirza wrote:
re: -ffp-damn-the-torpedoes-full-speed-ahead
If this option makes it into GCC, maybe it could be named -O3_unsafe. It
would be (probably) default for 99% of projects out there to use this
option alone (which is OK), so why not make their life easier. Just a
thought.
mirza
I w
re: -ffp-damn-the-torpedoes-full-speed-ahead
If this option makes it into GCC, maybe it could be named -O3_unsafe. It
would be (probably) default for 99% of projects out there to use this
option alone (which is OK), so why not make their life easier. Just a
thought.
mirza
Marcin Dalecki wrote:
> Please bear with me. English is my 3th foreign language.
No offense intended, You're lucky you haven't been subjected to my
Spanish... my wife cringes.
> You should always place Java last in discussions about numerical work.
> It's largely irrelevant in this area due to th
Scott Robert Ladd <[EMAIL PROTECTED]> writes:
> To support different expectations, I suggest defining the following
> floating-point options for GCC. This is a conceptual overview; once
> there's a consensus the categories, I'll propose something more formal.
>
> -ffp-correct
>
> This option foc
On 2005-06-15, at 13:50, Scott Robert Ladd wrote:
Perhaps my understanding of math isn't as elite as yours, but I do
know
that "worser" isn't a word. ;)
Please bear with me. English is my 3th foreign language.
Only the following options would make sense:
1. An option to declare 100% IEEE
Marcin Dalecki wrote:
> Sorry but I just got completely fed up by the references to "math" by
> the original post, since the authors leak of basic experience in the
> area of numerical computation was more then self evident.
My apologies for not meeting your high intellectual standards, ;P
> Maki
On 2005-06-15 12:53:26 +1000, Russell Shaw wrote:
> Robert Dewar wrote:
> >Russell Shaw wrote:
> >>The original bug was about testing the equality of doubles. I
> >>think that's just plain mathematically bad. Error bands should be
> >>used to test for "equality", using a band that is in accordance
On 2005-06-15, at 06:19, R Hill wrote:
Marcin Dalecki wrote:
[snip]
If you don't have anything constructive to contribute to the
discussion then feel free to not participate. If you have
objections then voice them appropriately or risk them being
dismissed as bullshit baiting.
Sorr
Marcin Dalecki wrote:
[snip]
If you don't have anything constructive to contribute to the discussion
then feel free to not participate. If you have objections then voice
them appropriately or risk them being dismissed as bullshit baiting.
--de.
Robert Dewar wrote:
Russell Shaw wrote:
The original bug was about testing the equality of doubles. I think
that's
just plain mathematically bad. Error bands should be used to test for
"equality", using a band that is in accordance with the minimum precision
specified in the compiler documenta
On 2005-06-14, at 19:29, Russell Shaw wrote:
The original bug was about testing the equality of doubles. I think
that's
just plain mathematically bad. Error bands should be used to test for
"equality", using a band that is in accordance with the minimum
precision
specified in the compiler
On 2005-06-14, at 16:32, Scott Robert Ladd wrote:
To support different expectations, I suggest defining the following
floating-point options for GCC. This is a conceptual overview; once
there's a consensus the categories, I'll propose something more
formal.
-ffp-correct
Please define corre
Vincent Lefevre wrote:
has little to say about mapping to high level languages, so it is
important to understand that appealing to this standard is necessary
but far from efficient.
Why not efficient?
Oops, efficiency on the mind, I meant sufficient :-)
Russell Shaw wrote:
The original bug was about testing the equality of doubles. I think that's
just plain mathematically bad. Error bands should be used to test for
"equality", using a band that is in accordance with the minimum precision
specified in the compiler documentation.
That's often t
On 2005-06-14 13:37:41 -0400, Scott Robert Ladd wrote:
> I suppose I need to be consistent... ;) I've said in past threads,
> GCC should default to -ansi -std=c99/c++98 -pedantic, and any
> deviation should require specification of an option.
You're not consistent here.
[from the gcc 4.0 man page
Robert Dewar wrote:
Scott Robert Ladd wrote:
To support different expectations, I suggest defining the following
floating-point options for GCC. This is a conceptual overview; once
there's a consensus the categories, I'll propose something more formal.
-ffp-correct
This option focuses code ge
Vincent Lefevre wrote:
> I don't like the word "correct" here, since the correctness
> depends very much on the context.
Good point.
> I disagree. The default should be a conforming C99 implementation.
I suppose I need to be consistent... ;) I've said in past threads, GCC
should default to -ansi
Robert Dewar wrote:
Scott Robert Ladd wrote:
To support different expectations, I suggest defining the following
floating-point options for GCC. This is a conceptual overview; once
there's a consensus the categories, I'll propose something more formal.
-ffp-correct
This option focuses code ge
On 2005-06-14 10:52:53 -0400, Robert Dewar wrote:
> Scott Robert Ladd wrote:
> >-ffp-correct
> >
> >This option focuses code generation on mathematical correctness,
> >portability, and consistency. No 80-bit long doubles, no fsin/fcos,
> >making certain that comparison operators work within reason.
On 2005-06-14 10:32:57 -0400, Scott Robert Ladd wrote:
> To support different expectations, I suggest defining the following
> floating-point options for GCC. This is a conceptual overview; once
> there's a consensus the categories, I'll propose something more formal.
>
> -ffp-correct
>
> This op
Scott Robert Ladd wrote:
To support different expectations, I suggest defining the following
floating-point options for GCC. This is a conceptual overview; once
there's a consensus the categories, I'll propose something more formal.
-ffp-correct
This option focuses code generation on mathematic
To support different expectations, I suggest defining the following
floating-point options for GCC. This is a conceptual overview; once
there's a consensus the categories, I'll propose something more formal.
-ffp-correct
This option focuses code generation on mathematical correctness,
portability
28 matches
Mail list logo
