This is the mail archive of the mailing list for the GNU Fortran project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]