fortran/893: Preliminary loop exit compiled wrongly

[List subscription]

On Mon, 27 Nov 2000, Toon Moene wrote:

> List subscription wrote:
> ^^^^^^^^^^^^^^^^^ Hmmmm, you probably want to change this ;-)
>
actually it is the account I use for the various lists... I do not want to
get 100+ messages/day on my personal one...

I isolated a well defined test. The routine IPOIDS generates Poisson
distributed random numbers (answer a number < 8 at the first question
and whatever number of trials you want at the second one). It
uses uniform random number generator (set to the compiler rand (it does
not really matter, even a constant number < 1 would make the issue).

The DO 1000 ... inside the routine (short enough to be easily checked)
is completely screwed by the compiler (see the printout, of course
removing optimization everything works fine).
If I remove the first part of the main IF ... THEN the problem disappear,
this part has been dummied and it is there just to keep the problem, don't
look at it.
It is obvious that the compiler does not properly handle the jumping out
from the loop. This is similar but not identical to the previously
reported problem and strenghten my suspicion that PLENTY of similar
situations are occurring. I have similar loops with conditional exit
almost everywhere.... (as in all MonteCarlo's). I believe even more that
the bug is extremely serious and urgent to fix.

I'll try to isolate further problems (I know they are there) to see if
they all belong to the same "category", ie improperly handled conditional
exit from loops (a very common feature of many codes). This one was easy
since the routine is short enough.

                   Ciao
                  Alfredo


      PROGRAM BUG2

      IMPLICIT DOUBLE PRECISION (A-H,O-Z)
*
      WRITE (*,*) ' Type <n> (< 8.0): '
      READ  (*,*) AVENUM
      WRITE (*,*) ' Type ntest: '
      READ  (*,*) NTEST
      AVE = 0.D+00
      DO 1000 I = 1, NTEST
         K = IPOIDS (AVENUM)
         AVE = AVE + K
 1000 CONTINUE
      AVE = AVE / NTEST
      WRITE (*,'(2(A,1X,1P,G23.15))') ' <n>: ', AVE, ' +/- ',
     &      SQRT(AVENUM/NTEST)
      STOP
      END

*$ CREATE IPOIDS.FOR
*COPY IPOIDS
*
*=== ipoids ===========================================================*
*
      INTEGER FUNCTION IPOIDS ( AVENUM )

      IMPLICIT DOUBLE PRECISION (A-H,O-Z)
      PARAMETER ( ONEONE = 1.D+00 )
      PARAMETER ( SIXSIX = 6.D+00 )
      PARAMETER ( EIGEIG = 8.D+00 )
*
*----------------------------------------------------------------------*
*                                                                      *
*     Integer POIsson DIstributed random numbers:                      *
*                                                                      *
*----------------------------------------------------------------------*
*
*  +-------------------------------------------------------------------*
*  |  Use the cumulant (nint) 4th order approximation:
      IF ( AVENUM .GT. EIGEIG ) THEN
         IPOIDS = 0
*  |
*  +-------------------------------------------------------------------*
*  |  Use the exact formula
      ELSE
         EXPAVE = EXP   (-AVENUM)
         RNDPOI = FLRNDM (RNDPOI)
         XNNFAC = EXPAVE
         SUMXNN = XNNFAC
*  |  +----------------------------------------------------------------*
*  |  |  Loop to find the number:
         DO 1000 I = 0, 20000
            IF ( RNDPOI .LT. SUMXNN ) THEN
               IPOIDS = I
               GO TO 2000
            END IF
            XNNFAC = XNNFAC * AVENUM / ( I + 1 )
            SUMXNN = SUMXNN + XNNFAC
 1000    CONTINUE
*  |  |
*  |  +----------------------------------------------------------------*
         IPOIDS = 20001
 2000    CONTINUE
         IF ( RNDPOI .GE. SUMXNN ) THEN
            WRITE (*,*) ' Wrong!'
            WRITE (*,'(A,2I6,1P,G23.15,/,3G23.15)')
     &         ' I,IPOIDS,RNDPOI,AVENUM,XNNFAC,SUMXNN',
     &           I,IPOIDS,RNDPOI,AVENUM,XNNFAC,SUMXNN
         END IF
      END IF
*  |
*  +------------------------------------------------------------------*
      RETURN
*=== End of function Ipoids ==========================================*
      END


      DOUBLE PRECISION FUNCTION FLRNDM (DUMMY)

      IMPLICIT DOUBLE PRECISION (A-H,O-Z)
      REAL RAND
*
      FLRNDM = RAND (0)
      RETURN
      END



> > I want to stress that the bug reported below is very serious and it is
> > present in all snapshots of gcc after gcc-2.95.2
>
> That's amazing - I believe it's less than two months ago that Martin
> Kahlert reported this bug.  It's also hard to trigger; removing the
> `WRITE' statement just before the abort call makes it go away.
>
> > gcc-2.95.2 is still compiling correctly that example.
> >
> > When I mean serious, I mean that for our codes (MonteCarlo's for high
> > energy physics) there are bugs popping up everywhere. I found at least
> > 7 different miscompiled routines in a few minutes. Inspections of the
> > first two showed problems similar to the example below. I am not
> > sure all problems are related to this bug only, however I see no point
> > in going on before getting a patch.
>
> Yep, I wouldn't jump to the conclusion that they're all one and the same
> bug.  We would be very grateful if you were able to isolate some more
> examples of bugs - this is the time to get them in the testsuite, so
> that we can be certain they're fixed before GCC 3.0 hits the archives.
>
> > Of course all problems disappear compiling with the (old) egcs-1.1.2
>
> Amazing, given all the bugs we *know* are in egcs-1.1.2 ;-)
>
> > and at least for those two routines I investigated, using gcc-2.95.2.
>
> > I have a question (in order to try to survive meanwhile);
> > is there any known incompatibility/patch I have to take care of in order
> > to rebuild correctly gcc-2.95.2 on a system running glibc-2.2 (RH7)?
>
> There's a simple patch to apply to GCC 2.95.2 to make it compilable on
> RH7 and any glibc-2.2 system.  Unfortunately, at present I can't seem to
> find it (help !).
>
> > And in case this can be done, which are the binary incompatibilities
> > (we link together c and fortran modules and sometimes c++ ones)?
>
> You can't mix C++ objects from 2.95.x and RH7's compiler; neither can
> you mix C++ objects from RH7's compiler and current snapshots.
> Otherwise we do not know of any incompatibilities.
>
> Hope this helps,
>
>

-- 

+----------------------------------------------------------------------------+
|  Alfredo Ferrari                         ||  Tel.: +41.22.767.6119         |
|  C.E.R.N.                                ||  Fax.: +41.22.767.7555         |
|  European Laboratory for Particle Physics||                                |
|  SL Division / EET Project               ||  e-mail:                       |
|  1211 Geneva 23                          ||     Alfredo.Ferrari@cern.ch    |
|  Switzerland                             ||     Alfredo.Ferrari@mi.infn.it |
+----------------------------------------------------------------------------+