--- Comment #23 from rguenth at gcc dot gnu dot org 2008-01-22 14:46
---
Subject: Bug 28796
Author: rguenth
Date: Tue Jan 22 14:45:56 2008
New Revision: 131723
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131723
Log:
2008-01-22 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #22 from rguenth at gcc dot gnu dot org 2006-11-06 09:33
---
Subject: Bug 28796
Author: rguenth
Date: Mon Nov 6 09:33:16 2006
New Revision: 118517
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118517
Log:
2006-11-06 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #21 from rguenth at gcc dot gnu dot org 2006-10-24 09:23
---
Ah well, this seems to be documented as such:
-mieee-fp
-mno-ieee-fp
Control whether or not the compiler uses IEEE floating point comparisons.
These handle correctly the case where the result of a comparison i
--- Comment #20 from rguenth at gcc dot gnu dot org 2006-10-24 09:19
---
This is now nearly fixed. What is remaining is that specifying the
-mno-ieee-fp
target option does not set flag_finite_math_only, but I am not sure if it
should so. This causes
[ollmia:/tmp] iano% gcc main3.c -W
--- Comment #19 from rguenth at gcc dot gnu dot org 2006-10-24 09:15
---
Subject: Bug 28796
Author: rguenth
Date: Tue Oct 24 09:15:07 2006
New Revision: 118001
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118001
Log:
2006-10-24 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #18 from rguenth at gcc dot gnu dot org 2006-10-21 10:13
---
Subject: Bug 28796
Author: rguenth
Date: Sat Oct 21 10:13:13 2006
New Revision: 117928
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117928
Log:
2006-10-21 Richard Guenther <[EMAIL PROTECTED]>
--- Comment #17 from rguenth at gcc dot gnu dot org 2006-08-24 13:41
---
See also the target specific fix
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00873.html
and the middle-end fix
http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00874.html
(as this is not a regression this may hav
--- Comment #16 from rguenth at gcc dot gnu dot org 2006-08-24 13:17
---
Created an attachment (id=12127)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12127&action=view)
patch
I'm going to improve the situation by following the principle of least surprise
and not relying on the
--- Comment #15 from rguenth at gcc dot gnu dot org 2006-08-24 13:03
---
One problem is that in fold-const.c we use HONOR_XXX macros, while in
builtins.c
folding we use MODE_HAS_XXX. HONOR_XXX changes with -ffinite-math-only and
friends, while MODE_HAS_XXX not (of course).
So to make
--- Comment #14 from iano at apple dot com 2006-08-22 18:25 ---
For your amusement:
[ollmia:/tmp] iano% cat main.c
#include
extern int __isnand( double );
static __inline__ int __inline_isnan( double __a )
{
if( __builtin_isnan( __builtin_nan("") ) )
return _
--- Comment #13 from rguenth at gcc dot gnu dot org 2006-08-22 08:26
---
I confirm there are problems in the i386/x86_64 backends and possibly the
middle-end expanders. And I appreciate testcases that show wrong or
inconsistent behavior (even more so if citing the relevant standards an
--- Comment #12 from iano at apple dot com 2006-08-22 02:05 ---
"That however is not a clear bug.
-ffinite-math-only says that it assumes that there are no NaNs in the
input, and you violated that assumption, so the results you will get are
undefined. That is, gcc is allowed to give
--- Comment #11 from iano at apple dot com 2006-08-22 01:45 ---
About the manual wrongheadedness:
The major argument that I have heard from members of the GCC community (here
and elsewhere) against isnan() in its various forms correctly detecting NaN
when various hacky math flags are tu
--- Comment #10 from wilson at specifix dot com 2006-08-22 01:37 ---
Subject: Re: New: __builtin_nan() and __builtin_unordered()
inconsistent
iano at apple dot com wrote:
> Cloning due to closed minded bug screener:
> ^^^
> >ATTN: P
--- Comment #9 from iano at apple dot com 2006-08-22 00:49 ---
Subject: Re: __builtin_nan() and __builtin_unordered() inconsistent
On Aug 21, 2006, at 5:42 PM, pinskia at physics dot uc dot edu wrote:
>
>
> --- Comment #8 from pinskia at physics dot uc dot edu
> 2006-08-22 00:
--- Comment #8 from pinskia at physics dot uc dot edu 2006-08-22 00:42
---
Subject: Re: __builtin_nan() and __builtin_unordered() inconsistent
> Which part of:
>
> __builtin_isunordered(nan,nan) = 1
> __builtin_isnan(nan) = 0
>
> is consistent?
Did you read what the options do beca
> Which part of:
>
> __builtin_isunordered(nan,nan) = 1
> __builtin_isnan(nan) = 0
>
> is consistent?
Did you read what the options do because it seems like you did not and you keep
on agruing that
it is inconsistent except for the fact this is way these options are done as it
just says "allow
--- Comment #7 from iano at apple dot com 2006-08-22 00:39 ---
Subject: Re: __builtin_nan() and __builtin_unordered() inconsistent
On Aug 21, 2006, at 5:34 PM, pinskia at gcc dot gnu dot org wrote:
>
>
> --- Comment #6 from pinskia at gcc dot gnu dot org 2006-08-22
> 00:34 ---
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-08-22 00:34 ---
(In reply to comment #5)
> My first complaint is that the implementation is inconsistent.
It is not inconsistent really. Just the -funsafe-math-optimizations is done
incorrectly for x86 (see the other bug which I k
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-08-22 00:31 ---
For x86, -ffinite-math-only should turn off IEEE-FP compares which you will get
the correct results at -O0 which case this is really the problem mentioned in
PR 19116 which is about how unsafe-math-optimizations turn
20 matches
Mail list logo
