[Bug debug/43516] New: "-fcompare-debug failure" at -O2

[Bug debug/43516] New: "-fcompare-debug failure" at -O2

[zsojka at seznam dot cz]

Command line:
gcc -O2 -fcompare-debug testcase.c

Tested revisions:
r157677 - fail (i686)
r157675 - OK (x86_64)
but after reducing, one of testcases started failing at x86_64

further reducing is hard, and this could be a dup of pr42977


-- 
           Summary: "-fcompare-debug failure" at -O2
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: zsojka at seznam dot cz
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43516

[Bug debug/43516] "-fcompare-debug failure" at -O2

[zsojka at seznam dot cz]

------- Comment #1 from zsojka at seznam dot cz  2010-03-25 11:30 -------
Created an attachment (id=20196)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20196&action=view)
~2000 lines long testcase

Command line:
gcc -O2 -fcompare-debug pr43516.c

fails at i686 r157677 and x86_64 r157675

delta doesn't reduce it further, other tool does a little


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43516

[Bug debug/43516] "-fcompare-debug failure" at -O2

[zsojka at seznam dot cz]

------- Comment #2 from zsojka at seznam dot cz  2010-03-25 11:32 -------
Created an attachment (id=20197)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20197&action=view)
~3000 lines long testcase

gcc -O2 -fcompare-debug pr43516-2.c

fails only at i686 r157677


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43516

[Bug debug/43516] "-fcompare-debug failure" at -O2

[jakub at gcc dot gnu dot org]

------- Comment #3 from jakub at gcc dot gnu dot org  2010-03-25 16:03 -------
This has nothing with PR42977 - the differences start appearing during
inlining.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-03-25 16:03:46
               date|                            |


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]

-- 

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] "-fcompare-debug failure" at -O2

[jakub at gcc dot gnu dot org]

------- Comment #4 from jakub at gcc dot gnu dot org  2010-03-25 16:49 -------
Seems remove_unused_scope_block_p removes from
BLOCK #0 
  SUPERCONTEXT: re_string_skip_chars
  VARS: prev_st rawbuf_idx mbclen wc 
the prev_st variable which was unused.  But remove_unused_scope_block_p
does this only for -g0/-g1.  Then during inlining, expand_call_inline ->
remap_blocks -> remap_block -> remap_decls -> remap_decl ->
copy_decl_maybe_to_var -> copy_decl_no_change -> copy_node_stat copies
these decls, and obviously if there are more in -g2 case from -g0 case,
DECL_UIDs get out of sync and thus the -fcompare-debug failure.  There isn't
actually any code change on the #c1 testcase, at least not on x86_64-linux, but
with the DECL_UIDs being out of sync there is the possibility that some
algorithm hashing by DECL_UIDs and then traversing the hash table would lead to
code differences.  Or have we changed all such places to use bitmaps?


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|wrong-code                  |
            Summary|[4.5 Regression] "-fcompare-|"-fcompare-debug failure" at
                   |debug failure" at -O2       |-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

[jakub at gcc dot gnu dot org]

------- 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

[zsojka at seznam dot cz]

------- 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=20199&action=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

[pinskia at gcc dot gnu dot org]

------- 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

[jakub at gcc dot gnu dot org]

------- 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

[Bug debug/43516] [4.5 Regression] "-fcompare-debug failure" at -O2

[jakub at gcc dot gnu dot org]

------- 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

[jakub at gcc dot gnu dot org]

------- 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

[jakub at gcc dot gnu dot org]

------- 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

[rguenth at gcc dot gnu dot org]

------- 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

[jakub at gcc dot gnu dot org]

------- 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=20208&action=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

[jakub at gcc dot gnu dot org]

------- 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=20209&action=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

[rguenth at gcc dot gnu dot org]

------- 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=20208&action=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

[rguenth at gcc dot gnu dot org]

------- 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=20209&action=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

[jakub at gcc dot gnu dot org]

------- 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=gcc&view=rev&rev=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

[jakub at gcc dot gnu dot org]

------- 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

[jakub at gcc dot gnu dot org]

------- 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=gcc&view=rev&rev=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