[Bug fortran/32352] New: Crash (out of bounds) with converting real to integer array index with -mrecip

[Bug fortran/32352] New: Crash (out of bounds) with converting real to integer array index with -mrecip

[burnus at gcc dot gnu dot org]

http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01043.html

(This is with the SVN version of GCC and the -mrecip / rsqrt patch by Uros on
x86_64-unknown-linux-gnu.)

I don't know whether this a bug in the patch [for rsqrt] or only revealed by
the
patch, but the "aermod.f90" benchmark from Polyhedron
[http://www.polyhedron.co.uk/pb05/polyhedron_benchmark_suite.html] crashes here
at run time (segmentation fault) when compiled with

  gfortran -ffast-math -mrecip aermod.f90

Valgrind claims:
==16734== Conditional jump or move depends on uninitialised value(s)
==16734==    at 0x4BA046: numrise_ (aermod.f90:35497)
==16734==    by 0x4CBC05: prmdelh_ (aermod.f90:39786)
==16734==    by 0x41D06F: prmcalc_ (aermod.f90:6787)
[...]

The program does not crash without -mrecip.

 - - -

Uros answered:
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01044.html

gdb points to the top of:

Dump of assembler code from 0x808a193 to 0x808a293:
   0x0808a193 <numrise_+8963>:     mov    0xffffaf8c(%ebp,%edx,4),%eax
   0x0808a19a <numrise_+8970>:     mov    %eax,0xfffffffc(%ebx,%ecx,4)
   0x0808a19e <numrise_+8974>:     mov    0xffff616c(%ebp,%edx,4),%eax
   0x0808a1a5 <numrise_+8981>:     mov    0x2c(%ebp),%edx
   0x0808a1a8 <numrise_+8984>:     mov    %eax,0xfffffffc(%edx,%ecx,4)
   0x0808a1ac <numrise_+8988>:     add    $0x1,%ecx


where %ebp points to zt. It looks that %edx (that has value of 12324
at the point of crash) got out of bounds. Index into the array (JN
(int) = RN (float)) is calculated from DELN variable, that is computed
using rcpss. DELN is equal to 4107.55908 in rcpss case and RN is
12325.6777. Perhaps the problem is, that index is constructed from FP
variable?

 [...]

Hm, I was referring to this part of numrise function:

! ---       Use sliding step-size to sample nearfield more frequently
           DELN = 2.*FLOAT(NN-NTR)/FLOAT(NTR*(NTR-1))
           RN = 0.0
           DO IN = 1 , NTR - 1
              RN = RN + 1.0 + (IN-1)*DELN
              JN = RN
              XTR(IN) = XT(JN)
              YTR(IN) = YT(JN)
              ZTR(IN) = ZT(JN)
              RTR(IN) = RT(JN)
           ENDDO 

 - - -

Note: valgrind shows now error for the version without -mrecip

With -mrecip and -bounds-check, one has:

At line 35436 of file aermod.f90
Fortran runtime error: Array reference out of bounds for array 'xt', lower
bound of dimension 1 exceeded

This is SUBROUTINE NUMRISE:
         DO IN = NBEG , NEND
! ---       Define coordinates of plume relative to bldg.-defined origin
            XBB = XT(IN-1) - XBADJ

No such error without bounds check.


-- 
           Summary: Crash (out of bounds) with converting real to integer
                    array index with -mrecip
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: burnus at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32352

[Bug fortran/32352] Crash (out of bounds) with converting real to integer array index with -mrecip

[burnus at gcc dot gnu dot org]

------- Comment #1 from burnus at gcc dot gnu dot org  2007-06-15 12:54 -------
Uros writes:
----------------------------------------------------------------
I have fond the problem in following lines:

! --- Process new position
     S = S + DS
     IF ( FLOAT(NNP/NP).EQ.FLOAT(NNP)/XNP ) THEN          <<<< here
        NN = NNP/NP

The problem is one ULP of the rcpss insn (+NR step), illustrated by
the following testcase:

--cut here--
float recip(float a)
{
 float xx = 1.0f/a;
 printf("%a\n", xx);

 return xx;
}

int NNP = 1;
int NP = 1;
float XNP = 1.0f;

int main()
{
 float a, b;
 int c;

 a = (float)(NNP/NP);
 b = (float)(NNP)*recip(XNP);

 printf("%a %a %i\n", a, b, a == b);

 return 0;
}
--cut here--

gcc -O2 -msse2 -mfpmath=sse -ffast-math equal.c
./a.out
0x1p+0
0x1p+0 0x1p+0 1

gcc -O2 -msse2 -mfpmath=sse -ffast-math -mrecip equal.c
./a.out
0x1.fffffep-1
0x1p+0 0x1.fffffep-1 0

Actually, the recip pass is OK, it is just a precision problem. This
is why -mrecip should stay separate option, not included in
-ffast-math...


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WORKSFORME


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32352

[Bug fortran/32352] Crash (out of bounds) with converting real to integer array index with -mrecip

[burnus at gcc dot gnu dot org]

------- Comment #2 from burnus at gcc dot gnu dot org  2007-06-15 13:31 -------
-> Middle-end
-> Wont Fix?!?


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|WORKSFORME                  |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32352

[Bug middle-end/32352] Crash (out of bounds) with converting real to integer array index with -mrecip

[burnus at gcc dot gnu dot org]

------- Comment #3 from burnus at gcc dot gnu dot org  2007-06-15 13:32 -------
-> Middle-end
-> WONTFIX - or can one do something about it?


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
          Component|fortran                     |middle-end
         Resolution|                            |WONTFIX


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32352

[Bug middle-end/32352] Crash (out of bounds) with converting real to integer array index with -mrecip

[ubizjak at gmail dot com]

------- Comment #4 from ubizjak at gmail dot com  2007-06-15 13:38 -------
(In reply to comment #3)
> -> Middle-end

target, because middle end just throws conversion into target optabs.

> -> WONTFIX - or can one do something about it?

Hardly... We can penalize everything with another NR-step (just for one last
ULP!), or we have in mind that (a == b) checks should be avoided, surely for
SFmode floats.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32352

[Bug target/32352] Crash (out of bounds) with converting real to integer array index with -mrecip

[dominiq at lps dot ens dot fr]

------- Comment #5 from dominiq at lps dot ens dot fr  2007-06-15 21:18 -------
I don't understand how recip(1.0f) can return something different from 1.0f:
the twelve bit approximation should return 1.0f then the NR-step should involve
only integers, hence no round-off errors.

What am I missing?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32352