[Bug lto/65536] LTO line number information garbled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536 --- Comment #26 from Jan Hubicka hubicka at ucw dot cz --- this is a proof of concept patch that makes streamer in to collect locations into a cache and apply them in sorted order (looking up correct max_column hints) at the end of handling of a given section. It also has facility to throw away locations of trees that are freed. while sorting at stream in time is not cool, it does not show top in the profiles and memory use of the cache is actually dominated by other stuff we read, so this seems to work quite well in practice. Main problem would be if someone copied/used the locator before cache is applied. This helps to get all lines and most of carrets right on firefox. I killed my Chromium tree so can't test it there (Martin, perhaps you could try?) I did not have much time today to test the patch. It also saves quite a lot of memory, about 400MB on firefox I guess. Honza
[Bug bootstrap/65537] [5 Regression] --with-build-config=bootstrap-lto fails on CentOS 5.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65537 Uroš Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-03-25 Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com Ever confirmed|0 |1 --- Comment #7 from Uroš Bizjak ubizjak at gmail dot com --- Patch at [1]. [1] https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01255.html
[Bug ipa/65478] [5 regression] crafty performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-25 Ever confirmed|0 |1 --- Comment #10 from Jan Hubicka hubicka at gcc dot gnu.org --- Maritn, also note that at that time tere was bug in inliner fixed by:2015-03-20 Jan Hubicka hubi...@ucw.cz * ipa-inline.c (can_inline_edge_p): Short circuit if inline_failed already is final. (ipa_inline): Recompute inline_failed codes. * cif-code.def (FUNCTION_NOT_OPTIMIZED, REDEFINED_EXTERN_INLINE, USES_COMDAT_LOCAL, ATTRIBUTE_MISMATCH, UNREACHABLE): Declare as CIF_FINAL_ERROR. so it would be useful to try if the regression still exists on trunk. With the patch our SPEC testers reports improvement http://gcc.opensuse.org/SPEC/CINT/sb-frescobaldi.suse.de-ai-64/186_crafty_recent_big.png While Igor reports even anoter regression on Intel based machine (and slightly different flags)
[Bug ipa/65478] [5 regression] crafty performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65478 --- Comment #9 from Jan Hubicka hubicka at ucw dot cz --- This suggests that cloning of function Search and not inlining NextMove is only part of the story. I'm attaching output of my script that compares inlining decisions. File 1 is wpa inlining dump file generated by r219862, File 2 is wpa inlining dump generated by r219863 on source where Search was annotated as noclone. Thanks. I suppose we need to oprofile resulting binary and see. (In reply to Jan Hubicka from comment #7) Yep, that sounds like resonable thing to try to me. OK, I'll prepare a patch for this part. Actually, there is one detail. Cloning SCC and keeping it a SCC is cool thing (as one avoid passing constant parameter across the recursive loop), but clonning function from SCC and keeping all calls within the connected component to go to the original SCC is not cool. It would be nice to make difference between these. Thanks! Honza
[Bug c++/65457] ICE in libgfortran/ieee/ieee_arithmetic.F90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65457 Bernd Edlinger bernd.edlinger at hotmail dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Bernd Edlinger bernd.edlinger at hotmail dot de --- no longer happens with current snapshot.
[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076 --- Comment #16 from Jan Hubicka hubicka at gcc dot gnu.org --- The chkp stuff is IMO bit problematic. I was thinking about cutting the optimization queue but was always hesitant to do so because of the cache locality and other implications. I am not sure if that was considered with chkp approach and if the split is really needed. Not something to track for GCC 5 though. The slowdown http://gcc.opensuse.org/c++bench-frescobaldi/tramp3d/split-build.html is quite gradual, while the code size jump http://gcc.opensuse.org/c++bench-frescobaldi/tramp3d/ happened at one point. I looked once into the code size with Jakub and part of that seems to be due to unwind info no longer using cfi directives at older gases. Part is the new heuristics. I am still hopping to understand better the code size part. To get performance back we however probalby look for several little factors contributing to the slowdown.
[Bug lto/65536] LTO line number information garbled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536 --- Comment #27 from Jan Hubicka hubicka at ucw dot cz --- I have in fact considered it already, since I think it should be fairly easy and it can be done incrementally. However, as always in GCC, things are never as trivial as they seem. I just tried following https://gcc.gnu.org/wiki/DebuggingGCC#Debugging_LTO to see what dump_line_table_statistics reports before and after my patch above, but it doesn't print the lto1 invokation. The debugx scripts (https://gcc.gnu.org/ml/gcc/2004-03/msg01195.html) do not seem to work with lto1 (why those scripts are not in contrib/?). I feel like a new contributor again! :) I simply use --save-temps --verbose and use lto1 invocation from there. It is easy ;) Having direct way to invoke lto1 in gdb from gcc wrapper or script may come handy, but it is not that hard to do by hand. Honza
[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076 --- Comment #17 from Jan Hubicka hubicka at ucw dot cz --- Even though the inline decisions does not seem to be changed considerably (at least on tramp3d). Yeah, clobbers don't account for anything for size/inline estimates (well, I hope so!). Yep, they are ignored. And yes, doing DSE early is quite an old idea... we should revisit it next stage1. I also run into it several time. We should not forget this time ;) Honza
[Bug c++/65498] [5 Regression] ICE in cxx_eval_call_expression when using __func__ inside dependent context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65498 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Marek Polacek mpolacek at gcc dot gnu.org --- So fixed (tried both snippets in comment 3).
[Bug middle-end/65519] [5 regression] unable to coalesce ssa_names 2 and 87 which are marked as MUST COALESCE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65519 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|ASSIGNED|RESOLVED Component|tree-optimization |middle-end Resolution|--- |FIXED --- Comment #17 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug middle-end/65519] [5 regression] unable to coalesce ssa_names 2 and 87 which are marked as MUST COALESCE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65519 --- Comment #18 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Mar 25 08:46:20 2015 New Revision: 221654 URL: https://gcc.gnu.org/viewcvs?rev=221654root=gccview=rev Log: 2015-03-25 Richard Biener rguent...@suse.de PR middle-end/65519 * genmatch.c (expr::gen_transform): Re-write to avoid using gimple_build. * gnat.dg/specs/opt2.ads: New testcase. Added: trunk/gcc/testsuite/gnat.dg/specs/opt2.ads Modified: trunk/gcc/ChangeLog trunk/gcc/genmatch.c trunk/gcc/testsuite/ChangeLog
[Bug testsuite/63256] [5 regression] FAIL: gcc.dg/sms-8.c scan-rtl-dump-times sms SMS succeeded 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63256 Segher Boessenkool segher at gcc dot gnu.org changed: What|Removed |Added CC||ma...@linux-mips.org --- Comment #5 from Segher Boessenkool segher at gcc dot gnu.org --- *** Bug 62028 has been marked as a duplicate of this bug. ***
[Bug testsuite/62028] Power64/Linux: FAIL: gcc.dg/sms-8.c scan-rtl-dump-times sms SMS succeeded 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62028 Segher Boessenkool segher at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Segher Boessenkool segher at gcc dot gnu.org --- Dup of 63256, which has more info. *** This bug has been marked as a duplicate of bug 63256 ***
[Bug lto/65536] LTO line number information garbled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536 --- Comment #29 from Martin Liška marxin at gcc dot gnu.org --- Created attachment 35131 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35131action=edit Chrome: ODR warnings before
[Bug lto/65536] LTO line number information garbled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536 --- Comment #30 from Martin Liška marxin at gcc dot gnu.org --- Created attachment 35132 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35132action=edit Chrome: ODR warnings with patch from #c21
[Bug fortran/63230] allocation of deferred length character as derived type component causes internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63230 vehre at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from vehre at gcc dot gnu.org --- Fixed with commit r221621.
[Bug lto/65536] LTO line number information garbled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536 --- Comment #28 from Martin Liška marxin at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #26) Created attachment 35130 [details] linemap this is a proof of concept patch that makes streamer in to collect locations into a cache and apply them in sorted order (looking up correct max_column hints) at the end of handling of a given section. It also has facility to throw away locations of trees that are freed. while sorting at stream in time is not cool, it does not show top in the profiles and memory use of the cache is actually dominated by other stuff we read, so this seems to work quite well in practice. Main problem would be if someone copied/used the locator before cache is applied. This helps to get all lines and most of carrets right on firefox. I killed my Chromium tree so can't test it there (Martin, perhaps you could try?) Sure. Unfortunately, there's still ICE, which is caused by a function body load that happens in IPA ICF: In function ‘Create’: lto1: internal compiler error: Segmentation fault 0x9037df crash_signal ../../gcc/toplev.c:383 0xed909c new_linemap ../../libcpp/line-map.c:265 0xed9467 linemap_add(line_maps*, lc_reason, unsigned int, char const*, unsigned int) ../../libcpp/line-map.c:314 0xed98d0 linemap_line_start(line_maps*, unsigned int, unsigned int) ../../libcpp/line-map.c:566 0xa8b190 unpack_ts_block_value_fields ../../gcc/tree-streamer-in.c:414 0xa8b190 streamer_read_tree_bitfields(lto_input_block*, data_in*, tree_node*) ../../gcc/tree-streamer-in.c:538 0x80a791 lto_read_tree_1 ../../gcc/lto-streamer-in.c:1197 0x80ab04 lto_read_tree ../../gcc/lto-streamer-in.c:1234 0x80ab04 lto_input_tree_1(lto_input_block*, data_in*, LTO_tags, unsigned int) ../../gcc/lto-streamer-in.c:1353 0x80ae01 lto_input_scc(lto_input_block*, data_in*, unsigned int*, unsigned int*) ../../gcc/lto-streamer-in.c:1258 0x80ae64 lto_input_tree(lto_input_block*, data_in*) ../../gcc/lto-streamer-in.c:1368 0xe26ff1 input_gimple_stmt ../../gcc/gimple-streamer-in.c:186 0xe26ff1 input_bb(lto_input_block*, LTO_tags, data_in*, function*, int) ../../gcc/gimple-streamer-in.c:303 0x80c457 input_function ../../gcc/lto-streamer-in.c:992 0x80c457 lto_read_body_or_constructor ../../gcc/lto-streamer-in.c:1129 0x614d5d cgraph_node::get_untransformed_body() ../../gcc/cgraph.c:3225 0xe6e580 ipa_icf::sem_function::init() ../../gcc/ipa-icf.c:1167 0xe6b730 ipa_icf::sem_item_optimizer::parse_nonsingleton_classes() ../../gcc/ipa-icf.c:2617 0xe72b9a ipa_icf::sem_item_optimizer::execute() ../../gcc/ipa-icf.c:2419 0xe74386 ipa_icf_driver ../../gcc/ipa-icf.c:3304 I also attach ODR warnings before and after the patch. Diff I did not have much time today to test the patch. It also saves quite a lot of memory, about 400MB on firefox I guess. Honza
[Bug target/61051] Duplicated instructions in both conditional branches
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61051 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-03-25 Ever confirmed|0 |1 --- Comment #2 from Steven Bosscher steven at gcc dot gnu.org --- This is code hoisting. That's not performed at -O2. Try -Os.
[Bug c/65452] strcmp (foo, foo) could give a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65452 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-25 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076 --- Comment #18 from rguenther at suse dot de rguenther at suse dot de --- On Wed, 25 Mar 2015, hubicka at ucw dot cz wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076 --- Comment #17 from Jan Hubicka hubicka at ucw dot cz --- Even though the inline decisions does not seem to be changed considerably (at least on tramp3d). Yeah, clobbers don't account for anything for size/inline estimates (well, I hope so!). Yep, they are ignored. Btw, and we indeed generate more clobbers with GCC 5: grep CLOBBER a/tramp3d-v4.ii.015t.ssa | wc -l 8937 grep CLOBBER b/tramp3d-v4.ii.018t.ssa | wc -l 12636 which is odd as we now have new code that replaces clobbers with SSA default defs... grep CLOBBER a/tramp3d-v4.ii.010t.eh | wc -l 13012 grep CLOBBER b/tramp3d-v4.ii.010t.eh | wc -l 13012 grep CLOBBER a/tramp3d-v4.ii.011t.cfg | wc -l 12827 grep CLOBBER b/tramp3d-v4.ii.011t.cfg | wc -l 12827 so we manage to drop a lot of them during into-SSA with GCC 4.9 but fail to do that with GCC 5. Which would mean we write less vars into SSA form(?) grep '_[0-9]* =' a/tramp3d-v4.ii.015t.ssa | wc -l 46055 grep '_[0-9]*(D)' a/tramp3d-v4.ii.015t.ssa | wc -l 30839 vs. grep '_[0-9]* =' b/tramp3d-v4.ii.018t.ssa | wc -l 45543 grep '_[0-9]*(D)' b/tramp3d-v4.ii.018t.ssa | wc -l 33782 eventually it might be that in 4.9 local_pure_const runs for a functions callees before we fixup its CFG and write it into SSA form. That might cause a significant cleanup of EH before entering into-SSA for 4.9 (as callees might become nothrow). At least that's now my theory. I wonder if it makes sense to run local + IPA pure-const as we now do IPA into-SSA. So sth like Index: gcc/passes.def === --- gcc/passes.def (revision 221633) +++ gcc/passes.def (working copy) @@ -58,7 +58,9 @@ along with GCC; see the file COPYING3. NEXT_PASS (pass_build_ssa); NEXT_PASS (pass_ubsan); NEXT_PASS (pass_early_warn_uninitialized); + NEXT_PASS (pass_local_pure_const); POP_INSERT_PASSES () + NEXT_PASS (pass_ipa_pure_const); NEXT_PASS (pass_chkp_instrumentation_passes); PUSH_INSERT_PASSES_WITHIN (pass_chkp_instrumentation_passes) (which likely doesn't work exactly like that, of course). Or keep doing local_pure_const only and make sure to process pass_build_ssa_passes in a proper order. Of course the real power of local-pure-const only arrives when done after local optimizations... But I'd say the compile-time effect is clearly going into-SSA before cleaning up EH significantly. And yes, doing DSE early is quite an old idea... we should revisit it next stage1. I also run into it several time. We should not forget this time ;) ;)
[Bug c/65452] strcmp (foo, foo) could give a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65452 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Target Milestone|--- |6.0
[Bug fortran/65548] [5 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-25 CC||jakub at gcc dot gnu.org Target Milestone|--- |5.0 Summary|[5.0 Regression]|[5 Regression] |gfc_conv_procedure_call |gfc_conv_procedure_call Ever confirmed|0 |1 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r221621.
[Bug c/65471] type interpretation in _Generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65471 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |SUSPENDED Last reconfirmed||2015-03-25 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Suspending until the DR is resolved.
[Bug c++/65509] [5 Regression] [C++11] GCC rejects operator== with two distinct pointers as not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65509 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0 Summary|[C++11] GCC rejects |[5 Regression] [C++11] GCC |operator== with two |rejects operator== with two |distinct pointers as not|distinct pointers as not |constexpr |constexpr
[Bug fortran/65548] [5 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- I'd also appreciate a short workaround. subroutine selector_init (selector, weight) real :: s integer :: n, i logical, dimension(:), allocatable :: mask integer, allocatable :: tmpi(:) real, allocatable :: tmpr(:) s = sum (weight) allocate (mask (size (weight)), source = weight /= 0) n = count (mask) if (n 0) then allocate(tmpi(n),tmpr(n)) tmpi = pack ([(i, i = 1, size (weight))], mask) tmpr = pack (weight / s, mask) allocate (selector%map (n), source = tmpi) allocate (selector%weight (n), source = tmpr) else allocate (selector%map (1), source = 1) allocate (selector%weight (1), source = 0.) end if end subroutine selector_init
[Bug c++/65509] [5 Regression] [C++11] GCC rejects operator== with two distinct pointers as not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65509 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Yeah, it is r218462.
[Bug tree-optimization/64715] [5 Regression] __builtin_object_size (..., 1) fails to locate subobject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715 --- Comment #19 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #14) Or, as discussed on IRC we can consider MEM_REFs where first operand isn't just SSA_NAME or ADDR_EXPR of a decl, but allow also ADDR_EXPR of handled_component_p (with base being a decl or MEM_REF with SSA_NAME first operand). Or add a new tree code, like OFFSETTED_ADDR_EXPR which would be like ADDR_EXPR, but with integer offset address to the ADDR_EXPR. Thinking about this some more we already have the ability to combine _2 = a.b[i].c; _3 = _2 + 8; by using handled-components: ARRAY_REF VIEW_CONVERT_EXPR (__typeof__ (a.b[i].c)[])a.b[i].c, 8 / __sizeof__(a.b[i].c) that is, we could attack this by implementing pointer arithmetic as represented by the frontend in the way it is defined by the C standard (in terms of array indexing). ptr + idx would be lowered as ARRAY_REF VIEW_CONVERT_EXPR (__typeof__ (*ptr) []) *ptr, idx thereby also avoiding the need to apply promotion of idx to sizetype to avoid the possible overflow of the multiplication by sizeof (*ptr). Of course it would be nice to avoid the awkward VIEW_CONVERT_EXPR here, but adding a new kind of handled-component isn't exactly non-intrusive either. Btw, there is an alternative to the array-ref/view-convert-expr form that is less restrictive on the actual 'idx'. We could simply use COMPONENT_REF *ptr, NULL field-decl, explicit-offset though the fact that COMPONENT_REFs have alias analysis effects and that the lowered offset is measured in DECL_OFFSET_ALIGN units of the field-decl makes that non-trivial to support as well. That said, the alternative is to add a new handled-component, say, OFFSET_VIEW_CONVERT_EXPR type, base, offset, that would have the same effect as doing _ptr = base + offset; MEM [_ptr, offset]; thus offset carries type-based alias information and 'type' carries alignment info. Type-based alias analysis would stop at OFFSET_VIEW_CONVERT_EXPR as it stops now at VIEW_CONVERT_EXPRs. Now we could also simply change VIEW_CONVERT_EXPR to take an (optional?) offset parameter. I like all of the above choices more than special-casing an address-only variant for offsets. All of the above enable us to avoid making variable-indexed indirect references addressable like we have to do now because of the restrictions of MEM_REF bases / offsets. The ARRAY_REF variant allows to handle non-constant pointer offsets as well while the offsetted VIEW_CONVERT_EXPR would handle only constant offsets (but allow non-element-size increments and arbitrary effective alias sets on the memory reference). We should already handle the ARRAY_REF VIEW_CONVERT_EXPR ... ... form correctly today, we just don't create it.
[Bug lto/65536] LTO line number information garbled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536 --- Comment #31 from Martin Liška marxin at gcc dot gnu.org --- Beginning of the difference of ODR warnings: 210,211c210,211 gen/blink/core/CSSPropertyNames.cpp:2330:0: warning: type ‘struct stringpool_t’ violates one definition rule [-Wodr] static const short lookup[] = --- gen/blink/core/CSSPropertyNames.cpp:1019:0: warning: type ‘struct stringpool_t’ violates one definition rule [-Wodr] struct stringpool_t 213,214c213,214 gen/blink/core/CSSValueKeywords.cpp:4309:0: note: a different type is defined in another translation unit static const short lookup[] = --- gen/blink/core/CSSValueKeywords.cpp:1850:0: note: a different type is defined in another translation unit struct stringpool_t 216,217c216,217 gen/blink/core/CSSPropertyNames.cpp:2330:0: note: the first difference of corresponding definitions is field ‘stringpool_str0’ static const short lookup[] = --- gen/blink/core/CSSPropertyNames.cpp:1021:0: note: the first difference of corresponding definitions is field ‘stringpool_str0’ char stringpool_str0[sizeof(grid)]; 219,220c219,220 gen/blink/core/CSSValueKeywords.cpp:4309:0: note: a field of same name but different type is defined in another translation unit static const short lookup[] = --- gen/blink/core/CSSValueKeywords.cpp:1852:0: note: a field of same name but different type is defined in another translation unit char stringpool_str0[sizeof(dot)]; 230,232c230,232 ../../../../out/Release/gen/blink/core/XPathGrammar.cpp:241:0: note: a different type is defined in another translation unit ../../../../out/Release/gen/blink/core/CSSGrammar.cpp:557:0: note: the first difference of corresponding definitions is field ‘yyvs_alloc’ ../../../../out/Release/gen/blink/core/XPathGrammar.cpp:241:0: note: a field of same name but different type is defined in another translation unit --- ../../../../out/Release/gen/blink/core/XPathGrammar.cpp:373:0: note: a different type is defined in another translation unit ../../../../out/Release/gen/blink/core/CSSGrammar.cpp:560:0: note: the first difference of corresponding definitions is field ‘yyvs_alloc’ ../../../../out/Release/gen/blink/core/XPathGrammar.cpp:376:0: note: a field of same name but different type is defined in another translation unit ...
[Bug fortran/65548] [5 Regression] gfc_conv_procedure_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548 vehre at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #5 from vehre at gcc dot gnu.org --- The function call is processed w/o a scalarizer, which is quite errorprone. I already have a fix. Now I just have get the other functionality of gfortran back online.
[Bug fortran/55901] [OOP] type is (character(len=*)) misinterpreted as array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55901 vehre at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #16 from vehre at gcc dot gnu.org --- Fixed with commit r221627.
[Bug fortran/64787] Invalid code on sourced allocation of class(*) character string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64787 vehre at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #5 from vehre at gcc dot gnu.org --- Fixed with commit r221621.
[Bug lto/65536] LTO line number information garbled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536 --- Comment #32 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #16) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- The main issue with LTO is that it re-creates a combined linemap but in (most of the time) quite awkward ordering (simply registering random-ordered file:line:column entries by switching files/lines appropriately). I've argued that it would be better to stream those file:line:columns separately so we can sort them before handing them over to libcpp for linemap re-creation. Yep, we discussed this few times. One issue is when we sort them. We can keep track of location as they are streamed out (and directly assign them new IDs in the awkward ordering as they come) and then produce the separate linemap section that would be read at once by WPA, sorted and fed into linemaps. Sorting at compile time is bit tricky as we probably do not want to patch existing pickled tree stream with the new locator IDs in the sorted sequence and we do not really know what locations we will need ahead of time. Well, the idea was to stream another index representing the sorted order so we can sort and merge at WPA in O(n) and re-map the index on stream-in time. I don't think we want to sort at WPA time. Other easier to implement idea for GCC 5 may be to simply collect locaiton info and pointers to trees per SCC component andonly if it survived merging feed it into linemap and in memory patch the new trees. This still should save quite some memory given that most of trees read are discarded by merging and may be quite easy to implement. Martin, the ICE by my patch is caused by libcpp getting out of memory? Btw, we don't have to fix this for GCC 5. We can of course backport a good solution later.
[Bug libstdc++/65543] rvalue stream insertion and extraction operators incorrectly implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65543 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Wed Mar 25 09:57:06 2015 New Revision: 221655 URL: https://gcc.gnu.org/viewcvs?rev=221655root=gccview=rev Log: 2015-03-25 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/65543 * include/std/istream (operator(basic_istream, _Tp): Revert thinko in r150387. * include/std/ostream (operator(basic_ostream, const _Tp): Likewise. * testsuite/27_io/rvalue_streams-2.cc: New. Added: trunk/libstdc++-v3/testsuite/27_io/rvalue_streams-2.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/std/istream trunk/libstdc++-v3/include/std/ostream
[Bug lto/65515] [5 Regression] FAIL: gcc.c-torture/compile/limits-fndefn.c -O2 -flto -flto-partition=none (ICE) -- SIGSEGV for stack growth failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65515 --- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Wed Mar 25 09:58:18 2015 New Revision: 221656 URL: https://gcc.gnu.org/viewcvs?rev=221656root=gccview=rev Log: PR lto/65515 * lto-streamer-out.c (DFS::worklist): New struct. (DFS::worklist_vec): New data member. (DFS::next_dfs_num): Remove. (DFS::DFS): Rewritten using worklist instead of recursion, using most of code from DFS::DFS_write_tree. (DFS::DFS_write_tree_body): Remove SINGLE_P argument, don't pass it to DFS_write_tree calls. (DFS::DFS_write_tree): Remove SINGLE_P argument, after quick initial checks push it into worklist_vec and return. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-streamer-out.c
[Bug lto/65536] LTO line number information garbled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536 --- Comment #33 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #26) Created attachment 35130 [details] linemap this is a proof of concept patch that makes streamer in to collect locations into a cache and apply them in sorted order (looking up correct max_column hints) at the end of handling of a given section. It also has facility to throw away locations of trees that are freed. while sorting at stream in time is not cool, it does not show top in the profiles and memory use of the cache is actually dominated by other stuff we read, so this seems to work quite well in practice. Main problem would be if someone copied/used the locator before cache is applied. This helps to get all lines and most of carrets right on firefox. I killed my Chromium tree so can't test it there (Martin, perhaps you could try?) I did not have much time today to test the patch. It also saves quite a lot of memory, about 400MB on firefox I guess. Looks sensible to me (apart from sorting at WPA time and missing TLC like adding function/code comments and removing no-op hunks). Richard. Honza
[Bug fortran/65532] [5 Regression] Unexpected error with legacy code (D1MACH)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65532 --- Comment #7 from Mikael Morin mikael at gcc dot gnu.org --- Author: mikael Date: Wed Mar 25 10:15:46 2015 New Revision: 221657 URL: https://gcc.gnu.org/viewcvs?rev=221657root=gccview=rev Log: Fix regression introduced at revision 221586. PR fortran/64952 PR fortran/65532 fortran/ * gfortran.h (struct gfc_namespace): New field 'types_resolved'. * resolve.c (resolve_types): Return early if field 'types_resolved' is set. Set 'types_resolved' at the end. testsuite/ * gfortran.dg/data_initialized_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/data_initialized_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/64952] Missing temporary in assignment from elemental function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64952 --- Comment #11 from Mikael Morin mikael at gcc dot gnu.org --- Author: mikael Date: Wed Mar 25 10:15:46 2015 New Revision: 221657 URL: https://gcc.gnu.org/viewcvs?rev=221657root=gccview=rev Log: Fix regression introduced at revision 221586. PR fortran/64952 PR fortran/65532 fortran/ * gfortran.h (struct gfc_namespace): New field 'types_resolved'. * resolve.c (resolve_types): Return early if field 'types_resolved' is set. Set 'types_resolved' at the end. testsuite/ * gfortran.dg/data_initialized_3.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/data_initialized_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug lto/65515] [5 Regression] FAIL: gcc.c-torture/compile/limits-fndefn.c -O2 -flto -flto-partition=none (ICE) -- SIGSEGV for stack growth failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65515 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed.
[Bug lto/65544] LTO link fails with -static-libstdc++ + weak new/delete operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65544 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Can you verify if the cross compiler uses a linker-plugin by specifying -fuse-linker-plugin? Without that errors like this are unfortunately expected.
[Bug target/65546] FAIL: gcc.dg/vect/costmodel/ppc/costmodel-vect-31a.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65546 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Peeling is certainly not profitable as with just 32 char elements in tmp.b and then just iterating over the first 16 there will be no vectorized iteration left if we peel at least one iteration (assuming v16qi vectors). Possibly 4.9 catched this only with the cost model (for targets that support unaligned stores aligned ones may be still better but of course in this case peeling for alignment should be forcefully disabled as it doesn't make sense and just makes us not consider using an unaligned store). Thus, testsuite issue I think.
[Bug c++/62164] 5.0: ICE: error: Both section and comdat group is set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62164 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- This seems to be fixed now.
[Bug c++/65509] [5 Regression] [C++11] GCC rejects operator== with two distinct pointers as not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65509 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- The difference between when i1 and i2 are constexprs and when they are not is that their cgraph nodes have definition = false if they are constexprs. Dunno if that is intentional or not.
[Bug c++/65547] Gcc not giving preprocessor error for invalid invocation of variadic macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65547 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- And as has been documented forever, the way to get diagnostics for GNU extensions that contradict the ISO standard is the -pedantic switch: https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Warning-Options.html#index-pedantic-279 There is no bug here.
[Bug target/65508] ICE: in initialize_inlined_parameters, at tree-inline.c:3305 with -fcheck-pointer-bounds -mmpx and nested function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65508 ienkovich at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from ienkovich at gcc dot gnu.org --- Fixed
[Bug c++/65154] [4.8/4.9/5 Regression] ICE with {} initialized array with string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65154 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Most likely started with r175674.
[Bug tree-optimization/62630] [5/6 Regression] gcc.dg/graphite/vect-pr43423.c XFAILed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62630 --- Comment #21 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Wed Mar 25 12:54:12 2015 New Revision: 221662 URL: https://gcc.gnu.org/viewcvs?rev=221662root=gccview=rev Log: 2015-03-25 Richard Biener rguent...@suse.de PR tree-optimization/62630 * gcc.dg/graphite/vect-pr43423.c: XFAIL. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/graphite/vect-pr43423.c
[Bug tree-optimization/62630] [5/6 Regression] gcc.dg/graphite/vect-pr43423.c XFAILed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62630 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||xfail Known to work||4.9.2 Target Milestone|5.0 |6.0 Summary|[5 regression] |[5/6 Regression] |gcc.dg/graphite/vect-pr4342 |gcc.dg/graphite/vect-pr4342 |3.c FAILs |3.c XFAILed Known to fail||5.0 --- Comment #20 from Richard Biener rguenth at gcc dot gnu.org --- XFAILed.
[Bug c++/65415] using, base class static member function template, and decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65415 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Trunk accepts the code since r221478.
[Bug c++/65509] [5 Regression] [C++11] GCC rejects operator== with two distinct pointers as not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65509 --- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #4) The difference between when i1 and i2 are constexprs and when they are not is that their cgraph nodes have definition = false if they are constexprs. Dunno if that is intentional or not. True, they don't have definitions because we're trying to evaluate the constexpr comparison in cxx_eval_binary_expression before finalize_decl could create the definitions for i1 and i2.
[Bug pch/65550] New: [5 Regression] ICE (segfault) with pch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65550 Bug ID: 65550 Summary: [5 Regression] ICE (segfault) with pch Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: pch Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org seen building the mp4v2 package in Debian unstable with r221551 and pch enabled. disabling pch lets the package build succeed. Program received signal SIGABRT, Aborted. 0x7690a107 in raise () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt #0 0x7690a107 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x7690b4e8 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x0136f69a in linemap_add(line_maps*, lc_reason, unsigned int, char const*, unsigned int) () #3 0x0136f913 in linemap_line_start(line_maps*, unsigned int, unsigned int) () #4 0x0136fae1 in linemap_position_for_column(line_maps*, unsigned int) () #5 0x0136dbc2 in _cpp_lex_direct () #6 0x0136eaee in _cpp_lex_token () #7 0x01373a98 in cpp_get_token_1(cpp_reader*, unsigned int*) () #8 0x008760ed in c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int) () #9 0x00715a50 in cp_lexer_get_preprocessor_token(cp_lexer*, cp_token*) () #10 0x0074c9df in c_parse_file() () #11 0x0087e673 in c_common_parse_file() () #12 0x00cc2662 in compile_file() () #13 0x00611a3d in toplev::main(int, char**) () #14 0x006128fa in main ()
[Bug lto/65536] LTO line number information garbled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65536 --- Comment #34 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Martin Liška from comment #30) Created attachment 35132 [details] Chrome: ODR warnings with patch from #c21 @Martin: The previous comment where the ICE is mentioned seems to refer to Jan's latest patch (with the cache), but this comment appears to refer to my patch in comment 21. Is that right? I don't see how you can get that backtrace with Jan's patch: linemap_line_start should only be called when applying the location cache, no? @Jan: I think: + linemap_line_start (line_table, loc.line, + MAX (81, loc.col + 1)) should simply be: + linemap_line_start (line_table, loc.line, + max + 1) For what is worth, I think your patch should already help a lot in GCC 5, it seems a move in the right direction. Perhaps the WPA sorting time is offset by the memory savings and lower number of maps, which should reduce lookup times. It would really be interesting to compute the sum of dump_line_table_statistics() for each input file before stream out and for the LTO line_table after stream in. It will give you some idea of how much you can expect to save in streamed out data and LTO memory by streaming out the line_tables directly.
[Bug libstdc++/65543] rvalue stream insertion and extraction operators incorrectly implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65543 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|5.0 |4.8.5 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 5.0, 4.9.3, 4.8.5.
[Bug tree-optimization/64715] [5 Regression] __builtin_object_size (..., 1) fails to locate subobject
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64715 --- Comment #20 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 35133 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35133action=edit gcc5-pr64715.patch Untested temporary hack for GCC 5.
[Bug c++/65547] Gcc not giving preprocessor error for invalid invocation of variadic macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65547 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Edward Diener from comment #3) Where do you get the idea that the standard doesn't require an error, it requires a diagnostic message ? 1.4 [intro.compliance], the text I quoted. Where do you get the idea it requires an error?
[Bug ipa/65076] [5 Regression] 16% tramp3d-v4.cpp compile time regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65076 --- Comment #19 from Richard Biener rguenth at gcc dot gnu.org --- I've meanwhile disabled pass_chkp_instrumentation_passes by default. The fixup_cfg in pass_build_ssa_passes doesn't do anything on tramp3d (and bootstrap/testing shows no issue removing it either). Adding a local_pure_const to the end of build_ssa_passes unfortunately makes us ICE in cgraph node verification during early inlining (we have a dangling call-stmt without a BB on a cgraph edge). Not sure how that happens as we fixup the cfg and rebuild cgraph edges before early inlining. Looks like re-building cgraph edges fixes that. This brings down the number of clobbers and stmts to 4.9 level. Index: gcc/passes.def === --- gcc/passes.def (revision 221660) +++ gcc/passes.def (working copy) @@ -54,10 +54,12 @@ along with GCC; see the file COPYING3. NEXT_PASS (pass_build_ssa_passes); PUSH_INSERT_PASSES_WITHIN (pass_build_ssa_passes) NEXT_PASS (pass_fixup_cfg); + NEXT_PASS (pass_rebuild_cgraph_edges); NEXT_PASS (pass_init_datastructures); NEXT_PASS (pass_build_ssa); NEXT_PASS (pass_ubsan); NEXT_PASS (pass_early_warn_uninitialized); + NEXT_PASS (pass_local_pure_const); POP_INSERT_PASSES () NEXT_PASS (pass_chkp_instrumentation_passes); as opposed to the also possible patch (which doesn't change anything but compile-time): Index: gcc/passes.def === --- gcc/passes.def (revision 221657) +++ gcc/passes.def (working copy) @@ -53,7 +53,6 @@ along with GCC; see the file COPYING3. NEXT_PASS (pass_ipa_chkp_early_produce_thunks); NEXT_PASS (pass_build_ssa_passes); PUSH_INSERT_PASSES_WITHIN (pass_build_ssa_passes) - NEXT_PASS (pass_fixup_cfg); NEXT_PASS (pass_init_datastructures); NEXT_PASS (pass_build_ssa); NEXT_PASS (pass_ubsan);
[Bug tree-optimization/65538] [5 Regression] Memory leak of ipa_node_params_sum elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65538 Martin Liška marxin at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Liška marxin at gcc dot gnu.org --- Fixed in 5.0.0.
[Bug target/65508] ICE: in initialize_inlined_parameters, at tree-inline.c:3305 with -fcheck-pointer-bounds -mmpx and nested function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65508 --- Comment #1 from ienkovich at gcc dot gnu.org --- Author: ienkovich Date: Wed Mar 25 12:41:27 2015 New Revision: 221661 URL: https://gcc.gnu.org/viewcvs?rev=221661root=gccview=rev Log: gcc/ PR target/65508 * tree-chkp.c (chkp_add_bounds_to_call_stmt): Set static chain for generated call. gcc/testsuite/ PR target/65508 * gcc.target/i386/mpx/pr65508.c: New. Added: trunk/gcc/testsuite/gcc.target/i386/mpx/pr65508.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-chkp.c
[Bug c++/65154] [4.8/4.9/5 Regression] ICE with {} initialized array with string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65154
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.8.5
Summary|ICE with {} initialized |[4.8/4.9/5 Regression] ICE
|array with string |with {} initialized array
||with string
--- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org ---
4.6 didn't ICE, thus a regression.
[Bug target/65342] [5 Regression] FAIL: gfortran.dg/intrinsic_(un)?pack_1.f90 -O1 execution test on powerpc-apple-darwin9 after r210201
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65342 --- Comment #14 from Dominique d'Humieres dominiq at lps dot ens.fr --- Results with the patch in comment 11 at https://gcc.gnu.org/ml/gcc-testresults/2015-03/msg02484.html Note that the patch in comment 6 also fixes this PR. It is probably the best short term solution. Could it be committed for 5.1?
[Bug testsuite/65506] [5 Regression] FAIL: gcc.dg/pr29215.c scan-tree-dump-not gimple memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65506 alalaw01 at gcc dot gnu.org changed: What|Removed |Added CC||alalaw01 at gcc dot gnu.org --- Comment #8 from alalaw01 at gcc dot gnu.org --- This test was also failing for target arm-none-eabi, also fixed by Jakub's r221607.
[Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||build Priority|P3 |P1
[Bug libstdc++/65543] rvalue stream insertion and extraction operators incorrectly implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65543 --- Comment #5 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Wed Mar 25 12:55:22 2015 New Revision: 221664 URL: https://gcc.gnu.org/viewcvs?rev=221664root=gccview=rev Log: 2015-03-25 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/65543 * include/std/istream (operator(basic_istream, _Tp): Revert thinko in r150387. * include/std/ostream (operator(basic_ostream, const _Tp): Likewise. * testsuite/27_io/rvalue_streams-2.cc: New. Added: branches/gcc-4_8-branch/libstdc++-v3/testsuite/27_io/rvalue_streams-2.cc Modified: branches/gcc-4_8-branch/libstdc++-v3/ChangeLog branches/gcc-4_8-branch/libstdc++-v3/include/std/istream branches/gcc-4_8-branch/libstdc++-v3/include/std/ostream
[Bug libstdc++/65543] rvalue stream insertion and extraction operators incorrectly implemented
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65543 --- Comment #4 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Wed Mar 25 12:55:04 2015 New Revision: 221663 URL: https://gcc.gnu.org/viewcvs?rev=221663root=gccview=rev Log: 2015-03-25 Paolo Carlini paolo.carl...@oracle.com PR libstdc++/65543 * include/std/istream (operator(basic_istream, _Tp): Revert thinko in r150387. * include/std/ostream (operator(basic_ostream, const _Tp): Likewise. * testsuite/27_io/rvalue_streams-2.cc: New. Added: branches/gcc-4_9-branch/libstdc++-v3/testsuite/27_io/rvalue_streams-2.cc Modified: branches/gcc-4_9-branch/libstdc++-v3/ChangeLog branches/gcc-4_9-branch/libstdc++-v3/include/std/istream branches/gcc-4_9-branch/libstdc++-v3/include/std/ostream
[Bug fortran/65541] [5 Regression] namelist regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65541 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- This fixes it: ... Confimed (the patch in comment 4 does not apply cleanly and needs some minor surgery) and it regtest without regression. Thanks for quick fix.
[Bug c++/65509] [5 Regression] [C++11] GCC rejects operator== with two distinct pointers as not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65509 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Marek Polacek from comment #8) The following (untested) should work: --- a/gcc/cp/decl.c +++ b/gcc/cp/decl.c @@ -6113,6 +6113,7 @@ make_rtl_for_nonlocal_decl (tree decl, tree init, const char* asmspec) not emitted into the object file unnecessarily. */ filename = LOCATION_FILE (input_location); if (!DECL_VIRTUAL_P (decl) + !DECL_DECLARED_CONSTEXPR_P (decl) TREE_READONLY (decl) DECL_INITIAL (decl) != NULL_TREE DECL_INITIAL (decl) != error_mark_node My reasoning is that we shouldn't defer assembling the variable if it might be needed in the constexpr context. But in the #c5 testcase it isn't DECL_DECLARED_CONSTEXPR_P, is it?
[Bug target/65510] target-tic6x: unrecognizable insn with -O(1,2,3,s).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65510
--- Comment #3 from Chen Gang gang.chen.5i5j at gmail dot com ---
(In reply to Chen Gang from comment #2)
For test.i:
int oxu_driver_init(void)
{
*(volatile unsigned int *)(-1) = *(unsigned int *)(-1);
}
If test.i use a valid number (= 0x10) or normal variable instead of -1,
it will be OK (the insns are almost the same between using valid numbers and
using variable).
If test.i use 0 (NULL) instead of -1, it will be OK, too, but it will
generate an abort() insn for it (unlike valid numbers' and variable's insn).
If test.i se invalid number (e.g. -2, -1, 0x1, 0x2 ... 0xf), it will
generate a different insn which can not be recognized by MD file.
So for me, we need process the left invalid numbers just as processing 0
(NULL) -- generate an abort() insn for them.
Oh, sorry, the contents above is incorrect, it is about memory alignment issue.
If the alignment is less than 32, it will cause issue. e.g. 0, 4, 8, 16, 20,
pointer parameter ... are all OK, but the other will cause issue.
[Bug bootstrap/65537] [5 Regression] --with-build-config=bootstrap-lto fails on CentOS 5.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65537 --- Comment #8 from uros at gcc dot gnu.org --- Author: uros Date: Wed Mar 25 16:01:36 2015 New Revision: 221667 URL: https://gcc.gnu.org/viewcvs?rev=221667root=gccview=rev Log: config/ChangeLog: PR bootstrap/65537 * bootstrap-lto-noplugin.mk: New build configuration. gcc/ChangeLog: PR bootstrap/65537 * doc/install.texi (Building a native compiler): Document new bootstrap-lto-noplugin configuration. Mention that bootstrap-lto configuration assumes that the host supports the linker plugin. Added: trunk/config/bootstrap-lto-noplugin.mk Modified: trunk/config/ChangeLog trunk/gcc/ChangeLog trunk/gcc/doc/install.texi
[Bug c++/63385] internal compiler error: in pop_binding, at cp/name-lookup.c for implicitly captured variable called closure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63385 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- 4.8/4.9/5 do not ICE anymore, closing as fixed thus.
[Bug middle-end/65555] New: [5 Regression] ICE: verify_gimple failed (LHS in noreturn call)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=6 Bug ID: 6 Summary: [5 Regression] ICE: verify_gimple failed (LHS in noreturn call) Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Created attachment 35136 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35136action=edit preprocessed source seen building the poligraph package in Debian unstable, using r221551 $ g++ -c -g -O src/xstd/FileScanner.ii FileScanner.cc: In member function 'void FileScanner::configure(int)': FileScanner.cc:331:1: error: LHS in noreturn call # VUSE .MEM_51 _20 = xexit (_22); FileScanner.cc:331:1: internal compiler error: verify_gimple failed Please submit a full bug report,
[Bug middle-end/65556] New: [5 Regression] ICE: verify_gimple failed (type precision mismatch in switch statement)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65556 Bug ID: 65556 Summary: [5 Regression] ICE: verify_gimple failed (type precision mismatch in switch statement) Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Created attachment 35137 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35137action=edit preprocessed source seen building the pcf2bdf package in Debian unstable, using r221551 $ g++ -c -g -O2 -Wno-write-strings pcf2bdf.ii pcf2bdf.cc: In function 'int main(int, char**)': pcf2bdf.cc:559:5: error: type precision mismatch in switch statement int main(int argc, char *argv[]) ^ switch (D.5231) default: D.4565, case 0: D.4566, case 1: D.4571 pcf2bdf.cc:559:5: internal compiler error: verify_gimple failed Please submit a full bug report, with preprocessed source if appropriate.
[Bug pch/65550] [5 Regression] ICE (segfault) with pch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65550 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-25 CC||trippels at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Doesn't happen with --enable-checking=release. src/bmff/impl.h:126:5: internal compiler error: Aborted 0xcaf40f crash_signal ../../gcc/gcc/toplev.c:383 0x1339c09 linemap_add(line_maps*, lc_reason, unsigned int, char const*, unsigned int) ../../gcc/libcpp/line-map.c:297 0x1339e82 linemap_line_start(line_maps*, unsigned int, unsigned int) ../../gcc/libcpp/line-map.c:566 0x133a050 linemap_position_for_column(line_maps*, unsigned int) ../../gcc/libcpp/line-map.c:611 0x1338131 _cpp_lex_direct ../../gcc/libcpp/lex.c:2329 0x133905d _cpp_lex_token ../../gcc/libcpp/lex.c:2166 0x133e007 cpp_get_token_1 ../../gcc/libcpp/macro.c:2442 0x86168c c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int) ../../gcc/gcc/c-family/c-lex.c:408 0x70101f cp_lexer_get_preprocessor_token ../../gcc/gcc/cp/parser.c:779 0x737fae cp_lexer_new_main ../../gcc/gcc/cp/parser.c:660 0x737fae cp_parser_new ../../gcc/gcc/cp/parser.c:3484 0x737fae c_parse_file() ../../gcc/gcc/cp/parser.c:33190 0x869c12 c_common_parse_file() ../../gcc/gcc/c-family/c-opts.c:1057 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions.
[Bug target/65531] ICE: symtab_node::verify failed: Two symbols with same comdat_group are not linked by the same_comdat_group list. with -fcheck-pointer-bounds -mmpx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65531 --- Comment #3 from ienkovich at gcc dot gnu.org --- When instrumentation clone is created for a node with a comdat group, it gets the same comdat group and is linked with the original node via same_comdat_group. Do I need to change this behavior to pass verification (e.g. don't set same_comdat_group for the clone in case the original node has NULL for same_comdat_group and is not a function definition)? Probably would be easier to just always have same_comdat_group list for nodes with same comdat_group with no exceptions.
[Bug c++/65553] New: ICE on valid variadic template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65553 Bug ID: 65553 Summary: ICE on valid variadic template Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: webrown.cpp at gmail dot com Created attachment 35134 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35134action=edit program producing ICE When compiling enclosed program via g++-mp-5 (MacPorts gcc5 5-20150308_0) 5.0.0 20150308 (experimental) via command line g++-mp-5 -std=c++14 junk.cpp the following messages obtain: junk.cpp:10:38: internal compiler error: tree check: accessed elt 2 of tree_vec with 1 elts in check_instantiated_args, at cp/pt.c:15822 template typename... Args, bool B = F2Args... ^ junk.cpp:10:38: internal compiler error: Abort trap: 6 g++-mp-5: internal compiler error: Abort trap: 6 (program cc1plus) Thanks to Andrew Sutton for reducing the test case.
[Bug tree-optimization/65551] New: [5 Regression] FAIL: 26_numerics/complex/50880.cc execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65551 Bug ID: 65551 Summary: [5 Regression] FAIL: 26_numerics/complex/50880.cc execution test Product: gcc Version: 5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: tree-optimization Assignee: thopre01 at gcc dot gnu.org Reporter: jgreenhalgh at gcc dot gnu.org Host: arm-none-linux-gnueabihf Target: arm-none-linux-gnueabihf As of r220390 we've started to FAIL this test from libstdc++ on arm-none-linux-gnueabihf: FAIL: 26_numerics/complex/50880.cc execution test ./50880.exe 50880.exe: /work/jamgre01/gcc-src/libstdc++-v3/testsuite/26_numerics/complex/50880.cc:36: void test01_do() [with T = double]: Assertion `cra.real() T(0)' failed. Aborted Bisect pinpointed the failure to this commit: Author: thopre01 thopre01@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Wed Feb 4 08:22:45 2015 + 2015-02-04 Thomas Preud'homme thomas.preudho...@arm.com gcc/ PR middle-end/62103 * tree-ssa-sccvn.c (fully_constant_vn_reference_p): Use TYPE_PRECISION to compute size of referenced value in the constant case. gcc/testsuite/ PR middle-end/62103 * gcc.c-torture/execute/bitfld-7.c: New test adapted from bitfld-6.c to use 24 bits for bitfield b. Compiler configured with: /work/jamgre01//gcc-src/configure --with-cpu=cortex-a9 --with-fpu=neon-fp16 --with-mode=thumb --with-float=hard --enable-languages=c,c++,fortran --prefix=/work/jamgre01//gcc-install --with-build-config=bootstrap-time
[Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972 --- Comment #17 from Kai Tietz ktietz at gcc dot gnu.org --- Author: ktietz Date: Wed Mar 25 15:05:02 2015 New Revision: 221665 URL: https://gcc.gnu.org/viewcvs?rev=221665root=gccview=rev Log: PR libgomp/64972 * oacc-parallel.c (GOACC_parallel): Use PRIu64 if available. (GOACC_data_start): Likewise. * target.c (gomp_map_vars): Likewise. Modified: trunk/libgomp/ChangeLog trunk/libgomp/oacc-parallel.c trunk/libgomp/target.c
[Bug c++/65552] New: [c++-concepts] Constraint checking regression for concepts with multiple type requirements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65552
Bug ID: 65552
Summary: [c++-concepts] Constraint checking regression for
concepts with multiple type requirements
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: tom at honermann dot net
I built the latest revision of the gcc c++-concepts branch (r221648) last night
and encountered a regression in constraint checking for concepts that specify
multiple type requirements.
Constraint checking only fails if a requires expression specifies multiple type
requirements. Placing the type constraints in distinct requires expressions
suffices to work around the problem.
$ cat t.cpp
templatetypename T
concept bool Concept() {
return requires () {
typename T::member_type1;
#if WORKAROUND
}
requires () {
#endif
typename T::member_type2;
};
}
struct model {
using member_type1 = int;
using member_type2 = int;
};
templateConcept C
struct S {};
Smodel s;
$ svn info # From my local svn gcc repo.
Path: .
URL: svn://gcc.gnu.org/svn/gcc/branches/c++-concepts
Repository Root: svn://gcc.gnu.org/svn/gcc
Repository UUID: 138bc75d-0d04-0410-961f-82ee72b054a4
Revision: 221648
Node Kind: directory
Schedule: normal
Last Changed Author: asutton
Last Changed Rev: 221633
Last Changed Date: 2015-03-24 09:36:27 -0400 (Tue, 24 Mar 2015)
$ g++ -c -std=c++1z t.cpp
t.cpp:18:8: error: template constraint failure
Smodel s;
^
t.cpp:18:8: note: constraints not satisfied
t.cpp:18:8: note: concept ‘Conceptmodel()’ was not satisfied
$ g++ -c -std=c++1z t.cpp -DWORKAROUND
no error
[Bug c++/61639] GCC 4.7.4 can't longer compile clang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61639 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-03-25 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- Without a testcase there's nothing to do.
[Bug libstdc++/33394] Add test case for Thread race segfault in std::string::append with -O and -s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33394 --- Comment #4 from alalaw01 at gcc dot gnu.org --- Author: alalaw01 Date: Wed Mar 25 15:46:58 2015 New Revision: 221666 URL: https://gcc.gnu.org/viewcvs?rev=221666root=gccview=rev Log: PR libstdc++/33394 * testsuite/21_strings/basic_string/pthread33394.cc: Use dg-additional-options. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/21_strings/basic_string/pthread33394.cc
[Bug c++/57588] [C++11] static constexpr in class fails to link
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57588 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com --- Thus, if I understand correctly the discussion (otherwise, please, reopen!) modulo access control issues in the testcase, we correctly fail at linktime.
[Bug c++/65509] [5 Regression] [C++11] GCC rejects operator== with two distinct pointers as not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65509 --- Comment #8 from Marek Polacek mpolacek at gcc dot gnu.org --- The following (untested) should work: --- a/gcc/cp/decl.c +++ b/gcc/cp/decl.c @@ -6113,6 +6113,7 @@ make_rtl_for_nonlocal_decl (tree decl, tree init, const char* asmspec) not emitted into the object file unnecessarily. */ filename = LOCATION_FILE (input_location); if (!DECL_VIRTUAL_P (decl) + !DECL_DECLARED_CONSTEXPR_P (decl) TREE_READONLY (decl) DECL_INITIAL (decl) != NULL_TREE DECL_INITIAL (decl) != error_mark_node My reasoning is that we shouldn't defer assembling the variable if it might be needed in the constexpr context.
[Bug c++/65509] [5 Regression] [C++11] GCC rejects operator== with two distinct pointers as not constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65509 --- Comment #10 from Marek Polacek mpolacek at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #9) But in the #c5 testcase it isn't DECL_DECLARED_CONSTEXPR_P, is it? True :(.
[Bug libgomp/64972] [5 Regression] Build failure in libgomp for i686-w64-mingw32 target after latest merge from gomp-4_0-branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64972 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #18 from Kai Tietz ktietz at gcc dot gnu.org --- Fixed on trunk.
[Bug c++/65553] ICE on valid variadic template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65553 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- Seconded. We can't take action with this testcase, sorry.
[Bug c++/65154] [4.8/4.9/5 Regression] ICE with {} initialized array with string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65154
--- Comment #5 from Mikhail Maltsev maltsevm at gmail dot com ---
I have posted a patch for this bug:
https://gcc.gnu.org/ml/gcc-patches/2015-03/msg00026.html
But it reveals some latent bug (PR65503). In the following case (after applying
the patch):
struct ss {
ss() {};
};
struct C {
ss s[1000];
};
int main() {
C cs[5]{};
}
We'll get 1000 calls to ss() in main instead of calling default c-tor of struct
C. (which is probably not what we want).
[Bug c++/61717] seg fault on using variadic templates to initialize array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61717 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- 4.8/4.9/5 do not ICE for me anymore.
[Bug c++/65553] ICE on valid variadic template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65553 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- I can't reproduce.
[Bug middle-end/65554] New: [5 Regression] ICE: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65554
Bug ID: 65554
Summary: [5 Regression] ICE: verify_gimple failed
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
Created attachment 35135
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35135action=edit
preprocessed source
seen building openmsx in Debian unstable, with r221551, fails with -O[123],
works with -O0
g++ -MP -MMD -MF derived/x86_64-linux-debian/dep/ide/HDCommand.d -o
derived/x86_64-linux-debian/obj/ide/HDCommand.o -g -fstack-protector-strong
-Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -O3 -m64 -pipe
-std=gnu++0x -Wall -Wextra -Wundef -Wunused-macros
-Wno-missing-field-initializers -Wzero-as-null-pointer-constant -Isrc
-Isrc/cassette -Isrc/commands -Isrc/config -Isrc/console -Isrc/cpu
-Isrc/debugger -Isrc/events -Isrc/fdc -Isrc/file -Isrc/ide -Isrc/input
-Isrc/laserdisc -Isrc/memory -Isrc/security -Isrc/serial -Isrc/settings
-Isrc/sound -Isrc/thread -Isrc/utils -Isrc/video -Isrc/video/ld
-Isrc/video/scalers -Isrc/video/v9990 -Iderived/x86_64-linux-debian/config
-I/usr/include/SDL -D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/SDL
-D_GNU_SOURCE=1 -D_REENTRANT -I/usr/include/freetype2 -I/usr/include/libpng12
-I/usr/include/tcl8.5 -I/usr/include/libxml2 -c src/ide/HDCommand.cc
src/ide/HDCommand.cc: In member function 'virtual void
openmsx::HDCommand::tabCompletion(std::vectorstd::basic_stringchar )
const':
src/ide/HDCommand.cc:78:6: error: non-trivial conversion at assignment
void HDCommand::tabCompletion(vectorstring tokens) const
^
long unsigned int
const char[7] *
# .MEM_152 = VDEF .MEM_149
MEM[(char * {ref-all})_88] = _126;
src/ide/HDCommand.cc:78:6: internal compiler error: verify_gimple failed
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug c++/53743] ICE when compiling firefox with PGO and LTO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53743 --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com --- Is this still an issue?
[Bug c++/54543] Expression (condition ? array : throw expr)[index] fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54543 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-03-25 Ever confirmed|0 |1
[Bug lto/65559] New: [5 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65559 Bug ID: 65559 Summary: [5 Regression] lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947 Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: rai...@emrich-ebersheim.de Running the testsuite I get ICEs for lto in several places, but the ICE is always the same: lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947 libbacktrace could not find executable to open Here one example: Executing on host: /opt/devel/SCRATCH/tmp.5jnZ8G4weh/gcc-5.0.0/gcc-5.0.0/gcc/xgcc -B/opt/devel/SCRATCH/tmp.5jnZ8G4weh/gcc-5.0.0/gcc-5.0.0/gcc/ /opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/testsuite/gcc.c-torture/execute/builtins/fprintf.c /opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/testsuite/gcc.c-torture/execute/builtins/fprintf-lib.c /opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c -fno-diagnostics-show-caret -fdiagnostics-color=never -w -O2 -flto -flto-partition=none -fno-tree-loop-distribute-patterns -Wl,--allow-multiple-definition -lm-o /opt/devel/SCRATCH/tmp.5jnZ8G4weh/gcc-5.0.0/gcc-5.0.0/gcc/testsuite/gcc/fprintf.x7 (timeout = 300) spawn /opt/devel/SCRATCH/tmp.5jnZ8G4weh/gcc-5.0.0/gcc-5.0.0/gcc/xgcc -B/opt/devel/SCRATCH/tmp.5jnZ8G4weh/gcc-5.0.0/gcc-5.0.0/gcc/ /opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/testsuite/gcc.c-torture/execute/builtins/fprintf.c /opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/testsuite/gcc.c-torture/execute/builtins/fprintf-lib.c /opt/devel/gnu/src/gcc-mingw-w64/gcc-5.0.0/gcc/testsuite/gcc.c-torture/execute/builtins/lib/main.c -fno-diagnostics-show-caret -fdiagnostics-color=never -w -O2 -flto -flto-partition=none -fno-tree-loop-distribute-patterns -Wl,--allow-multiple-definition -lm -o /opt/devel/SCRATCH/tmp.5jnZ8G4weh/gcc-5.0.0/gcc-5.0.0/gcc/testsuite/gcc/fprintf.x7 lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947 libbacktrace could not find executable to open Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper.exe: fatal error: D:\opt\devel\SCRATCH\tmp.5jnZ8G4weh\gcc-5.0.0\gcc-5.0.0\gcc\xgcc.exe returned 1 exit status compilation terminated. D:\opt\devel\gnu\gcc\MINGW_NT\x86_64-w64-mingw32\mingw-w64-runtime-trunk-svn\gcc-5.0.0\bin\ld.exe: error: lto-wrapper failed collect2.exe: error: ld returned 1 exit status compiler exited with status 1 output is: lto1.exe: internal compiler error: in read_cgraph_and_symbols, at lto/lto.c:2947 libbacktrace could not find executable to open Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. lto-wrapper.exe: fatal error: D:\opt\devel\SCRATCH\tmp.5jnZ8G4weh\gcc-5.0.0\gcc-5.0.0\gcc\xgcc.exe returned 1 exit status compilation terminated. D:\opt\devel\gnu\gcc\MINGW_NT\x86_64-w64-mingw32\mingw-w64-runtime-trunk-svn\gcc-5.0.0\bin\ld.exe: error: lto-wrapper failed collect2.exe: error: ld returned 1 exit status FAIL: gcc.c-torture/execute/builtins/fprintf.c compilation, -O2 -flto -flto-partition=none (internal compiler error)
[Bug c++/55335] [DR 5] cv-qualifiers of destination type in copy-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55335 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE Target Milestone|--- |4.9.1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- This is fixed in 4.9.1. *** This bug has been marked as a duplicate of bug 60019 ***
[Bug c++/54987] missed ambiguity in template function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54987 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC|afalin at xakep dot ru | Known to work||4.9.0, 5.0 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- 4.9.0 correctly rejects this, I'm adding the testcase and closing the bug.
[Bug c++/53814] FAIL: g++.dg/cpp0x/nullptr28.C -std=c++11 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53814 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #5 from John David Anglin danglin at gcc dot gnu.org --- Branch is no longer maintained.
[Bug c++/65552] [c++-concepts] Constraint checking regression for concepts with multiple type requirements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65552 Andrew Sutton andrew.n.sutton at gmail dot com changed: What|Removed |Added CC||andrew.n.sutton at gmail dot com --- Comment #1 from Andrew Sutton andrew.n.sutton at gmail dot com --- Confirmed and resolved in r221669.
[Bug middle-end/65556] [5 Regression] ICE: verify_gimple failed (type precision mismatch in switch statement)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65556
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-03-25
CC||trippels at gcc dot gnu.org
Target Milestone|--- |5.0
Ever confirmed|0 |1
--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
markus@x4 tmp % cat pcf2bdf.ii
struct
{
long id : 1;
} a;
int
main ()
{
switch (a.id)
case 0:
;
}
markus@x4 tmp % gcc -w -c pcf2bdf.ii
pcf2bdf.ii: In function ‘int main()’:
pcf2bdf.ii:6:1: error: type precision mismatch in switch statement
main ()
^
switch (D.2335) default: D.2336, case 0: D.2331
pcf2bdf.ii:6:1: internal compiler error: verify_gimple failed
0xcec17f verify_gimple_in_seq(gimple_statement_base*)
../../gcc/gcc/tree-cfg.c:4737
0xac009c gimplify_body(tree_node*, bool)
../../gcc/gcc/gimplify.c:9100
0xac0406 gimplify_function_tree(tree_node*)
../../gcc/gcc/gimplify.c:9185
0x90c2b7 cgraph_node::analyze()
../../gcc/gcc/cgraphunit.c:633
0x90f36d analyze_functions
../../gcc/gcc/cgraphunit.c:1023
0x90fc55 symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2435
0x6ec4c7 cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4755
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/54543] Expression (condition ? array : throw expr)[index] fails to compile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54543 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- The code is valid. The workaround we use in the library is to use the comma operator: return ((0 = n n 10) ? arr : (throw error, arr))[n];
[Bug middle-end/65554] [5 Regression] ICE: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65554
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-03-25
CC||trippels at gcc dot gnu.org
Target Milestone|--- |5.0
Ever confirmed|0 |1
--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
markus@x4 tmp % cat HDCommand.ii
namespace std
{
template class class initializer_list
{
int *_M_array;
int _M_len;
};
class A
{
public:
void operator=(initializer_listint);
};
class B
{
void m_fn1 (A ) const;
};
void
B::m_fn1 (A ) const
{
A extra;
extra = {};
}
}
markus@x4 tmp % g++ -std=c++11 -O2 -c HDCommand.ii
HDCommand.ii: In member function ‘void std::B::m_fn1(std::A) const’:
HDCommand.ii:18:1: error: non-trivial conversion at assignment
B::m_fn1 (A ) const
^
int
sizetype
D.2166._M_len = 0;
HDCommand.ii:18:1: internal compiler error: verify_gimple failed
0xcec17f verify_gimple_in_seq(gimple_statement_base*)
../../gcc/gcc/tree-cfg.c:4737
0xac009c gimplify_body(tree_node*, bool)
../../gcc/gcc/gimplify.c:9100
0xac0406 gimplify_function_tree(tree_node*)
../../gcc/gcc/gimplify.c:9185
0x90c2b7 cgraph_node::analyze()
../../gcc/gcc/cgraphunit.c:633
0x90f36d analyze_functions
../../gcc/gcc/cgraphunit.c:1023
0x90fc55 symbol_table::finalize_compilation_unit()
../../gcc/gcc/cgraphunit.c:2435
0x6ec4c7 cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4755
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug ipa/65557] New: ICE: SIGSEGV in hash_table::find_slot_with_hash() with -fdevirtualize -fipa-cp -fipa-icf-functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65557 Bug ID: 65557 Summary: ICE: SIGSEGV in hash_table::find_slot_with_hash() with -fdevirtualize -fipa-cp -fipa-icf-functions Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Created attachment 35138 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35138action=edit reduced testcase Compiler output: $ gcc -fdevirtualize -fipa-cp -fipa-icf-functions testcase.C testcase.C:16:6: internal compiler error: Segmentation fault S1 s1; ^ 0xe0a5cf crash_signal /mnt/svn/gcc-trunk/gcc/toplev.c:383 0xc123e2 hash_tablehash_mapint, ipa_node_params*, function_summaryipa_node_params*::summary_hashmap_traits::hash_entry, xcallocator, true::find_slot_with_hash(int const, unsigned int, insert_option) /mnt/svn/gcc-trunk/gcc/hash-table.h:1542 0xc12591 hash_mapint, ipa_node_params*, function_summaryipa_node_params*::summary_hashmap_traits::get_or_insert(int const, bool*) /mnt/svn/gcc-trunk/gcc/hash-map.h:232 0xc12591 function_summaryipa_node_params*::get(int) /mnt/svn/gcc-trunk/gcc/symbol-summary.h:230 0x18605de function_summaryipa_node_params*::get(cgraph_node*) /mnt/svn/gcc-trunk/gcc/symbol-summary.h:112 0x18605de ipa_icf::sem_function::equals_wpa(ipa_icf::sem_item*, hash_mapsymtab_node*, ipa_icf::sem_item*, default_hashmap_traits) /mnt/svn/gcc-trunk/gcc/ipa-icf.c:518 0x18581ca ipa_icf::sem_item_optimizer::subdivide_classes_by_equality(bool) /mnt/svn/gcc-trunk/gcc/ipa-icf.c:2518 0x185fb7a ipa_icf::sem_item_optimizer::execute() /mnt/svn/gcc-trunk/gcc/ipa-icf.c:2296 0x18624a6 ipa_icf_driver /mnt/svn/gcc-trunk/gcc/ipa-icf.c:3172 0x18624a6 ipa_icf::pass_ipa_icf::execute(function*) /mnt/svn/gcc-trunk/gcc/ipa-icf.c:3219 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. Tested revisions: r221607 - ICE
[Bug c++/54987] missed ambiguity in template function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54987 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Done.
[Bug libstdc++/54005] Use __atomic_always_lock_free in libstdc++ is_lock_free instead of __atomic_is_lock_free
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54005 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-03-25 Ever confirmed|0 |1 --- Comment #14 from Jonathan Wakely redi at gcc dot gnu.org --- Can we close this? (N.B. https://gcc.gnu.org/ml/libstdc++/2015-02/msg00040.html will make further changes to these functions to fix PR65033, but only to make them account for mis-aligned types, they will still be per-type not per-object)
