[Bug rtl-optimization/69896] [6 Regression] wrong code with -frename-registers @ x64_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69896 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Thu Feb 25 08:09:02 2016 New Revision: 233692 URL: https://gcc.gnu.org/viewcvs?rev=233692&root=gcc&view=rev Log: PR rtl-optimization/69896 * regcprop.c: Include cfgrtl.h. (copyprop_hardreg_forward_1): If noop_p insn uses narrower than remembered mode, either delete it (if noop_move_p), or treat like copy_p but not noop_p instruction. * gcc.dg/pr69896.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr69896.c Modified: trunk/gcc/ChangeLog trunk/gcc/regcprop.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/69896] [6 Regression] wrong code with -frename-registers @ x64_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69896 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug c++/69564] [5/6 Regression] lto and/or C++ make scimark2 LU slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69564 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #11 from Jakub Jelinek --- Maybe. But the middle-end is able to perform that optimization later too (e.g. during phiopt pass, or ifcvt).
[Bug libstdc++/69945] Provide an equivalent of __libc_freeres to release emergency EH pool memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69945 --- Comment #2 from Richard Biener --- but as the allocator lives in libsupc++ which is static only we can add that symbol there (unversioned)?
[Bug libstdc++/69945] Provide an equivalent of __libc_freeres to release emergency EH pool memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69945 --- Comment #3 from Jakub Jelinek --- libsupc++ is linked into libstdc++.so.6.
[Bug lto/69953] New: Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953 Bug ID: 69953 Summary: Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: john.frankish at outlook dot com Target Milestone: --- I compiled libsigc++, glibmm, atkmm, cairomm and pangomm with "./configure --prefix=/usr/local --disable-static --localstatedir=/var" and no flags and gtkmm-2.24.4 with CXX="g++ -std=c++11" gparted-0.25 then compiles without problems If I repeat the same thing using CC="gcc -flto -fuse-linker-plugin -mtune=generic -Os -pipe" CXX="g++ -flto -fuse-linker-plugin -mtune=generic -Os -pipe" ./configure --prefix=/usr/local --disable-static --localstatedir=/var gparted-0.25 then fails to compile as below. The same issue exists with gtkmm-3.16.0 and inkscape-0.91 libtool: link: g++ -flto -fuse-linker-plugin -mtune=generic -Os -pipe -Wall -std=gnu++11 -o gpartedbin Copy_Blocks.o DMRaid.o Device.o DialogFeatures.o DialogManageFlags.o Dialog_Base_Partition.o Dialog_Disklabel.o Dialog_FileSystem_Label.o Dialog_Partition_Copy.o Dialog_Partition_Info.o Dialog_Partition_Name.o Dialog_Partition_New.o Dialog_Partition_Resize_Move.o Dialog_Progress.o Dialog_Rescue_Data.o DrawingAreaVisualDisk.o FS_Info.o FileSystem.o Frame_Resizer_Base.o Frame_Resizer_Extended.o GParted_Core.o HBoxOperations.o LVM2_PV_Info.o Operation.o OperationChangeUUID.o OperationCheck.o OperationCopy.o OperationCreate.o OperationDelete.o OperationDetail.o OperationFormat.o OperationLabelFileSystem.o OperationNamePartition.o OperationResizeMove.o Partition.o PipeCapture.o Proc_Partitions_Info.o SWRaid_Info.o TreeView_Detail.o Utils.o Win_GParted.o btrfs.o exfat.o ext2.o f2fs.o fat16.o hfs.o hfsplus.o jfs.o linux_swap.o lvm2_pv.o main.o nilfs2.o ntfs.o reiser4.o reiserfs.o ufs.o xfs.o -pthread -L/usr/local/lib /usr/local/lib/libgthread-2.0.so /usr/local/lib/libgtkmm-2.4.so /usr/local/lib/libatkmm-1.6.so /usr/local/lib/libgdkmm-2.4.so /usr/local/lib/libgiomm-2.4.so /usr/local/lib/libpangomm-1.4.so /usr/local/lib/libglibmm-2.4.so /usr/local/lib/libcairomm-1.0.so /usr/local/lib/libsigc-2.0.so /usr/local/lib/libgtk-x11-2.0.so /usr/local/lib/libgdk-x11-2.0.so /usr/local/lib/libpangocairo-1.0.so /usr/local/lib/libatk-1.0.so /usr/local/lib/libcairo.so /usr/local/lib/libgdk_pixbuf-2.0.so /usr/local/lib/libgio-2.0.so /usr/local/lib/libpangoft2-1.0.so /usr/local/lib/libpango-1.0.so /usr/local/lib/libgobject-2.0.so /usr/local/lib/libglib-2.0.so /usr/local/lib/libfontconfig.so /usr/local/lib/libfreetype.so /usr/local/lib/libparted-fs-resize.so /usr/local/lib/libparted.so -ldl /usr/lib/libuuid.so -pthread /tmp/cczCWt7F.ltrans0.ltrans.o: In function `Gtk::TreeViewColumn::TreeViewColumn(Glib::ustring const&, Gtk::TreeModelColumn const&) [clone .lto_priv.613]': :(.text+0x692): undefined reference to `VTT for Gtk::TreeViewColumn' :(.text+0x6ce): undefined reference to `VTT for Gtk::TreeViewColumn' :(.text+0x6e7): undefined reference to `vtable for Gtk::TreeViewColumn' :(.text+0x6ef): undefined reference to `vtable for Gtk::TreeViewColumn' :(.text+0x721): undefined reference to `VTT for Gtk::TreeViewColumn' :(.text+0x733): undefined reference to `VTT for Gtk::TreeViewColumn' /tmp/cczCWt7F.ltrans0.ltrans.o: In function `Gtk::TreeViewColumn::TreeViewColumn >(Glib::ustring const&, Gtk::TreeModelColumn > const&) [clone .lto_priv.612]': :(.text+0x2ca8): undefined reference to `VTT for Gtk::TreeViewColumn' :(.text+0x2ce4): undefined reference to `VTT for Gtk::TreeViewColumn' :(.text+0x2cfd): undefined reference to `vtable for Gtk::TreeViewColumn' :(.text+0x2d05): undefined reference to `vtable for Gtk::TreeViewColumn' :(.text+0x2d3c): undefined reference to `VTT for Gtk::TreeViewColumn' :(.text+0x2d4e): undefined reference to `VTT for Gtk::TreeViewColumn' /tmp/cczCWt7F.ltrans28.ltrans.o: In function `GParted::DialogManageFlags::DialogManageFlags(GParted::Partition const&, std::map, std::allocator > >) [clone .constprop.455]': :(.text+0xf1f): undefined reference to `VTT for Gtk::TreeViewColumn' :(.text+0xf65): undefined reference to `VTT for Gtk::TreeViewColumn' :(.text+0xf7f): undefined reference to `vtable for Gtk::TreeViewColumn' :(.text+0xf88): undefined reference to `vtable for Gtk::TreeViewColumn' :(.text+0xfd5): undefined reference to `VTT for Gtk::TreeViewColumn' :(.text+0xfec): undefined reference to `VTT for Gtk::TreeViewColumn' collect2: error: ld returned 1 exit status Makefile:512: recipe for target 'gpartedbin' failed make[2]: *** [gpartedbin] Error 1 make[2]: Leaving directory '/usr/src/gparted-0.25.0/src' Makefile:580: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/usr/src/gparted-0.25.0' Makefile:434: recipe for target 'all' failed make: *
[Bug tree-optimization/69776] [4.9/5 Regression] Wrong optimization with aliasing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69776 --- Comment #13 from Richard Biener --- Author: rguenth Date: Thu Feb 25 09:07:08 2016 New Revision: 233693 URL: https://gcc.gnu.org/viewcvs?rev=233693&root=gcc&view=rev Log: 2016-02-25 Richard Biener Backport from mainline 2016-02-15 Richard Biener PR tree-optimization/69776 * tree-ssa-sccvn.h (vn_reference_lookup): Adjust prototype. * tree-ssa-sccvn.c (vn_reference_lookup): Add parameter to indicate whether we can use TBAA to disambiguate against stores. Use alias-set zero if not. (visit_reference_op_store): Do not use TBAA when looking up redundant stores. * tree-ssa-pre.c (compute_avail): Use TBAA here. (eliminate_dom_walker::before_dom_children): But not when looking up redundant stores. * gcc.dg/torture/pr69776.c: New testcase. 2016-02-16 Richard Biener PR tree-optimization/69776 * tree-ssa-alias.c (indirect_ref_may_alias_decl_p): Get alias sets from caller. (indirect_refs_may_alias_p): Likewise. (refs_may_alias_p_1): Pass alias sets as from ao_ref. * tree-ssa-sccvn.c (vn_reference_lookup): Also adjust vr alias-set according to tbaa_p. * tree-ssa-dom.c (lookup_avail_expr): Add tbaa_p flag. (optimize_stmt): For redundant store discovery do not allow tbaa. * gcc.dg/torture/pr69776-2.c: New testcase. Added: branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr69776-2.c branches/gcc-5-branch/gcc/testsuite/gcc.dg/torture/pr69776.c Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/tree-ssa-alias.c branches/gcc-5-branch/gcc/tree-ssa-dom.c branches/gcc-5-branch/gcc/tree-ssa-pre.c branches/gcc-5-branch/gcc/tree-ssa-sccvn.c branches/gcc-5-branch/gcc/tree-ssa-sccvn.h
[Bug tree-optimization/69951] wrong code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69951 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-02-25 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Hm, this really seems like a wrong code. Started a long time ago, before r104500.
[Bug tree-optimization/69935] load not hoisted out of linked-list traversal loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69935
--- Comment #4 from Richard Biener ---
It FAILs
FAIL: gcc.dg/vect/vect-aggressive-1.c -flto -ffat-lto-objects
scan-tree-dump-ti
mes vect "vectorized 1 loops" 1
because in
__attribute__ ((noinline)) int
foo (void)
{
int i, res = 0;
#pragma omp simd safelen(8)
for (i = 0; i < N; i++)
{
int t = a[i];
if (c[i] != 0)
if (t != 100 & t > 5)
res += 1;
}
return res;
}
we now sink the load from a[i] into the if (c[i]...) which confuses
vectorization
or rather if-conversion:
t_5 = a[i_17];
tree could trap...
(yeah, it misses very basic support for checking index evolution, niter and
array bounds).
It also seems to miscompile the fortran FE somehow as I get loads of Fortran
testsuite FAILs of the sort
in gfc_format_decoder, at fortran/error.c:937^M
0x6346ae gfc_format_decoder^M
/space/rguenther/src/svn/trunk/gcc/fortran/error.c:937^M
0x1346a88 pp_format(pretty_printer*, text_info*)^M
/space/rguenther/src/svn/trunk/gcc/pretty-print.c:633^M
0x1342548 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)^M
/space/rguenther/src/svn/trunk/gcc/diagnostic.c:825^M
0x634537 gfc_error^M
/space/rguenther/src/svn/trunk/gcc/fortran/error.c:1279^M
(note the missing 'internal compiler error:') and
/space/rguenther/src/svn/trunk/gcc/testsuite/gfortran.dg/coarray/poly_run_3.f90:6:6:
Warning: Non-RECURSIVE procedure '__copy_MAIN___T' at (1) is possibly calling
itself recursively. Declare it RECURSIVE or use '-frecursive'^M
FAIL: gfortran.dg/coarray/poly_run_3.f90 -fcoarray=single -O2 -latomic (test
for excess errors)
[Bug libstdc++/69945] Provide an equivalent of __libc_freeres to release emergency EH pool memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69945 --- Comment #4 from rguenther at suse dot de --- On Thu, 25 Feb 2016, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69945 > > --- Comment #3 from Jakub Jelinek --- > libsupc++ is linked into libstdc++.so.6. But the hook could be unversioned? AFAIK it is going to be used via dlsym only?
[Bug c/69104] invalid atomic memory order not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69104 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Marek Polacek --- Both patches committed.
[Bug c++/69952] ICE with a long double vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69952 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-02-25 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed with trunk. Even gcc 4.6 ICEs.
[Bug libstdc++/69945] Provide an equivalent of __libc_freeres to release emergency EH pool memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69945 --- Comment #5 from Jakub Jelinek --- Unversioned symbols in otherwise versioned shared library? On some systems impossible, on others possible through ugly hacks. IMHO we don't want that.
[Bug c++/69905] Digit separators break literal operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69905 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- It compiles for me with GCC 6 (and gnu++14).
[Bug c++/69836] compilation error with constexpr in template types with redeclared methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69836 --- Comment #1 from Marek Polacek --- *** Bug 69837 has been marked as a duplicate of this bug. ***
[Bug c++/69837] compilation error with constexpr in template types with redeclared methods
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69837 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Marek Polacek --- dup *** This bug has been marked as a duplicate of bug 69836 ***
[Bug lto/69953] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2016-02-25 CC||trippels at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf --- Find out which source file implements Gtk::TreeViewColumn. Attach the preprocessed file of that compilation unit here.
[Bug other/69006] [6 Regression] Extraneous newline emitted between error messages in GCC 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69006 --- Comment #6 from Andreas Krebbel --- Author: krebbel Date: Thu Feb 25 10:02:16 2016 New Revision: 233695 URL: https://gcc.gnu.org/viewcvs?rev=233695&root=gcc&view=rev Log: PR other/69006: S/390: Fix extra newlines after diagnostics. gcc/ChangeLog 2016-02-25 Dominik Vogt Backport from mainline 2016-01-29 Dominik Vogt PR other/69006 * config/s390/s390-c.c (s390_resolve_overloaded_builtin): Remove trailing blank line from error message. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/s390/s390-c.c
[Bug libgomp/69625] S/390 deadlock in libgomp.c/doacross-1.c test (vararg function trashes r6)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69625 --- Comment #5 from Andreas Krebbel --- Author: krebbel Date: Thu Feb 25 10:04:30 2016 New Revision: 233697 URL: https://gcc.gnu.org/viewcvs?rev=233697&root=gcc&view=rev Log: S/390: Fix r6 vararg handling. This patch fixes a problem introduced with the GPR into FPR slot save feature for leaf functions. r6 is argument register as well as call-saved. Currently we might decide that it will be a candidate for being saved into an FPR. If it turns out later that r6 also needs to be saved due to being required for vararg we undo the FPR save decision and put it on the stack again. Unfortunately the code did not adjust the GPR restore range accordingly so that the register does not get restored in the load multiple. This fixes the following testcases on s390x: < FAIL: libgomp.c/doacross-1.c execution test < FAIL: libgomp.c/doacross-2.c execution test < FAIL: libgomp.c/doacross-3.c execution test < FAIL: libgomp.c++/doacross-1.C execution test gcc/ChangeLog: 2016-02-25 Andreas Krebbel Backport from mainline 2016-02-05 Andreas Krebbel PR target/69625 * config/s390/s390.c (SAVE_SLOT_NONE, SAVE_SLOT_STACK): New defines. (s390_register_info_gprtofpr): Use new macros above. (s390_register_info_stdarg_fpr): Adjust max_fpr to better match its name. (s390_register_info_stdarg_gpr): Adjust max_gpr to better match its name. Adjust restore and save gpr ranges. (s390_register_info_set_ranges): New function. (s390_register_info): Use new macros above. Call s390_register_info_set_ranges. (s390_optimize_register_info): Likewise. (s390_hard_regno_rename_ok): Use new macros. (s390_hard_regno_scratch_ok): Likewise. (s390_emit_epilogue): Likewise. (s390_can_use_return_insn): Likewise. (s390_optimize_prologue): Likewise. * config/s390/s390.md (GPR2_REGNUM, GPR6_REGNUM): New constants. Modified: branches/gcc-5-branch/gcc/ChangeLog branches/gcc-5-branch/gcc/config/s390/s390.c branches/gcc-5-branch/gcc/config/s390/s390.md
[Bug libgomp/69625] S/390 deadlock in libgomp.c/doacross-1.c test (vararg function trashes r6)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69625 --- Comment #6 from Andreas Krebbel --- Author: krebbel Date: Thu Feb 25 10:07:45 2016 New Revision: 233700 URL: https://gcc.gnu.org/viewcvs?rev=233700&root=gcc&view=rev Log: S/390: PR 69625: Add test case gcc/testsuite/ChangeLog 2016-02-25 Dominik Vogt Backport from mainline 2016-02-19 Dominik Vogt PR target/69625 * gcc.target/s390/pr69625.c: Add test case. Added: branches/gcc-5-branch/gcc/testsuite/gcc.target/s390/pr69625.c Modified: branches/gcc-5-branch/gcc/testsuite/ChangeLog
[Bug lto/69953] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953 --- Comment #2 from Richard Biener --- Also try GCC 5.3 (or a recent snapshot from the branch).
[Bug c++/69952] ICE with a long double vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69952 Richard Biener changed: What|Removed |Added Keywords||accepts-invalid, ||ice-on-invalid-code Target||x86_64-*-*, i?86-*-* --- Comment #2 from Richard Biener --- I think we should somehow reject this given its size is not power-of-two. Should work with long double 128 though.
[Bug c++/69954] New: internal compiler error: in dependent_type_p, at cp/pt.c:21141
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69954
Bug ID: 69954
Summary: internal compiler error: in dependent_type_p, at
cp/pt.c:21141
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: Caspar at Kielwein dot de
Target Milestone: ---
Created attachment 37788
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37788&action=edit
preprocessed code of reduced example
The attached code triggers an ICE on valid code.
The attached file is a reduced example from production code.
gcc test_range.ii --std=c++14
test_range.ii: In substitution of ‘template ::operator Container() [with Container = auto:1;
= ]’:
test_range.ii:18:60: required by substitution of ‘template constexpr decltype
((declval()(declval()((declval)()...)), void_flag()))
void_check(int) [with source = foo()::; sink =
foo()::; P = {}]’
test_range.ii:60:62: required by substitution of ‘template
decltype (invoke_helper(0), S, T>()) connection::operator()() [with S = foo()::; T =
foo()::]’
test_range.ii:79:44: required from here
test_range.ii:50:32: internal compiler error: in dependent_type_p, at
cp/pt.c:21141
template
^
0x60d62c dependent_type_p(tree_node*)
../../src/gcc/cp/pt.c:21141
0x60d960 dependent_scope_p(tree_node*)
../../src/gcc/cp/pt.c:21172
0x603007 make_typename_type(tree_node*, tree_node*, tag_types, int)
../../src/gcc/cp/decl.c:3513
0x615843 tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:12576
0x6254b4 type_unification_real
../../src/gcc/cp/pt.c:17151
0x6287fd fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, bool, bool)
../../src/gcc/cp/pt.c:16485
0x5e5af9 add_template_candidate_real
../../src/gcc/cp/call.c:3067
0x5e617c add_template_candidate
../../src/gcc/cp/call.c:3164
0x5e617c add_candidates
../../src/gcc/cp/call.c:5295
0x5e37db build_user_type_conversion_1
../../src/gcc/cp/call.c:3713
0x5e40e0 implicit_conversion
../../src/gcc/cp/call.c:1876
0x5e4e9c add_conv_candidate
../../src/gcc/cp/call.c:2220
0x5e5b5c add_template_candidate_real
../../src/gcc/cp/call.c:3118
0x5ea4be add_template_conv_candidate
../../src/gcc/cp/call.c:3179
0x5ea4be build_op_call_1
../../src/gcc/cp/call.c:4306
0x5ea4be build_op_call(tree_node*, vec**, int)
../../src/gcc/cp/call.c:4368
0x6b1eb8 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../src/gcc/cp/semantics.c:2426
0x613d55 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:15379
0x61314a tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:15159
0x614ce0 tsubst(tree_node*, tree_node*, int, tree_node*)
../../src/gcc/cp/pt.c:12655
Please submit a full bug report,
Could reproduce with gcc 4.9 and gcc 5.2.1
gcc 6 compiles correctly, ICE does not happen.
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
[Bug fortran/69955] New: Memory leak with array constructor and derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69955 Bug ID: 69955 Summary: Memory leak with array constructor and derived type Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mrestelli at gmail dot com Target Milestone: --- The attached code leaks memory for me: $ gfortran --version GNU Fortran (GCC) 6.0.0 20160224 (experimental) program p implicit none type :: t1 real, allocatable :: x(:) end type t1 type :: t2 type(t1), allocatable :: ts(:) end type t2 integer :: i,j type(t2) :: var(100) do i=1,100 allocate(var(i)%ts(i)) do j=1,i allocate(var(i)%ts(j)%x(i+j)) enddo enddo do j=1,1 ! change this to control the amount of leaked memory write(*,*) size( (/( var(i)%ts , i=1,size(var) )/) ) enddo do i=1,100 deallocate(var(i)%ts) enddo end program p
[Bug tree-optimization/69951] wrong code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69951 Richard Biener changed: What|Removed |Added Keywords||wrong-code CC||hubicka at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #2 from Richard Biener --- We have a duplicate for this - basically (most) of alias analysis doesn't handle aliases (hah). In this case it's points-to I think and then FRE facing # p_1 = PHI <&c(2), &b(3)> *p_1 = 1; d = 2; _11 = *p_1; and optimizing the load to 1. Honza has fixed some cases for GCC 6 but appearantly not points-to. See tree-ssa-structalias.c, lookup_vi_for_tree should probably canonicalize to the ultimate alias. pt_solution_set_var and pt_solution_includes_1 need to be adjusted accordingly as well. -fno-tree-pta fixes this bug (on trunk). Honza - I'd need sth like equal_address_to (as used in compare_base_decls) but "one sided" so that if two decls have the same address they get canonicalized to the same decl so I can continue to use DECL_UID equality for the alias check.
[Bug tree-optimization/69943] expressions with multiple associative operators don't always create instruction-level parallelism
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69943 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #4 from Richard Biener --- It's a long-standing issue that reassoc doesn't associate ! TYPE_OVERFLOW_WRAPS chains. It could do that to a limited extent (only cancelling ops that don't affect overflow) or fully if it re-writes the operation to unsigned arithmetic at commit time. Some way of detecting desired vs. just canonicalization transforms is required to avoid rewriting all signed integer ops into unsigned (well, maybe it's not that bad actually, who knows). I believe there is a duplicate PR about this somewhere.
[Bug fortran/69955] Memory leak with array constructor and derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69955 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-02-25 Blocks||68800 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from 4.8 up to trunk (6.0). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68800 [Bug 68800] Fortran FE produces many memory leaks
[Bug tree-optimization/48795] -Warray-bounds false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48795 Richard Biener changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #6 from Richard Biener --- I have a patch.
[Bug tree-optimization/66974] -Warray-bounds false positive with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66974 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2016-02-25 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #6 from Richard Biener --- Also fixed by loop header copying.
[Bug middle-end/63213] -Warray-bounds false positive with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63213 --- Comment #3 from Richard Biener --- Not fixed by loop header copying earlier.
[Bug tree-optimization/69956] New: [ICE] Wrong vector type @ fold-const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69956
Bug ID: 69956
Summary: [ICE] Wrong vector type @ fold-const
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: kyukhin at gcc dot gnu.org
Target Milestone: ---
Created attachment 37789
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37789&action=edit
Reproducer
Hello,
Attached testcase produces ICE when compiled as following:
gcc -S -O2 -march=skylake-avx512 repro.i -ftree-vectorize
I observe the ICE since 02.02.2016
/nfs/ims/home/kyukhin/repro.i:2:1: internal compiler error: tree check:
expected vector_type, have integer_type in co\
nst_unop, at fold-const.c:1665
fn1() {
^~~
0xda1f9c tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/export/users/gnutester/stability/svn/trunk/gcc/tree.c:9637
0x860742 tree_check(tree_node*, char const*, int, char const*, tree_code)
/export/users/gnutester/stability/svn/trunk/gcc/tree.h:3006
0x860742 const_unop(tree_code, tree_node*, tree_node*)
/export/users/gnutester/stability/svn/trunk/gcc/fold-const.c:1665
0xe7f639 gimple_resimplify1(gimple**, code_helper*, tree_node*, tree_node**,
tree_node* (*)(tree_node*))
/export/users/gnutester/stability/svn/trunk/gcc/gimple-match-head.c:85
0xee84b3 gimple_simplify(gimple*, code_helper*, tree_node**, gimple**,
tree_node* (*)(tree_node*), tree_node* (*)(tre\
e_node*))
/export/users/gnutester/stability/svn/trunk/gcc/gimple-match-head.c:622
0x8a0933 gimple_fold_stmt_to_constant_1(gimple*, tree_node* (*)(tree_node*),
tree_node* (*)(tree_node*))
/export/users/gnutester/stability/svn/trunk/gcc/gimple-fold.c:4981
0xc409d2 back_propagate_equivalences
/export/users/gnutester/stability/svn/trunk/gcc/tree-ssa-dom.c:881
0xc409d2 record_temporary_equivalences(edge_def*, const_and_copies*,
avail_exprs_stack*)
/export/users/gnutester/stability/svn/trunk/gcc/tree-ssa-dom.c:963
0xd0663a thread_through_normal_block
/export/users/gnutester/stability/svn/trunk/gcc/tree-ssa-threadedge.c:858
0xd07a22 thread_across_edge(gcond*, edge_def*, bool, const_and_copies*,
avail_exprs_stack*, tree_node* (*)(gimple*, g\
imple*, avail_exprs_stack*))
/export/users/gnutester/stability/svn/trunk/gcc/tree-ssa-threadedge.c:1005
0xc404c0 dom_opt_dom_walker::thread_across_edge(edge_def*)
/export/users/gnutester/stability/svn/trunk/gcc/tree-ssa-dom.c:989
0xc406eb dom_opt_dom_walker::after_dom_children(basic_block_def*)
/export/users/gnutester/stability/svn/trunk/gcc/tree-ssa-dom.c:1423
0x11a47a7 dom_walker::walk(basic_block_def*)
/export/users/gnutester/stability/svn/trunk/gcc/domwalk.c:307
0xc432a0 execute
/export/users/gnutester/stability/svn/trunk/gcc/tree-ssa-dom.c:614
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
I suspect scalar masks.
[Bug tree-optimization/69951] wrong code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69951 Richard Biener changed: What|Removed |Added Known to work||3.4.6 Known to fail||4.0.0 --- Comment #3 from Richard Biener --- 3.x worked.
[Bug bootstrap/69709] [6 Regression] profiled bootstrap error on s390x-linux-gnu with r233194
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69709 --- Comment #8 from Dominik Vogt --- Created attachment 37790 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37790&action=edit Test case The option -fpeel-loops triggers the bug. The attached program has a different result with -fpeel-loops than without it. $ gcc -O2 -march=z10 -fpeel-loops pr69709.c && ./a.out 1 bits set in result $ gcc -O2 -march=z10 pr69709.c && ./a.out 2 bits set in result (2 is the correct result).
[Bug bootstrap/69709] [6 Regression] profiled bootstrap error on s390x-linux-gnu with r233194
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69709 --- Comment #9 from Dominik Vogt --- (-fpeel-loops is activated by -fprofile-use, so this is the connection to profilesbootstrap.)
[Bug lto/69630] [6 Regression] LTO ICE in types_same_for_odr at ipa-devirt.c:402
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69630 --- Comment #5 from Jan Hubicka --- Author: hubicka Date: Thu Feb 25 12:10:04 2016 New Revision: 233711 URL: https://gcc.gnu.org/viewcvs?rev=233711&root=gcc&view=rev Log: PR ipa/69630 * ipa-devirt.c (possible_polymorphic_call_targets): Do not ICE on builtin_unreachable. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-devirt.c
[Bug tree-optimization/69956] [ICE] Wrong vector type @ fold-const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69956 Ilya Enkovich changed: What|Removed |Added CC||ysrumyan at gmail dot com --- Comment #1 from Ilya Enkovich --- Looks like it is r233068.
[Bug driver/68463] Offloading fails when some objects are compiled with LTO and some without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68463 --- Comment #4 from iverbin at gcc dot gnu.org --- Author: iverbin Date: Thu Feb 25 12:23:52 2016 New Revision: 233712 URL: https://gcc.gnu.org/viewcvs?rev=233712&root=gcc&view=rev Log: gcc/ PR driver/68463 * config/gnu-user.h (CRTOFFLOADBEGIN): Define. Add crtoffloadbegin.o if offloading is enabled and -fopenacc or -fopenmp is specified. (CRTOFFLOADEND): Likewise. (GNU_USER_TARGET_STARTFILE_SPEC): Add CRTOFFLOADBEGIN. (GNU_USER_TARGET_ENDFILE_SPEC): Add CRTOFFLOADEND. * lto-wrapper.c (offloadbegin, offloadend): Remove static vars. (offload_objects_file_name): New static var. (tool_cleanup): Remove offload_objects_file_name file. (find_offloadbeginend): Replace with ... (find_crtoffloadtable): ... this. (run_gcc): Remove offload_argc and offload_argv. Get offload_objects_file_name from -foffload-objects=... option. Read names of object files with offload from this file, pass them to compile_images_for_offload_targets. Don't call find_offloadbeginend and don't pass offloadbegin and offloadend to the linker. Don't pass offload non-LTO files to the linker, because now they're not claimed. libgcc/ PR driver/68463 * Makefile.in (crtoffloadtable$(objext)): New rule. * configure.ac (extra_parts): Add crtoffloadtable$(objext) if enable_offload_targets is not empty. * configure: Regenerate. * offloadstuff.c: Move __OFFLOAD_TABLE__ from crtoffloadend to crtoffloadtable. libgomp/ PR driver/68463 * testsuite/libgomp.oacc-c-c++-common/parallel-dims-2.c: Remove. lto-plugin/ PR driver/68463 * lto-plugin.c (struct plugin_offload_file): New. (offload_files): Change type. (offload_files_last, offload_files_last_obj): New. (offload_files_last_lto): New. (free_2): Adjust accordingly. (all_symbols_read_handler): Don't add offload files to lto_arg_ptr. Don't call free_1 for offload_files. Write names of object files with offloading to the temporary file. Add new option to lto_arg_ptr. (claim_file_handler): Don't claim file if it contains offload sections without LTO sections. If it contains offload sections, add to the list. Removed: trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/parallel-dims-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/gnu-user.h trunk/gcc/lto-wrapper.c trunk/libgcc/ChangeLog trunk/libgcc/Makefile.in trunk/libgcc/configure trunk/libgcc/configure.ac trunk/libgcc/offloadstuff.c trunk/libgomp/ChangeLog trunk/lto-plugin/ChangeLog trunk/lto-plugin/lto-plugin.c
[Bug c/63393] [regression]-ffreestanding not work: memset call cause valgrind crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63393 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |INVALID --- Comment #6 from Marek Polacek --- Given Comment 5 I suppose this is invalid.
[Bug tree-optimization/69956] [6 Regression] Wrong vector type @ fold-const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69956
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-02-25
Target Milestone|--- |6.0
Summary|[ICE] Wrong vector type @ |[6 Regression] Wrong vector
|fold-const |type @ fold-const
Ever confirmed|0 |1
--- Comment #2 from Richard Biener ---
We have VEC_UNPACK_HI_EXPR of 'int' type on { 0, 0, ... }
vect_patt_45.15_139 = [vec_unpack_hi_expr] mask__39.12_136;
_139 is of type int.
[Bug lto/69630] [6 Regression] LTO ICE in types_same_for_odr at ipa-devirt.c:402
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69630
--- Comment #6 from Tobias Burnus ---
(In reply to Jan Hubicka from comment #5)
> URL: https://gcc.gnu.org/viewcvs?rev=233711&root=gcc&view=rev
> Log:
> PR ipa/69630
> * ipa-devirt.c (possible_polymorphic_call_targets): Do not ICE
> on builtin_unreachable.
This does not fix the problem of the test case of comment 1. The committed
patch (comment 5) has added:
@@ -3181,6 +3181,7 @@ possible_polymorphic_call_targets (tree otr_type,
{
if (complete
&& nodes.length () == 1
+ && TREE_CODE (TREE_TYPE (nodes[0]->decl)) == METHOD_TYPE
&& warn_suggest_final_types
&& !outer_type->derived_types.length ())
Which doesn't prevent the ICE. The patch in comment 3 works - and has added the
following. (Cf. line numbers and last lines of the patches):
@@ -3197,6 +3198,7 @@
if (complete
&& warn_suggest_final_methods
&& nodes.length () == 1
+ && TREE_CODE (TREE_TYPE (nodes[0]->decl)) == METHOD_TYPE
&& types_same_for_odr (DECL_CONTEXT (nodes[0]->decl),
outer_type->type))
[Bug c/67956] gcc's printf attribute accepts %m as a format character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67956 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #7 from Marek Polacek --- Nothing to do here.
[Bug fortran/69834] Collision in derived type hashes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69834 --- Comment #5 from Paul Thomas --- Created attachment 37791 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37791&action=edit Better Patch I couldn't persuade the last patch to work on submodule_6.f08. Evidently, submodules wind up with their own vtables and so the addresses are not unique. I need to understand why this is the case, when modules are OK. I suspect that the name-mangling in trans-decl.c has something to do with it. In the mean time, the new attachment is a patch based on the use of the name itself and borrows the character capability of select case. This one bootstraps and regtests on FC23/x86_64 Paul
[Bug c++/69564] [5/6 Regression] lto and/or C++ make scimark2 LU slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69564 --- Comment #12 from Jakub Jelinek --- I don't see any difference though, neither with the fold-const.c change, nor with the loop-invert.patch (at least on my Haswell-E, -g -Ofast x86_64, single runs only; though, it shows the LU slowdown with C++ clearly, and also that clang wins on SOR and Sparse matmult, we win significantly on MonteCarlo and less significantly on FFT, C LU is comparable): gcc trunk 20160224 Composite Score: 2482.97 FFT Mflops: 1982.24(N=1024) SOR Mflops: 1904.08(100 x 100) MonteCarlo: Mflops: 677.65 Sparse matmult Mflops: 2775.38(N=1000, nz=5000) LU Mflops: 5075.48(M=100, N=100) g++ trunk 20160224 Composite Score: 2314.35 FFT Mflops: 1986.77(N=1024) SOR Mflops: 1903.29(100 x 100) MonteCarlo: Mflops: 678.80 Sparse matmult Mflops: 2775.33(N=1000, nz=5000) LU Mflops: 4227.54(M=100, N=100) g++ trunk 20160224 + fold-const.c MIN/MAX change Composite Score: 2331.88 FFT Mflops: 1983.28(N=1024) SOR Mflops: 1906.04(100 x 100) MonteCarlo: Mflops: 676.53 Sparse matmult Mflops: 2823.60(N=1000, nz=5000) LU Mflops: 4269.96(M=100, N=100) g++ trunk 20150224 + fold-const.c MIN/MAX change + loop-invert.patch Composite Score: 2332.00 FFT Mflops: 1983.18(N=1024) SOR Mflops: 1905.64(100 x 100) MonteCarlo: Mflops: 674.50 Sparse matmult Mflops: 2823.55(N=1000, nz=5000) LU Mflops: 4273.14(M=100, N=100) clang 3.8 Composite Score: 2418.13 FFT Mflops: 1583.23(N=1024) SOR Mflops: 2130.27(100 x 100) MonteCarlo: Mflops: 281.80 Sparse matmult Mflops: 3026.40(N=1000, nz=5000) LU Mflops: 5068.95(M=100, N=100) clang++ 3.8 Composite Score: 2434.04 FFT Mflops: 1595.89(N=1024) SOR Mflops: 2131.09(100 x 100) MonteCarlo: Mflops: 281.63 Sparse matmult Mflops: 3001.59(N=1000, nz=5000) LU Mflops: 5159.98(M=100, N=100)
[Bug c++/69564] [5/6 Regression] lto and/or C++ make scimark2 LU slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69564 --- Comment #13 from Richard Biener --- Would be still good to get rid of. Not sure why we key off in_gimple_form either. What we get is branches done in different directions and thus BB reorder entered with a different BB order. Edge frequencies seem to match but BB frequencies are off, somehow differently scaled. -;; basic block 21, loop depth 2, count 0, freq 655, maybe hot -;; Invalid sum of incoming frequencies 985, should be 655 +;; basic block 21, loop depth 2, count 0, freq 3, maybe hot ... ;; basic block 23, loop depth 2, count 0, freq 720, maybe hot +;; basic block 23, loop depth 2, count 0, freq 2, maybe hot etc. (- is C + is C++) very few edge frequency differences, but those on backedges for example: ;;pred: 25 [100.0%] (FALLTHRU,EXECUTABLE) -;;26 [91.0%] (TRUE_VALUE,EXECUTABLE) - # ivtmp.72_13 = PHI <0(25), ivtmp.72_14(26)> - # ivtmp.75_226 = PHI <0(25), ivtmp.75_192(26)> ... +;;26 [80.0%] (FALSE_VALUE,EXECUTABLE) + # ivtmp.73_13 = PHI <0(25), ivtmp.73_14(26)> + # ivtmp.76_226 = PHI <0(25), ivtmp.76_192(26)> it's already that at profile-estimate time (for LU_factor) which also has 2 more basic blocks and 3 more edges for C++ (with the folding thing "fixed"). Didn't check performance with the folding fixed.
[Bug target/61949] [6 regression] SEGV compiling gcc.dg/pch/import-[12].c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949 --- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #10 from Jakub Jelinek --- > Can you please bisect it to the exact change that reintroduced it? Sure: the reghunt found this patch: 2016-02-08 Richard Biener Jeff Law PR target/68273 * tree-ssanames.c (make_ssa_name_fn): Always use unqualified types for anonymous SSA names. Rainer
[Bug target/61949] [6 regression] SEGV compiling gcc.dg/pch/import-[12].c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949 --- Comment #12 from Richard Biener --- Can you please answer comment #5 now?
[Bug target/61949] [6 regression] SEGV compiling gcc.dg/pch/import-[12].c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949 --- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #12 from Richard Biener --- > Can you please answer comment #5 now? The testcase there compiles and executes just fine, both before and with your patch. Rainer
[Bug target/61949] [6 regression] SEGV compiling gcc.dg/pch/import-[12].c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949 --- Comment #14 from rguenther at suse dot de --- On Thu, 25 Feb 2016, ro at CeBiTec dot Uni-Bielefeld.DE wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949 > > --- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> --- > > --- Comment #12 from Richard Biener --- > > Can you please answer comment #5 now? > > The testcase there compiles and executes just fine, both before and with > your patch. Do the segfaults happen in the same place again?
[Bug c++/69957] New: Ambiguous overload due to incorrect partial ordering of V<> and V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69957
Bug ID: 69957
Summary: Ambiguous overload due to incorrect partial ordering
of V<> and V
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roman.perepelitsa at gmail dot com
Target Milestone: ---
=== Program #1 ===
template struct V {};
template
void Foo(V, V) {}
template
void Foo(V<>, V) {}
int main() {
Foo(V<>(), V<>());
}
Expected: compiles.
Actual: error: call of overloaded 'Foo(V<>, V<>)' is ambiguous.
=== Program #2 ===
(This might be a different bug)
template struct V {};
template
void Foo(V, V) {}
template
void Foo(V<>, Us&&...) {}
int main() {
Foo(V<>(), V<>());
}
Expected: error: call of overloaded 'Foo(V<>, V<>)' is ambiguous.
Actual: compiles.
[Bug target/61949] [6 regression] SEGV compiling gcc.dg/pch/import-[12].c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949 --- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE --- They do, and for the same reason: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1 (LWP 1)] 0x08f5ecc1 in md5_read_ctx (resbuf=0x8046fd8, ctx=0x8046e90) at /var/gcc/reghunt/trunk/libiberty/md5.c:91 91memcpy (resbuf, buffer, 16); 1: x/i $pc => 0x8f5ecc1 : movaps -0x28(%ebp),%xmm0 (gdb) p/x $ebp $1 = 0x8046e74 Rainer
[Bug debug/69785] c++filt can't demangle string or compiler produce wrong mangled string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69785 Matthias Klose changed: What|Removed |Added CC||doko at gcc dot gnu.org --- Comment #4 from Matthias Klose --- here's another symbol involving cxx13, taken from libecap 1.0.1 _ZN9__gnu_cxx13new_allocatorISt10_List_nodeISt4pairINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEENSt3tr18weak_ptrIN7libecap7adapter7ServiceEE9constructISG_IRKSF_EEEvPT_DpOT0_
[Bug tree-optimization/48795] -Warray-bounds false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48795 --- Comment #7 from Richard Biener --- Author: rguenth Date: Thu Feb 25 13:20:25 2016 New Revision: 233714 URL: https://gcc.gnu.org/viewcvs?rev=233714&root=gcc&view=rev Log: 2016-02-25 Richard Biener PR tree-optimization/48795 * tree-vrp.c (check_array_ref): Use array_at_struct_end_p. * gcc.dg/Warray-bounds-18.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/Warray-bounds-18.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vrp.c
[Bug tree-optimization/48795] -Warray-bounds false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48795 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||6.0 Resolution|--- |FIXED --- Comment #8 from Richard Biener --- Fixed on trunk.
[Bug target/61949] [6 regression] SEGV compiling gcc.dg/pch/import-[12].c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949 --- Comment #16 from rguenther at suse dot de --- On Thu, 25 Feb 2016, ro at CeBiTec dot Uni-Bielefeld.DE wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949 > > --- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE Uni-Bielefeld.DE> --- > They do, and for the same reason: > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 1 (LWP 1)] > 0x08f5ecc1 in md5_read_ctx (resbuf=0x8046fd8, ctx=0x8046e90) > at /var/gcc/reghunt/trunk/libiberty/md5.c:91 > 91memcpy (resbuf, buffer, 16); > 1: x/i $pc > => 0x8f5ecc1 : movaps -0x28(%ebp),%xmm0 > (gdb) p/x $ebp > $1 = 0x8046e74 So this is with bootstrap-O3? On x86_64-linux I get 0040 : 40: f3 0f 6f 07 movdqu (%rdi),%xmm0 44: 48 89 f0mov%rsi,%rax 47: 0f 11 06movups %xmm0,(%rsi) 4a: c3 retq 4b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) for it (with -O3, that is). Can you please tell me how to configure a cross (from x86_64-linux) and attach preprocessed source of md5.c?
[Bug tree-optimization/69956] [6 Regression] Wrong vector type @ fold-const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69956
Ilya Enkovich changed:
What|Removed |Added
CC||ienkovich at gcc dot gnu.org
--- Comment #3 from Ilya Enkovich ---
(In reply to Richard Biener from comment #2)
> We have VEC_UNPACK_HI_EXPR of 'int' type on { 0, 0, ... }
>
> vect_patt_45.15_139 = [vec_unpack_hi_expr] mask__39.12_136;
>
>
> _139 is of type int.
For multi-step conversion we get a type by mode:
intermediate_mode = insn_data[icode1].operand[0].mode;
intermediate_type
= lang_hooks.types.type_for_mode (intermediate_mode,
TYPE_UNSIGNED (prev_type));
We can never get boolean vector like this. We may introduce a target hook to
get boolean vector by mode or just compute it from the previous vectype. This
patch fixes ICE for the testcase:
diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
index 9678d7c..1434d98 100644
--- a/gcc/tree-vect-stmts.c
+++ b/gcc/tree-vect-stmts.c
@@ -9000,9 +9000,19 @@ supportable_widening_operation (enum tree_code code,
gimple *stmt,
for (i = 0; i < MAX_INTERM_CVT_STEPS; i++)
{
intermediate_mode = insn_data[icode1].operand[0].mode;
- intermediate_type
- = lang_hooks.types.type_for_mode (intermediate_mode,
- TYPE_UNSIGNED (prev_type));
+ if (VECTOR_BOOLEAN_TYPE_P (prev_type))
+ {
+ intermediate_type
+ = build_truth_vector_type (TYPE_VECTOR_SUBPARTS (prev_type) / 2,
+ current_vector_size);
+ if (intermediate_mode != TYPE_MODE (intermediate_type)
+ return false;
+ }
+ else
+ intermediate_type
+ = lang_hooks.types.type_for_mode (intermediate_mode,
+ TYPE_UNSIGNED (prev_type));
+
optab3 = optab_for_tree_code (c1, intermediate_type, optab_default);
optab4 = optab_for_tree_code (c2, intermediate_type, optab_default);
Similar change is is required for narrowing case.
[Bug debug/69785] c++filt can't demangle string or compiler produce wrong mangled string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69785 --- Comment #5 from Markus Trippelsdorf --- libcxxabi demangler doesn't handle any of the strings, too.
[Bug target/61949] [6 regression] SEGV compiling gcc.dg/pch/import-[12].c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949 --- Comment #17 from Richard Biener --- ./configure --target=i386-pc-solaris2.10 is not enough, with -O3 -msse2 and the preprocessed file I get md5_finish_ctx: ... callmd5_process_block movl12(%ebp), %eax addl$16, %esp movdqu (%ebx), %xmm0 movups %xmm0, (%eax) leal-12(%ebp), %esp popl%ebx popl%esi popl%edi popl%ebp ret thus the expected unaligned moves, also not from the stacak.
[Bug fortran/69955] Memory leak with array constructor and derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69955 Thomas Koenig changed: What|Removed |Added CC||tkoenig at gcc dot gnu.org --- Comment #2 from Thomas Koenig --- Compile time or runtime? (Can't test right now).
[Bug target/61949] [6 regression] SEGV compiling gcc.dg/pch/import-[12].c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949 --- Comment #18 from ro at CeBiTec dot Uni-Bielefeld.DE --- > So this is with bootstrap-O3? No, just a regular (i.e. -O2) bootstrap. I've just checked again: the SEGV doesn't happen with the stage1 compiler, but with both the stage2 and stage3 ones. > On x86_64-linux I get > > 0040 : > 40: f3 0f 6f 07 movdqu (%rdi),%xmm0 > 44: 48 89 f0mov%rsi,%rax > 47: 0f 11 06movups %xmm0,(%rsi) > 4a: c3 retq > 4b: 0f 1f 44 00 00 nopl 0x0(%rax,%rax,1) > > for it (with -O3, that is). Can you please tell me how to configure > a cross (from x86_64-linux) and attach preprocessed source of md5.c? I'm configuring (natively) with configure --with-gmp=/vol/gcc --with-mpfr=/vol/gcc --with-mpc=/vol/gcc --without-ppl --without-cloog --enable-languages=c --disable-lto --disable-libgomp --disable-libquadmath --disable-libssp --disable-libitm --disable-libatomic --disable-libcilkrts --disable-multilib but all the --without-* and --disable-* options only serve to reduce reghunt time. For a cross, it should be sufficient to use --target=i386-pc-solaris2.10 Will attach md5.i immediately. Rainer
[Bug target/61949] [6 regression] SEGV compiling gcc.dg/pch/import-[12].c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949 --- Comment #19 from Rainer Orth --- Created attachment 37792 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37792&action=edit preprocessed libiberty/md5.c
[Bug fortran/69955] Memory leak with array constructor and derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69955 --- Comment #3 from Dominique d'Humieres --- > Compile time or runtime? (Can't test right now). My check was for run time: running the test grabs my 16Gb of memory. My guess is that the temporary for write(*,*) size( (/( var(i)%ts , i=1,size(var) )/) ) is not released.
[Bug debug/69785] c++filt can't demangle string or compiler produce wrong mangled string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69785 --- Comment #6 from Matthias Klose --- this one can be demangled: _ZN9__gnu_cxx13new_allocatorISt10_List_nodeISt4pairINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEENSt3tr18weak_ptrIN7libecap7adapter7ServiceEE9constructISG_JRKSF_EEEvPT_DpOT0_ it has _JRKSF_ instead of _IRKSF_
[Bug ipa/69589] [6 Regression] ICE in initialize_node_lattices, at ipa-cp.c:971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69589
Jan Hubicka changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2016-02-25
Ever confirmed|0 |1
--- Comment #15 from Jan Hubicka ---
Looking into the ICE now. Interesting detail is that type S is not merged even
though it is very simple:
#pragma GCC visibility push(hidden)
struct S {
int e;
virtual ~S () {}
};
--- aa 2016-02-25 14:35:42.111872702 +0100
+++ bb 2016-02-25 14:35:40.918649436 +0100
@@ -1,24 +1,26 @@
- constant 128>
unit size constant 16>
align 64 symtab 0 alias set -1 canonical type 0x76cbc2a0
-fields
unsigned DI
size
unit size
align 64 symtab 0 alias set -1 structural equality>
-unsigned virtual DI file a.C line 7 col 8
+unsigned virtual DI file b.C line 38 col 8
size
unit size
align 64 offset_align 128
offset
-bit offset context
-chain
-nonlocal SI file a.C line 8 col 7
+bit offset context
+chain
+nonlocal SI file b.C line 39 col 7
size
unit size
align 32 offset_align 128
offset
-bit offset context
>> context
-chain >duplicate #0
+bit offset context
>> context
+pointer_to_this chain >
dunno why it can't be merged.
Richi, any idea?
[Bug target/61949] [6 regression] SEGV compiling gcc.dg/pch/import-[12].c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949 --- Comment #20 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #17 from Richard Biener --- > ./configure --target=i386-pc-solaris2.10 > > is not enough, with -O3 -msse2 and the preprocessed file I get > > md5_finish_ctx: > ... > callmd5_process_block > movl12(%ebp), %eax > addl$16, %esp > movdqu (%ebx), %xmm0 > movups %xmm0, (%eax) > leal-12(%ebp), %esp > popl%ebx > popl%esi > popl%edi > popl%ebp > ret > > thus the expected unaligned moves, also not from the stacak. That's what I get when I manually compile with -O3 -msse2. But the compile happens with /var/gcc/reghunt/pch-import-1/28660/./prev-gcc/xgcc -B/var/gcc/reghunt/pch-import-1/28660/./prev-gcc/ -B/usr/local/i386-pc-solaris2.10/bin/ -B/usr/local/i386-pc-solaris2.10/bin/ -B/usr/local/i386-pc-solaris2.10/lib/ -isystem /usr/local/i386-pc-solaris2.10/include -isystem /usr/local/i386-pc-solaris2.10/sys-include-c -DHAVE_CONFIG_H -g -O2 -I. -I/var/gcc/reghunt/trunk/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic -D_GNU_SOURCE /var/gcc/reghunt/trunk/libiberty/md5.c -o md5.o effectively just -O2: md5_finish_ctx: [...] callmd5_process_block movl(%ebx), %eax addl$16, %esp movl%eax, -40(%ebp) movl4(%ebx), %eax movl%eax, -36(%ebp) movl8(%ebx), %eax movl%eax, -32(%ebp) movl12(%ebx), %eax movl%eax, -28(%ebp) movl12(%ebp), %eax movaps -40(%ebp), %xmm0 movups %xmm0, (%eax) leal-12(%ebp), %esp popl%ebx popl%esi popl%edi popl%ebp ret
[Bug debug/69785] c++filt can't demangle string or compiler produce wrong mangled string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69785 --- Comment #7 from Matthias Klose --- Created attachment 37793 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37793&action=edit preprocessed source both symbols are defined in https://sources.debian.net/src/libecap/1.0.1-3/src/libecap/common/registry.cc/ preprocessed source built by g++ -save-temps -DHAVE_CONFIG_H -I../../../src -I../../../src -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -std=c++11 -c registry.cc -fPIC -DPIC -o .libs/registry.o
[Bug fortran/69955] Memory leak with array constructor and derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69955 --- Comment #4 from mrestelli --- My problem also shows up at runtime, compilation is fine.
[Bug ipa/69589] [6 Regression] ICE in initialize_node_lattices, at ipa-cp.c:971
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69589 Jan Hubicka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #16 from Jan Hubicka --- I am looking into the actual ICE. The reason is that the function is virtual and it appears as possible polymorphic call target. As such it probably should not be declared local. Will cook up the patch.
[Bug fortran/38303] poor error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38303 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Dominique d'Humieres --- PR60144 is a duplicate containing more discussions. *** This bug has been marked as a duplicate of bug 60144 ***
[Bug fortran/60144] Misleading error message when missing "then" after "if" and "else if"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60144 Dominique d'Humieres changed: What|Removed |Added CC||Joost.VandeVondele at mat dot ethz ||.ch --- Comment #4 from Dominique d'Humieres --- *** Bug 38303 has been marked as a duplicate of this bug. ***
[Bug lto/69953] Using lto causes gtkmm/gparted and gtkmm/inkscape compile to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69953 --- Comment #3 from Martin Liška --- Hello. I've just tried to build latest inkscape (gparted) with latest GCC, and no problem seen for following configurations: inkscape: -Os -flto=9 -flto -fuse-linker-plugin -mtune=generic -Os -pipe gparted: -Os -flto=9 -flto -fuse-linker-plugin -mtune=generic -Os -pipe Martin
[Bug target/61949] [6 regression] SEGV compiling gcc.dg/pch/import-[12].c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949
--- Comment #21 from Richard Biener ---
Ok, can reproduce but I need -msse2 in addition to -O2 (but executing ./cc1 so
your diver may add that).
That's memcpy expanded as
uint128_t _36;
...
_36 = MEM[(char * {ref-all})&buffer];
MEM[(char * {ref-all})resbuf_31(D)] = _36;
via folding I guess.
tree type = lang_hooks.types.type_for_size (ilen * 8, 1);
if (type
&& TYPE_MODE (type) != BLKmode
&& (GET_MODE_SIZE (TYPE_MODE (type)) * BITS_PER_UNIT
== ilen * 8)
/* If the destination pointer is not aligned we must be able
to emit an unaligned store. */
&& (dest_align >= GET_MODE_ALIGNMENT (TYPE_MODE (type))
|| !SLOW_UNALIGNED_ACCESS (TYPE_MODE (type), dest_align)
|| (optab_handler (movmisalign_optab, TYPE_MODE (type))
!= CODE_FOR_nothing)))
{
tree srctype = type;
tree desttype = type;
if (src_align < GET_MODE_ALIGNMENT (TYPE_MODE (type)))
src_align is 32, dest_align is 8.
So when expanding we see
unit size
align 32 symtab 0 alias set -1 canonical type 0x768a9bd0 precision
128 min max >
arg 0
public unsigned SI
size
unit size
align 32 symtab 0 alias set -1 canonical type 0x76a1da80>
arg 0
used BLK file /var/gcc/reghunt/trunk/libiberty/md5.c line 84 col 14
size unit size
align 128 context
abstract_origin
(mem/c:BLK (plus:SI (reg/f:SI 82 virtual-stack-vars)
(const_int -16 [0xfff0])) [1 buffer+0 S16 A128])>
/var/gcc/reghunt/trunk/libiberty/md5.c:91:19 start:
/var/gcc/reghunt/trunk/libiberty/md5.c:91:19 finish:
/var/gcc/reghunt/trunk/libiberty/md5.c:91:24>
arg 1
constant 0>>
so the decl for 'buffer' actually got 128bit alignment from expansion! (thus
my pointing at incoming stack alignment guarantees on solaris)
You can see the same from md5_read_ctx:
md5_read_ctx:
subl$28, %esp
movl32(%esp), %edx
movl36(%esp), %eax
movl(%edx), %ecx
movl%ecx, (%esp)
movl4(%edx), %ecx
movl%ecx, 4(%esp)
movl8(%edx), %ecx
movl12(%edx), %edx
movl%ecx, 8(%esp)
movl%edx, 12(%esp)
movaps (%esp), %xmm0
movups %xmm0, (%eax)
addl$28, %esp
so either sth goes wrong just for the inline in finish_ctx or somehow we
set the desired alignment of this kind of locals too high.
[Bug target/61949] [6 regression] SEGV compiling gcc.dg/pch/import-[12].c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949 --- Comment #22 from Richard Biener --- Btw, don't see how this can be in any way related to the cited rev.
[Bug target/61949] [6 regression] SEGV compiling gcc.dg/pch/import-[12].c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949 --- Comment #23 from Richard Biener --- Well, looks like same analysis as the last time ;) Sth is broken on solaris - please check with gdb how the stack is aligned on function entry.
[Bug fortran/53576] Very unhelpful error message: "Unclassifiable statement" instead of "Can't convert TYPE to ..."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53576 --- Comment #2 from Dominique d'Humieres --- I get the error Error: Can't convert TYPE(amn_t) to COMPLEX(4) at (1) if I replace amn%nsites in do jj = 1, amn%nsites with a constant value (tested 0 and 5).
[Bug c++/68049] [5/6 Regression] template instantiation involving may_alias defines symbol twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68049 --- Comment #3 from Jason Merrill --- Author: jason Date: Thu Feb 25 14:09:18 2016 New Revision: 233715 URL: https://gcc.gnu.org/viewcvs?rev=233715&root=gcc&view=rev Log: PR c++/68049 * tree.c (strip_typedefs): Use DECL_ORIGINAL_TYPE. Added: trunk/gcc/testsuite/g++.dg/ext/attribute-may-alias-3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c
[Bug c++/67364] [5/6 Regression] "accessing uninitialized member" error in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67364 --- Comment #5 from Jason Merrill --- Author: jason Date: Thu Feb 25 14:09:24 2016 New Revision: 233716 URL: https://gcc.gnu.org/viewcvs?rev=233716&root=gcc&view=rev Log: PR c++/67364 * constexpr.c (cxx_eval_component_reference): Don't complain about unevaluated empty classes. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-empty10.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c
[Bug fortran/54687] Use gcc option machinery for gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54687 --- Comment #11 from Dominique d'Humieres --- What is left in this PR before closing it as FIXED?
[Bug c++/67364] [5/6 Regression] "accessing uninitialized member" error in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67364 --- Comment #6 from Jason Merrill --- Author: jason Date: Thu Feb 25 14:10:09 2016 New Revision: 233718 URL: https://gcc.gnu.org/viewcvs?rev=233718&root=gcc&view=rev Log: PR c++/67364 * constexpr.c (cxx_eval_component_reference): Don't complain about unevaluated empty classes. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-empty10.C Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/constexpr.c
[Bug c++/68049] [5/6 Regression] template instantiation involving may_alias defines symbol twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68049 --- Comment #4 from Jason Merrill --- Author: jason Date: Thu Feb 25 14:10:03 2016 New Revision: 233717 URL: https://gcc.gnu.org/viewcvs?rev=233717&root=gcc&view=rev Log: PR c++/68049 * tree.c (strip_typedefs): Use DECL_ORIGINAL_TYPE. Added: branches/gcc-5-branch/gcc/testsuite/g++.dg/ext/attribute-may-alias-3.C Modified: branches/gcc-5-branch/gcc/cp/ChangeLog branches/gcc-5-branch/gcc/cp/tree.c
[Bug c++/67364] [5/6 Regression] "accessing uninitialized member" error in constexpr context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67364 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #7 from Jason Merrill --- Fixed.
[Bug c++/68049] [5/6 Regression] template instantiation involving may_alias defines symbol twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68049 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jason Merrill --- Fixed.
[Bug c++/69958] New: sizeof... computes wrong size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69958
Bug ID: 69958
Summary: sizeof... computes wrong size
Product: gcc
Version: 5.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: CoachHagins at gmail dot com
Target Milestone: ---
When sizeof...() is used in a wrapped context, it computes the incorrect size.
This is evident when using std::index_sequence_for, but I think it's a language
problem and not a library problem because I can reproduce the same mal-behavior
without involving the standard library.
I get the same behavior in 5.2 and 5.3; -std=c++14
See the following code example.
template
struct list { };
template
struct size { };
template
using size_for = size;
template
using plain = size_for;
// This assertion passes
static_assert(std::is_same<
size<5>,
plain>::value, "");
template
using plain2 = size_for;
// This assertion passes
static_assert(std::is_same<
size<5>,
plain2>::value, "");
template
using wrapped = list>;
// This assertion fails (produces size<4>)
static_assert(std::is_same<
list>,
wrapped>::value, "");
template
using wrapped2 = list>;
// This assertion fails (produces size<2>)
static_assert(std::is_same<
list>,
wrapped2>::value, "");
[Bug fortran/55214] Program fail to evaluate where clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55214 --- Comment #3 from Dominique d'Humieres --- Still present on trunk (6.0) at revision r233693.
[Bug c++/69959] New: [6 Regression] gcc-6 doesn't build gcc-5 anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69959 Bug ID: 69959 Summary: [6 Regression] gcc-6 doesn't build gcc-5 anymore Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: trippels at gcc dot gnu.org Target Milestone: --- markus@x4 gcc % g++ -c -DIN_GCC_FRONTEND -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -Icp -I../../gcc/gcc -I../../gcc/gcc/cp -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/bid -I../libdecnumber -I../../gcc/gcc/../libbacktrace -o cp/except.o -MT cp/except.o -MMD -MP -MF cp/.deps/except.TPo ../../gcc/gcc/cp/except.c In file included from ./tm.h:27:0, from ../../gcc/gcc/cp/except.c:27: ../../gcc/gcc/config/elfos.h:102:21: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix] fprintf ((FILE), "%s"HOST_WIDE_INT_PRINT_UNSIGNED"\n",\ ^ ../../gcc/gcc/config/elfos.h:170:24: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix] fprintf ((FILE), ","HOST_WIDE_INT_PRINT_UNSIGNED",%u\n", \ ^ In file included from ./tm.h:48:0, from ../../gcc/gcc/cp/except.c:27: ../../gcc/gcc/defaults.h:126:24: warning: invalid suffix on literal; C++11 requires a space between literal and string macro [-Wliteral-suffix] fprintf ((FILE), ","HOST_WIDE_INT_PRINT_UNSIGNED",%u\n", \ ^ In file included from ../../gcc/gcc/cp/except.c:1023:0: cfns.gperf: In function ‘const char* libc_name_p(const char*, unsigned int)’: cfns.gperf:101:1: error: ‘const char* libc_name_p(const char*, unsigned int)’ redeclared inline with ‘gnu_inline’ attribute cfns.gperf:26:14: note: ‘const char* libc_name_p(const char*, unsigned int)’ previously declared here cfns.gperf: At global scope: cfns.gperf:26:14: warning: inline function ‘const char* libc_name_p(const char*, unsigned int)’ used but never defined was fine a few days ago.
[Bug fortran/56981] Slow I/O: Unformatted 5x slower, large sys component; formatted slow as well
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56981 Dominique d'Humieres changed: What|Removed |Added Status|NEW |WAITING --- Comment #13 from Dominique d'Humieres --- What is missing to close this PR as FIXED?
[Bug fortran/54687] Use gcc option machinery for gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54687 Dominique d'Humieres changed: What|Removed |Added Status|NEW |WAITING
[Bug c++/69785] c++filt can't demangle string or compiler produce wrong mangled string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69785
Markus Trippelsdorf changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
Component|debug |c++
--- Comment #8 from Markus Trippelsdorf ---
Might be a wrong code bug.
gcc-6 is fine:
markus@x4 tmp % cat registry.ii
namespace std {
inline namespace __cxx11 {}
template struct A { static constexpr _Tp value = __v;
};
template struct conditional;
template struct __and_;
template
struct __and_<_B1, _B2> : conditional<_B1>::type {};
template struct __is_convertible_helper {
template static A __test(int);
typedef decltype(__test<_From, _To>(0)) type;
};
template
struct is_convertible : __is_convertible_helper::type {};
template struct enable_if;
template struct conditional { typedef is_convertible type; };
template struct pair {
template >::value>>
pair(pair<_U1, _U2>);
};
template pair make_pair(_T1, _T2);
}
namespace __gnu_cxx {
template class new_allocator {
public:
template struct rebind { typedef new_allocator<_Tp1> other;
};
template
void construct(_Up *, _Args &&...) {}
};
}
namespace std {
template using __allocator_base = __gnu_cxx::new_allocator<_Tp>;
template class allocator : public __allocator_base {};
template struct char_traits;
namespace __cxx11 {
template >
class basic_string;
}
namespace tr1 {
template class weak_ptr;
}
}
namespace libecap {
bool RegisterVersionedService();
namespace adapter {
class Service {};
}
}
namespace std {
template struct _List_node;
template class B {
protected:
allocator::rebind<
_List_node>,
tr1::weak_ptr>>>::other
_M_get_Node_allocator();
};
class C : B>>> {
_List_node>,
tr1::weak_ptr>>
*_M_create_node___p;
template void _M_create_node(_Args &&... p1) try {
_M_get_Node_allocator().construct(_M_create_node___p, p1...);
} catch (...) {
}
public:
pair end();
pair push_back___trans_tmp_1 = end();
void push_back(const pair>,
tr1::weak_ptr>
p1) {
_M_insert(push_back___trans_tmp_1, p1);
}
template void _M_insert(pair, _Args &&... p2) {
_M_create_node(p2...);
}
};
}
std::C TheStagingArea;
char RegisterVersionedService_v;
bool libecap::RegisterVersionedService() {
adapter::Service s;
std::pair si = std::make_pair(RegisterVersionedService_v, s);
TheStagingArea.push_back(si);
}
markus@x4 tmp % clang++ -std=c++11 -w -c registry.ii -S -o - | grep
_ZN9__gnu_cxx13new_allocatorISt10_List_nodeISt4pairINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEENSt3tr18weak_ptrIN7libecap7adapter7ServiceEE9constructISG_IRKSF_EEEvPT_DpOT0_
markus@x4 tmp % g++ -std=c++11 -c registry.ii -S -o - | grep
_ZN9__gnu_cxx13new_allocatorISt10_List_nodeISt4pairINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEENSt3tr18weak_ptrIN7libecap7adapter7ServiceEE9constructISG_IRKSF_EEEvPT_DpOT0_
markus@x4 tmp % /usr/x86_64-pc-linux-gnu/gcc-bin/4.9.3/g++ -std=c++11 -c
registry.ii -S -o - | grep
_ZN9__gnu_cxx13new_allocatorISt10_List_nodeISt4pairINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEENSt3tr18weak_ptrIN7libecap7adapter7ServiceEE9constructISG_IRKSF_EEEvPT_DpOT0_
call
_ZN9__gnu_cxx13new_allocatorISt10_List_nodeISt4pairINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEENSt3tr18weak_ptrIN7libecap7adapter7ServiceEE9constructISG_IRKSF_EEEvPT_DpOT0_
.section
.text._ZN9__gnu_cxx13new_allocatorISt10_List_nodeISt4pairINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEENSt3tr18weak_ptrIN7libecap7adapter7ServiceEE9constructISG_IRKSF_EEEvPT_DpOT0_,"axG",@progbits,_ZN9__gnu_cxx13new_allocatorISt10_List_nodeISt4pairINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEENSt3tr18weak_ptrIN7libecap7adapter7ServiceEE9constructISG_IRKSF_EEEvPT_DpOT0_,comdat
.weak
_ZN9__gnu_cxx13new_allocatorISt10_List_nodeISt4pairINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEENSt3tr18weak_ptrIN7libecap7adapter7ServiceEE9constructISG_IRKSF_EEEvPT_DpOT0_
.type
_ZN9__gnu_cxx13new_allocatorISt10_List_nodeISt4pairINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEENSt3tr18weak_ptrIN7libecap7adapter7ServiceEE9constructISG_IRKSF_EEEvPT_DpOT0_,
@function
_ZN9__gnu_cxx13new_allocatorISt10_List_nodeISt4pairINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEENSt3tr18weak_ptrIN7libecap7adapter7ServiceEE9constructISG_IRKSF_EEEvPT_DpOT0_:
.size
_ZN9__gnu_cxx13new_allocatorISt10_List_nodeISt4pairINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEENSt3tr18weak_ptrIN7libecap7adapter7ServiceEE9constructISG_IRKSF_EEEvPT_DpOT0_,
.-_ZN9__gnu_cxx13new_allocatorISt10_List_nodeISt4pairINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEENSt3tr18weak_ptrIN7libecap7adapter7ServiceEE9constructISG_IRKSF_EEEvPT_DpOT0_
.set
_
[Bug driver/68463] Offloading fails when some objects are compiled with LTO and some without
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68463 iverbin at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from iverbin at gcc dot gnu.org --- Fixed in GCC 6.
[Bug c++/69564] [5/6 Regression] lto and/or C++ make scimark2 LU slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69564 --- Comment #14 from Jakub Jelinek --- With -Ofast -g -march=native -funroll-loops we actually (for C) beat clang on LU. The SOR difference is most likely IVOPTs/scheduling/RA thing, there is nothing to actually vectorize because of the dependencies. clang 3.8 (no matter if -funroll-loops is used or not) unrolls the main SOR loop 4 times and we get roughly: .align 16, 0x90 .LBB1_12: vmovsd -24(%r13,%rax,8), %xmm4 vaddsd -24(%r12,%rax,8), %xmm4, %xmm4 vmovsd -24(%rbx,%rax,8), %xmm5 vaddsd %xmm5, %xmm3, %xmm3 vaddsd %xmm3, %xmm4, %xmm3 vmulsd %xmm0, %xmm2, %xmm2 vfmadd231sd %xmm3, %xmm1, %xmm2 vmovsd %xmm2, -32(%rbx,%rax,8) vmovsd -16(%r13,%rax,8), %xmm3 vaddsd -16(%r12,%rax,8), %xmm3, %xmm3 vmovsd -16(%rbx,%rax,8), %xmm4 vaddsd %xmm4, %xmm3, %xmm3 vaddsd %xmm3, %xmm2, %xmm2 vmulsd %xmm0, %xmm5, %xmm3 vfmadd231sd %xmm2, %xmm1, %xmm3 vmovsd %xmm3, -24(%rbx,%rax,8) vmovsd -8(%r13,%rax,8), %xmm2 vaddsd -8(%r12,%rax,8), %xmm2, %xmm2 vmovsd -8(%rbx,%rax,8), %xmm5 vaddsd %xmm5, %xmm2, %xmm2 vaddsd %xmm2, %xmm3, %xmm2 vmulsd %xmm0, %xmm4, %xmm3 vfmadd231sd %xmm2, %xmm1, %xmm3 vmovsd %xmm3, -16(%rbx,%rax,8) vmovsd (%r13,%rax,8), %xmm2 vaddsd (%r12,%rax,8), %xmm2, %xmm4 vmovsd (%rbx,%rax,8), %xmm2 vaddsd %xmm2, %xmm4, %xmm4 vaddsd %xmm4, %xmm3, %xmm4 vmulsd %xmm0, %xmm5, %xmm3 vfmadd231sd %xmm4, %xmm1, %xmm3 vmovsd %xmm3, -8(%rbx,%rax,8) addq$4, %rax cmpl%eax, %r15d jne .LBB1_12 gcc -Ofast -g -march=native unrolls just twice: .p2align 4,,10 .p2align 3 .L9: vmovsd -8(%r8,%rdi,8), %xmm5 vmovsd -16(%r9,%rdi,8), %xmm1 vmulsd %xmm4, %xmm2, %xmm4 movslq %edi, %rax vaddsd -16(%r10,%rdi,8), %xmm1, %xmm1 vaddsd %xmm0, %xmm5, %xmm0 vmulsd %xmm5, %xmm2, %xmm5 vaddsd %xmm0, %xmm1, %xmm0 vmovapd %xmm0, %xmm1 vfmadd132sd %xmm3, %xmm4, %xmm1 vmovsd (%r8,%rdi,8), %xmm4 vmovsd %xmm1, -16(%r8,%rdi,8) vaddsd %xmm4, %xmm1, %xmm1 vmovsd -8(%r10,%rdi,8), %xmm0 vaddsd -8(%r9,%rdi,8), %xmm0, %xmm0 vaddsd %xmm1, %xmm0, %xmm0 vfmadd132sd %xmm3, %xmm5, %xmm0 vmovsd %xmm0, -8(%r8,%rdi,8) addq$2, %rdi cmpq%rcx, %rdi jne .L9 and with additional -funroll-loops we unroll 8 times instead: .L9: vmovsd -8(%rax,%rdi,8), %xmm6 vmovsd -16(%r8,%rdi,8), %xmm5 vmulsd %xmm7, %xmm1, %xmm8 leaq2(%rdi), %r14 vaddsd -16(%r9,%rdi,8), %xmm5, %xmm9 vmovsd (%rax,%rdi,8), %xmm12 leaq4(%rdi), %r10 vaddsd %xmm3, %xmm6, %xmm10 vmulsd %xmm6, %xmm1, %xmm7 vmulsd %xmm12, %xmm1, %xmm0 vaddsd %xmm10, %xmm9, %xmm11 vfmadd132sd %xmm2, %xmm8, %xmm11 vmovsd %xmm11, -16(%rax,%rdi,8) vaddsd %xmm12, %xmm11, %xmm15 vmovsd -8(%r9,%rdi,8), %xmm13 vaddsd -8(%r8,%rdi,8), %xmm13, %xmm14 vaddsd %xmm15, %xmm14, %xmm4 vfmadd132sd %xmm2, %xmm7, %xmm4 vmovsd %xmm4, -8(%rax,%rdi,8) vmovsd -8(%rax,%r14,8), %xmm6 vmovsd -16(%r8,%r14,8), %xmm3 vaddsd -16(%r9,%r14,8), %xmm3, %xmm8 vmovsd (%rax,%r14,8), %xmm10 vaddsd %xmm4, %xmm6, %xmm5 vmulsd %xmm6, %xmm1, %xmm11 vmulsd %xmm10, %xmm1, %xmm4 vaddsd %xmm5, %xmm8, %xmm9 vfmadd132sd %xmm2, %xmm0, %xmm9 vmovsd %xmm9, -16(%rax,%r14,8) vaddsd %xmm10, %xmm9, %xmm13 vmovsd -8(%r9,%r14,8), %xmm12 vaddsd -8(%r8,%r14,8), %xmm12, %xmm7 vaddsd %xmm13, %xmm7, %xmm14 vfmadd132sd %xmm2, %xmm11, %xmm14 vmovsd %xmm14, -8(%rax,%r14,8) vmovsd -8(%rax,%r10,8), %xmm15 vmovsd -16(%r8,%r10,8), %xmm6 vaddsd -16(%r9,%r10,8), %xmm6, %xmm0 vmovsd (%rax,%r10,8), %xmm9 vaddsd %xmm14, %xmm15, %xmm3 vmulsd %xmm15, %xmm1, %xmm5 vmulsd %xmm9, %xmm1, %xmm14 vaddsd %xmm3, %xmm0, %xmm8 vfmadd132sd %xmm2, %xmm4, %xmm8 vmovsd %xmm8, -16(%rax,%r10,8) vaddsd %xmm9, %xmm8, %xmm12 vmovsd -8(%r9,%r10,8), %xmm10 vaddsd -8(%r8,%r10,8), %xmm10, %xmm11 vaddsd %xmm12, %xmm11, %xmm7 vfmadd132sd %xmm2, %xmm5, %xmm7 vmovsd %xmm7, -8(%rax,%r10,8) leaq6(%rdi), %r10 addq$8, %rdi vmovsd -8(%rax,%r10,8), %xmm13 vmovsd -16(%r8,%r10,8), %xmm15 vaddsd -16(%r9,%r10,8), %xmm15, %xmm6 vaddsd %xmm7, %xmm13, %xmm4 vmovsd (%rax,%r10,8), %xmm7 vmulsd
[Bug fortran/61628] [MinGW)Write of medium sized or larger matrix fails without error message.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61628 --- Comment #23 from Dominique d'Humieres --- > Arjen, any further results or information on this bug? PING!
[Bug fortran/61628] [MinGW)Write of medium sized or larger matrix fails without error message.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61628 Dominique d'Humieres changed: What|Removed |Added Status|NEW |WAITING
[Bug c++/69959] [6 Regression] gcc-6 doesn't build gcc-5 anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69959 Jakub Jelinek changed: What|Removed |Added CC||edlinger at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- We want r233572 on the branches that use C++ compiler (or you need to bootstrap older compilers with g++ -std=gnu++98).
[Bug target/61949] [6 regression] SEGV compiling gcc.dg/pch/import-[12].c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949 --- Comment #24 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #22 from Richard Biener --- > Btw, don't see how this can be in any way related to the cited rev. This reghunt was straightforward, but last time I'd found that it this testcase was very sensitive to environment changes. Rainer
[Bug target/61949] [6 regression] SEGV compiling gcc.dg/pch/import-[12].c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61949
--- Comment #25 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #21 from Richard Biener ---
> Ok, can reproduce but I need -msse2 in addition to -O2 (but executing ./cc1 so
> your diver may add that).
It does: config.gcc has
i[34567]86-*-solaris2* | x86_64-*-solaris2.1[0-9]*)
# Set default arch_32 to pentium4, tune_32 to generic like the other
# i386 targets, although config.guess defaults to i386-pc-solaris2*.
with_arch_32=${with_arch_32:-pentium4}
with_tune_32=${with_tune_32:-generic}
thus cc1 is called with -mtune=generic -march=pentium4.
Rainer
[Bug c++/69842] [6 Regression] Parameter deduction in polymorphic lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69842 --- Comment #5 from Jason Merrill --- Author: jason Date: Thu Feb 25 15:23:47 2016 New Revision: 233719 URL: https://gcc.gnu.org/viewcvs?rev=233719&root=gcc&view=rev Log: PR c++/69842 * method.c (forward_parm): Handle parameter packs. * lambda.c (maybe_add_lambda_conv_op): Use it for them. Added: trunk/gcc/testsuite/g++.dg/cpp1y/lambda-generic-variadic4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/lambda.c trunk/gcc/cp/method.c
[Bug c++/69842] [6 Regression] Parameter deduction in polymorphic lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69842 Jason Merrill changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jason Merrill --- Fixed more. :)
[Bug c++/69842] [6 Regression] Parameter deduction in polymorphic lambdas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69842 Jason Merrill changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jason Merrill --- Fixed more. :)
[Bug c++/69959] [6 Regression] gcc-6 doesn't build gcc-5 anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69959 Bernd Edlinger changed: What|Removed |Added CC||bernd.edlinger at hotmail dot de --- Comment #2 from Bernd Edlinger --- (In reply to Jakub Jelinek from comment #1) > We want r233572 on the branches that use C++ compiler (or you need to > bootstrap older compilers with g++ -std=gnu++98). yes. I asked for permission here: https://gcc.gnu.org/ml/gcc-patches/2016-02/msg01409.html should I ping for it?
[Bug c++/69958] sizeof... computes wrong size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69958 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Trunk also fails the two static assertions, clang++ 3.8 accepts it.
[Bug sanitizer/69839] cross-compiling programs w/-fsanitize=address fails: ld: warning: libstdc++.so.6, needed by libasan.so, not found (try using -rpath or -rpath-link)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69839 --- Comment #6 from Joakim Tjernlund --- (In reply to Jakub Jelinek from comment #5) > Likely a bug on the Gentoo side. > The linker handles differently libraries specified on the command line and > libraries that are needed by those shared libraries, but are not mentioned > on the command line. See binutils documentation. Digging into this I noticed ld searches $sysroot/etc/ld.so.conf so I tried adding /usr/lib/gcc/powerpc-g2.20-linux-gnu/4.9.3/, like so: # ld.so.conf autogenerated by env-update; make all changes to # contents of /etc/env.d directory /usr/powerpc-g2.20-linux-gnu/lib /usr/lib/gcc/powerpc-g2.20-linux-gnu/4.9.3/ However I see using strace that ld tries to open: "/usr/powerpc-g2.20-linux-gnu/usr/lib/gcc/powerpc-g2.20-linux-gnu/4.9.3/libstdc++.so.6 That is, ld prefixes every path in ld.so.conf with $sysroot. Is that correct or a bug in binutils?
