4.5.0 r153685 Command line: $ valgrind --track-origins=yes -v /mnt/svn/gcc-trunk/binary-153685-lto/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/cc1 -fpreprocessed testcase.i -m32 -O1 -version -fgcse-sm -o tmp.o ... GNU C (GCC) version 4.5.0 20091028 (experimental) (x86_64-unknown-linux-gnu) compiled by GNU C version 4.5.0 20091028 (experimental), GMP version 4.3.1, MPFR version 2.4.1-p5, MPC version 0.7 ... ==5211== 43 errors in context 1 of 2: ==5211== Conditional jump or move depends on uninitialised value(s) ==5211== at 0x7B2215: store_killed_after (store-motion.c:270) ==5211== by 0x7B3221: execute_rtl_store_motion (store-motion.c:1084) ==5211== by 0x71349C: execute_one_pass (passes.c:1519) ==5211== by 0x7136C4: execute_pass_list (passes.c:1568) ==5211== by 0x7136D6: execute_pass_list (passes.c:1569) ==5211== by 0x80B8B0: tree_rest_of_compilation (tree-optimize.c:392) ==5211== by 0x9836AB: cgraph_expand_function (cgraphunit.c:1160) ==5211== by 0x985524: cgraph_optimize (cgraphunit.c:1219) ==5211== by 0x985A5E: cgraph_finalize_compilation_unit (cgraphunit.c:1089) ==5211== by 0x4AE2DA: c_write_global_declarations (c-decl.c:9489) ==5211== by 0x7B8CAB: toplev_main (toplev.c:1061) ==5211== by 0x6587A25: (below main) (in /lib64/libc-2.10.1.so) ==5211== Uninitialised value was created by a heap allocation ==5211== at 0x4C270AC: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==5211== by 0xC90C27: xmalloc (xmalloc.c:147) ==5211== by 0x7B30CB: execute_rtl_store_motion (store-motion.c:1066) ==5211== by 0x71349C: execute_one_pass (passes.c:1519) ==5211== by 0x7136C4: execute_pass_list (passes.c:1568) ==5211== by 0x7136D6: execute_pass_list (passes.c:1569) ==5211== by 0x80B8B0: tree_rest_of_compilation (tree-optimize.c:392) ==5211== by 0x9836AB: cgraph_expand_function (cgraphunit.c:1160) ==5211== by 0x985524: cgraph_optimize (cgraphunit.c:1219) ==5211== by 0x985A5E: cgraph_finalize_compilation_unit (cgraphunit.c:1089) ==5211== by 0x4AE2DA: c_write_global_declarations (c-decl.c:9489) ==5211== by 0x7B8CAB: toplev_main (toplev.c:1061) ==5211== ==5211== ==5211== 2273 errors in context 2 of 2: ==5211== Conditional jump or move depends on uninitialised value(s) ==5211== at 0x7B21FD: store_killed_after (store-motion.c:270) ==5211== by 0x7B3221: execute_rtl_store_motion (store-motion.c:1084) ==5211== by 0x71349C: execute_one_pass (passes.c:1519) ==5211== by 0x7136C4: execute_pass_list (passes.c:1568) ==5211== by 0x7136D6: execute_pass_list (passes.c:1569) ==5211== by 0x80B8B0: tree_rest_of_compilation (tree-optimize.c:392) ==5211== by 0x9836AB: cgraph_expand_function (cgraphunit.c:1160) ==5211== by 0x985524: cgraph_optimize (cgraphunit.c:1219) ==5211== by 0x985A5E: cgraph_finalize_compilation_unit (cgraphunit.c:1089) ==5211== by 0x4AE2DA: c_write_global_declarations (c-decl.c:9489) ==5211== by 0x7B8CAB: toplev_main (toplev.c:1061) ==5211== by 0x6587A25: (below main) (in /lib64/libc-2.10.1.so) ==5211== Uninitialised value was created by a heap allocation ==5211== at 0x4C270AC: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==5211== by 0xC90C27: xmalloc (xmalloc.c:147) ==5211== by 0x7B30CB: execute_rtl_store_motion (store-motion.c:1066) ==5211== by 0x71349C: execute_one_pass (passes.c:1519) ==5211== by 0x7136C4: execute_pass_list (passes.c:1568) ==5211== by 0x7136D6: execute_pass_list (passes.c:1569) ==5211== by 0x80B8B0: tree_rest_of_compilation (tree-optimize.c:392) ==5211== by 0x9836AB: cgraph_expand_function (cgraphunit.c:1160) ==5211== by 0x985524: cgraph_optimize (cgraphunit.c:1219) ==5211== by 0x985A5E: cgraph_finalize_compilation_unit (cgraphunit.c:1089) ==5211== by 0x4AE2DA: c_write_global_declarations (c-decl.c:9489) ==5211== by 0x7B8CAB: toplev_main (toplev.c:1061)
Created attachment 18928 [details] partially reduced testcase
Created attachment 18929 [details] warning disappears when this diff is applied
Steven knows this code best.
Mine. Investigating.
Created attachment 19029 [details] reduced testcase BINARY=/mnt/svn/gcc-trunk/binary-154190-lto/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/cc1 valgrind --malloc-fill=0x00 $BINARY -O1 -fgcse-sm -fPIC -m32 -o malloc-00.S pr41862.i valgrind --malloc-fill=0xff $BINARY -O1 -fgcse-sm -fPIC -m32 -o malloc-ff.S pr41862.i diff malloc-00.S malloc-ff.S Gives: 13a14 > movl %esi, gm@GOTOFF(%ebx) 21,22c22,23 < leal 1(%esi), %eax < movl %eax, gm@GOTOFF(%ebx) --- > addl $1, %esi > movl %esi, gm@GOTOFF(%ebx) The first store is redundant, caused by using uninitialised memory by gcc.
Also it causes bootstrap comparison failures for me at x86_64-pc-linux-gnu, r154643 export CFLAGS="-O2 -fgcse-sm" export CXXFLAGS="-O2 -fgcse-sm" ../configure --enable-languages=c,c++ --prefix=/mnt/svn/gcc-trunk/binary-154643-O2-gcse-sm make ... Comparing stages 2 and 3 warning: gcc/cc1plus-checksum.o differs warning: gcc/cc1-checksum.o differs Bootstrap comparison failure! x86_64-unknown-linux-gnu/32/libgcc/multf3_s.o differs x86_64-unknown-linux-gnu/32/libgcc/bid128_div.o differs x86_64-unknown-linux-gnu/32/libgcc/addtf3_s.o differs x86_64-unknown-linux-gnu/32/libgcc/fixtfsi.o differs make[2]: *** [compare] Error 1 Should this be marked as regression?
My fault for not using -fgcse-sm in BOOT_CFLAGS. With that, it gets worse: $ nice -n 19 make -j3 BOOT_CFLAGS="-O2 -fgcse-sm" Comparing stages 2 and 3 warning: gcc/cc1plus-checksum.o differs warning: gcc/cc1-checksum.o differs Bootstrap comparison failure! gcc/cp/pt.o differs gcc/explow.o differs gcc/tree-into-ssa.o differs gcc/bitmap.o differs gcc/dwarf2out.o differs gcc/double-int.o differs gcc/ipa-prop.o differs gcc/stor-layout.o differs libdecnumber/decimal128.o differs libdecnumber/decimal32.o differs libdecnumber/decimal64.o differs libdecnumber/decNumber.o differs x86_64-unknown-linux-gnu/32/libgcc/trunctfxf2_s.o differs x86_64-unknown-linux-gnu/32/libgcc/multf3_s.o differs x86_64-unknown-linux-gnu/32/libgcc/multf3.o differs x86_64-unknown-linux-gnu/32/libgcc/fixtfsi_s.o differs x86_64-unknown-linux-gnu/32/libgcc/bid128_div.o differs
http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01114.html fixes part of this bug, but I still get a bootstrap comparison failure.
Thank you for commiting that patch. I am also receiving bootstrap comparison failures at x86_64 (r155455, -O2 -fgcse-sm): gcc/double-int.o differs libcpp/expr.o differs r155434 without -fgcse-sm bootstraps fine (I didn't test r155455 without -fgcse-sm, yet) When I applied patch from comment #2 (it does the same as the commited patch) to r153685, it bootstraped fine as well. There are (used to be?) "random" cfgloopmanip.o comparison failures appearing when building from gentoo's sources (not vanilla, so I didn't report it, and I wasn't able to reproduce it) (those sources are weekly snapshots - some snapshots managed to compile, some didn't). I hope this information can be in some way useful.
(In reply to comment #9) > When I applied patch from comment #2 (it does the same as the commited patch) > to r153685, it bootstraped fine as well. With -O2 -fgcse-sm, that is. (I don't know if that was a luck, some latent bug that wasn't visible in that revision, or a new bug has been introduced to trunk since then)
Can you try with --without-build-config? It might be just a compare-debug failure.
Re. comment #11: If I configure with "--without-build-config" on ia64-unknown-linux-gnu, with -fgcse-sm enabled, then the bootstrap completes successfully (all languages except ada). If I configure without the extra option, the bootstrap fails. You say that it might be "just a compare-debug failure" -- what does that mean and what can/should I do about it?
For traceability: http://gcc.gnu.org/ml/gcc-patches/2009-12/msg01114.html I somehow forgot to add the PR number to the commit.
It means that gcse-sm generates different code with -g vs. -g0 which likely means that it is confused by the extra DEBUG_INSNs that appear with -g or that its generated code depends on things like insn uids.
Created attachment 19457 [details] Ignore all DEBUG_INSNs in store-motion.c With this patch I can complete a bootstrap on ia64-unknown-linux-gnu with -fgcse-sm. Can't tell whether the patch makes sense, though :-)
If it also passes testing it is ok for trunk (it does make sense to me).
Subject: Bug 41862 Author: steven Date: Sun Jan 3 22:41:22 2010 New Revision: 155596 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155596 Log: PR rtl-optimization/41862 * store-motion.c (store_killed_in_insn, compute_store_table, remove_reachable_equiv_notes, replace_store_insn, build_store_vectors): Ignore all DEBUG_INSNs. Modified: trunk/gcc/ChangeLog trunk/gcc/store-motion.c
Works for me now.