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.
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.
Logged In: YES
user_id=86185
Changed for 3.1 release.