This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: nearest_1.f90 failure on i686-linux
On Mon, Oct 09, 2006 at 05:00:44PM +0200, Dominique Dhumieres wrote:
> > I would suspect that it is target specific. I can't reproduce
> > this on i386-*-freebsd or amd64-*-freebsd.
>
> I just check with gfortran 4.2.0 20061009 on an AMD64 Linux box and
> I don't see it with the -ffloat-store option.
>
> > Does OSX have FLT_EVAL_METHOD? Can you check whether the
> > nextafterf and nextafter actually work?
>
> Where should I look? As said in my mail (between line), I don't think
> the problem is with NEAREST, it looks more as an optimization problem
> of TRANSFER. A diff between nearest_2_db.f90.003t.original files gives:
Look in /usr/include/float.h. On FreeBSD, I have
#define FLT_EVAL_METHOD (-1) /* i387 semantics are...interesting */
> Anyway, it is in general a very bad sign when the outcome of a program depends
> on additional PRINT, IF, EQUIVALENCE when using optimization.
This normal means a memory alignment issue. If it is an
optimization bug, then we'll need to probably generate a
C or C++ testcase. Most (may all) Fortran guys aren't
familiar with the middle-end, and only a few (one or two)
middle-end people know Fortran :(
BTW, if you really want to investigate the issue, you can do
-fdump-tree-all -O3. This generates 81 intermediate files.
Comparing between working and nonworking output may help
narrow down where the problem lies.
--
Steve