[Bug c++/57850] Option -fdump-translation-unit not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57850 --- Comment #5 from Dima --- Why is this bug is still marked unconfirmed? Is there something I can do to confirm it?
[Bug c++/57850] [4.8/4.9 Regression] Option -fdump-translation-unit not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57850 --- Comment #11 from Dima --- (In reply to Jason Merrill from comment #9) > Created attachment 30818 [details] > patch > > Can you verify that this patch fixes the issue? Yes, it works for me and makes abi-compliance-checker function once again. Regards, Dmitrijs.
[Bug c++/57850] [4.8/4.9 Regression] Option -fdump-translation-unit not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57850 --- Comment #12 from Dima --- Is this going to be applied for 4.9 & 4.8 series?
[Bug libgcj/40868] ecjx.cc should be compiled by host gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40868 --- Comment #16 from Dima 2010-09-27 22:13:18 UTC --- (In reply to comment #15) > (In reply to comment #14) > > Created attachment 21898 [details] [details] > > backport > > > > This is the backport I use against gcc-4.4 > > dear dima, thanks for that patch but it's not sufficient. it even applies and > configures right but too many things had changed between release 4.4.4 and > revision 163580. so the resulting generated makefile is faulty and leaves the > variable @GCC_FOR_ECJX@ unsubtituted which causes compile to fail. This patch does apply against snapshot gcc-4.4 branch 26-09-2010. And does build libgcj & java cross-compiler from i386|x86_64-gnu-linux to i686-w64-mingw32. After the patch is applied you do need to rerun correct autoreconf (2.59). Buildlog - http://launchpadlibrarian.net/56490712/buildlog_ubuntu-lucid-i386.w64-toolchain_1.0b%2B201009260029-0w2228g93841b22110p11~lucid1_FULLYBUILT.txt.gz
[Bug bootstrap/41337] [LTO] Parallel build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41337 Dima changed: What|Removed |Added CC||dmitrij.ledkov at ubuntu ||dot com --- Comment #2 from Dima 2010-11-16 21:53:42 UTC --- I have the same error. Would please share your pilot error and how you have fixed it? Maybe I'm doing the same thing
[Bug bootstrap/41337] [LTO] Parallel build failure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41337 --- Comment #4 from Dima 2010-11-17 21:02:58 UTC --- (In reply to comment #3) > If you encounter parallel build failures, please post exact revision that was > built, configure command line, build system type, number of processors on the > box, N argument in 'make -jN', and ideally also the likelihood (in precent) > that the build fails, if it is not deterministic. Please also post the last > 300 or so lines of build output, and maybe check whether it always fails in > the > same spot. > I'm building a cross-compiler: build/host = gnu-linux; target = i686-w64-mingw32. I've been using gcc-4.4 branch this whole week (will test again with trunk when I have time). It is fully deterministic (100% fail rate at the same spot) when I supply --with-build-libsubdir pointing to the $prefix/$target-triplet/lib. But the mentioned value for --with-build-libsubdir option is bogus and doesn't make sense. > It is not too hard to pinpoint parallel build failures but only if there is > enough data available. I no longer believe my error was to do with parallel make, it was the error between the keyboard and the chair =) in other words "pilot error". If someone else will come across with > make[1]: *** No rule to make target `build/gencondmd', needed by `s-condmd' Check your config and make sure it is sane =)
