[Bug middle-end/62289] [5 Regression] ICE (segfault) for gfortran.dg/graphite/pr42393.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62289 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to amker from comment #1) Some comments on it at https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02274.html Namely: This is a bug in ISL. Theyâll fix it in a new version of ISL. https://groups.google.com/forum/#!topic/isl-development/SeNZf5IA-Lk The thread lists the ISL patch, https://11523367451463622537.googlegroups.com/attach/9eb3bcd38b58b2b1/diff and: Does the attached help? - Yes, It helps to fix the problem in isl-0.13.
[Bug debug/62225] DW_AT_location for local variable is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62225 --- Comment #3 from Yao Qi qiyao at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #1) I bet if you remove register, it will work. Or compile with variable tracking turned on. I compiled the code again with -fvar-tracking, and looks DW_AT_location for local variable is there. 29a: Abbrev Number: 7 (DW_TAG_variable) 9b DW_AT_name: l 9d DW_AT_decl_file : 1 9e DW_AT_decl_line : 15 9f DW_AT_type: 0x25 a3 DW_AT_location: 0x0 (location list) 2a7: Abbrev Number: 7 (DW_TAG_variable) a8 DW_AT_name: r aa DW_AT_decl_file : 1 ab DW_AT_decl_line : 15 ac DW_AT_type: 0x25 b0 DW_AT_location: 0x2a (location list) Contents of the .debug_loc section: Offset BeginEnd Expression 080483b1 080483b4 (DW_OP_reg11 (st0)) 000b 080483b4 080483cf (DW_OP_fbreg: 0) 0017 080483cf 080483d2 (DW_OP_reg11 (st0)) 0022 End of list 002a 080483b4 080483cb (DW_OP_reg11 (st0)) 0035 080483cb 080483ef (DW_OP_fbreg: 12) 0041 End of list
[Bug fortran/62298] Internal Compiler Error in fold_convert_loc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62298 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- *** Bug 62297 has been marked as a duplicate of this bug. ***
[Bug fortran/62297] Internal Compiler Error in fold_convert_loc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62297 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Duplicate of pr 62298. *** This bug has been marked as a duplicate of bug 62298 ***
[Bug fortran/62298] Internal Compiler Error in fold_convert_loc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62298 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-29 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed.
[Bug middle-end/62292] [5 Regression] FAIL: (geterrorname|getmethodname) run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62292 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Fri Aug 29 08:11:57 2014 New Revision: 214716 URL: https://gcc.gnu.org/viewcvs?rev=214716root=gccview=rev Log: 2014-08-29 Richard Biener rguent...@suse.de PR middle-end/62292 * gimple-fold.c (gimple_fold_builtin_strcpy): Fix error from previous refactoring. (gimple_fold_builtin_strncpy): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c
[Bug c++/62303] New: g++ 4.9.1 lto1: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62303 Bug ID: 62303 Summary: g++ 4.9.1 lto1: internal compiler error: Segmentation fault Product: gcc Version: lto Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: smf.linux at ntlworld dot com Created attachment 33415 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33415action=edit Full details of failure with -wrapper valgind While build Qt 4.8.6 as a lto build I found the following when building libQtCLucene.so the rest of the build is ok. If the I swap the optimization from O3 to O2 the problem goes away. The gcc version is 4.9.1, the binutils is 2.24 built using the instructions from LFS. I have also tried the latest gcc from git and that behaves the same: lto1: internal compiler error: Segmentation fault 0x840f5da crash_signal ../../gcc-4.9.1/gcc/toplev.c:337 0x8342b70 lto_get_decl_name_mapping(lto_file_decl_data*, char const*) ../../gcc-4.9.1/gcc/lto-section-in.c:346 0x8340b59 copy_function ../../gcc-4.9.1/gcc/lto-streamer-out.c:1989 0x8340b59 lto_output() ../../gcc-4.9.1/gcc/lto-streamer-out.c:2083 0x8373250 write_lto ../../gcc-4.9.1/gcc/passes.c:2298 0x8375ffa ipa_write_optimization_summaries(lto_symtab_encoder_d*) ../../gcc-4.9.1/gcc/passes.c:2495 0x813cb48 do_stream_out ../../gcc-4.9.1/gcc/lto/lto.c:2464 0x8140b00 stream_out ../../gcc-4.9.1/gcc/lto/lto.c:2506 0x8140b00 lto_wpa_write_files ../../gcc-4.9.1/gcc/lto/lto.c:2643 0x8140b00 do_whole_program_analysis ../../gcc-4.9.1/gcc/lto/lto.c:3302 0x8140b00 lto_main() ../../gcc-4.9.1/gcc/lto/lto.c:3422
[Bug c++/61484] [C++11] can't initialize constexpr multi-dimentional array of a literal type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61484 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- This works in current mainline, I'm adding the testcase and closing the bug.
[Bug c++/62303] g++ 4.9.1 lto1: internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62303 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- dup. *** This bug has been marked as a duplicate of bug 62026 ***
[Bug lto/62026] [4.9/5 Regression] Crash in lto_get_decl_name_mapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62026 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||smf.linux at ntlworld dot com --- Comment #4 from Markus Trippelsdorf trippels at gcc dot gnu.org --- *** Bug 62303 has been marked as a duplicate of this bug. ***
[Bug c++/61484] [C++11] can't initialize constexpr multi-dimentional array of a literal type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61484 --- Comment #4 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Fri Aug 29 08:41:16 2014 New Revision: 214718 URL: https://gcc.gnu.org/viewcvs?rev=214718root=gccview=rev Log: 2014-08-29 Paolo Carlini paolo.carl...@oracle.com PR c++/61484 * g++.dg/cpp0x/constexpr-61484.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-61484.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 61484, which changed state. Bug 61484 Summary: [C++11] can't initialize constexpr multi-dimentional array of a literal type https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61484 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/61484] [C++11] can't initialize constexpr multi-dimentional array of a literal type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61484 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- Done.
[Bug fortran/62298] Internal Compiler Error in fold_convert_loc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62298 --- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr --- The ICE occurs in the functions string_lowercase, string_uppercase, and string_replace, and it is the same as for the test in comment 5 of pr49802. For the record, the attached test is a variant of the one in pr62176.
[Bug middle-end/62292] [5 Regression] FAIL: (geterrorname|getmethodname) run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62292 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug bootstrap/62301] [5 Regression] PowerPC bootstrap broken since r214654
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62301 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0 Summary|PowerPC bootstrap broken|[5 Regression] PowerPC |since r214654 |bootstrap broken since ||r214654
[Bug c++/62302] [5 Regression] Change in the comdat used for constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62302 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0 Summary|Change in the comdat used |[5 Regression] Change in |for constructors|the comdat used for ||constructors
[Bug bootstrap/62300] [5 Regression] internal compiler error: in as_a, at is-a.h:192
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62300 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug c++/62299] [4.9/5 regression] ICE with __attribute__((__weakref__())) and __thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62299 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Target Milestone|--- |4.9.2
[Bug c++/62299] [4.9/5 regression] ICE with __attribute__((__weakref__())) and __thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62299 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||trippels at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- dup. *** This bug has been marked as a duplicate of bug 61558 ***
[Bug middle-end/61558] [5 Regression] ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61558 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||lucdanton at free dot fr --- Comment #6 from Markus Trippelsdorf trippels at gcc dot gnu.org --- *** Bug 62299 has been marked as a duplicate of this bug. ***
[Bug fortran/44735] ICE on FORALL with character array pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44735 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- This PR is fixed by the patch at https://gcc.gnu.org/ml/fortran/2014-08/msg00114.html. Test that can be executed: subroutine bug character(len=10) :: F_string character(len=1), dimension(:), pointer :: p_chars allocate(p_chars(10)) p_chars = ['a','b','c','d','e','f','g','h','i','j'] forall (i=1:len(F_string)) F_string(i:i) = p_chars(i) end forall print *, F_string deallocate(p_chars) end subroutine bug call bug() end [Book15] f90/bug% a.out abcdefghij
[Bug fortran/60593] ICE with deferred length variable in FORALL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60593 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- This PR is fixed by the patch at https://gcc.gnu.org/ml/fortran/2014-08/msg00114.html. Test that can be executed: character(len=10), target :: c character(len=:), pointer :: p c = 'abcdefghij' p = c(2:10) print *, C2FChar(5, p) contains function C2FChar(j, s) result(res) implicit none integer, intent(in) :: j character(len=:), pointer, intent(in) :: s character(len=:), allocatable :: res integer i allocate(character(j) :: res) forall (i = 1:j) res(i:i) = s(i:i) end function end [Book15] f90/bug% a.out bcdef
[Bug lto/62026] [4.9/5 Regression] Crash in lto_get_decl_name_mapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62026 --- Comment #5 from Stuart Foster smf.linux at ntlworld dot com --- (In reply to Markus Trippelsdorf from comment #4) *** Bug 62303 has been marked as a duplicate of this bug. *** Which branch of gcc is this fix in ? Thanks
[Bug lto/62026] [4.9/5 Regression] Crash in lto_get_decl_name_mapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62026 --- Comment #6 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Stuart Foster from comment #5) (In reply to Markus Trippelsdorf from comment #4) *** Bug 62303 has been marked as a duplicate of this bug. *** Which branch of gcc is this fix in ? It is not fixed yet.
[Bug libstdc++/62258] uncaught_exception() equals to `true' after rethrow_exception()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62258 Deniz Bahadir D.Bahadir at GMX dot de changed: What|Removed |Added CC||D.Bahadir at GMX dot de --- Comment #3 from Deniz Bahadir D.Bahadir at GMX dot de --- I can confirm this bug. It even occurs with GCC 4.8.2 (on Ubuntu 14.04).
[Bug fortran/62298] Internal Compiler Error in fold_convert_loc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62298 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- Workaround: replace res = this with res%buffer = this%buffer res%length = this%len() ...other needed components With these changes the code compiles, but I cannot guarantee that it works!
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678 --- Comment #60 from Markus Trippelsdorf trippels at gcc dot gnu.org --- (In reply to Jason Merrill from comment #59) (In reply to Markus Trippelsdorf from comment #58) These are breaking with -flto because make_decl_local clears DECL_COMDAT, so the check I added to ipa_devirt doesn't trigger. Honza, can we just remove that from make_decl_local? It seems harmless to me to leave the flag set. For 4.9 this may trigger the assert in gcc/ipa.c: 983 gcc_assert ((!DECL_WEAK (node-decl) 984!DECL_COMDAT (node-decl)) 985 || TREE_PUBLIC (node-decl) 986 || node-weakref 987 || DECL_EXTERNAL (node-decl));
[Bug tree-optimization/62291] PRE uses too much memory and compile-time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62291 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-29 Ever confirmed|0 |1
[Bug bootstrap/62304] New: [5 regression] ICE in follow_jumps, find_dead_or_set_registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62304 Bug ID: 62304 Summary: [5 regression] ICE in follow_jumps, find_dead_or_set_registers Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: dmalcolm at gcc dot gnu.org, ebotcazou at gcc dot gnu.org Host: sparc*-sun-solaris2.* Target: sparc*-sun-solaris2.* Build: sparc*-sun-solaris2.* David, one of your recent patches (since 20140822, r214311) broke Solaris/SPARC bootstrap: when compiling the stage1 libgcc, I get e.g. /var/gcc/regression/trunk/11-gcc/build/./gcc/xgcc -B/var/gcc/regression/trunk/11-gcc/build/./gcc/ -B/vol/gcc/sparc-sun-solaris2.11/bin/ -B/vol/gcc/sparc-sun-solaris2.11/lib/ -isystem /vol/gcc/sparc-sun-solaris2.11/include -isystem /vol/gcc/sparc-sun-solaris2.11/sys-include-g -O2 -m64 -O2 -g -O2 -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -I. -I. -I../../.././gcc -I/vol/gcc/src/hg/trunk/local/libgcc -I/vol/gcc/src/hg/trunk/local/libgcc/. -I/vol/gcc/src/hg/trunk/local/libgcc/../gcc -I/vol/gcc/src/hg/trunk/local/libgcc/../include -DHAVE_CC_TLS -o _absvsi2.o -MT _absvsi2.o -MD -MP -MF _absvsi2.dep -DL_absvsi2 -c /vol/gcc/src/hg/trunk/local/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS /vol/gcc/src/hg/trunk/local/libgcc/libgcc2.c: In function '__absvdi2': /vol/gcc/src/hg/trunk/local/libgcc/libgcc2.c:232:1: internal compiler error: in safe_as_a, at is-a.h:205 } ^ 0xae862f follow_jumps /vol/gcc/src/hg/trunk/local/gcc/reorg.c:2326 0xaeb4fb relax_delay_slots /vol/gcc/src/hg/trunk/local/gcc/reorg.c:3175 0xaedfbb dbr_schedule /vol/gcc/src/hg/trunk/local/gcc/reorg.c:3743 0xaeed83 rest_of_handle_delay_slots /vol/gcc/src/hg/trunk/local/gcc/reorg.c:3885 0xaeede7 execute /vol/gcc/src/hg/trunk/local/gcc/reorg.c:3916 resp. /var/gcc/regression/trunk/11-gcc/build/./gcc/xgcc -B/var/gcc/regression/trunk/11-gcc/build/./gcc/ -B/vol/gcc/sparc-sun-solaris2.11/bin/ -B/vol/gcc/sparc-sun-solaris2.11/lib/ -isystem /vol/gcc/sparc-sun-solaris2.11/include -isystem /vol/gcc/sparc-sun-solaris2.11/sys-include-g -O2 -m64 -O2 -g -O2 -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fPIC -I. -I. -I../../.././gcc -I/vol/gcc/src/hg/trunk/local/libgcc -I/vol/gcc/src/hg/trunk/local/libgcc/. -I/vol/gcc/src/hg/trunk/local/libgcc/../gcc -I/vol/gcc/src/hg/trunk/local/libgcc/../include -DHAVE_CC_TLS -o _addvdi3.o -MT _addvdi3.o -MD -MP -MF _addvdi3.dep -DL_addvdi3 -c /vol/gcc/src/hg/trunk/local/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS /vol/gcc/src/hg/trunk/local/libgcc/libgcc2.c: In function '__addvti3': /vol/gcc/src/hg/trunk/local/libgcc/libgcc2.c:109:1: internal compiler error: in safe_as_a, at is-a.h:205 } ^ 0xaf0bbb find_dead_or_set_registers /vol/gcc/src/hg/trunk/local/gcc/resource.c:500 0xaf1683 find_dead_or_set_registers /vol/gcc/src/hg/trunk/local/gcc/resource.c:577 0xaf3e33 mark_target_live_regs(rtx_insn*, rtx_insn*, resources*) /vol/gcc/src/hg/trunk/local/gcc/resource.c:1115 0xae8b0b fill_slots_from_thread /vol/gcc/src/hg/trunk/local/gcc/reorg.c:2404 0xaea88b fill_eager_delay_slots /vol/gcc/src/hg/trunk/local/gcc/reorg.c:2906 0xaedfaf dbr_schedule /vol/gcc/src/hg/trunk/local/gcc/reorg.c:3742 0xaeed83 rest_of_handle_delay_slots /vol/gcc/src/hg/trunk/local/gcc/reorg.c:3885 0xaeede7 execute /vol/gcc/src/hg/trunk/local/gcc/reorg.c:3916 Need to determine which exact patch caused this and if it reproduces in a cross compiler. Rainer
[Bug bootstrap/62304] [5 regression] ICE in follow_jumps, find_dead_or_set_registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62304 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |5.0
[Bug bootstrap/62304] [5 regression] ICE in follow_jumps, find_dead_or_set_registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62304 Dave Malcolm dmalcolm at redhat dot com changed: What|Removed |Added CC||dmalcolm at redhat dot com --- Comment #1 from Dave Malcolm dmalcolm at redhat dot com --- The crash in find_dead_or_set_registers is the one discussed in: https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02619.html and I introduced it in r214693 (aka patch #225) The crash in follow_jumps is similar to it, and occurs here: new_thread = follow_jumps (JUMP_LABEL_AS_INSN (new_thread), insn, crossing); where JUMP_LABEL_AS_INSN erroneously tries to coerce JUMP_LABEL (new_thread) to be an insn, but it's a RETURN. I introduced this one in r214684 (aka patch #218) Sorry; am working on a fix.
[Bug bootstrap/62304] [5 regression] ICE in follow_jumps, find_dead_or_set_registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62304 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #1 from Dave Malcolm dmalcolm at redhat dot com --- The crash in find_dead_or_set_registers is the one discussed in: https://gcc.gnu.org/ml/gcc-patches/2014-08/msg02619.html and I introduced it in r214693 (aka patch #225) The crash in follow_jumps is similar to it, and occurs here: new_thread = follow_jumps (JUMP_LABEL_AS_INSN (new_thread), insn, crossing); where JUMP_LABEL_AS_INSN erroneously tries to coerce JUMP_LABEL (new_thread) to be an insn, but it's a RETURN. I introduced this one in r214684 (aka patch #218) I see, thanks. I completely lost track what's happening in this patch series... Sorry; am working on a fix. Great, thanks. Rainer
[Bug c++/60430] static_assert and reference to const/constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60430 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-29 Ever confirmed|0 |1
[Bug c++/59938] [C++11] Bogus ... is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59938 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- This is already fixed in mainline. I'm addding the testcase and closing the bug.
[Bug c++/59938] [C++11] Bogus ... is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59938 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Fri Aug 29 12:24:17 2014 New Revision: 214724 URL: https://gcc.gnu.org/viewcvs?rev=214724root=gccview=rev Log: 2014-08-29 Paolo Carlini paolo.carl...@oracle.com PR c++/59938 * g++.dg/cpp0x/constexpr-59938.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-59938.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 59938, which changed state. Bug 59938 Summary: [C++11] Bogus ... is not a constant expression https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59938 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/59938] [C++11] Bogus ... is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59938 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- Done.
[Bug c++/62305] New: throw segfaults on 64bit Cygwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62305
Bug ID: 62305
Summary: throw segfaults on 64bit Cygwin
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dominik.stras...@onespin-solutions.com
The symptoms of this problems are quite similar to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56747, however it is no *always*
cured by compiling with -O1. I tried compiling various source files I have with
-O0, then the problem vanished, but later reappeared on a different exception
path.
Another thing I tried was to put the function below into a separate file and
trying with optimization options which did not succeed. Is the problem maybe
located not in the catching function but in the cleanup regions of a the stack
between the throw and the catch ?
Host triple: x86_64-w64-mingw32-g++
The function catching the exception looks like this:
pairunsigned,unsigned
ExpRef::getConstRange(CompEnv rCompEnv,const NetReg crNetReg) const {
CompEnv::BoolVarToggler noSideEffects(rCompEnv.deactivateSideEffects());
unsigned uiWidth = 0;
try {
uiWidth = crNetReg.width(rCompEnv);
if (!usePreciseConstRange) {
return pairunsigned,unsigned(uiWidth-1,0);
}
Sel::LLRes llIndex = checkRange(rCompEnv);
if (!llIndex.isEmpty() !llIndex.isPartiallyEmpty()
llIndex.isConstant()) {
assert(llIndex.left() = llIndex.right());
assert(llIndex.right() = 0);
assert(llIndex.llLeft() = llIndex.llRight());
// width might be 0 in error case ...
assert(llIndex.llLeft()+1 = uiWidth);
return pairunsigned,unsigned(llIndex.llLeft(),llIndex.llRight());
}
} catch(...) {
// do nothing
}
return pairunsigned,unsigned(uiWidth-1,0);
}
The crash looks like this:
gdb: unknown target exception 0x20474343 at 0x7fefcc8940d
Program received signal ?, Unknown signal.
[Switching to Thread 4920.0x1124]
0x07fefcc8940d in RaiseException ()
from C:\Windows\system32\KernelBase.dll
(gdb) where
#0 0x07fefcc8940d in RaiseException ()
from C:\Windows\system32\KernelBase.dll
#1 0x6144cd4d in libgcc_s_seh-1!_Unwind_RaiseException ()
from
C:\cygwin64\home\cve\distributions\unreleased_distributions\Distr\latest\onespin360\onespin\bin\cygwin64\libgcc_s_seh-1.dll
#2 0x6fcb76c8 in libstdc++-6!.cxa_throw ()
from
C:\cygwin64\home\cve\distributions\unreleased_distributions\Distr\latest\onespin360\onespin\bin\cygwin64\libstdc++-6.dll
Stackframe #3 is the throw location.
I know that this is not very much I have here for diagnosis, so it is morea
call for help on debugging this crash. Is there a way to find out which
function is currently unwound ?
[Bug tree-optimization/62291] PRE uses too much memory and compile-time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62291 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Fri Aug 29 12:39:50 2014 New Revision: 214727 URL: https://gcc.gnu.org/viewcvs?rev=214727root=gccview=rev Log: 2014-08-29 Richard Biener rguent...@suse.de PR tree-optimization/62291 * tree-ssa-pre.c (sorted_array_from_bitmap_set): Reserve exactly the vector size needed and use quick_push. (phi_translate_1): Adjust comment. (valid_in_sets): Remove block argument and remove pointless checking of NAMEs. (dependent_clean): Adjust for removal of block argument. (clean): Likewise. (compute_antic_aux): Likewise. (compute_partial_antic_aux): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-pre.c
[Bug c++/57764] class static constexpr variables cannot be references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57764 --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com --- This is fixed in 4.9.0 and mainline. I'm adding the testcase and closing the bug.
[Bug c++/57764] class static constexpr variables cannot be references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57764 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Fri Aug 29 12:47:19 2014 New Revision: 214728 URL: https://gcc.gnu.org/viewcvs?rev=214728root=gccview=rev Log: 2014-08-29 Paolo Carlini paolo.carl...@oracle.com PR c++/57764 * g++.dg/cpp0x/constexpr-57764.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-57764.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 57764, which changed state. Bug 57764 Summary: class static constexpr variables cannot be references https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57764 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/57764] class static constexpr variables cannot be references
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57764 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Done.
[Bug tree-optimization/62291] PRE uses too much memory and compile-time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62291 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- As said in the mail for the just applied patch: The second patch (once done) will refactor insertion phase to do a dominator walk similar to what elimination does computing AVAIL_OUT on-the-fly (and only keeping it live for a single block). It's a bit more complicated than for elimination as insertion looks at a block and all its predecessors, it's also a bit more costly as we iterate insertion. It's also more costly because computing AVAIL_OUT on-the-fly requires looking at all statements which insertion currently doesn't do at all. So I've not yet settled on a final idea how to best re-factor it, eventually insertion and elimination can be merged (and then still iterate(?)). Ideas welcome ;)
[Bug lto/62026] [4.9/5 Regression] Crash in lto_get_decl_name_mapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62026 --- Comment #7 from Stuart Foster smf.linux at ntlworld dot com --- (In reply to Markus Trippelsdorf from comment #6) (In reply to Stuart Foster from comment #5) (In reply to Markus Trippelsdorf from comment #4) *** Bug 62303 has been marked as a duplicate of this bug. *** Which branch of gcc is this fix in ? It is not fixed yet. Sorry miss read comment 3.
[Bug c++/56991] constexpr std::initializer_list rejects too complex initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56991 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.1 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- This is fixed in 4.9.1 and mainline. I'm adding a reduced testcase and closing the bug.
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 56991, which changed state. Bug 56991 Summary: constexpr std::initializer_list rejects too complex initialization https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56991 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/56991] constexpr std::initializer_list rejects too complex initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56991 --- Comment #6 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Fri Aug 29 13:12:02 2014 New Revision: 214729 URL: https://gcc.gnu.org/viewcvs?rev=214729root=gccview=rev Log: 2014-08-29 Paolo Carlini paolo.carl...@oracle.com PR c++/56991 * g++.dg/cpp0x/constexpr-56991.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-56991.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/62301] [5 Regression] PowerPC bootstrap broken since r214654
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62301 --- Comment #2 from Bill Schmidt wschmidt at gcc dot gnu.org --- Example backtrace for segv: #0 0x4d5a28a0 in ?? () #1 0x10370128 in mem_loc_descriptor(rtx_def*, machine_mode, machine_mode, var_init_status) () #2 0x103704f4 in mem_loc_descriptor(rtx_def*, machine_mode, machine_mode, var_init_status) () #3 0x1037a59c in loc_descriptor(rtx_def*, machine_mode, var_init_status) () #4 0x1037a7b8 in loc_descriptor(rtx_def*, machine_mode, var_init_status) () #5 0x1037ad58 in dw_loc_list_1(tree_node*, rtx_def*, int, var_init_status) () #6 0x10375dac in loc_list_from_tree(tree_node*, int) () #7 0x1037d43c in add_location_or_const_value_attribute(die_struct*, tree_node*, bool, dwarf_attribute) [clone .constprop.340] () #8 0x10363e3c in gen_variable_die(tree_node*, tree_node*, die_struct*) () #9 0x10365dd4 in gen_decl_die(tree_node*, tree_node*, die_struct*) () #10 0x10380484 in decls_for_scope(tree_node*, die_struct*, int) () #11 0x1035fd70 in gen_subprogram_die(tree_node*, die_struct*) () #12 0x10365b18 in gen_decl_die(tree_node*, tree_node*, die_struct*) () #13 0x10367518 in dwarf2out_function_decl(tree_node*) () #14 0x103e65a0 in (anonymous namespace)::pass_final::execute(function*) () #15 0x10635a7c in execute_one_pass(opt_pass*) () #16 0x10636184 in execute_pass_list_1(opt_pass*) () #17 0x1063619c in execute_pass_list_1(opt_pass*) () #18 0x1063619c in execute_pass_list_1(opt_pass*) () #19 0x10636224 in execute_pass_list(function*, opt_pass*) () #20 0x102d98a4 in cgraph_node::expand() () #21 0x102db3b8 in symbol_table::compile() () #22 0x102dd2f8 in symbol_table::finalize_compilation_unit() () #23 0x10132738 in c_write_global_declarations() () #24 0x107220c0 in compile_file() () #25 0x1072522c in toplev_main(int, char**) () #26 0x1010f288 in main ()
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 54126, which changed state. Bug 54126 Summary: ICE on constexpr move ctor with const ref type instead of error https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54126 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/54126] ICE on constexpr move ctor with const ref type instead of error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54126 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |RESOLVED Known to work||4.8.0, 4.9.1, 5.0 Resolution|--- |FIXED --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed long time ago. ICEs with improperly reduced testcases involving std::initializer_list (per Comment #3) are fixed in mainline (Dup of c++/60848, c++/61723).
[Bug bootstrap/62301] [5 Regression] PowerPC bootstrap broken since r214654
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62301
--- Comment #3 from Bill Schmidt wschmidt at gcc dot gnu.org ---
Looks like a subtle logic change in the patch:
+ FOR_EACH_SUBRTX (iter, array, body, ALL)
+if (const_rtx y = *iter)
+ {
+ /* Check if a label_ref Y refers to label X. */
+ if (GET_CODE (y) == LABEL_REF LABEL_P (y) XEXP (y, 0) == x)
+ return true;
- if (*body == NULL_RTX)
-return y == NULL_RTX;
+ if (rtx_equal_p (x, y))
+ return true;
- /* Return true if a label_ref *BODY refers to label Y. */
- if (GET_CODE (*body) == LABEL_REF LABEL_P (y))
-return XEXP (*body, 0) == y;
If XEXP (y, 0) != x, it seems we should return false to match what was done
before. Testing a patch to fix this.
[Bug bootstrap/62301] [5 Regression] PowerPC bootstrap broken since r214654
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62301 --- Comment #4 from Bill Schmidt wschmidt at gcc dot gnu.org --- Unfortunately that was not sufficient -- same SEGVs are still occurring.
[Bug c++/62306] New: [4.9/5 Regression?] Change in the comdat used for constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62306
Bug ID: 62306
Summary: [4.9/5 Regression?] Change in the comdat used for
constructors
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rafael.espindola at gmail dot com
CC: jason at redhat dot com
Given
struct Option {
virtual ~Option() {}
};
template class DataType class opt : public Option {};
template class optint;
before r206182
gcc would print
.section.text._ZN3optIiED0Ev,axG,@progbits,_ZN3optIiED0Ev,comdat
now it prints
.section.text._ZN3optIiED0Ev,axG,@progbits,_ZN3optIiED5Ev,comdat
It looks reasonable to use D5, but it is not clear if that was intentional and
there are no tests for this change in behaviour.
[Bug sanitizer/62307] New: -fsanitize=undefined doesn't pay attention to __attribute__((returns_nonnull))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62307
Bug ID: 62307
Summary: -fsanitize=undefined doesn't pay attention to
__attribute__((returns_nonnull))
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: zackw at panix dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Consider
extern int *__errno_location(void)
__attribute__ ((__const__))
__attribute__ ((__returns_nonnull__));
void set_errno(int x)
{
(*__errno_location()) = x;
}
(This is a close approximation to how GNU libc defines errno -- there currently
isn't a returns_nonnull annotation, but I'm about to file a bug for _that_ ;-)
With 4.9.1, -fsanitize=undefined -O2 -fdump-tree-optimized, I get
set_errno (int x)
{
int * _1;
bb 2:
_1 = __errno_location ();
if (_1 == 0B)
goto bb 3;
else
goto bb 4;
bb 3:
__builtin___ubsan_handle_type_mismatch (*.Lubsan_data0, 0);
bb 4:
*_1 = x_3(D);
return;
}
The returns_nonnull annotation should cause the compiler to delete the runtime
check. (None of the RTL passes delete it either.)
This type of unnecessary check is the single largest source of calls to
__builtin___ubsan_handle_type_mismatch in a real program. I see a number of
other cases where we could be doing better at eliminating these checks on this
pointer is already known to be non-NULL grounds, e.g.
if (_191 == 0B)
goto bb 17;
else
goto bb 18;
bb 17:
__builtin___ubsan_handle_type_mismatch (*.Lubsan_data26, 0);
bb 18:
*_191 = _37;
if (_191 == 0B)
goto bb 19;
else
goto bb 20;
bb 19:
__builtin___ubsan_handle_type_mismatch (*.Lubsan_data27, 0);
... so maybe it's a pass-ordering problem? Or rather, the fact that
UBSAN_NULL() is an opaque operation until .sanopt, which prevents nearly all of
the tree optimizers from doing anything with it?
[Bug target/62281] gcc doesn't conform to Solaris 32-bit ABI by expecting 16-byte stack alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62281 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added CC||ro at gcc dot gnu.org Target Milestone|--- |5.0 --- Comment #6 from Rainer Orth ro at gcc dot gnu.org --- I've been seeing the same issue in PR middle-end/61949, but only on Solaris 10, not S11, and the failures have been intermittent (i.e. happened during one bootstrap, but were gone a week later). Regarding I believe the problem was fixed for the limited case of Solaris 9 x86 in bug 60107. However, the analysis for this fix seems slightly off. It infers that, because Solaris 10 creates outgoing thread stacks aligned on 16 bytes, the 32-bit ABI has changed to 16-byte stack alignment on this platform, which isn't correct. I believe the i386 psABI is irrelevant here: while it requires word alignment, it doesn't preclude that Solaris guarantees a stricter alignment, which from what I've seen both S10 and S11 do. I suggest -mincoming-stack-boundary=2 should be the default for all 32-bit Solaris binaries. Before making any changes in this area, I'd like word from the responsible libc engineer (Roger Faulkner probably) what various Solaris versions do and don't guarantee. Rainer
[Bug sanitizer/62307] -fsanitize=undefined doesn't pay attention to __attribute__((returns_nonnull))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62307 Marc Glisse glisse at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org --- -fsanitize=null seems to imply -fno-delete-null-pointer-checks, so I assume this is on purpose. It would actually be quite natural for the sanitizer to insert an extra check after every call to a returns_nonnull function, checking that the result is indeed !=0. Otherwise yes, sanopt is way too late for any other optimization to take place.
[Bug bootstrap/62301] [5 Regression] PowerPC bootstrap broken since r214654
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62301 rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-08-29 CC||rsandifo at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- (In reply to Bill Schmidt from comment #4) Unfortunately that was not sufficient -- same SEGVs are still occurring. Sorry, it was a really dumb typo. Instead of: if (GET_CODE (y) == LABEL_REF LABEL_P (y) XEXP (y, 0) == x) it should be: if (GET_CODE (y) == LABEL_REF LABEL_P (x) XEXP (y, 0) == x) I confirmed that that is enough to get identical expmed.c code before and after the patch, am testing a full bootstrap now.
[Bug rtl-optimization/62308] New: A bug with aarch64 big-endian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62308
Bug ID: 62308
Summary: A bug with aarch64 big-endian
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: yml6087582 at 163 dot com
Hi, when I compiled test.c with aarch64-none-elf-gcc -mbig-endian -S ,it
reported the following error:
test.c:In function 'checkx2823':
test.c:3:25:internal compiler error:Segmentation fault
void checkx2823(struct S2823 args){};
test.c:
typedef int __attribute__((vector_size(16))) v4si;
struct S2823 {v4si a;int b[0];};
void checkx2823 (struct S2823 args){};
With the option of -mlittle-endian ,it would not have this error.And the error
would interrupt cc1 in the rtl-optimization reload,can someone help me find the
reason ?
Thankyou!
by yimingliang
[Bug target/62281] gcc doesn't conform to Solaris 32-bit ABI by expecting 16-byte stack alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62281 --- Comment #7 from joseph at codesourcery dot com joseph at codesourcery dot com --- FWIW, I recommended to Sun in Mar 2006 that the kernel should ensure 16-byte alignment for both signal handlers and process startup (apparently this resulted in Sun bug 6397812, Problem with stack alignment for signal delivery on AMD64). (This does not of course mean that the ABI ended up with such an alignment requirement at interface boundaries in general.)
[Bug bootstrap/62304] [5 regression] ICE in follow_jumps, find_dead_or_set_registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62304 --- Comment #3 from Dave Malcolm dmalcolm at redhat dot com --- Do you have preprocessed source handy for the reorg.c crash?
[Bug other/62248] Configure error with --with-fpu=fp-armv8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62248 --- Comment #3 from Yvan Roux yroux at gcc dot gnu.org --- Author: yroux Date: Fri Aug 29 15:41:52 2014 New Revision: 214731 URL: https://gcc.gnu.org/viewcvs?rev=214731root=gccview=rev Log: 2014-08-29 Yvan Roux yvan.r...@linaro.org Backport from mainline 2014-08-27 Yvan Roux yvan.r...@linaro.org PR other/62248 * config.gcc (arm*-*-*): Check --with-fpu against arm-fpus.def. Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config.gcc
[Bug bootstrap/62301] [5 Regression] PowerPC bootstrap broken since r214654
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62301 --- Comment #6 from Bill Schmidt wschmidt at gcc dot gnu.org --- Ah...I've been staring at the two versions for so long and that never leaped out at me. :) Thanks, Richard!
[Bug other/62248] Configure error with --with-fpu=fp-armv8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62248 Yvan Roux yroux at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||yroux at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Yvan Roux yroux at gcc dot gnu.org --- Done.
[Bug sanitizer/62307] -fsanitize=undefined doesn't pay attention to __attribute__((returns_nonnull))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62307 --- Comment #2 from Zack Weinberg zackw at panix dot com --- (In reply to Marc Glisse from comment #1) -fsanitize=null seems to imply -fno-delete-null-pointer-checks, so I assume this is on purpose. It would actually be quite natural for the sanitizer to insert an extra check after every call to a returns_nonnull function, checking that the result is indeed !=0. Otherwise yes, sanopt is way too late for any other optimization to take place. I had a different mental model of how ubsan was supposed to function -- I was expecting it to insert explicit checks before every construct with potentially runtime-undefined behavior (not due to array bounds or pointer lifetimes), but then for the compiler to try as hard as possible to *eliminate* the checks where provably unnecessary. I was hoping, in fact, to be able to use -fsanitize=undefined -fdump-tree-optimized as a poor man's tell me all the places where the program can't be proven *not* to have runtime-undefined behavior.
[Bug bootstrap/62301] [5 Regression] PowerPC bootstrap broken since r214654
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62301 --- Comment #7 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Fri Aug 29 15:51:13 2014 New Revision: 214733 URL: https://gcc.gnu.org/viewcvs?rev=214733root=gccview=rev Log: gcc/ PR bootstrap/62301 * rtlanal.c (rtx_referenced_p): Fix typo in LABEL_P call. Modified: trunk/gcc/ChangeLog trunk/gcc/rtlanal.c
[Bug c++/54002] [C++0x] Initializing constexpr static member using constexpr static method fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54002 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- I'm adding the testcase to the testsuite and closing the bug.
[Bug bootstrap/62301] [5 Regression] PowerPC bootstrap broken since r214654
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62301 rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- Patch applied.
[Bug bootstrap/62304] [5 regression] ICE in follow_jumps, find_dead_or_set_registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62304 --- Comment #4 from Dave Malcolm dmalcolm at redhat dot com --- (In reply to Dave Malcolm from comment #3) Do you have preprocessed source handy for the reorg.c crash? No need; I've reproduced it locally now.
[Bug c++/54002] [C++0x] Initializing constexpr static member using constexpr static method fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54002 --- Comment #5 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Fri Aug 29 15:58:26 2014 New Revision: 214734 URL: https://gcc.gnu.org/viewcvs?rev=214734root=gccview=rev Log: 2014-08-29 Paolo Carlini paolo.carl...@oracle.com PR c++/54002 * g++.dg/cpp0x/constexpr-54002.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-54002.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/54002] [C++0x] Initializing constexpr static member using constexpr static method fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54002 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- Done.
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 54002, which changed state. Bug 54002 Summary: [C++0x] Initializing constexpr static member using constexpr static method fails https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54002 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug bootstrap/62301] [5 Regression] PowerPC bootstrap broken since r214654
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62301 --- Comment #9 from Bill Schmidt wschmidt at gcc dot gnu.org --- Thanks, Richard!
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678 --- Comment #61 from Jason Merrill jason at gcc dot gnu.org --- Yes, for 4.9 probably better to remove the DECL_COMDAT check from ipa_visibility; there's really no need for it, as all artificial virtuals are implicitly inline and thus would always have DECL_COMDAT set if not for IPA clearing it.
[Bug bootstrap/61078] [5 Regression] ESA mode bootstrap failure since r209897
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61078 --- Comment #7 from Andreas Krebbel krebbel at gcc dot gnu.org --- (In reply to jgreenhalgh from comment #6) As mentioned in the original patch submission [1], the effect is to allow removal the removal of temporary registers when shuffling arguments for a call. Ok. In fact it is exactly the removal of a temporary reg which revealed the back-end bug. The overlapping live ranges so far protected us from running into this particular problem. If S/390 passes small numbers of arguments in registers, I'd expect the net result to be positive for performance. I agree. S/390 should be able to benefit from that so forget about reverting your patch :) I'll find a way to fix the patterns in question. Thanks for the explanation!
[Bug bootstrap/62304] [5 regression] ICE in follow_jumps, find_dead_or_set_registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62304 --- Comment #5 from Dave Malcolm dmalcolm at redhat dot com --- Created attachment 33416 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33416action=edit Candidate patch. Bootstrapped on x86_64; seems to work on stage1 cris and sparc
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678 --- Comment #62 from Jason Merrill jason at gcc dot gnu.org --- Created attachment 33417 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33417action=edit Patch #5 Like so. This patch fixes the bug in both 4.9 and trunk, but only when the linker plugin isn't used. If the linker plugin is used, the resolution file tells LTO to emit ~B even though it isn't used.
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678
--- Comment #63 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Hmm, I've tested the following with 4.9 branch:
diff --git a/gcc/ipa.c b/gcc/ipa.c
index ebaa82dbfe41..b55b8ccab4ac 100644
--- a/gcc/ipa.c
+++ b/gcc/ipa.c
@@ -980,11 +980,6 @@ function_and_variable_visibility (bool whole_program)
#endif
symtab_dissolve_same_comdat_group_list (node);
}
- gcc_assert ((!DECL_WEAK (node-decl)
- !DECL_COMDAT (node-decl))
- || TREE_PUBLIC (node-decl)
- || node-weakref
- || DECL_EXTERNAL (node-decl));
if (cgraph_externally_visible_p (node, whole_program))
{
gcc_assert (!node-global.inlined_to);
diff --git a/gcc/symtab.c b/gcc/symtab.c
index 288821d58ab9..cc2ee0f662b4 100644
--- a/gcc/symtab.c
+++ b/gcc/symtab.c
@@ -961,7 +961,6 @@ symtab_make_decl_local (tree decl)
if (DECL_ONE_ONLY (decl) || DECL_COMDAT (decl))
{
DECL_SECTION_NAME (decl) = 0;
- DECL_COMDAT (decl) = 0;
}
DECL_COMDAT_GROUP (decl) = 0;
DECL_WEAK (decl) = 0;
and it fixes all issues. I've successfully build pykde4, kdelibs and Firefox.
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678 --- Comment #64 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Markus Trippelsdorf from comment #63) I expect my patch will also fix it for you, then.
[Bug target/54418] [4.8 Regression] [SH] Invalid operands for opcode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54418 John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de changed: What|Removed |Added CC||glaubitz at physik dot fu-berlin.d ||e --- Comment #6 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- I'm seeing this issue again when compiling postgresql-9.4 with gcc-4.9.1, but I am not sure whether the issues are related. The tail of the build log is: gcc -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -I/usr/include/mit-krb5 -DLINUX_OOM_SCORE_ADJ=0 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -I../../../../src/include -I/«PKGBUILDDIR»/build/../src/include -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -I/usr/include/libxml2 -I/usr/include/tcl8.6 -c -o timestamp.o /«PKGBUILDDIR»/build/../src/backend/utils/adt/timestamp.c /tmp/ccBriPih.s: Assembler messages: /tmp/ccBriPih.s:1824: Error: invalid operands for opcode /tmp/ccBriPih.s:1838: Error: invalid operands for opcode make[6]: *** [timestamp.o] Error 1 The full buildlog can be found here [1]. Cheers, Adrian
[Bug target/43744] SH: Error: pcrel too far
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43744 John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de changed: What|Removed |Added CC||glaubitz at physik dot fu-berlin.d ||e --- Comment #12 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- I'm seeing this issue again when compiling binutils-2.24.51.20140818 with gcc-4.9.1, but I am not sure whether the issues are related. The tail of the build log is: /bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../opcodes -I. -I../../opcodes -I../bfd -I../../opcodes/../include -I../../opcodes/../bfd-W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -g -O2 -MT hppa-dis.lo -MD -MP -MF .deps/hppa-dis.Tpo -c -o hppa-dis.lo ../../opcodes/hppa-dis.c libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../../opcodes -I. -I../../opcodes -I../bfd -I../../opcodes/../include -I../../opcodes/../bfd -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -g -O2 -MT hppa-dis.lo -MD -MP -MF .deps/hppa-dis.Tpo -c ../../opcodes/hppa-dis.c -fPIC -DPIC -o .libs/hppa-dis.o /tmp/ccZrwibi.s: Assembler messages: /tmp/ccZrwibi.s:1903: Error: pcrel too far make[5]: *** [hppa-dis.lo] Error 1 The full buildlog can be found here [1]. Cheers, Adrian [1] http://buildd.debian-ports.org/status/fetch.php?pkg=binutilsarch=sh4ver=2.24.51.20140818-1stamp=1408638991
[Bug target/54418] [4.8 Regression] [SH] Invalid operands for opcode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54418 --- Comment #7 from John Paul Adrian Glaubitz glaubitz at physik dot fu-berlin.de --- (In reply to John Paul Adrian Glaubitz from comment #6) The full buildlog can be found here [1]. Forgot the actual link: http://buildd.debian-ports.org/status/fetch.php?pkg=postgresql-9.4arch=sh4ver=9.4~beta2-1stamp=1409261773
[Bug fortran/62309] New: -fno-automatic with -finit-local prevents initialization of automatics in recursive functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62309 Bug ID: 62309 Summary: -fno-automatic with -finit-local prevents initialization of automatics in recursive functions Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: fritzoreese at gmail dot com It seems with gcc-4.8.3 -fno-automatic prevents initializers from being applied to automatic variables. The following does not behave as I would expect it to with (linux-x86-64): function f (x) implicit none integer f, x integer a ! should be SAVEd from -fno-automatic a = a + x ! should increment by y every time f = a return endfunction recursive function g (x) implicit none integer g, x integer b ! should be automatic from recursive b = b + x ! should be set to y every time g = b return endfunction implicit none integer f, g ! Should return static value of a; accumulates x print *, f(3) ! - 3, ok print *, f(4) ! - 7, ok print *, f(2) ! - 2, ok ! Should return automatic value of c; equal to y each time print *, g(3) ! - garbage, expected 3 print *, g(4) ! - garbage, expected 4 print *, g(2) ! - garbage, expected 2 end $ gfortran -fno-automatic -finit-local-zero auto_test.f $ ./a.out 3 7 9 32770 32771 32769 $ According to gfortran's manual page, -fno-automatic should Treat each program unit (except those marked as RECURSIVE) as if the SAVE statement were specified for every local variable [...]. As far as I can tell, -finit-local-zero should still initialize automatic variables in RECURSIVE functions.
[Bug fortran/62309] -fno-automatic with -finit-local prevents initialization of automatics in recursive functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62309
Fritz Reese fritzoreese at gmail dot com changed:
What|Removed |Added
CC||fritzoreese at gmail dot com
--- Comment #1 from Fritz Reese fritzoreese at gmail dot com ---
Created attachment 33418
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33418action=edit
Patch and testcase
I believe this is a simple fix; to actually follow the specification set forth
in the man page, don't treat symbols in a RECURSIVE namespace as if they are
saved in resolve.c (apply_default_init_local):
2014-08-29 Fritz Reese reese-fr...@zai.com
* resolve.c (apply_default_init_local): Don't treat variables in
RECURSIVE units as saved.
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 43eb240..a428633 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -11104,6 +11104,7 @@ apply_default_init_local (gfc_symbol *sym)
result variable, which are also nonstatic. */
if (sym-attr.save || sym-ns-save_all
|| (gfc_option.flag_max_stack_var_size == 0 !sym-attr.result
+ !sym-ns-proc_name-attr.recursive
(!sym-attr.dimension || !is_non_constant_shape_array (sym
{
/* Don't clobber an existing initializer! */
diff --git a/gcc/testsuite/gfortran.dg/auto_save_2.f90
b/gcc/testsuite/gfortran.
new file mode 100644
index 000..0d39d48
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/auto_save_2.f90
@@ -0,0 +1,52 @@
+! { dg-do run }
+! { dg-options -fno-automatic -finit-local-zero }
+!
+! Make sure variables are saved with -fno-automatic except in
+! functions marked RECURSIVE, and that they are still initialized with
+! -finit-local-zero.
+!
+
+function f (x)
+implicit none
+ integer f, x
+ integer a ! should be SAVEd
+ a = a + x ! should increment by y every time
+ f = a
+ return
+endfunction
+
+recursive function g (x)
+implicit none
+ integer g, x
+ integer b ! should be automatic
+ b = b + x ! should be set to y every time
+ g = b
+ return
+endfunction
+
+implicit none
+integer f, g
+
+! Should return static value of a; accumulates y
+if ( f(3) .ne. 3 ) then
+ call abort ()
+endif
+if ( f(4) .ne. 7 ) then
+ call abort ()
+endif
+if ( f(2) .ne. 9 ) then
+ call abort ()
+endif
+
+! Should return automatic value of a; equal to y each time
+if ( g(3) .ne. 3 ) then
+ call abort ()
+endif
+if ( g(4) .ne. 4 ) then
+ call abort ()
+endif
+if ( g(2) .ne. 2 ) then
+ call abort ()
+endif
+
+end
[Bug c++/62306] [4.9/5 Regression?] Change in the comdat used for constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62306 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-29 CC|jason at redhat dot com|jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org --- So, the change to use D5 for the deleting dtor was deliberate when we started using D5 for the base/complete dtor aliases in 4.5. Then 4.7 started using D0 again for some reason, and then 4.9 went back to D5. Jakub, do you remember why you wanted to put the deleting dtor in D5 in the first place? The gcc-patches threads don't seem to mention why. https://gcc.gnu.org/ml/gcc-patches/2009-11/threads.html#00700 https://gcc.gnu.org/ml/gcc-patches/2009-11/threads.html#01768 https://gcc.gnu.org/ml/gcc-patches/2009-12/threads.html#00023
[Bug fortran/62215] Updating .mod files on Win32 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62215 --- Comment #8 from Janne Blomqvist jb at gcc dot gnu.org --- Author: jb Date: Fri Aug 29 20:46:15 2014 New Revision: 214742 URL: https://gcc.gnu.org/viewcvs?rev=214742root=gccview=rev Log: PR 62215 Reinstate unlinking old module file before renaming. 2014-08-29 Jeffrey Armstrong jeffrey.armstr...@approximatrix.com PR fortran/62215 * module.c (gfc_dump_module): Unlink old module file before renaming new one. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/module.c
[Bug fortran/62215] Updating .mod files on Win32 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62215 --- Comment #9 from Janne Blomqvist jb at gcc dot gnu.org --- Author: jb Date: Fri Aug 29 20:49:16 2014 New Revision: 214743 URL: https://gcc.gnu.org/viewcvs?rev=214743root=gccview=rev Log: PR 62215 Unlink old module file before renaming. 2014-08-29 Jeffrey Armstrong jeffrey.armstr...@approximatrix.com Backport from trunk PR fortran/62215 * module.c (gfc_dump_module): Unlink old module file before renaming new one. Modified: branches/gcc-4_9-branch/gcc/fortran/ChangeLog branches/gcc-4_9-branch/gcc/fortran/module.c
[Bug bootstrap/57125] Build not SMP safe; fails to build bconfig.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57125 Andrew Oakley andrew at ado dot is-a-geek.net changed: What|Removed |Added CC||andrew at ado dot is-a-geek.net --- Comment #5 from Andrew Oakley andrew at ado dot is-a-geek.net --- Created attachment 33419 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33419action=edit Possible fix Attached is a patch which appears to fix this issue for me (on gcc 4.8.3). In gcc/Makefile.in there is a comment: # The gengtype generator program is special: Two versions are built. # One is for the build machine, and one is for the host to allow # plugins to define their types and generate the supporting GGC # datastructures and routines with GTY markers. # The host object files depend on CONFIG_H, and the build objects # on BCONFIG_H. For the build objects, add -DGENERATOR_FILE manually, # the build-%: rule doesn't apply to them. The change I chose to make swaps the make dependencies around, alternatively GENERATOR_FILE may defined in the wrong case. I'm not sure what the right behaviour is here, or which set of objects is which!
[Bug sanitizer/62307] -fsanitize=undefined doesn't pay attention to __attribute__((returns_nonnull))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62307 --- Comment #3 from Alexey Samsonov samsonov at google dot com --- FYI, Jakub has proposed a patch to add additional check to -fsanitize=undefined that would specifically sanitize functions with returns_nonnull attribute: however, it would sanitize bodies of the function and insert checks before return-statements to verify in runtime that the function actually doesn't return null.
[Bug c++/62302] [5 Regression] Change in the comdat used for constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62302 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2014-08-29 CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/62215] Updating .mod files on Win32 fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62215 Janne Blomqvist jb at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #10 from Janne Blomqvist jb at gcc dot gnu.org --- Fixed on trunk and 4.9, closing. Thanks for the report and patch!
[Bug bootstrap/62304] [5 regression] ICE in follow_jumps, find_dead_or_set_registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62304 --- Comment #6 from Steve Ellcey sje at gcc dot gnu.org --- (In reply to Dave Malcolm from comment #5) Created attachment 33416 [details] Candidate patch. Bootstrapped on x86_64; seems to work on stage1 cris and sparc This patch fixed my MIPS build. I am running the testsuite now and it looks good so far.
[Bug c++/62310] New: fails to consider default initializers (NSDMIs) when checking inheriting constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62310
Bug ID: 62310
Summary: fails to consider default initializers (NSDMIs) when
checking inheriting constructors
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Consider:
struct A { A(int); A() = delete; };
struct B { B(int); B() = delete; };
struct C : B { using B::B; A a = 0; } c(0);
GCC rejects this valid code:
stdin:1:114: error: use of deleted function ‘C::C(int)’
stdin:1:97: note: ‘C::C(int)’ is implicitly deleted because the default
definition would be ill-formed:
stdin:1:97: error: use of deleted function ‘A::A()’
stdin:1:20: note: declared here
However, if you remove the '= delete' from A, GCC does in fact call A::A(int),
so this seems to be limited to determining if the inheriting constructor should
be deleted.
[Bug other/62311] New: Found a potential copy and paste issue on in gcc/config/cr16.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62311
Bug ID: 62311
Summary: Found a potential copy and paste issue on in
gcc/config/cr16.c
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: ettl.martin at gmx dot de
Please take a look at following suspicious code, where the same statement
appears twice in a logical or-operation:
/*file gcc/config/cr16.c, line 2027*/
static bool
cr16_frame_pointer_required (void)
{
return (cfun-calls_alloca || crtl-calls_eh_return
|| cfun-has_nonlocal_label || crtl-calls_eh_return);
}
As you can see, the statement crtl-calls_eh_return appears twice, which looks
like a copypaste issue.
Best regards and many thanks
Martin Ettl
[Bug bootstrap/57125] Build not SMP safe; fails to build bconfig.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57125 --- Comment #6 from Andrew Oakley andrew at ado dot is-a-geek.net --- Sorry, this patch doesn't seem sufficient (perhaps I was just lucky for a while). Apologies for the noise.
[Bug target/43744] SH: Error: pcrel too far
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43744 Kazumoto Kojima kkojima at gcc dot gnu.org changed: What|Removed |Added Known to work|| --- Comment #13 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to John Paul Adrian Glaubitz from comment #12) I'm seeing this issue again when compiling binutils-2.24.51.20140818 with gcc-4.9.1, but I am not sure whether the issues are related. I can't reproduce it in my environment. Could you please attach the preprocessed .i file for the problematic case?
[Bug c++/62310] fails to consider default initializers (NSDMIs) when checking inheriting constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62310 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #1 from Paul Pluzhnikov ppluzhnikov at google dot com --- Google ref: b/17333074
[Bug target/62312] New: [4.9/5 Regression] [SH] Invalid operands for opcode div0s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62312 Bug ID: 62312 Summary: [4.9/5 Regression] [SH] Invalid operands for opcode div0s Product: gcc Version: 4.9.1 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: kkojima at gcc dot gnu.org CC: glaubitz at physik dot fu-berlin.de, olegendo at gcc dot gnu.org Target: sh*-*-* Created attachment 33420 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33420action=edit A reduced test case for -O2 The attached test case generates an invalid instruction like div0s @(4,r8),r1 with -O2. It seems that (define_insn *cmp_div0s_0 [(set (reg:SI T_REG) (eq:SI (lshiftrt:SI (match_operand:SI 0 arith_reg_operand) (const_int 31)) (ge:SI (match_operand:SI 1 arith_reg_operand) (const_int 0] TARGET_SH1 div0s%0,%1 [(set_attr type arith)]) has no constraints.
[Bug target/54418] [4.8 Regression] [SH] Invalid operands for opcode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54418 --- Comment #8 from Kazumoto Kojima kkojima at gcc dot gnu.org --- (In reply to John Paul Adrian Glaubitz from comment #6) I'm seeing this issue again when compiling postgresql-9.4 with gcc-4.9.1, but I am not sure whether the issues are related. I've filed a new PR62312 for the issue in #c6 because it looks a bit different problem.
