Re: fortran/893: Preliminary loop exit compiled wrongly

[List subscription <list at pceet030 dot cern dot ch>]

Hi Toon

thanks a lot for the answer. I can confirm that this bug was not there
both in egcs-1.1.2 and gcc-2.95-2: egcs-1.1.2 was also correctly
compiling our codes (>1000 routines, >500,000 lines) in the sense that:
a) it was producing identical results with and without optimization
b) it was producing results identical to the same code compiled on
   Digital Unix, IBM-AIX and HP-UX with their native compilers.
I agree that there could be other bugs still floating around. If it is
useful I can (painfully) try to isolate all of those we found and try to
slim them down to usable examples.

I hope I'll get feedback, in the sense that I have to go
thru > 1000 routines switching on optimization one by one and isolating
all those which are turning mad. Then I have to find inside each
routine what is making them crazy. It could be a long job. I'll do...

                        Cheers
                     Alfredo Ferrari

P.S. If somebody can send me the patch to get gcc-2.95.2 working with
glibc-2.2 and RH7 I would appreciate a lot!

On Mon, 27 Nov 2000, Toon Moene wrote:

> List subscription wrote:
> ^^^^^^^^^^^^^^^^^ Hmmmm, you probably want to change this ;-)
>
> > 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 |
+----------------------------------------------------------------------------+