This is the mail archive of the
mailing list for the GCC project.
Re: need help with 176.gcc from SPEC CPU2000 on LP64 with GCC 3
- From: Janis Johnson <janis187 at us dot ibm dot com>
- To: Jim Wilson <wilson at redhat dot com>
- Cc: Janis Johnson <janis187 at us dot ibm dot com>, gcc at gcc dot gnu dot org
- Date: Wed, 13 Feb 2002 10:16:53 -0800
- Subject: Re: need help with 176.gcc from SPEC CPU2000 on LP64 with GCC 3
- References: <20020212103239.A1905@us.ibm.com> <email@example.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.
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?