--- Comment #13 from jvdelisle at gcc dot gnu dot org 2007-12-02 21:02
---
Fixed on trunk. Hope everyone is satisfied.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2007-11-30 04:18
---
Subject: Bug 34230
Author: jvdelisle
Date: Fri Nov 30 04:18:05 2007
New Revision: 130532
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130532
Log:
2007-11-29 Steven G. Kargl <[EMAIL PROTECTED]>
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2007-11-30 04:11
---
Subject: Bug 34230
Author: jvdelisle
Date: Fri Nov 30 04:10:47 2007
New Revision: 130530
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=130530
Log:
2007-11-29 Steven G. Kargl <[EMAIL PROTECTED]>
--- Comment #10 from sgk at troutmask dot apl dot washington dot edu
2007-11-28 20:08 ---
Subject: Re: Expressions of parameters evaluated with too high precision
On Wed, Nov 28, 2007 at 07:23:57PM -, fxcoudert at gcc dot gnu dot org
wrote:
>
> To sum up my point of view: -fno-ra
--- Comment #9 from burnus at gcc dot gnu dot org 2007-11-28 19:35 ---
> > If +Inf is a representable value, you need to go fix the IO subsystem
> > to read +Inf (and NaN).
I just checked:
- NAG f95, g95, ifort and sunf95 accept (case insensitive and with optional
"+"/"-" prefix) "NAN"
--- Comment #8 from fxcoudert at gcc dot gnu dot org 2007-11-28 19:23
---
(In reply to comment #7)
> a) Do other compilers have an equivalent to -fno-range-check?
Most compilers have a behaviour similar to -fno-range-check by default, only
warning about range problems (Intel, Sun, g95
--- Comment #7 from kargl at gcc dot gnu dot org 2007-11-28 19:06 ---
(In reply to comment #6)
> I consider this a bug. I have to check, but I think that the IEEE rules are
> clear, even though they are not mandatory until we introduce the corresponding
> standard modules. The calculatio
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-11-28 18:03
---
I consider this a bug. I have to check, but I think that the IEEE rules are
clear, even though they are not mandatory until we introduce the corresponding
standard modules. The calculation of y does overflow, and
--- Comment #5 from kargl at gcc dot gnu dot org 2007-11-28 00:06 ---
(In reply to comment #4)
> (In reply to comment #3)
>
> (Admittedly from the 4.2.2 manual):
> 2.2 Options controlling Fortran dialect
> -frange-check
> Enable range checking on results of simplification of constan
--- Comment #4 from terry at chem dot gu dot se 2007-11-27 22:56 ---
(In reply to comment #3)
(Admittedly from the 4.2.2 manual):
2.2 Options controlling Fortran dialect
-frange-check
Enable range checking on results of simplification of constant expressions
during compilation. For
--- Comment #3 from kargl at gcc dot gnu dot org 2007-11-27 22:45 ---
(In reply to comment #2)
> (In reply to comment #1)
> > There is no bug here. You have explicitly disabled
> > range checking. This means that you no longer have
> > a limitation on range in constant folding. It may
--- Comment #2 from terry at chem dot gu dot se 2007-11-27 21:57 ---
(In reply to comment #1)
> There is no bug here. You have explicitly disabled
> range checking. This means that you no longer have
> a limitation on range in constant folding. It may
> be help to look at -fdump-parse
--- Comment #1 from kargl at gcc dot gnu dot org 2007-11-26 00:12 ---
There is no bug here. You have explicitly disabled
range checking. This means that you no longer have
a limitation on range in constant folding. It may
be help to look at -fdump-parse-tree. YOu don't
have an Inf un
13 matches
Mail list logo
