patch for estimate_probability instability

Geoff Keating geoffk@geoffk.org
Tue Nov 13 15:03:00 GMT 2001


> Cc: jh@suse.cz, gcc-patches@gcc.gnu.org
> X-Yow: Yow!
> From: Andreas Schwab <schwab@suse.de>
> Date: 16 Nov 2001 11:39:11 +0100
> User-Agent: Gnus/5.090003 (Oort Gnus v0.03) Emacs/21.1
> X-MIME-Autoconverted: from quoted-printable to 8bit by cygnus.com id CAA07641
> 
> Geoff Keating <geoffk@geoffk.org> writes:
> 
> |> > Date: Thu, 15 Nov 2001 21:59:45 +0100
> |> > From: Jan Hubicka <jh@suse.cz>
> |> > Cc: Jan Hubicka <jh@suse.cz>, gcc-patches@gcc.gnu.org
> |> > Content-Disposition: inline
> |> > User-Agent: Mutt/1.3.20i
> |> > 
> |> > > Jan Hubicka <jh@suse.cz> writes:
> |> > > 
> |> > > > Hi,
> |> > > > I've installed attached patch to cfg-brach to avoid estimate-branches
> |> > > > instability and bootstrap misscomparisons.
> |> > > > 
> |> > > > I am not quite sure if such a sollution can be acceptable for Mainline.
> |> > > 
> |> > > I think this is just papering over some other problem.  Floating-point
> |> > > is not a random number generator, so given the same input it should
> |> > > produce the same output.  What is being compiled differently to cause
> |> > > the comparison failure?
> |> > i386 fp is ranom number generator. If you store value to memory it
> |> > gets truncated from 80bits. When optimizing value is not stored, when
> |> > not optimizing it is stored causing different roudoff error in two runs.
> |> 
> |> Can we fix that?
> |> 
> |> Perhaps GCC needs to limit FP precision to 'double' on x86 as we
> |> recommend for other code.
> 
> Wouldn't that break long double?

Does GCC use long double?

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>



More information about the Gcc-patches mailing list