[Bug lto/65475] New: [5 Regression] ICE in odr_vtable_hasher::equal (Segmentation fault)

[Bug lto/65475] New: [5 Regression] ICE in odr_vtable_hasher::equal (Segmentation fault)

[marxin at gcc dot gnu.org]

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

            Bug ID: 65475
           Summary: [5 Regression] ICE in odr_vtable_hasher::equal
                    (Segmentation fault)
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: hubicka at ucw dot cz
          Reporter: marxin at gcc dot gnu.org

Hi.

Following ICE can be seen in boost library:

$ g++ -O2 1.ii 2.ii -flto

1.ii:4:45: warning: type ‘struct failure’ violates one definition rule [-Wodr]
   class __attribute((__abi_tag__("cxx11"))) failure : A {};
                                             ^
2.ii:4:45: note: a type with different virtual table pointers is defined in
another translation unit
   class __attribute((__abi_tag__("cxx11"))) failure {
                                             ^
1.ii:4:45: warning: type ‘struct failure’ violates one definition rule [-Wodr]
   class __attribute((__abi_tag__("cxx11"))) failure : A {};
                                             ^
2.ii:4:45: note: a type with different bases is defined in another translation
unit
   class __attribute((__abi_tag__("cxx11"))) failure {
                                             ^
lto1: internal compiler error: Segmentation fault
0x9024df crash_signal
    ../../gcc/toplev.c:383
0x781cf1 odr_vtable_hasher::equal(odr_type_d const*, tree_node const*)
    ../../gcc/ipa-devirt.c:591
0x781cf1 hash_table<odr_vtable_hasher, xcallocator,
false>::find_slot_with_hash(tree_node const*, unsigned int, insert_option)
    ../../gcc/hash-table.h:981
0x77b9bd get_odr_type(tree_node*, bool)
    ../../gcc/ipa-devirt.c:1717
0x77d32c register_odr_type(tree_node*)
    ../../gcc/ipa-devirt.c:1839
0x5b4566 lto_read_decls
    ../../gcc/lto/lto.c:1946
0x5b4f0b lto_file_finalize
    ../../gcc/lto/lto.c:2236
0x5b4f0b lto_create_files_from_ids
    ../../gcc/lto/lto.c:2246
0x5b4f0b lto_file_read
    ../../gcc/lto/lto.c:2287
0x5b4f0b read_cgraph_and_symbols
    ../../gcc/lto/lto.c:2992
0x5b4f0b lto_main()
    ../../gcc/lto/lto.c:3462

$ cat 1.ii
namespace std {
class ios_base {
  struct A {};
  class __attribute((__abi_tag__("cxx11"))) failure : A {};
} a;
}


$ cat 2.ii
namespace std {
template <typename, typename = int> class Trans_NS___cxx11_basic_ostringstream;
class ios_base {
  class __attribute((__abi_tag__("cxx11"))) failure {
    virtual char m_fn2();
  };
};
class B : virtual ios_base {};
template <typename, typename> class Trans_NS___cxx11_basic_ostringstream : B {
public:
  void m_fn1();
};
}

class A {
public:
  A(int) {
    std::Trans_NS___cxx11_basic_ostringstream<wchar_t> a;
    a.m_fn1();
  }
};
int b;
void fn1() { (A(b)); }
>From gcc-bugs-return-480864-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Mar 19 19:16:31 2015
Return-Path: <gcc-bugs-return-480864-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 18184 invoked by alias); 19 Mar 2015 19:16:31 -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 18120 invoked by uid 48); 19 Mar 2015 19:16:26 -0000
From: "aral at gmx dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/65470] regex_search corrupts matches when haystack is destroyed
Date: Thu, 19 Mar 2015 19:54:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: aral at gmx dot de
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:
Message-ID: <bug-65470-4-EfIgqkDfMx@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65470-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65470-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/msg02008.txt.bz2
Content-length: 1117

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

--- Comment #3 from aral at gmx dot de ---
I don't argue that it might be a misunderstanding of the user, hence my
suggestion 1) - however, I disagree with your wording "clearly documented" as
far as

(a) http://en.cppreference.com/w/cpp/regex/regex_search and
(b) http://www.cplusplus.com/reference/regex/regex_search/

are concerned. I could not find any clear statement on "c++ official language
reference" with a google search. Is (a) official?

Either way, (a) states
"7) The overload 3 is prohibited from accepting temporary strings, otherwise
this function populates match_results m with string iterators that become
invalid immediately."

I do not find this very clear, especially since 7) is denoted "since C++14",
and the temporary strings are already a problem in C++11.

How about a statement like this for 2), 3), 5) and 6)? And maybe a clearer
wording? I find the abscence of such a warning, along with the "const"
statement in the parameter declaration (indicating one could submit a string
literal for const charT* s) misleading to say the least.

[Bug lto/65475] [5 Regression] ICE in odr_vtable_hasher::equal (Segmentation fault)

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
In odr_vtable_hasher::equal:

585      t2 = TYPE_MAIN_VARIANT (t2);
586      if (t1 == t2)
587        return true;
588      tree v1 = BINFO_VTABLE (TYPE_BINFO (t1));
589      tree v2 = BINFO_VTABLE (TYPE_BINFO (t2));
590      return (operand_equal_p (TREE_OPERAND (v1, 1),
591                   TREE_OPERAND (v2, 1), 0)
592          && DECL_ASSEMBLER_NAME
593             (TREE_OPERAND (TREE_OPERAND (v1, 0), 0))
594             == DECL_ASSEMBLER_NAME


(gdb) p t1->type_non_common.binfo->binfo.vtable
$4 = (tree) 0x0

(gdb) p t2->type_non_common.binfo->binfo.vtable
$5 = (tree) 0x7ffff6e289b0


(gdb) p debug_tree(t1)
 <record_type 0x7ffff6e2bd20 failure QI
    size <integer_cst 0x7ffff6c36ca8 type <integer_type 0x7ffff6c3a150
bitsizetype> constant 8>
    unit size <integer_cst 0x7ffff6c36cc0 type <integer_type 0x7ffff6c3a0a8
sizetype> constant 1>
    align 8 symtab 0 alias set -1 canonical type 0x7ffff6e2bd20
    attributes <tree_list 0x7ffff6e28550
        purpose <identifier_node 0x7ffff6e28500 __abi_tag__>
        value <tree_list 0x7ffff6e28528
            value <string_cst 0x7ffff6e1b900 type <array_type 0x7ffff6e2bc78>
                readonly constant static "cxx11\000">>>
    fields <type_decl 0x7ffff6e29558 failure
        type <record_type 0x7ffff6e2e0a8 failure QI size <integer_cst
0x7ffff6c36ca8 8> unit size <integer_cst 0x7ffff6c36cc0 1>
            align 8 symtab 0 alias set -1 canonical type 0x7ffff6e2bd20
attributes <tree_list 0x7ffff6e28550> fields <type_decl 0x7ffff6e29558 failure>
context <record_type 0x7ffff6e2bdc8 ios_base>
            chain <type_decl 0x7ffff6e29260 failure>>
        nonlocal VOID file 1.ii line 4 col 57
        align 1 context <record_type 0x7ffff6e2bd20 failure> result
<record_type 0x7ffff6e2bd20 failure>> context <record_type 0x7ffff6e2bdc8
ios_base>
    chain <type_decl 0x7ffff6e29260 failure>>

(gdb) p debug_tree(t2)
 <record_type 0x7ffff6e2ec78 Trans_NS___cxx11_basic_ostringstream addressable
needs-constructing BLK
    size <integer_cst 0x7ffff6c36bb8 type <integer_type 0x7ffff6c3a150
bitsizetype> constant 64>
    unit size <integer_cst 0x7ffff6c36bd0 type <integer_type 0x7ffff6c3a0a8
sizetype> constant 8>
    align 64 symtab 0 alias set -1 canonical type 0x7ffff6e2ec78
    fields <field_decl 0x7ffff6e29d10 D.3973
        type <record_type 0x7ffff6e2ebd0 B addressable needs-constructing BLK
size <integer_cst 0x7ffff6c36bb8 64> unit size <integer_cst 0x7ffff6c36bd0 8>
            align 64 symtab 0 alias set -1 canonical type 0x7ffff6e2e9d8 fields
<field_decl 0x7ffff6e29be0 _vptr.B> context <namespace_decl 0x7ffff6e29130 std>
            chain <type_decl 0x7ffff6e29b48 B>>
        ignored BLK file 2.ii line 9 col 37 size <integer_cst 0x7ffff6c36bb8
64> unit size <integer_cst 0x7ffff6c36bd0 8>
        align 64 offset_align 128
        offset <integer_cst 0x7ffff6c36be8 constant 0>
        bit offset <integer_cst 0x7ffff6c36c30 constant 0> context <record_type
0x7ffff6e2ec78 Trans_NS___cxx11_basic_ostringstream>
        chain <type_decl 0x7ffff6e29da8 Trans_NS___cxx11_basic_ostringstream
type <record_type 0x7ffff6e2ed20 Trans_NS___cxx11_basic_ostringstream>
            external nonlocal suppress-debug VOID file 2.ii line 9 col 78
            align 8 context <record_type 0x7ffff6e2ec78
Trans_NS___cxx11_basic_ostringstream> result <record_type 0x7ffff6e2ec78
Trans_NS___cxx11_basic_ostringstream>>> context <namespace_decl 0x7ffff6e29130
std>
    chain <type_decl 0x7ffff6e29c78 Trans_NS___cxx11_basic_ostringstream>>


Thanks,
Martin
>From gcc-bugs-return-480866-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Mar 19 19:25:00 2015
Return-Path: <gcc-bugs-return-480866-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 96234 invoked by alias); 19 Mar 2015 19:25:00 -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 96198 invoked by uid 48); 19 Mar 2015 19:24:56 -0000
From: "aral at gmx dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/65470] regex_search corrupts matches when haystack is destroyed
Date: Thu, 19 Mar 2015 20:00:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: major
X-Bugzilla-Who: aral at gmx dot de
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:
Message-ID: <bug-65470-4-sYhawJ0FdJ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65470-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65470-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/msg02010.txt.bz2
Content-length: 895

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

--- Comment #4 from aral at gmx dot de ---
Addition: after you referred to the properties of match_results, I had a look
at

  http://en.cppreference.com/w/cpp/regex/match_results

which has a clearer wording. However, I still think this clear statement
  => "it's undefined behavior to examine std::match_results if the original
character sequence was destroyed or iterators to it were invalidated for other
reasons"

should be added to the description of the functions that populate the
match_results. "The user" (I, in this case) does not always check the
descriptions of every single function parameter if the function description
seems to give all the information needed to use it.

What could be improved (to avoid bugs going undetected) is to raise an
exception if the match_results are accessed after the haystack has been
destroyed.

[Bug lto/65475] [5 Regression] ICE in odr_vtable_hasher::equal (Segmentation fault)

[hubicka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-03-19
                 CC|                            |hubicka at gcc dot gnu.org
           Assignee|hubicka at ucw dot cz              |hubicka at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #2 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Mine. The type1 should not be in the vtable hash. I suppose it is an issue with
merging non-polymorphic and polymorphic type over ODR violation.

[Bug lto/65475] [5 Regression] ICE in odr_vtable_hasher::equal (Segmentation fault)

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
The following should help:
Index: ipa-devirt.c
===================================================================
--- ipa-devirt.c        (revision 221528)
+++ ipa-devirt.c        (working copy)
@@ -1412,9 +1412,18 @@ add_type_duplicate (odr_type val, tree t
   if (!val->types_set)
     val->types_set = new hash_set<tree>;

+  /* Chose polymorphic type as leader (this happens only in case of ODR
+     violations.  */
+  if ((TREE_CODE (type) == RECORD_TYPE && TYPE_BINFO (type)
+       && polymorphic_type_binfo_p (TYPE_BINFO (type)))
+      && (TREE_CODE (val->type) != RECORD_TYPE || !TYPE_BINFO (val->type)
+          || !polymorphic_type_binfo_p (TYPE_BINFO (val->type))))
+    {
+      prevail = true;
+      build_bases = true;
+    }
   /* Always prefer complete type to be the leader.  */
-
-  if (!COMPLETE_TYPE_P (val->type) && COMPLETE_TYPE_P (type))
+  else if (!COMPLETE_TYPE_P (val->type) && COMPLETE_TYPE_P (type))
     {
       prevail = true;
       build_bases = TYPE_BINFO (type);

[Bug lto/65475] [5 Regression] ICE in odr_vtable_hasher::equal (Segmentation fault)

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška <marxin at gcc dot gnu.org> ---
Unfortunately, there is another problem with applied patch:

$ cat 1.ii
namespace std {
class exception {};
class runtime_error : exception {
  virtual char m_fn1();
} a;
}

$ cat 2.ii
namespace std {
class exception {
  virtual char m_fn1();
};
class runtime_error : exception {
} a;
}

$ g++ 1.ii 2.ii -flto -O1
/home/marxin/Programming/bin/gcc/bin/ld: error: /tmp/cc7v39VO.o: multiple
definition of 'std::a'
/home/marxin/Programming/bin/gcc/bin/ld: /tmp/ccJ8pPM4.o: previous definition
here
2.ii:2:7: warning: type ‘struct exception’ violates one definition rule [-Wodr]
 class exception {
       ^
1.ii:2:7: note: a type with different virtual table pointers is defined in
another translation unit
 class exception {};
       ^
2.ii:2:7: warning: type ‘struct exception’ violates one definition rule [-Wodr]
 class exception {
       ^
1.ii:2:7: note: a type with different bases is defined in another translation
unit
 class exception {};
       ^
1.ii:3:7: warning: type ‘struct runtime_error’ violates one definition rule
[-Wodr]
 class runtime_error : exception {
       ^
2.ii:5:7: note: a type with different virtual table pointers is defined in
another translation unit
 class runtime_error : exception {
       ^
lto1: internal compiler error: in add_type_duplicate, at ipa-devirt.c:1575
0x77c43c add_type_duplicate
    ../../gcc/ipa-devirt.c:1573
0x77c43c get_odr_type(tree_node*, bool)
    ../../gcc/ipa-devirt.c:1772
0x77d25c register_odr_type(tree_node*)
    ../../gcc/ipa-devirt.c:1848
0x5b43d6 lto_read_decls
    ../../gcc/lto/lto.c:1946
0x5b4d7b lto_file_finalize
    ../../gcc/lto/lto.c:2236
0x5b4d7b lto_create_files_from_ids
    ../../gcc/lto/lto.c:2246
0x5b4d7b lto_file_read
    ../../gcc/lto/lto.c:2287
0x5b4d7b read_cgraph_and_symbols
    ../../gcc/lto/lto.c:2992
0x5b4d7b lto_main()
    ../../gcc/lto/lto.c:3462


Thanks,
Martin
>From gcc-bugs-return-480931-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Mar 20 09:58:51 2015
Return-Path: <gcc-bugs-return-480931-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 10000 invoked by alias); 20 Mar 2015 09:58:51 -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 9941 invoked by uid 48); 20 Mar 2015 09:58:47 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/65486] ICE: in type_natural_mode, at config/i386/i386.c:6646
Date: Fri, 20 Mar 2015 10:11: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: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub 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-65486-4-MACpGKK4EI@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65486-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65486-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/msg02075.txt.bz2
Content-length: 519

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

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

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Note long double vectors are never beneficial, there is no HW support for them,
so while the testcase is valid, using it is always a bad idea.

[Bug lto/65475] [5 Regression] ICE in odr_vtable_hasher::equal (Segmentation fault)

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
   Target Milestone|---                         |5.0

[Bug lto/65475] [5 Regression] ICE in odr_vtable_hasher::equal (Segmentation fault)

[hubicka at ucw dot cz]

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

--- Comment #5 from Jan Hubicka <hubicka at ucw dot cz> ---
Hmm, yeah, in one unit base is virutal and in other it is not.  Perhaps just
dropping
that sanity check or restricting it to non-odr-violation-reported....

Honza

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65475
> 
> --- Comment #4 from Martin Liška <marxin at gcc dot gnu.org> ---
> Unfortunately, there is another problem with applied patch:
> 
> $ cat 1.ii
> namespace std {
> class exception {};
> class runtime_error : exception {
>   virtual char m_fn1();
> } a;
> }
> 
> $ cat 2.ii
> namespace std {
> class exception {
>   virtual char m_fn1();
> };
> class runtime_error : exception {
> } a;
> }
> 
> $ g++ 1.ii 2.ii -flto -O1
> /home/marxin/Programming/bin/gcc/bin/ld: error: /tmp/cc7v39VO.o: multiple
> definition of 'std::a'
> /home/marxin/Programming/bin/gcc/bin/ld: /tmp/ccJ8pPM4.o: previous definition
> here
> 2.ii:2:7: warning: type ???struct exception??? violates one definition rule [-Wodr]
>  class exception {
>        ^
> 1.ii:2:7: note: a type with different virtual table pointers is defined in
> another translation unit
>  class exception {};
>        ^
> 2.ii:2:7: warning: type ???struct exception??? violates one definition rule [-Wodr]
>  class exception {
>        ^
> 1.ii:2:7: note: a type with different bases is defined in another translation
> unit
>  class exception {};
>        ^
> 1.ii:3:7: warning: type ???struct runtime_error??? violates one definition rule
> [-Wodr]
>  class runtime_error : exception {
>        ^
> 2.ii:5:7: note: a type with different virtual table pointers is defined in
> another translation unit
>  class runtime_error : exception {
>        ^
> lto1: internal compiler error: in add_type_duplicate, at ipa-devirt.c:1575
> 0x77c43c add_type_duplicate
>     ../../gcc/ipa-devirt.c:1573
> 0x77c43c get_odr_type(tree_node*, bool)
>     ../../gcc/ipa-devirt.c:1772
> 0x77d25c register_odr_type(tree_node*)
>     ../../gcc/ipa-devirt.c:1848
> 0x5b43d6 lto_read_decls
>     ../../gcc/lto/lto.c:1946
> 0x5b4d7b lto_file_finalize
>     ../../gcc/lto/lto.c:2236
> 0x5b4d7b lto_create_files_from_ids
>     ../../gcc/lto/lto.c:2246
> 0x5b4d7b lto_file_read
>     ../../gcc/lto/lto.c:2287
> 0x5b4d7b read_cgraph_and_symbols
>     ../../gcc/lto/lto.c:2992
> 0x5b4d7b lto_main()
>     ../../gcc/lto/lto.c:3462
> 
> 
> Thanks,
> Martin
> 
> -- 
> You are receiving this mail because:
> You are on the CC list for the bug.
> You are the assignee for the bug.
>From gcc-bugs-return-481013-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Mar 20 18:15:04 2015
Return-Path: <gcc-bugs-return-481013-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 1229 invoked by alias); 20 Mar 2015 18:15:03 -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 1097 invoked by uid 55); 20 Mar 2015 18:14:58 -0000
From: "hubicka at ucw dot cz" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/65492] Bad optimization in -O3 due to if-conversion and/or unrolling
Date: Fri, 20 Mar 2015 19:11:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hubicka at ucw dot cz
X-Bugzilla-Status: NEW
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:
Message-ID: <bug-65492-4-T64EnF9WZV@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65492-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65492-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/msg02157.txt.bz2
Content-length: 1013

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

--- Comment #7 from Jan Hubicka <hubicka at ucw dot cz> ---
> https://gcc.gnu.org/bugzilla/show_bug.cgi?ide492
>
> Richard Biener <rguenth at gcc dot gnu.org> changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |hubicka at gcc dot gnu.org
>
> --- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
> --param max-peel-branches default of 32 seems to be quite high.  For this
> loop we have two branches on the hot path and 4 times unrolling.
>
> Honza - how did you arrive at the default of 32?  Shouldn't that depend
> on the number of other stmts thus rather look at branch density?

In https://gcc.gnu.org/ml/gcc-patches/2012-10/msg02716.html I claim value
around 32 is needed for apply. (not that I would recall that)

I do not have really strong opinion concerning the branch density.

Honza

[Bug lto/65475] [5 Regression] ICE in odr_vtable_hasher::equal (Segmentation fault)

[hubicka at gcc dot gnu.org]

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

--- Comment #6 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Author: hubicka
Date: Fri Mar 20 18:19:18 2015
New Revision: 221542

URL: https://gcc.gnu.org/viewcvs?rev=221542&root=gcc&view=rev
Log:

    PR ipa/65475
    * ipa-devirt.c (add_type_duplicate): Prevail polymorphic type over
    non-polymorphic
    * g++.dg/lto/pr65475_0.C: New testcase.
    * g++.dg/lto/pr65475_1.C: New testcase.

Added:
    trunk/gcc/testsuite/g++.dg/lto/pr65475_0.C
    trunk/gcc/testsuite/g++.dg/lto/pr65475_1.C
Modified:
    trunk/gcc/ipa-devirt.c
    trunk/gcc/testsuite/ChangeLog

[Bug lto/65475] [5 Regression] ICE in odr_vtable_hasher::equal (Segmentation fault)

[hubicka at gcc dot gnu.org]

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

--- Comment #7 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
The ICE is now fixed. I will leave this open to fix the duplicated ODR warnings
(we probably only want to warn once per type). 

Martin, can you commit the testcase?

[Bug lto/65475] [5 Regression] ICE in odr_vtable_hasher::equal (Segmentation fault)

[hubicka at gcc dot gnu.org]

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

--- Comment #8 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Author: hubicka
Date: Mon Mar 23 00:17:07 2015
New Revision: 221582

URL: https://gcc.gnu.org/viewcvs?rev=221582&root=gcc&view=rev
Log:

    PR ipa/65475
    * ipa-devirt.c: Include demangle.h
    (odr_type_d): Add field rtti_broken.
    (odr_subtypes_equivalent_p): Do not require name to match.
    (compare_virtual_tables): Fix typo; if type already has ODR violation,
    bypass the tests; be ready for function referneces in vtables that are
    not DECL_VIRTUAL; make warnings to be OPT_Wodr.
    (warn_odr): Give up for nameless types.
    (warn_types_mismatch): Report mismatch in mangled names;
    report mismatch in anonymous namespaces; look into component types to
    give useful error; report when mismatch is dragged in from other ODR
    type.
    (odr_types_equivalent_p): Match types for being polymorphic; avoid
    duplicated diagnostics.
    (add_type_duplicate): Reorder checks so more informative ones come
    first; fix typo; do not output "the extra base is defined here" when
    we did not warn.
    (BINFO_N_BASE_BINFOS): Relax sanity check.
    * g++.dg/lto/pr65475b_0.C: New testcase.
    * g++.dg/lto/pr65475b_1.C: New testcase.
    * g++.dg/lto/pr65475c_0.C: New testcase.
    * g++.dg/lto/pr65475c_1.C: New testcase.

Added:
    trunk/gcc/testsuite/g++.dg/lto/pr65475b_0.C
    trunk/gcc/testsuite/g++.dg/lto/pr65475b_1.C
    trunk/gcc/testsuite/g++.dg/lto/pr65475c_0.C
    trunk/gcc/testsuite/g++.dg/lto/pr65475c_1.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ipa-devirt.c
    trunk/gcc/testsuite/ChangeLog

[Bug lto/65475] [5 Regression] ICE in odr_vtable_hasher::equal (Segmentation fault)

[hubicka at gcc dot gnu.org]

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

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

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

--- Comment #9 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
Fixed.

[Bug lto/65475] [5 Regression] ICE in odr_vtable_hasher::equal (Segmentation fault)

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Mon Mar 23 19:51:51 2015
New Revision: 221605

URL: https://gcc.gnu.org/viewcvs?rev=221605&root=gcc&view=rev
Log:
    PR ipa/65475
    * g++.dg/lto/pr65475_0.C: Use dg-lto-options instead of
    dg-options.
    * g++.dg/lto/pr65475b_0.C: Likewise.

Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/g++.dg/lto/pr65475_0.C
    trunk/gcc/testsuite/g++.dg/lto/pr65475b_0.C