[Bug c++/58207] New: ICE in sort_constexpr_mem_initializers due to out of bounds vector access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58207
Bug ID: 58207
Summary: ICE in sort_constexpr_mem_initializers due to out of
bounds vector access
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tsaunders at mozilla dot com
Created attachment 30680
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30680&action=edit
preprocessed and somewhat reduced test case
The attached test case causes an ICE after errors with xg++ (GCC) 4.9.0
20130817 (experimental) as well as with g++ 4.8.0 but not with g++ 4.7.2
#0 diagnostic_report_diagnostic (context=0x1823300
, diagnostic=diagnostic@entry=0x7fffda00) at
../../gcc/gcc/diagnostic.c:757
location = 3464477
orig_diag_kind = DK_ICE
saved_format_spec =
#1 0x00ffbf80 in internal_error (gmsgid=gmsgid@entry=0x13e2d6b "in %s,
at %s:%d") at ../../gcc/gcc/diagnostic.c:1127
diagnostic = {message = {format_spec = 0x13e2d6b "in %s, at %s:%d",
args_ptr = 0x7fffd9e8, err_no = 2, locus = 0x76974093
<__GI___libc_malloc+99>, x_data = 0x0}, location = 3464477, override_column =
0,
x_data = 0x0, kind = DK_ICE, option_index = 0}
ap = {{gp_offset = 8, fp_offset = 48, overflow_arg_area =
0x7fffdb00, reg_save_area = 0x7fffda40}}
__FUNCTION__ = "internal_error"
#2 0x00ffa7f4 in fancy_abort (file=file@entry=0x109f4c0
"../../gcc/gcc/vec.h", line=line@entry=827, function=function@entry=0x10cf8a0
<_ZZN3vecI17constructor_elt_d5va_gc8vl_embedEixEjE12__FUNCTION__> "operator[]")
at ../../gcc/gcc/diagnostic.c:1181
No locals.
#3 0x006be2b8 in vec::operator[]
(ix=0, this=) at ../../gcc/gcc/vec.h:827
No locals.
#4 0x006d6427 in operator[] (ix=, this=)
at ../../gcc/gcc/tree.h:4111
No locals.
#5 build_constexpr_constructor_member_initializers (body=,
type=0x75337bd0) at ../../gcc/gcc/cp/semantics.c:6207
vec = 0x75376e58
ok =
#6 massage_constexpr_body (fun=fun@entry=0x753c5300,
body=body@entry=0x753bbb10) at ../../gcc/gcc/cp/semantics.c:6280
__FUNCTION__ = "massage_constexpr_body"
#7 0x006ddbb4 in register_constexpr_fundef
(fun=fun@entry=0x753c5300, body=0x753bbb10) at
../../gcc/gcc/cp/semantics.c:6384
entry = {decl = 0x753c5300, body = 0x2}
slot =
__FUNCTION__ = "register_constexpr_fundef"
#8 0x0057c058 in maybe_save_function_definition (fun=)
at ../../gcc/gcc/cp/decl.c:13761
No locals.
#9 finish_function (flags=flags@entry=3) at ../../gcc/gcc/cp/decl.c:13882
fndecl = 0x753c5300
fntype = 0x753c6000
ctype = 0x0
__FUNCTION__ = "finish_function"
inclass_inline = 1
#10 0x006643be in cp_parser_function_definition_after_declarator
(parser=parser@entry=0x768d40b0, inline_p=inline_p@entry=true) at
../../gcc/gcc/cp/parser.c:22275
fn =
ctor_initializer_p = true
saved_in_unbraced_linkage_specification_p = false
saved_in_function_body = false
saved_num_template_parameter_lists = 0
#11 0x0064a09d in cp_parser_late_parsing_for_member
(member_function=, parser=0x768d40b0) at
../../gcc/gcc/cp/parser.c:22921
function_scope = 0x0
tokens = 0x7538cbc0
#12 cp_parser_class_specifier_1 (parser=parser@entry=0x768d40b0) at
../../gcc/gcc/cp/parser.c:19014
decl =
pushed_scope =
e =
class_type =
ix = 3
nested_name_specifier_p =
saved_num_template_parameter_lists =
saved_in_function_body =
saved_in_unbraced_linkage_specification_p =
scope =
type =
in_switch_statement_p =
__FUNCTION__ = "cp_parser_class_specifier_1"
attributes =
in_statement =
old_scope =
closing_brace =
#13 0x0064c211 in cp_parser_class_specifier (parser=0x768d40b0) at
../../gcc/gcc/cp/parser.c:19038
ret =
#14 cp_parser_type_specifier (parser=parser@entry=0x768d40b0,
flags=flags@entry=1, decl_specs=decl_specs@entry=0x7fffdf00,
is_declaration=is_declaration@entry=true,
declares_class_or_enum=declares_class_or_enum@entry=0x7fffde7c,
is_cv_qualifier=is_cv_qualifier@entry=0x7fffde7b) at
../../gcc/gcc/cp/parser.c:14040
type_spec = 0x0
keyword =
ds = ds_last
#15 0x006616ca in cp_parser_decl_specifier_seq
(parser=parser@entry=0x768d40b0, flags=flags@entry=1,
decl_specs=decl_specs@entry=0x7fffdf00,
declares_class_or_enum=declares_class_or_enum@entry=0x7fffdefc)
at ../../gcc/gcc/cp/parser.c:11283
decl_spec_declares_class_or_enum
[Bug c++/58575] New: gcc should compile firefox code faster.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58575 Bug ID: 58575 Summary: gcc should compile firefox code faster. Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tsaunders at mozilla dot com CC: hubicka at ucw dot cz Its ceretainly possible given https://blog.mozilla.org/nnethercote/2013/09/12/bleg-for-a-new-machine-2/ (I'm not sure what versions njn is using but probably doesn't matter too much). I rofiled build a build of content/ in the firefox tree for a --enable-optimize --disable-debug build you can see the data I gathered at http://people.mozilla.org/~tsaunders/gcc-perf.data . The two things that came up high in profiles were C++ parsing stuff and memory allocation. I suppose there isn't too much to be done about the memory allocation issue in the short term, but I wonder if there's changes to the parser that would help at least some.
[Bug c++/58868] [4.9 Regression] ICE: in count_type_elements, at expr.c:5495 with -std=gnu++0x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58868
Trevor Saunders changed:
What|Removed |Added
CC||tsaunders at mozilla dot com
--- Comment #4 from Trevor Saunders ---
> enum ID {
> PLACES
> };
>
> struct Histograms {
> const ID foo;
the enum isn't actually needed, I can reproduce with
static struct {
const int type;
} const cnvNameType[] = {
{ 1 }
};
> Fairly recent, comes from building firefox aurora with gcc trunk
to be pedantic it is in icu, and presumably if you just build that you get this
crash too.
[Bug c++/61482] ICE when compiling Firefox ESR 24 with r211488
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61482 Trevor Saunders changed: What|Removed |Added CC||tsaunders at mozilla dot com --- Comment #2 from Trevor Saunders --- (In reply to Richard Biener from comment #1) > Please provide preprocessed source. I've been seeing this, and trying to reduce it. Hopefully that'll finish soon, but the reducers don't like this source much :/
[Bug c++/61482] ICE when compiling Firefox ESR 24 with r211488
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61482 --- Comment #3 from Trevor Saunders --- Created attachment 32938 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=32938&action=edit test case Its pretty close to undreadable, but its fairly reduced, it started at ~400k lines.
[Bug c++/61482] ICE when compiling Firefox ESR 24 with r211488
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61482 --- Comment #5 from Trevor Saunders --- > Could you please post the full gcc invocation? Err yeah that would be useful ;) gcc -flto -r -Os -nostdlib -std=gnu++11 start.ii
[Bug bootstrap/61598] [4.10 regression] fold-const.c:14755:37: error: no matching function for call to 'hash_table >::find_slot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61598 Trevor Saunders changed: What|Removed |Added CC||tsaunders at mozilla dot com --- Comment #2 from Trevor Saunders --- So we went from find_slot taking a const uninon tree_node *& to taking a union tree_node * const& I tend to think that the later is more "correct" since the type of thing in the hash table and hence the thing that is const is a union tree_node *. Further the result of find_slot is a tree_node ** which is not const. So I think the appropriate solution is to just const_cast to tree, but a sanity check of that would be nice.
[Bug middle-end/63621] [5 Regression] ICE: error: Both section and comdat group is set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63621 --- Comment #6 from Trevor Saunders --- On Mon, Nov 24, 2014 at 03:32:37PM +, trippels at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63621 > > --- Comment #5 from Markus Trippelsdorf --- > (In reply to tbsaunde from comment #3) > > r217991 seems to work > > Not for me. yeah, I should copy paste better, sorry
[Bug ipa/60154] ICE: in cgraph_function_node at gcc/cgraph.c:2962
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60154 Trevor Saunders changed: What|Removed |Added CC||tsaunders at mozilla dot com --- Comment #1 from Trevor Saunders --- This doesn't ICE for me though it has a zillion errors. Can you still reproduce?
[Bug bootstrap/61631] [4.10 regression] ICE unwind-dw2.c:1639:5: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61631 --- Comment #2 from Trevor Saunders --- > r211936 PASS > [r211937..r211985) not build with --enable-checking=fold due PR61598 > r211985 FAIL I think if you apply r211985 directly on top of r211937 you'll find that bootstraps, so presumably some patch after mine broke it in the mean time. Trev
[Bug bootstrap/61679] build fails with G++ 4.5.1 - prototype for hash_table does not match any in class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61679
--- Comment #1 from Trevor Saunders ---
The following patch compiles with 4.9 for me, but I don't have easy
access to a machine with 4.5 on it, would you mind testing if it works
for you?
diff --git a/gcc/hash-table.h b/gcc/hash-table.h
index 22af12f..2356f8d 100644
--- a/gcc/hash-table.h
+++ b/gcc/hash-table.h
@@ -663,7 +663,7 @@ hash_table::~hash_table ()
HASH is the hash value for the element to be inserted. */
template class Allocator>
-typename Descriptor::value_type **
+typename hash_table::value_type **
hash_table
::find_empty_slot_for_expand (hashval_t hash)
{
@@ -803,7 +803,7 @@ hash_table::clear_slot
(value_type **slot)
be used to insert or delete an element. */
template class Allocator>
-typename Descriptor::value_type *
+typename hash_table::value_type *
hash_table
::find_with_hash (const compare_type *comparable, hashval_t hash)
{
[Bug bootstrap/61679] build fails with G++ 4.5.1 - prototype for hash_table does not match any in class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61679 --- Comment #3 from Trevor Saunders --- > (In reply to Trevor Saunders from comment #1) > > The following patch compiles with 4.9 for me, but I don't have easy > > access to a machine with 4.5 on it, would you mind testing if it works > > for you? > > Applied the patch to r212302 (2014-07-04), however, still seeing compilation > failure: Well, you didn't mention those errors in the original description, so I didn't try and fix them. Is the below list complete? I'd expect to see errors for the partial specialization for true as well. > /a/gcc-4.5.1/bld/rls/bin/g++ -c -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND > -DIN_GCC_FRONTEND -O0 -g3 -DIN_GCC-fno-exceptions -fno-rtti > -fasynchronous-unwind-tables -W -Wall -Wwrite-strings -Wcast-qual > -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long > -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. > -I. -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc > -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/. > -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/../include > -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/../libcpp/include > -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/../libdecnumber > -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/../libdecnumber/bid > -I../libdecnumber -I/eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/../libbacktrace > > -o attribs.o -MT attribs.o -MMD -MP -MF ./.deps/attribs.TPo > /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/attribs.c > In file included from /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/attribs.c:35:0: > /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/hash-table.h:845:1: error: prototype > for ‘typename Descriptor::value_type** hash_table false>::find_slot_with_hash(hash_table false>::compare_type*, hashval_t, insert_option)’ does not match any in class > ‘hash_table’ > /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/hash-table.h:542:16: error: candidate > is: hash_table::value_type** > hash_table false>::find_slot_with_hash(hash_table false>::compare_type*, hashval_t, insert_option) You can probably fix this one in the same way as the previous ones. > /eng/upc/dev/gary/gupc-gcc-trunk/src/gcc/hash-table.h:927:1: error: prototype > for ‘void hash_table false>::traverse_noresize(Argument)’ does not match any in class > ‘hash_table’ > [...] maybe the same sort of thing will work for this one too, but its hard to know when the messages are cut off. Trev
[Bug bootstrap/61679] build fails with G++ 4.5.1 - prototype for hash_table does not match any in class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61679 --- Comment #6 from Trevor Saunders --- > --- Comment #4 from Gary Funck --- > Created attachment 33076 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33076&action=edit > make log after trying patch thanks! I think the attached patch should fix all of those issues, would you mind testing it? Trev
[Bug pch/63229] [5.0 Regression] FAIL: ./except-1.h -O0 (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63229 --- Comment #3 from Trevor Saunders --- > --- Comment #2 from Dominique d'Humieres --- > Likely r214834. I bet its the same as http://gcc.gnu.org/ml/gcc-patches/2014-09/msg00730.html which I'll commit the fix for as soon as it finishes testing. Trev
