[Bug debug/63572] New: [5 Regression] ICF breaks user debugging experience

[Bug debug/63572] New: [5 Regression] ICF breaks user debugging experience

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572

            Bug ID: 63572
           Summary: [5 Regression] ICF breaks user debugging experience
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
                CC: hubicka at gcc dot gnu.org, jakub at gcc dot gnu.org,
                    jakub at redhat dot com, mliska at suse dot cz, uros at gcc dot gnu.org
        Depends on: 63566
            Blocks: 63571

+++ This bug was initially created as a clone of Bug #63566 +++

On -O2 -g:
#define A \
  x += y * z; \
  y = (y << ((z & 2) + 1)) \
      ^ (y >> (__SIZEOF_INT__ * __CHAR_BIT__ - (z & 2) - 1)); \
  z *= 7;
#define B A A A A A A A A A A
#define C B B B B B B B B B B

static unsigned int
f1 (unsigned int x, unsigned int y, unsigned int z)
{
  C
  return x + y + z;
}

static unsigned int
f2 (unsigned int x, unsigned int y, unsigned int z)
{
  C
  return x + y + z;
}

__attribute__((noinline, noclone)) unsigned int
f3 (unsigned int x, unsigned int y, unsigned int z)
{
  return f1 (x, z, y) + 6;
}

__attribute__((noinline, noclone)) unsigned int
f4 (unsigned int x, unsigned int y, unsigned int z)
{
  return f2 (y, x, z) + 7;
}

__attribute__((noinline, noclone, used)) unsigned int
f5 (unsigned int x, unsigned int y, unsigned int z)
{
  return f1 (2 * x, z / 2, y + 3) - 6;
}

__attribute__((noinline, noclone, used)) unsigned int
f6 (unsigned int x, unsigned int y, unsigned int z)
{
  return f2 (y + 2, x | 1, z / 73) + 1;
}

int
main ()
{
  unsigned int x = f3 (0x173214, 0x182172, 0x9314);
  unsigned int y = f4 (0x173214, 0x182172, 0x9314);
#if __SIZEOF_INT__ * __CHAR_BIT__ == 32
  if (x != 0xd8e56f78U || y != 0x494c6699U)
    __builtin_abort ();
#endif
  return 0;
}

GCC emits incomplete DW_TAG_GNU_call_site DIEs for the f1 calls (that have been
optimized into ICF alias to f2) - no DW_AT_abstract_origin is provided,
and does not emit any DW_TAG_subprogram for f1 at all, just f2.
The question is how exactly do we want to emit the DW_TAG_subprogram for
icf_merged aliases.  Name/abstract origin/function type/names of arguments must
be it's own, I guess ICF will happily merge functions where the arguments have
e.g. different argument names, or different DECL_ABSTRACT_ORIGIN etc.
My question is mainly about DW_TAG_lexical_block/DW_TAG_inlined_subroutine, but
as even names of local variables can differ, or it can have different functions
inlined, I bet we need to fully populate DW_TAG_subprogram for the ICF aliases,
and have some mapping between BLOCKs in the ICF alias and BLOCKs in the kept
definition, so that we can reconstruct ranges.  Then, when we emit
DW_TAG_subprogram details for the kept original function definition when
finalizing its RTL, we also need to handle similarly all the ICF aliases.
Which is going to be non-fun.  Also, supposedly not just that, but we also need
a way to track multiple locations, not just blocks.
E.g. in one function, first 3 statements can have one location_t, say line 31,
and last 3 statements can have another location_t, say line 38.  Now, in
another
function ICF merged with that, the similar first 2 statements can have one
location_t, say line 47, the second 2 statements can have location_t line 49
and last 2 statements location_t line 53.  So, it might be impossible to create
e.g. a pointer_map from one set of locations to another set, we'd need to
analyze the correspondence between location_t's in between all the spots in the
function (gimple_location, EXPR_LOCATION) where they appear, and perhaps create
some artificial locations to make sure there is a 1-1 mapping between all ICF
merged functions.  Another problem is that we emit these days .debug_line using
.file/.loc directives and gas constructs that.  Not sure if we can have
multiple .debug_line proglets describing the same area of code (perhaps we need
some DWARF extension for that?) and if we had that possibility, the question is
how to emit it.
As for the DW_AT_abstract_origin of DW_TAG_GNU_call_site, that should probably
be just very easy, if there is a DIE for the ICF merged alias, supposedly it
will be found normally.

And, then we'll certainly need some GDB changes (and systemtap/elfutils etc.) - 
if some code range has multiple DW_TAG_subprogram DIEs covering that range,
e.g. if you want to put a breakpoint into a line in one of the functions

[Bug debug/63572] [5 Regression] ICF breaks user debugging experience

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
For debugging most important is to get

(gdb) b foo

still work when foo was merged with bar and the program now calls bar

Similarly nice (but probably impossible) is

(gdb) b foo.c:23

with foo.c:23 inside foo.  Of course foo and bar, even if considered equal
by ICF, are by no means equivalent lexically.  So foo.c:23 could at most
break at the start of bar.  (or give a useful diagnostic from gdb)

[Bug debug/63572] [5 Regression] ICF breaks user debugging experience

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-10-17
                 CC|                            |ccoutant at gcc dot gnu.org,
                   |                            |jan.kratochvil at redhat dot com,
                   |                            |jason at gcc dot gnu.org,
                   |                            |mark at gcc dot gnu.org
   Target Milestone|---                         |5.0
     Ever confirmed|0                           |1

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
For the different locations and blocks, I meant something like:

struct S { int a; int b; int c; };
struct T { int d; int e; int f; };

static int
f1 (struct S *x)
{
  int g = x->a * 7;
  {
    int h = x->b * 11;
    {
      int i = x->c;
      return g + h + i;
    }
  }
}

static int
f2 (struct T *x)
{
  int j = x->d * 7; int k = x->e * 11;
  int l = x->f;
  return j + k + l;
}

int f3 (struct S *x) { return f1 (x); }
int f4 (struct T *x) { return f2 (x); }
int f5 (struct S *x) { return f1 (x) + 1; }
int f6 (struct T *x) { return f2 (x) + 1; }

(but for some reason ICF doesn't merge this, so we need better testcase).
The point was that with identical .text there doesn't have to be 1:1 mapping
between location_t's (and those now include both file:line:column and BLOCK),
in the above example supposedly there is many:1 mapping from f2 to f1
location_t, but generally there could be overlaps etc.

[Bug debug/63572] [5 Regression] ICF breaks user debugging experience

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |trippels at gcc dot gnu.org

--- Comment #3 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
*** Bug 63562 has been marked as a duplicate of this bug. ***

[Bug debug/63572] [5 Regression] ICF breaks user debugging experience

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Better testcase, where ICF actually happens.

struct S { int a; int b; int c; };

__attribute__((noinline)) static int
f1 (struct S *x)
{
  static int u = 1;
  int g = x->a * 7;
  {
    static int v = 2;
    int h = x->b * 11;
    int i = x->c;
    return g + h + i;
  }
}

__attribute__((noinline)) static int
f2 (struct S *x)
{
  static int w = 3;
  int j = x->a * 7; int k = x->b * 11;
  {
    static int y = 4;
    int l = x->c;
    return j + k + l;
  }
}

__attribute__((noinline)) int f3 (struct S *x) { return f1 (x); }
__attribute__((noinline)) int f4 (struct S *x) { return f2 (x) + 1; }
__attribute__((noinline)) int f5 (struct S *x) { return f1 (x) + 2; }
__attribute__((noinline)) int f6 (struct S *x) { return f2 (x) + 3; }

int
main ()
{
  struct S s = { 1, 2, 3 };
  asm volatile ("" : : "r" (&s) : "memory");
  int a[4];
  a[0] = f3 (&s);
  a[1] = f4 (&s);
  a[2] = f5 (&s);
  a[3] = f6 (&s);
  asm volatile ("" : : "r" (a) : "memory");
  return 0;
}

As for .debug_line, the only solution which doesn't require any extensions
would be IMHO to put the icf_merged clone's DW_TAG_subprogram into its own
DW_TAG_partial_unit, import it into the DW_TAG_compile_unit where it is needed,
and use a different DW_AT_stmt_list offset in there, and emit part of
.debug_line (the one for the icf_merged aliases) manually into .debug_line by
the compiler and see whether the assembler will deal with it properly.

Anyway, the ideal user debugging experience IMHO with the above testcase is:
b f1 - debugger finds out that f1 and f2 subprograms have overlapping ranges,
puts a breakpoint into f1==f2 prologue, and when the breakpoint is hit,
unwinds, checks if from the backtrace it is possible using DW_TAG_GNU_call_site
figure out which of the functions has been called; if it is, depending on if it
is f1 or f2 either honors or ignores the breakpoint; if it isn't possible to
uniquely identify what the caller meant to call, honor the breakpoint.
To map instructions back to line info, blocks etc., again, check unwind
info/backtrace which function it is, if it is known which one it is, go into
.debug_line table corresponding to the CU/PU of the subprogram, otherwise pick
one.  Ditto for the
DW_TAG_subprogram/DW_TAG_lexical_block/DW_TAG_inlined_subroutine trees.

Does that sound like a plan?

[Bug debug/63572] [5 Regression] ICF breaks user debugging experience

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|jakub at redhat dot com            |

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
struct S { int a; int b; int c; };
volatile int t;

__attribute__((noinline)) static int
f1 (struct S *x)
{
  static int u = 1;
  int g = x->a * 7;
  t++;
  {
    static int v = 2;
    int h = x->b * 11;
    t++;
    int i = x->c;
    t++;
    return g + h + i;
  }
}

__attribute__((noinline)) static int
f2 (struct S *x)
{
  static int w = 3;
  int j = x->a * 7; t++; int k = x->b * 11; t++;
  {
    static int y = 4;
    int l = x->c;
    t++;
    return j + k + l;
  }
}

__attribute__((noinline)) int f3 (struct S *x) { return f1 (x); }
__attribute__((noinline)) int f4 (struct S *x) { return f2 (x) + 1; }
__attribute__((noinline)) int f5 (struct S *x) { return f1 (x) + 2; }
__attribute__((noinline)) int f6 (struct S *x) { return f2 (x) + 3; }

int
main ()
{
  struct S s = { 1, 2, 3 };
  asm volatile ("" : : "r" (&s) : "memory");
  int a[4];
  a[0] = f3 (&s);
  a[1] = f4 (&s);
  a[2] = f5 (&s);
  a[3] = f6 (&s);
  asm volatile ("" : : "r" (a) : "memory");
  return 0;
}

Even better testcase, which actually has more executable statements, and thus
allows to inspect if one sees e.g. the u/v/w/y/g/h/i/j/k/l variables in the
scope etc.

[Bug debug/63572] [5 Regression] ICF breaks user debugging experience

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Not sure if we can do anything about this.  ICF breaks this in a similar way
as tail merging does (which makes this kind of regressions older).

I'd say we should suspend this bug ....

[Bug debug/63572] [5 Regression] ICF breaks user debugging experience

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572

--- Comment #10 from Martin Liška <marxin at gcc dot gnu.org> ---
As Cary Countant wrote me, gold's ICF has never implemented support for call
site tables in GDB. Moreover, when Jakub designed the new call site tags, the
design hasn't been changed. In last 4 years, there still hasn't been any demand
for it.

Well, I would at least implement emission of a separate DW_TAG_subprogram DIE
with correct DW_AT_abstract_origin. As I have no experience with debug info,
may I ask Jakub for a hint where to start and how to properly do it?
>From gcc-bugs-return-476498-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Feb 09 15:49:18 2015
Return-Path: <gcc-bugs-return-476498-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 24160 invoked by alias); 9 Feb 2015 15:49:17 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 24057 invoked by uid 48); 9 Feb 2015 15:49:14 -0000
From: "larsbj at gullik dot net" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug sanitizer/64984] New: [5 Regression] ICE in check_noexcept_t with ubsan
Date: Mon, 09 Feb 2015 15:49:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: sanitizer
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: larsbj at gullik dot net
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc
Message-ID: <bug-64984-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-02/txt/msg00831.txt.bz2
Content-length: 5410

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64984

            Bug ID: 64984
           Summary: [5 Regression] ICE in check_noexcept_t with ubsan
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: sanitizer
          Assignee: unassigned at gcc dot gnu.org
          Reporter: larsbj at gullik dot net
                CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
                    jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

With this test program I get an ICE.

----------
#include <map>

class Type
{
public:
    Type();
    virtual ~Type();

    bool operator<(const Type &) const;
};

int main()
{
    std::map<Type, int> map;
    map[Type()] = 0;
}
------------

g++ --version
g++ (GCC) 5.0.0 20150203 (experimental)

g++ -fsanitize=undefined -std=gnu++11 -c test.cpp

In file included from /opt/gcc/gcc-trunk/include/c++/5.0.0/bits/move.h:57:0,
                 from /opt/gcc/gcc-trunk/include/c++/5.0.0/bits/stl_pair.h:59,
                 from
/opt/gcc/gcc-trunk/include/c++/5.0.0/bits/stl_algobase.h:64,
                 from /opt/gcc/gcc-trunk/include/c++/5.0.0/bits/stl_tree.h:63,
                 from /opt/gcc/gcc-trunk/include/c++/5.0.0/map:60,
                 from test.cpp:1:
/opt/gcc/gcc-trunk/include/c++/5.0.0/type_traits: In instantiation of ‘struct
std::__is_nt_constructible_impl<Type&&, Type&&>’:
/opt/gcc/gcc-trunk/include/c++/5.0.0/type_traits:137:12:   required from
‘struct std::__and_<std::is_constructible<Type&&, Type&&>,
std::__is_nt_constructible_impl<Type&&, Type&&> >’
/opt/gcc/gcc-trunk/include/c++/5.0.0/type_traits:1174:12:   required from
‘struct std::is_nothrow_constructible<Type&&, Type&&>’
/opt/gcc/gcc-trunk/include/c++/5.0.0/type_traits:1205:12:   required from
‘struct std::__is_nothrow_move_constructible_impl<Type&&, true>’
/opt/gcc/gcc-trunk/include/c++/5.0.0/type_traits:1211:12:   required from
‘struct std::is_nothrow_move_constructible<Type&&>’
/opt/gcc/gcc-trunk/include/c++/5.0.0/tuple:367:7:   required from ‘constexpr
std::_Tuple_impl<_Idx, _Head>::_Tuple_impl(std::_Tuple_impl<_Idx, _Head>&&)
[with long unsigned int _Idx = 0ul; _Head = Type&&]’
/opt/gcc/gcc-trunk/include/c++/5.0.0/tuple:976:70:   required from
‘std::tuple<_Elements&& ...> std::forward_as_tuple(_Elements&& ...) [with
_Elements = {Type}]’
/opt/gcc/gcc-trunk/include/c++/5.0.0/bits/stl_map.h:500:27:   required from
‘std::map<_Key, _Tp, _Compare, _Alloc>::mapped_type& std::map<_Key, _Tp,
_Compare, _Alloc>::operator[](std::map<_Key, _Tp, _Compare,
_Alloc>::key_type&&) [with _Key = Type; _Tp = int; _Compare = std::less<Type>;
_Alloc = std::allocator<std::pair<const Type, int> >; std::map<_Key, _Tp,
_Compare, _Alloc>::mapped_type = int; std::map<_Key, _Tp, _Compare,
_Alloc>::key_type = Type]’
test.cpp:15:15:   required from here
/opt/gcc/gcc-trunk/include/c++/5.0.0/type_traits:1162:12: internal compiler
error: Segmentation fault
     struct __is_nt_constructible_impl<_Tp, _Arg>
            ^
0xa89c7f crash_signal
        ../../gcc/gcc/toplev.c:383
0x69ea1b check_noexcept_r
        ../../gcc/gcc/cp/except.c:1162
0xc6b254 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set<tree_node*, default_hashset_traits>*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set<tree_node*, default_hashset_traits>*))
        ../../gcc/gcc/tree.c:11086
0xc6b438 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set<tree_node*, default_hashset_traits>*, tree_node*
(*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*,
hash_set<tree_node*, default_hashset_traits>*))
        ../../gcc/gcc/tree.c:11390
0xc6ca18 walk_tree_without_duplicates_1(tree_node**, tree_node*
(*)(tree_node**, int*, void*), void*, tree_node* (*)(tree_node**, int*,
tree_node* (*)(tree_node**, int*, void*), void*, hash_set<tree_node*,
default_hashset_traits>*))
        ../../gcc/gcc/tree.c:11416
0x69e7cf expr_noexcept_p(tree_node*, int)
        ../../gcc/gcc/cp/except.c:1255
0x69e922 finish_noexcept_expr(tree_node*, int)
        ../../gcc/gcc/cp/except.c:1240
0x61e2ee tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
        ../../gcc/gcc/cp/pt.c:14880
0x61b6ab tsubst_expr
        ../../gcc/gcc/cp/pt.c:14383
0x61c63c tsubst_template_arg
        ../../gcc/gcc/cp/pt.c:9692
0x626839 tsubst_template_args
        ../../gcc/gcc/cp/pt.c:10242
0x623544 tsubst_aggr_type
        ../../gcc/gcc/cp/pt.c:10439
0x617771 tsubst(tree_node*, tree_node*, int, tree_node*)
        ../../gcc/gcc/cp/pt.c:11894
0x631c69 instantiate_class_template_1
        ../../gcc/gcc/cp/pt.c:9260
0x631c69 instantiate_class_template(tree_node*)
        ../../gcc/gcc/cp/pt.c:9673
0x68aa5d complete_type(tree_node*)
        ../../gcc/gcc/cp/typeck.c:146
0x68aaff complete_type_or_maybe_complain(tree_node*, tree_node*, int)
        ../../gcc/gcc/cp/typeck.c:158
0x608d09 xref_basetypes(tree_node*, tree_node*)
        ../../gcc/gcc/cp/decl.c:12493
0x63116e instantiate_class_template_1
        ../../gcc/gcc/cp/pt.c:9279
0x63116e instantiate_class_template(tree_node*)
        ../../gcc/gcc/cp/pt.c:9673
>From gcc-bugs-return-476499-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Feb 09 15:57:01 2015
Return-Path: <gcc-bugs-return-476499-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 20533 invoked by alias); 9 Feb 2015 15:57:01 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 20437 invoked by uid 48); 9 Feb 2015 15:56:58 -0000
From: "mpolacek at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug sanitizer/64984] [5 Regression] ICE in check_noexcept_t with ubsan
Date: Mon, 09 Feb 2015 15:57:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: sanitizer
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: mpolacek at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cf_reconfirmed_on cc target_milestone everconfirmed
Message-ID: <bug-64984-4-GfnjYxcgzC@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-64984-4@http.gcc.gnu.org/bugzilla/>
References: <bug-64984-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-02/txt/msg00832.txt.bz2
Content-length: 755

https://gcc.gnu.org/bugzilla/show_bug.cgi?idd984

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-02-09
                 CC|                            |mpolacek at gcc dot gnu.org
   Target Milestone|---                         |5.0
     Ever confirmed|0                           |1

--- Comment #1 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Confirmed.  Seems to be a bug in the vptr checking; -std=gnu++11
-fsanitize=vptr ICEs, -std=gnu++11 -fsanitize=undefined -fno-sanitize=vptr
compiles ok.

[Bug debug/63572] [5 Regression] ICF breaks user debugging experience

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572
Bug 63572 depends on bug 63566, which changed state.

Bug 63566 Summary: [5 Regression] i686 bootstrap fails: ICE RTL flag check: INSN_UID used with unexpected rtx code 'set' in INSN_UID, at rtl.h:1326
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63566

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

[Bug debug/63572] [5 Regression] ICF breaks user debugging experience

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572

--- Comment #11 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Reported by HJ:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65237

As of r221117,  I still see

FAIL: gcc.dg/guality/sra-1.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none  line 32 a[0] == 4
FAIL: gcc.dg/guality/sra-1.c   -O2  line 21 a.i == 4
FAIL: gcc.dg/guality/sra-1.c   -O3 -fomit-frame-pointer  line 21 a.i == 4
FAIL: gcc.dg/guality/sra-1.c   -O3 -g  line 21 a.i == 4
FAIL: gcc.dg/guality/sra-1.c   -Os  line 21 a.i == 4

on Linux/x86-32.

[Bug debug/63572] [5 Regression] ICF breaks user debugging experience

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572

Jeffrey A. Law <law at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4
                 CC|                            |law at redhat dot com

[Bug debug/63572] [5 Regression] ICF breaks user debugging experience

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572

--- Comment #12 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #11)
> Reported by HJ:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65237
> 
> As of r221117,  I still see
> 
> FAIL: gcc.dg/guality/sra-1.c   -O2 -flto -fno-use-linker-plugin
> -flto-partition=none  line 32 a[0] == 4
> FAIL: gcc.dg/guality/sra-1.c   -O2  line 21 a.i == 4
> FAIL: gcc.dg/guality/sra-1.c   -O3 -fomit-frame-pointer  line 21 a.i == 4
> FAIL: gcc.dg/guality/sra-1.c   -O3 -g  line 21 a.i == 4
> FAIL: gcc.dg/guality/sra-1.c   -Os  line 21 a.i == 4
> 
> on Linux/x86-32.

I've just run guality testsuite and I'm given identical results with and w/o
-fipa-icf. Thus, I guess sra-1.c test isn't caused by ICF.

Thanks,
Martin
>From gcc-bugs-return-479311-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Mar 04 11:05:48 2015
Return-Path: <gcc-bugs-return-479311-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 31210 invoked by alias); 4 Mar 2015 11:05:48 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 30775 invoked by uid 48); 4 Mar 2015 11:05:44 -0000
From: "trippels at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/65309] [Regression] Executes wrong function inside an anonymous namespace on runtime
Date: Wed, 04 Mar 2015 11:05:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: trippels at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-65309-4-BYUnOSfrhm@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65309-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65309-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-03/txt/msg00455.txt.bz2
Content-length: 449

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide309

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |trippels at gcc dot gnu.org

--- Comment #2 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
I cannot reproduce this. What linker are you using?

[Bug debug/63572] [5 Regression] ICF breaks user debugging experience

[howarth at bromo dot med.uc.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572

howarth at bromo dot med.uc.edu changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |howarth at bromo dot med.uc.edu

--- Comment #13 from howarth at bromo dot med.uc.edu ---
Is this bug going to be suspended for 5.0? If so, it would also allow Bug
65303, "Tracking bug for ICF issues", to be closed as well for 5.0.

[Bug debug/63572] [5/6 Regression] ICF breaks user debugging experience

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|5.0                         |5.2

--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 5.1 has been released.

[Bug debug/63572] [5/6 Regression] ICF breaks user debugging experience

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|5.2                         |5.3

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 5.2 is being released, adjusting target milestone to 5.3.

[Bug debug/63572] [8/9/10/11 Regression] ICF breaks user debugging experience

[hubicka at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bernd.edlinger at hotmail dot de

--- Comment #24 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
*** Bug 97937 has been marked as a duplicate of this bug. ***

[Bug debug/63572] [8/9/10/11 Regression] ICF breaks user debugging experience

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P4                          |P2

--- Comment #25 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Jan Hubicka from comment #24)
> *** Bug 97937 has been marked as a duplicate of this bug. ***

Testcase from the bug.  The thing is after ICFing test and test2 we still
emit the very same code as when not doing ICF but the only effect is
no debug info for test1.

int test(void)
{
  return 0;
}

int test1(void)
{
  return 0;
}

struct s {
  int (*x) (void);
  int (*y) (void);
};

struct s xxx = { test, test1 };

[Bug debug/63572] [8/9/10/11 Regression] ICF breaks user debugging experience

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572

--- Comment #26 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Bet we ICF and then inline it back into the "thunk".

[Bug debug/63572] [9/10/11/12 Regression] ICF breaks user debugging experience

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|8.5                         |9.4

--- Comment #27 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 8 branch is being closed.

[Bug debug/63572] [9/10/11/12 Regression] ICF breaks user debugging experience

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.4                         |9.5

--- Comment #28 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9.4 is being released, retargeting bugs to GCC 9.5.

[Bug debug/63572] [10/11/12/13 Regression] ICF breaks user debugging experience

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|9.5                         |10.4

--- Comment #29 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 9 branch is being closed

[Bug debug/63572] [10/11/12/13 Regression] ICF breaks user debugging experience

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.4                        |10.5

--- Comment #30 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.

[Bug debug/63572] [10/11/12/13/14 Regression] ICF breaks user debugging experience

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572

--- Comment #31 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
In theory, what we could do (expensive though) is keep the IL of the functions
that were ICF merged with the picked up candidate, just mark them in cgraph
specially so that e.g. IPA doesn't consider references to functions/vars from
the other copies as distinct references, compile those functions right after
compiling their chosen ICF winner (or right before it), but don't emit into
assembly, instead compare with how the ICF winner
and emit just debug info for the other copies after building some mapping
between the debug related labels in the different functions.  If we compiled it
into different code, something bad happened (e.g. some debug counter or
similar) and we'd just not emit the debug info for the other copies (like we
don't emit it currently for those).

[Bug debug/63572] [11/12/13/14 Regression] ICF breaks user debugging experience

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.5                        |11.5

--- Comment #32 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10 branch is being closed.