From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugs-return-480865-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 36102 invoked by alias); 19 Mar 2015 19:21:14 -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
Received: (qmail 35932 invoked by uid 48); 19 Mar 2015 19:21:09 -0000
From: "marxin at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/65475] [5 Regression] ICE in odr_vtable_hasher::equal (Segmentation fault)
Date: Thu, 19 Mar 2015 19:59:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: lto
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: marxin at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: hubicka at ucw dot cz
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65475-4-1ucUFlufLX@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65475-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65475-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-03/txt/msg02009.txt.bz2

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

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

585      t2 =3D TYPE_MAIN_VARIANT (t2);
586      if (t1 =3D=3D t2)
587        return true;
588      tree v1 =3D BINFO_VTABLE (TYPE_BINFO (t1));
589      tree v2 =3D 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             =3D=3D DECL_ASSEMBLER_NAME


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

(gdb) p t2->type_non_common.binfo->binfo.vtable
$5 =3D (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 0x7ffff6e2bc7=
8>
                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 fail=
ure>
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 addressab=
le
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 B=
LK
size <integer_cst 0x7ffff6c36bb8 64> unit size <integer_cst 0x7ffff6c36bd0 =
8>
            align 64 symtab 0 alias set -1 canonical type 0x7ffff6e2e9d8 fi=
elds
<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 0x7ffff6e29=
130
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?id=65470

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