[Bug debug/45419] -fcompare-debug failure at -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419 --- Comment #20 from Alexandre Oliva aoliva at gcc dot gnu.org 2010-10-08 04:41:09 UTC --- Author: aoliva Date: Fri Oct 8 04:40:59 2010 New Revision: 165149 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=165149 Log: PR debug/45673 PR debug/45604 PR debug/45419 PR debug/45408 * tree-pretty-print.c (dump_generic_node): Explicitly dump the type of MEM_REFs to INTEGER_CSTs. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-pretty-print.c
[Bug debug/45419] -fcompare-debug failure at -O3
--- Comment #19 from aoliva at gcc dot gnu dot org 2010-09-13 03:42 --- Subject: Bug 45419 Author: aoliva Date: Mon Sep 13 03:42:07 2010 New Revision: 164242 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164242 Log: PR debug/45604 PR debug/45419 PR debug/45408 * tree-pretty-print.c (dump_generic_node): Disregard top-level types of MEM_REF pointer types to the same type. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-pretty-print.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
[Bug debug/45419] -fcompare-debug failure at -O3
--- Comment #17 from aoliva at gcc dot gnu dot org 2010-09-08 21:54 --- Subject: Bug 45419 Author: aoliva Date: Wed Sep 8 21:53:48 2010 New Revision: 164031 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164031 Log: PR debug/45419 PR debug/45408 * tree-pretty-print.c (dump_generic_node): Disregard top-level qualifiers in otherwise equal MEM_REF pointer types. * fold-const.c (operand_equal_p): Compare pointer type of MEM_REFs. * tree.c (iterative_hash_expr): Hash the pointer type of MEM_REFs. Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/tree-pretty-print.c trunk/gcc/tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
[Bug debug/45419] -fcompare-debug failure at -O3
--- Comment #18 from aoliva at gcc dot gnu dot org 2010-09-08 21:56 --- Fixed -- aoliva at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
[Bug debug/45419] -fcompare-debug failure at -O3
--- Comment #15 from aoliva at gcc dot gnu dot org 2010-09-04 15:26 --- Got a patch -- aoliva at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
[Bug debug/45419] -fcompare-debug failure at -O3
--- Comment #16 from aoliva at gcc dot gnu dot org 2010-09-04 15:27 --- *** Bug 45408 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
[Bug debug/45419] -fcompare-debug failure at -O3
--- Comment #13 from aoliva at gcc dot gnu dot org 2010-09-03 08:59 --- The different types arise when, say, we copyprop a const-unqualified variable into a MEM_REF that used to reference a const-qualified temp. The top-level const qualifications are irrelevant at that point, for we're dealing with rvalues of pointer types. I'm experimenting with simply dropping the TYPE_QUALS test from tree-pretty-print. This fixed the pt.c -fcompare-debug problem. Richard, is there any reason for top-level qualifiers to be relevant in MEM_REF operands? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
[Bug debug/45419] -fcompare-debug failure at -O3
--- Comment #14 from rguenther at suse dot de 2010-09-03 09:06 --- Subject: Re: -fcompare-debug failure at -O3 On Fri, 3 Sep 2010, aoliva at gcc dot gnu dot org wrote: --- Comment #13 from aoliva at gcc dot gnu dot org 2010-09-03 08:59 --- The different types arise when, say, we copyprop a const-unqualified variable into a MEM_REF that used to reference a const-qualified temp. The top-level const qualifications are irrelevant at that point, for we're dealing with rvalues of pointer types. I'm experimenting with simply dropping the TYPE_QUALS test from tree-pretty-print. This fixed the pt.c -fcompare-debug problem. Richard, is there any reason for top-level qualifiers to be relevant in MEM_REF operands? Hmm, not really. But in the end at some point I want to drop the fancy printing of MEM_REFs. What you can do is instead of dump_generic_node (buffer, TREE_TYPE (TREE_OPERAND (node, 1)), spc, flags | TDF_SLIM, false); do dump_generic_node (buffer, TYPE_MAIN_VARIANT (TREE_TYPE (TREE_OPERAND (node, 1))), spc, flags | TDF_SLIM, false); as that is what matters. Or even better, see if the issue goes away when you change the gimplifier to use the main variant in the first place. That's sth I would prefer - not sure why I missed that. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
[Bug debug/45419] -fcompare-debug failure at -O3
--- Comment #12 from aoliva at gcc dot gnu dot org 2010-09-02 12:21 --- 'been looking into this as well. cp/pt.c -fcompare-debug fails for me on x86_64-linux-gnu. I'm not sure yet why we get different different types for the integer_csts in operand 0 of MEM_REFs, but it occurred to me that we could add a flag to operand_equal_p to check that all types are the same. Ideally, we'd have corresponding flags for hashing as well, but not necessarly for correctness. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
[Bug debug/45419] -fcompare-debug failure at -O3
--- Comment #7 from jakub at gcc dot gnu dot org 2010-08-30 12:53 --- Created an attachment (id=21593) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21593action=view) gcc46-pr45419.patch Fix for the valgrind issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
[Bug debug/45419] -fcompare-debug failure at -O3
--- Comment #8 from jakub at gcc dot gnu dot org 2010-08-30 14:05 --- The other issue comes from MEM_ATTRS caching. mem_attrs_htab_eq considers MEM_EXPR to be equal if: 279 (p-expr == q-expr 280 || (p-expr != NULL_TREE q-expr != NULL_TREE 281 operand_equal_p (p-expr, q-expr, 0; With -g there happens to be a different MEM_ATTRS in the cache than without -g, and as both are operand_equal_p, gcc doesn't care which one it chooses. As -fcompare-debug does a textual comparison, I guess we'd for -fdump-final-insns need to dump something that is stable. E.g. it could print just iterative_hash_expr (MEM_EXPR (memref), 0) instead of printing the expression. I'm not sure whether that would fix this completely, because I believe if there are collisions, mem_attrs_htab_eq could return true even if mem_attrs_htab_hash is different. Therefore perhaps mem_attrs_htab_eq should also check (size_t) iterative_hash_expr (p-expr, 0) == (size_t) iterative_hash_expr (q-expr, 0) if operand_equal_p returned true. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
[Bug debug/45419] -fcompare-debug failure at -O3
--- Comment #9 from jakub at gcc dot gnu dot org 2010-08-30 14:29 --- Unfortunately printing iterative_hash_expr for MEM_EXPR if final_insns_dump_p is actually worse, because iterative_hash_expr uses DECL_UID, which isn't guaranteed to be the same between -g and -g0. So, either we shouldn't print MEM_EXPR at all for final_insns_dump_p, or come up with iterative_hash_expr alternative which doesn't hash using DECL_UIDs, but DECL_NAME. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
[Bug debug/45419] -fcompare-debug failure at -O3
--- Comment #10 from rguenther at suse dot de 2010-08-30 14:30 --- Subject: Re: -fcompare-debug failure at -O3 On Mon, 30 Aug 2010, jakub at gcc dot gnu dot org wrote: --- Comment #9 from jakub at gcc dot gnu dot org 2010-08-30 14:29 --- Unfortunately printing iterative_hash_expr for MEM_EXPR if final_insns_dump_p is actually worse, because iterative_hash_expr uses DECL_UID, which isn't guaranteed to be the same between -g and -g0. So, either we shouldn't print MEM_EXPR at all for final_insns_dump_p, or come up with iterative_hash_expr alternative which doesn't hash using DECL_UIDs, but DECL_NAME. Or dump MEM_EXPR caching? Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
[Bug debug/45419] -fcompare-debug failure at -O3
--- Comment #11 from jakub at gcc dot gnu dot org 2010-08-30 17:17 --- Subject: Bug 45419 Author: jakub Date: Mon Aug 30 17:17:15 2010 New Revision: 163654 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163654 Log: PR debug/45419 * tree-ssa-live.c (dump_enumerated_decls): Clear the whole wi variable. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-live.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
[Bug debug/45419] -fcompare-debug failure at -O3
--- Comment #1 from zsojka at seznam dot cz 2010-08-26 17:12 --- Created an attachment (id=21572) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21572action=view) testcase Delta (with line granularity) fails to reduce the file further. The difference in debug and non-debug runs is very small: $ diff pr45419.*gkd 19581c19581 (compare:CCZ (mem/c:QI (symbol_ref:DI (buf.3274) [flags 0x2] var_decl # buf) [ MEM[(char *)buf]+0 S1 A256]) --- (compare:CCZ (mem/c:QI (symbol_ref:DI (buf.3274) [flags 0x2] var_decl # buf) [ MEM[(const char *)buf]+0 S1 A256]) 19913c19913 (compare:CCZ (mem/c:QI (symbol_ref:DI (buf.3274) [flags 0x2] var_decl # buf) [ MEM[(char *)buf]+0 S1 A256]) --- (compare:CCZ (mem/c:QI (symbol_ref:DI (buf.3274) [flags 0x2] var_decl # buf) [ MEM[(const char *)buf]+0 S1 A256]) only const is missing/added -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
[Bug debug/45419] -fcompare-debug failure at -O3
--- Comment #2 from hjl dot tools at gmail dot com 2010-08-26 17:46 --- I can't reproduce it on Fedora 13. But valgrind reports: Compiler executable checksum: d32748fe5bfee4f2f9ecf4e95f2e1498 ==17242== Conditional jump or move depends on uninitialised value(s) ==17242==at 0x7ED1AF: walk_gimple_stmt (gimple.c:1627) ==17242==by 0xB20D9E: dump_enumerated_decls (tree-ssa-live.c:1261) ==17242==by 0xA7CD39: execute_cleanup_cfg_post_optimizing (tree-optimize.c:214) ==17242==by 0x8F342C: execute_one_pass (passes.c:1568) ==17242==by 0x8F3615: execute_pass_list (passes.c:1623) ==17242==by 0xA7D3D3: tree_rest_of_compilation (tree-optimize.c:452) ==17242==by 0xD0BB5E: cgraph_expand_function (cgraphunit.c:1469) ==17242==by 0xD0BDF6: cgraph_expand_all_functions (cgraphunit.c:1548) ==17242==by 0xD0C41B: cgraph_optimize (cgraphunit.c:1804) ==17242==by 0xD09E6C: cgraph_finalize_compilation_unit (cgraphunit.c:1012) ==17242==by 0x4B238D: c_write_global_declarations (c-decl.c:9735) ==17242==by 0x9EA743: compile_file (toplev.c:983) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
[Bug debug/45419] -fcompare-debug failure at -O3
--- Comment #3 from jakub at gcc dot gnu dot org 2010-08-26 17:58 --- Unfortunately can't reproduce it myself, neither with bootstrapped, nor with just stage1 built gcc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
[Bug debug/45419] -fcompare-debug failure at -O3
--- Comment #4 from zsojka at seznam dot cz 2010-08-26 18:37 --- Created an attachment (id=21574) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21574action=view) different testcase Thank you for answers! This not yet reduced testcase fails in a similiar way (r163468, x86_64-linux). It needs only -O2 to reproduce. $ gcc -std=gnu++0x -fcompare-debug -O2 040.ii -w gcc: error: 040.ii: -fcompare-debug failure (length) $ diff 040.*gkd 54739c54739 (const_int 8 [0x8]))) [ MEM[(const struct OverflowSafeInt )CMD_ERROR + 8].m_value+0 S8 A64]) --- (const_int 8 [0x8]))) [ MEM[(struct OverflowSafeInt *)CMD_ERROR + 8B].m_value+0 S8 A64]) It shows 3 differences: missing const - * (PR45408) 8 - 8B Information about gcc used: $ /mnt/svn/gcc-trunk/binary-163468-lto-fortran-checking-yes-rtl-df/bin/gcc -v Using built-in specs. COLLECT_GCC=/mnt/svn/gcc-trunk/binary-163468-lto-fortran-checking-yes-rtl-df/bin/gcc COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-163468-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /mnt/svn/gcc-trunk/configure --enable-languages=c,c++,lto,fortran --prefix=/mnt/svn/gcc-trunk/binary-163468-lto-fortran-checking-yes-rtl-df/ --enable-checking=yes,rtl,df Thread model: posix gcc version 4.6.0 20100823 (experimental) (GCC) $ cat /proc/sys/kernel/randomize_va_space 0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
[Bug debug/45419] -fcompare-debug failure at -O3
--- Comment #5 from hjl dot tools at gmail dot com 2010-08-26 19:48 --- valgrind issue is caused by revision 162156: http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg00510.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||amylaar at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
[Bug debug/45419] -fcompare-debug failure at -O3
--- Comment #6 from hjl dot tools at gmail dot com 2010-08-26 20:02 --- (In reply to comment #4) Created an attachment (id=21574) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21574action=view) [edit] different testcase Thank you for answers! This not yet reduced testcase fails in a similiar way (r163468, x86_64-linux). It needs only -O2 to reproduce. $ gcc -std=gnu++0x -fcompare-debug -O2 040.ii -w gcc: error: 040.ii: -fcompare-debug failure (length) $ diff 040.*gkd 54739c54739 (const_int 8 [0x8]))) [ MEM[(const struct OverflowSafeInt )CMD_ERROR + 8].m_value+0 S8 A64]) --- (const_int 8 [0x8]))) [ MEM[(struct OverflowSafeInt *)CMD_ERROR + 8B].m_value+0 S8 A64]) It shows 3 differences: missing const - * (PR45408) 8 - 8B This is caused by revision 161655: http://gcc.gnu.org/ml/gcc-cvs/2010-07/msg6.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-08-26 20:02:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45419
