This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: Optimisation prevents overflow?
- From: "Janne Blomqvist" <blomqvist dot janne at gmail dot com>
- To: "Davide Mancusi" <arekfu at yahoo dot it>
- Cc: fortran at gcc dot gnu dot org
- Date: Fri, 20 Jul 2007 12:41:53 +0300
- Subject: Re: Optimisation prevents overflow?
- Dkim-signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aWph4Lo4pLjz997V1stfD39mIu3q+s9aUQ0Q87X/WUi/TIrEq+GlX7OdrGWqOm+eLLx2y0shHRilgvatBuAj4OzJD/bufrqyDmY3FWO4cz0CGKzOkGzKAnUhKkSuk5PgG19CqBM5ycQsubrSru7eXddUU3ppv2mE/pzgFN61Y+8=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Gqd7GPMPJJpTu/jo9cj1KfdJvLME0UV+Wgs/+ydzoLmX8x4bmknzKVgk0Bg0+1vrF/ilQ2N6M/dYGE1sP6QRUSROyzw8JQv8djuYBGiz7c3A0ykhAl6IcgcbFmaH/2cTXu8yoVTKC5jeXTScISU2iLia5D/2UkSSFDUQ1Nwll+s=
- References: <469FD202.7080407@yahoo.it> <200707192335.15396.franke.daniel@gmail.com> <20070719144206.D13825@droplet.stanford.edu> <200707192349.57403.franke.daniel@gmail.com> <20070719151643.F13825@droplet.stanford.edu> <46A07E29.3090303@yahoo.it>
On 7/20/07, Davide Mancusi <arekfu@yahoo.it> wrote:
Brooks Moses wrote:
> So, yeah, -ffloat-store or -mfpmath=sse is the right answer.
This brings me to a "philosophical" question, then. Say that program
"foo" gives different results depending on the use of -ffloat-store; I
am not talking about round-off here, I mean real differences. Would you
say that "foo" is not portable?
Yes. If you need more precision or range than what real(8) provides
you have to use a type with more precision and/or range rather than
relying on the compiler to keep the variable in the 80-bit x87
register stack.
Gfortran supports real(10) on x86 and x86-64, which ensures no loss of
precision, range, or roundoff when storing an x87 fp register to
memory.
In other words, relying on overflow (or
underflow) is obviously not portable, but is overflow the _only_ way to
trigger inconsistent behaviours?
Depending on your definition of inconsistent, almost anything that has
to do with floating point might lead to inconsistent behaviour between
different hardware, compilers, optimization levels and whatnot. ;-)
See the Goldberg article for more information (google for "Goldberg
floating point").
--
Janne Blomqvist