Re: need help with 176.gcc from SPEC CPU2000 on LP64 with GCC 3

[Janis Johnson <janis187 at us dot ibm dot com>]

On Tue, Feb 12, 2002 at 11:06:00PM -0800, Jim Wilson wrote:
> I got all of the cint2000 benchmarks working on ia64-linux last summer.
> Except eon that is, because eon was not valid ISO C++ at the time.  SPEC
> has already fixed this.  I haven't tried them since though.  I tried again
> today.  It took a while, because OS updates and filesystem reorgs badly broke
> my spec2000 install dir, but I did manage to get a successful 176.gcc run using
> a gcc checked out today.
> 
> Looking at my notes, I see I did make a bug fix to 176.gcc.  SPEC modified
> the obstack API, but did not change the obstack version number.  This can
> fail on linux (maybe only on 64-bit host?) because we then link against
> the obstack in libc.so which implements the wrong API.  This is also probably
> against the spirit of SPEC.  There is probably more such trickery in other
> places.  Anyways, to double check, I removed my patch, tried to run 176.gcc,
> and got a segfault in memset as you reported.  Someone should point out this
> problem to SPEC.

Thanks, this fixes the problem for me.  I'll sent a note to SPEC with a
pointer to your message in the archives.

> I also have patches for 186.crafty and 253.perlbmk, but those are pretty
> obvious configuration changes so you may not need them.

Those are fixed in v1.2; your change to 176.gcc is the only source change
that's now needed on ia64-unknown-linux-gnu.

Janis

P.S.  I compiled and ran (with test input) all of the integer tests on
i686-pc-linux-gnu and ia64-unknown-linux-gnu with a variety of
optimization options and got some run-time failures with -funroll-loops.
I don't have the time or knowledge about loop unrolling to track these
down for proper problem reports.  What should I do with this information?