------- Comment #4 from howarth at nitro dot med dot uc dot edu 2010-09-01
23:11 -------
(In reply to comment #3)
>
> I think I can prove that my patch doesn't affect code generation, except
> possibly on the SPARC, so I'm a little skeptical about your diagnosis. Are
> you
> sure it's not r163679 instead?
>
Clean bootstrap of r163659 followed by 20 instances of...
make -k check-gcc RUNTESTFLAGS="builtins.exp=sprintf-chk.c
--target_board=unix'{-m32,-m64}'"
produce 20 instances of all 40 tests passing. Repeated clean bootstrap for
r163660 and 20 instances
of the same make check statement produced 10 out of 20 times the failure...
FAIL: gcc.c-torture/execute/builtins/sprintf-chk.c compilation, -Os (internal
compiler error)
The evidence of r163660 being to blame looks pretty convincing to me.
Using built-in specs.
COLLECT_GCC=../../dist/bin/gcc
COLLECT_LTO_WRAPPER=/Users/howarth/dist/libexec/gcc/x86_64-apple-darwin10.4.0/4.6.0/lto-wrapper
Target: x86_64-apple-darwin10.4.0
Configured with: ../gcc/configure --prefix=/Users/howarth/dist --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--enable-checking=yes --enable-languages=c --enable-lto
Thread model: posix
gcc version 4.6.0 20100830 (experimental) (GCC)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45484
