Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#25 gcc 3.1 miscompiles regina 3.0

closed
Mark Hessling
None
5
2002-10-27
2002-05-24
Paul G. Barnett
No

But I cannot tell who is at fault!. I built regina 3.0 with gcc
3.1 on 2 different linux mandrake systems, both exhibit the
fault. In get_a_strendTSD() in memory.c, we have (line 783)

mt->flists[bin] = (*((char **)(vptr))) ;

((streng *)vptr)->len = 0 ;

the compiled code or 2nd line actually zeros the
mt->flists[bin] pointer to chain of unused blocks, not the len
field of the new block.

Consequently, almost 8k of available mem is discared on
every call to get_a_strengTSD. rexxcps.rexx consumes
about 500Mb.

This only happens with gcc 3.1, 3.0x and 2.9x are fine, and
only with -O2 or -O3 - -O1 is ok.

Looking thru the gcc-bugs mailing list archive, I found bug
6752, which implies a possible coding error (we are using
char * and streng * types to point to the same location), and
that in such cases we should use gcc option -fno-strict-
aliasing Sure enough this fixes the problem so I would like
to suggest we add this to configure.in for gcc when using -
O3. The alternative would be to find a cast that would keep
the optimiser happy - I havnt found one (so it might still be a
compiler bug) the -fno-strict-aliasing option has no
measurable effect on the performance of regina.

Discussion

  • Mark Hessling
    Mark Hessling
    2002-05-31

    • assigned_to: nobody --> rexx
     
  • Logged In: YES
    user_id=333840

    It fails on a pentium pro, p2, and on an AMD K7, but works on a
    K6. and on the former, adding -march=i586 fixes. It sure looks
    like a compiler bug to me, but the expedient solution may be to
    add the -fno-strict-aliasing anyway.

     
  • Logged In: YES
    user_id=333840

    OK - now I understand it. Regina has probably never
    correctly compiled without the -fno-strict-aliasing option.
    What has changed is that for versions of gcc prior to 3.1,
    this options was implied for -O3.At 3.1, this changed so
    that -O3 no longer implies it, it must be supplied explicitly.

    configure.in needs to be changed to supply this option for
    gcc with -O3

    It seems that other gcc users have indepenandly discoverd
    this - for example, the linux kernal has used
    -fno-strict-aliasing for some time.

     
  • Mark Hessling
    Mark Hessling
    2002-10-27

    Logged In: YES
    user_id=86185

    Changed for 3.1 release.

     
  • Mark Hessling
    Mark Hessling
    2002-10-27

    • status: open --> closed