public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "marxin at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug lto/65475] New: [5 Regression] ICE in odr_vtable_hasher::equal (Segmentation fault)
Date: Thu, 19 Mar 2015 19:44:00 -0000 [thread overview]
Message-ID: <bug-65475-4@http.gcc.gnu.org/bugzilla/> (raw)
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.
next reply other threads:[~2015-03-19 19:15 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-19 19:44 marxin at gcc dot gnu.org [this message]
2015-03-19 19:59 ` [Bug lto/65475] " marxin at gcc dot gnu.org
2015-03-19 22:21 ` hubicka at gcc dot gnu.org
2015-03-20 8:29 ` hubicka at gcc dot gnu.org
2015-03-20 10:07 ` marxin at gcc dot gnu.org
2015-03-20 10:58 ` rguenth at gcc dot gnu.org
2015-03-20 19:11 ` hubicka at ucw dot cz
2015-03-20 19:12 ` hubicka at gcc dot gnu.org
2015-03-20 21:41 ` hubicka at gcc dot gnu.org
2015-03-23 2:19 ` hubicka at gcc dot gnu.org
2015-03-23 3:01 ` hubicka at gcc dot gnu.org
2015-03-23 21:07 ` jakub at gcc dot gnu.org
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bug-65475-4@http.gcc.gnu.org/bugzilla/ \
--to=gcc-bugzilla@gcc.gnu.org \
--cc=gcc-bugs@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).