[Bug debug/43516] [4.5 Regression] -fcompare-debug failure at -O2
--- Comment #19 from jakub at gcc dot gnu dot org 2010-04-07 14:23 --- Subject: Bug 43516 Author: jakub Date: Wed Apr 7 14:23:35 2010 New Revision: 158062 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=158062 Log: PR debug/43516 * tree.c (MAX_INT_CACHED_PREC): Define. (nonstandard_integer_type_cache): New array. (build_nonstandard_integer_type): Cache results for precision = MAX_INT_CACHED_PREC. Modified: trunk/gcc/ChangeLog trunk/gcc/tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43516
[Bug debug/43516] [4.5 Regression] -fcompare-debug failure at -O2
--- Comment #18 from jakub at gcc dot gnu dot org 2010-03-27 21:39 --- The first patch is now in, so this isn't a -fcompare-debug failure anymore. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43516
[Bug debug/43516] [4.5 Regression] -fcompare-debug failure at -O2
--- Comment #9 from jakub at gcc dot gnu dot org 2010-03-26 10:28 --- We call get_alias_set on a 1 bit precision unsigned type with no alias set. This calls lang_hooks.get_alias_set, which does c_common_signed_type. With -g it returns a type with alias set computed, but with -g0 that type doesn't have alias set computed yet and a new alias set is created for it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43516
[Bug debug/43516] [4.5 Regression] -fcompare-debug failure at -O2
--- Comment #10 from jakub at gcc dot gnu dot org 2010-03-26 10:42 --- In particular, for -g0 the alias set of that unsigned 1 bit type actually changes. This is on the #c1 testcase, with -g -fcompare-debug=-gtoggle pr43516.c -O2 -fdump-final-insns=/tmp/1 resp. -g0 -fcompare-debug=-gtoggle pr43516.c -O2 -fdump-final-insns=/tmp/2 Putting a breakpoint on new_alias_set when it returns 41 or more, when it returns 41 in the backtrace is first get_alias_set for the signed 1 bit type that c_common_signed_type returned, then 2 frames up get_alias_set for the problematic unsigned 1 bit type. In -g0 case a few get_alias_set calls on this unsigned 1 bit type suddenly c_common_signed_type returns a different type, which doesn't have alias set computed, while for -g it doesn't. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43516
[Bug debug/43516] [4.5 Regression] -fcompare-debug failure at -O2
--- Comment #11 from jakub at gcc dot gnu dot org 2010-03-26 11:03 --- Ah, apparently the type returned by c_common_signed_type - ... - build_nonstandard_integer_type is not referenced from anywhere anymore during FRE, except from static GTY ((if_marked (type_hash_marked_p), param_is (struct type_hash))) htab_t type_hash_table; With -g0 at the end of FRE ggc_collect actually performs GC, while with -g it doesn't at this point (different amount of memory allocated, ...). As that signed 1 bit type isn't marked, it is removed from the hash table and therefore during PRE when get_alias_set is called again on the unsigned 1 bit type, this signed 1 bit type isn't found anymore and thus build_nonstandard_integer_type returns a fresh new type. BTW, even if GC didn't happen, type_hash_marked_p returns return ggc_marked_p (type) || TYPE_SYMTAB_POINTER (type); where TYPE_SYMTAB_POINTER depends on -g vs. -g0. I think there can't be too many non-standard integer types, so perhaps just build_nonstandard_type should make sure whatever it once returns isn't garbage collected. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43516
[Bug debug/43516] [4.5 Regression] -fcompare-debug failure at -O2
--- Comment #12 from rguenth at gcc dot gnu dot org 2010-03-26 11:50 --- Not a real bug. P4. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43516
[Bug debug/43516] [4.5 Regression] -fcompare-debug failure at -O2
--- Comment #13 from jakub at gcc dot gnu dot org 2010-03-26 13:13 --- Created an attachment (id=20208) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20208action=view) gcc45-pr43516-1.patch One possible fix, just don't print MEM alias sets in -fdump-final-insns= dump. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43516
[Bug debug/43516] [4.5 Regression] -fcompare-debug failure at -O2
--- Comment #14 from jakub at gcc dot gnu dot org 2010-03-26 13:15 --- Created an attachment (id=20209) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20209action=view) gcc45-pr43516-2.patch Another possible patch, this one speeds up build_nonstandard_integer (e.g. on the #c1 testcase it is called hundreds times) and at the same time ensures the type isn't garbage collected and thus this problem won't occur. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43516
[Bug debug/43516] [4.5 Regression] -fcompare-debug failure at -O2
--- Comment #15 from rguenth at gcc dot gnu dot org 2010-03-26 13:33 --- (In reply to comment #13) Created an attachment (id=20208) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20208action=view) [edit] gcc45-pr43516-1.patch One possible fix, just don't print MEM alias sets in -fdump-final-insns= dump. This one is ok if it passes bootstrap regtest. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43516
[Bug debug/43516] [4.5 Regression] -fcompare-debug failure at -O2
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-03-26 13:36 --- (In reply to comment #14) Created an attachment (id=20209) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20209action=view) [edit] gcc45-pr43516-2.patch Another possible patch, this one speeds up build_nonstandard_integer (e.g. on the #c1 testcase it is called hundreds times) and at the same time ensures the type isn't garbage collected and thus this problem won't occur. This one is ok for 4.6. Possibly with GTY if_marked foo to allow us reclaim integer constants hanging off these nonstandard types? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43516
[Bug debug/43516] [4.5 Regression] -fcompare-debug failure at -O2
--- Comment #17 from jakub at gcc dot gnu dot org 2010-03-26 16:19 --- Subject: Bug 43516 Author: jakub Date: Fri Mar 26 16:18:51 2010 New Revision: 157753 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157753 Log: PR debug/43516 * flags.h (final_insns_dump_p): New extern. * final.c (final_insns_dump_p): New variable. (rest_of_clean_state): Set it before -fdump-final-insns= dumping, clear afterwards. * print-rtl.c (print_rtx): If final_insns_dump_p don't dump MEM_ALIAS_SET on MEMs. Modified: trunk/gcc/ChangeLog trunk/gcc/final.c trunk/gcc/flags.h trunk/gcc/print-rtl.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43516
[Bug debug/43516] [4.5 Regression] -fcompare-debug failure at -O2
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Summary|-fcompare-debug failure at|[4.5 Regression] -fcompare- |-O2 |debug failure at -O2 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43516
[Bug debug/43516] [4.5 Regression] -fcompare-debug failure at -O2
--- Comment #5 from jakub at gcc dot gnu dot org 2010-03-25 16:50 --- Well, I'm not sure it is a 4.5 regression, I think 4.4 and earlier behave the same. BTW, there is also some alias set difference (44 vs. 43) I'll look at tomorrow. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Summary|-fcompare-debug failure at|[4.5 Regression] -fcompare- |-O2 |debug failure at -O2 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43516
[Bug debug/43516] [4.5 Regression] -fcompare-debug failure at -O2
--- Comment #6 from zsojka at seznam dot cz 2010-03-25 17:13 --- Created an attachment (id=20199) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20199action=view) unreduced testcase from comment #1 (from gawk sources) This testcase fails at i686 with: gcc regex.i -fcompare-debug -O2 gcc regex.i -fcompare-debug -O1 -fstrict-aliasing -fno-strict-aliasing seems to solve the failure for all testcases All testcases (both reduced and unreduced) do not show code difference when compiled with and without debug in r157677 (i686). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43516
[Bug debug/43516] [4.5 Regression] -fcompare-debug failure at -O2
--- Comment #7 from pinskia at gcc dot gnu dot org 2010-03-25 18:34 --- Note this is hard to reduce really, even removing of some BLOCKS causes it to pass. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43516
[Bug debug/43516] [4.5 Regression] -fcompare-debug failure at -O2
--- Comment #8 from jakub at gcc dot gnu dot org 2010-03-25 21:06 --- Oops, sorry, forgot that -fdump-final-insns=XX does emit decl uids into the dump, unless -fcompare-debug=-gtoggle is also passed to cc1. So I was comparing what -fcompare-debug actually is not comparing. The alias differences are the only real ones, looking into it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43516
