I just tried to bootstrap gcc-4.3-20061209. The compiler said ../../src/gcc-4.3-20061209/gcc/config/i386/sync.md:94: unknown mode `<DCASHMODE>' ../../src/gcc-4.3-20061209/gcc/config/i386/sync.md:94: following context is `3 "register_operand" "b")' make[3]: *** [s-mddeps] Error 1 This is on a x86_64 machine. I have a memory that 4.3-20061202 also failed to bootstrap. I know 4.3-20061225 was ok, so my best guess is that the problem arrived between 20061225 and 20061202
Does this work now on the mainline?
(In reply to comment #1) > Does this work now on the mainline? The only access to mainline I have is by the weekly snapshots. I expect to try out 4.3-20061216. Thus, answer expected Monday 18 Dec 2006.
(In reply to comment #2) > I expect to try out 4.3-20061216. I tried it out and it is still broken. Is that three snapshots in a row that fail on x86_64 ?
(In reply to comment #3) > I tried it out and it is still broken. I have more detail. I finally managed to get a working compiler by removing all of the following flags from the configure line --disable-multilib --with-cpu=opteron --with-mpfr=/home/dcb/somewhere_else I am not certain which one causes the problem, but since the original crash occurs in the machine description, I suspect that the --with-cpu=opteron is causing the problem.
I can confirm this problem on recent snapshots as well (20070105 and 20070112). I'm also on x86_64. Bootstrap fails with that same message. Configuring GCC with: --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.3.98-alpha20070112 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.98-alpha20070112/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.98-alpha20070112 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.98-alpha20070112/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.3.98-alpha20070112/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.98-alpha20070112/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-nls --with-system-zlib --disable-checking --disable-werror --enable-secureplt --disable-libunwind-exceptions --enable-multilib --disable-libmudflap --disable-libssp --disable-libgcj --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-bootstrap --enable-__cxa_atexit --enable-clocale=gnu
(In reply to comment #5) > I can confirm this problem on recent snapshots as well (20070105 and 20070112). Agreed. Snapshot 20010112 goes wrong and it's definately the flag --with-cpu=opteron that causes the trouble. Looks like a broken machine description to me, but I could be wrong.
I got same result with --with-cpu=athlon64 on gcc-4.3-20070112 snapshot.
Does this work with a much newer GCC?
(In reply to Andrew Pinski from comment #8) > Does this work with a much newer GCC? Hard to say for definite. The machine was recycled many years ago and is probably in landfill by now. Given the great age of this bug report, I'd say it's pretty certain the problem has either gone away or we don't care about that machine type by now.
So let's close as invalid then.