[Bug target/63483] Scheduler performs Invalid move of aliased memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483 --- Comment #18 from rguenther at suse dot de --- On Thu, 9 Oct 2014, ubizjak at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483 > > Uroš Bizjak changed: > >What|Removed |Added > > Attachment #33665|0 |1 > is obsolete|| > > --- Comment #16 from Uroš Bizjak --- > Created attachment 33672 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33672&action=edit > Updated patch. Looks ok with all the explanation. I wonder when is the appropriate time to retire support for architectures without byte granular memory access.
[Bug target/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 --- Comment #17 from Richard PALO --- Created attachment 33675 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33675&action=edit c test program for snprintf I tried the attached test program and post the following results from my system demonstrating that the 'f' format does indeed seem erroneous, at least for the particular case in hand involving '1/3': $ /opt/local/gcc49/bin/gcc -std=c99 cflt.c $ ./a.out FLT_EVAL_METHOD = 2 (e) 1/3 => +3.33312e-01 (f) 1/3 => +0.2 (e) 1/7 => +1.42857142857142848e-01 (f) 1/7 => +0.14285714285714284 (e) 1/9 => +1.11104e-01 (f) 1/9 => +0.0
[Bug other/63504] [5 Regression] Issues found by --enable-checking=valgrind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63504 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.0
[Bug other/63504] [5 Regression] Issues found by --enable-checking=valgrind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63504 --- Comment #1 from Markus Trippelsdorf --- Two more variations of issue 3) ==47649== Invalid read of size 4 ==47649==at 0x10B00978: reg_num_sign_bit_copies_for_combine(rtx_def const*, machine_mode, rtx_def const*, machine_mode, unsigned int, unsigned int*) (combine.c:9581) ==47649==by 0x105E3CC3: num_sign_bit_copies1(rtx_def const*, machine_mode, rtx_def const*, machine_mode, unsigned int) (rtlanal.c:4661) ==47649==by 0x10B0493B: if_then_else_cond(rtx_def*, rtx_def**, rtx_def**) (combine.c:8785) ==47649==by 0x10B047D7: if_then_else_cond(rtx_def*, rtx_def**, rtx_def**) (combine.c:8640) ==47649==by 0x10B12D67: combine_simplify_rtx(rtx_def*, machine_mode, int, int) (combine.c:5270) ==47649==by 0x10B14C7B: subst(rtx_def*, rtx_def*, rtx_def*, int, int, int) (combine.c:5207) ==47649==by 0x10B14DF7: subst(rtx_def*, rtx_def*, rtx_def*, int, int, int) (combine.c:5152) ==47649==by 0x10B1694B: try_combine(rtx_insn*, rtx_insn*, rtx_insn*, rtx_insn*, int*, rtx_insn*) (combine.c:3093) ==47649==by 0x10B1BA47: combine_instructions (combine.c:1261) ==47649==by 0x10B1BA47: rest_of_handle_combine (combine.c:13902) ==47649==by 0x10B1BA47: (anonymous namespace)::pass_combine::execute(function*) (combine.c:13945) ==47649==by 0x10573E27: execute_one_pass(opt_pass*) (passes.c:2151) ==47649==by 0x105744C3: execute_pass_list_1(opt_pass*) (passes.c:2203) ==47649==by 0x105744DB: execute_pass_list_1(opt_pass*) (passes.c:2204) ==47649== Address 0x69d38a8 is 0 bytes after a block of size 1,720 alloc'd ==47649==at 0x402924C: malloc (vg_replace_malloc.c:296) ==47649==by 0x10C6DE73: xmalloc (xmalloc.c:147) ==47649==by 0x105B2883: regstat_init_n_sets_and_refs() (regstat.c:60) ==47649==by 0x10B1AEE3: rest_of_handle_combine (combine.c:13899) ==47649==by 0x10B1AEE3: (anonymous namespace)::pass_combine::execute(function*) (combine.c:13945) ==47649==by 0x10573E27: execute_one_pass(opt_pass*) (passes.c:2151) ==47649==by 0x105744C3: execute_pass_list_1(opt_pass*) (passes.c:2203) ==47649==by 0x105744DB: execute_pass_list_1(opt_pass*) (passes.c:2204) ==47649==by 0x1057455B: execute_pass_list(function*, opt_pass*) (passes.c:2214) ==47649==by 0x102E2157: cgraph_node::expand() (cgraphunit.c:1735) ==47649==by 0x102E3727: expand_all_functions (cgraphunit.c:1871) ==47649==by 0x102E3727: symbol_table::compile() (cgraphunit.c:2206) ==47649==by 0x102E4F93: symbol_table::finalize_compilation_unit() (cgraphunit.c:2283) ==47649==by 0x104DF877: write_global_declarations() (langhooks.c:328) ==47649== ==47649== Invalid read of size 4 ==47649==at 0x10B00C68: reg_nonzero_bits_for_combine(rtx_def const*, machine_mode, rtx_def const*, machine_mode, unsigned long, unsigned long*) (combine.c:9504) ==47649==by 0x105DAEF3: nonzero_bits1(rtx_def const*, machine_mode, rtx_def const*, machine_mode, unsigned long) (rtlanal.c:4175) ==47649==by 0x10B04C23: if_then_else_cond(rtx_def*, rtx_def**, rtx_def**) (combine.c:8792) ==47649==by 0x10B047D7: if_then_else_cond(rtx_def*, rtx_def**, rtx_def**) (combine.c:8640) ==47649==by 0x10B12D67: combine_simplify_rtx(rtx_def*, machine_mode, int, int) (combine.c:5270) ==47649==by 0x10B14C7B: subst(rtx_def*, rtx_def*, rtx_def*, int, int, int) (combine.c:5207) ==47649==by 0x10B14DF7: subst(rtx_def*, rtx_def*, rtx_def*, int, int, int) (combine.c:5152) ==47649==by 0x10B1694B: try_combine(rtx_insn*, rtx_insn*, rtx_insn*, rtx_insn*, int*, rtx_insn*) (combine.c:3093) ==47649==by 0x10B1BA47: combine_instructions (combine.c:1261) ==47649==by 0x10B1BA47: rest_of_handle_combine (combine.c:13902) ==47649==by 0x10B1BA47: (anonymous namespace)::pass_combine::execute(function*) (combine.c:13945) ==47649==by 0x10573E27: execute_one_pass(opt_pass*) (passes.c:2151) ==47649==by 0x105744C3: execute_pass_list_1(opt_pass*) (passes.c:2203) ==47649==by 0x105744DB: execute_pass_list_1(opt_pass*) (passes.c:2204) ==47649== Address 0x69d38a8 is 0 bytes after a block of size 1,720 alloc'd ==47649==at 0x402924C: malloc (vg_replace_malloc.c:296) ==47649==by 0x10C6DE73: xmalloc (xmalloc.c:147) ==47649==by 0x105B2883: regstat_init_n_sets_and_refs() (regstat.c:60) ==47649==by 0x10B1AEE3: rest_of_handle_combine (combine.c:13899) ==47649==by 0x10B1AEE3: (anonymous namespace)::pass_combine::execute(function*) (combine.c:13945) ==47649==by 0x10573E27: execute_one_pass(opt_pass*) (passes.c:2151) ==47649==by 0x105744C3: execute_pass_list_1(opt_pass*) (passes.c:2203) ==47649==by 0x105744DB: execute_pass_list_1(opt_pass*) (passes.c:2204) ==47649==by 0x1057455B: execute_pass_list(function*, opt_pass*) (passes.c:2214) ==47649==by 0x102E2157: cgraph_node::expand() (cgraphunit.c:1735) ==47649==by 0x102E3727: expand_all_functions (cgraphunit.c:1871) ==47649==by 0x102E3727: symbol_table::compile() (cgraphunit.c:2206) ==
[Bug libfortran/63471] [5.0 Regression] unix.c:1906:10: error: implicit declaration of function 'ttyname_r'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471 --- Comment #7 from Janne Blomqvist --- (In reply to dave.anglin from comment #3) > On some platforms (MacOS 10.4 and Solaris 11), ttyname_r may return a > 'char *', not 'int'. FWIW, libgfortran uses the AC_USE_SYSTEM_EXTENSIONS macro, which on Solaris defines _POSIX_PTHREAD_SEMANTICS making it prefer the POSIX _r functions instead of the POSIX draft _r versions. I'm not sure we care about OS X 10.4 anymore? Newer versions apparently provide the POSIX ttyname_r. So, are you planning on enabling _REENTRANT in the HP-UX 11 driver like you did for 10, or do you want to solve this in some other way?
[Bug target/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 --- Comment #18 from Richard PALO --- Created attachment 33676 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33676&action=edit another test program after coming across http://stackoverflow.com/questions/16839658/printf-width-specificer-to-maintain-precision-of-floating-point-value I modified the test program to the attached, and here is the output: FLT_EVAL_METHOD = 2 DBL_MANT_DIG = 53 DECIMAL_DIG = 21 DBL_DIG = 15 e precision 10 => +3.33e-01 f precision 10 => +0.33 e precision 11 => +3.333e-01 f precision 11 => +0.333 e precision 12 => +3.e-01 f precision 12 => +0. e precision 13 => +3.3e-01 f precision 13 => +0.3 e precision 14 => +3.33e-01 f precision 14 => +0.33 e precision 15 => +3.333e-01 f precision 15 => +0.333 e precision 16 => +3.3332e-01 f precision 16 => +0. e precision 17 => +3.33312e-01 f precision 17 => +0.2 e precision 18 => +3.333148e-01 f precision 18 => +0.12 e precision 19 => +3.3331483e-01 f precision 19 => +0.148 e precision 20 => +3.33314830e-01 f precision 20 => +0.1483 e precision 21 => +3.333148296e-01 f precision 21 => +0.14830 e precision 22 => +3.3331482962e-01 f precision 22 => +0.148296 e precision 23 => +3.33314829616e-01 f precision 23 => +0.1482962 e precision 24 => +3.333148296163e-01 f precision 24 => +0.14829616 e precision 25 => +3.3331482961626e-01 f precision 25 => +0.148296163
[Bug c++/63405] [4.9/5 regression] ICE in cp_perform_integral_promotions, at cp/typeck.c:2084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63405 --- Comment #15 from Gert-jan Los --- Created attachment 33678 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33678&action=edit test.log
[Bug c++/63405] [4.9/5 regression] ICE in cp_perform_integral_promotions, at cp/typeck.c:2084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63405 --- Comment #14 from Gert-jan Los --- 2014-10-08 23:06:21 CEST schrieb jason at gcc dot gnu.org: > --- Comment #12 from Jason Merrill --- > Author: jason > Date: Wed Oct 8 21:05:50 2014 > New Revision: 216013 > > URL: https://gcc.gnu.org/viewcvs?rev=216013&root=gcc&view=rev > Log: > PR c++/63405 > * pt.c (tsubst_pack_expansion): Limit simple expansion to type packs. Thank you. I can confirm this patch fixes the original issue on trunk. In addition it fixes the attached test case which showed false warnings about unused template pack arguments. (Now bootstrapping gcc-4_9-branch)
[Bug fortran/59488] [OpenMP] named constant in parallel construct leads to "not specified in enclosing parallel" error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59488 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Created attachment 33679 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33679&action=edit gcc5-pr59488.patch Untested fix.
[Bug other/63387] Optimize pairs of isnan() calls into a single isunordered()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63387 --- Comment #3 from Marc Glisse --- According to Joseph's explanation at https://sourceware.org/bugzilla/show_bug.cgi?id=17441 , this transformation should be conditional to !flag_signaling_nans.
[Bug c++/63207] [5 regression] ICE in expand_expr_real_l when instantiating a template with a lambda that captures a const variable with a dependent initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63207 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Blocks||54367 Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #2 from Paolo Carlini --- Fixed then.
[Bug other/63504] [5 Regression] Issues found by --enable-checking=valgrind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63504 --- Comment #2 from Markus Trippelsdorf --- To reproduce issue 3) run: valgrind --track-origins=yes --trace-children=yes gfortran gcc/testsuite/gfortran.dg/actual_array_result_1.f90 -fno-diagnostics-show-caret -fdiagnostics-color=never -Os -c
[Bug c++/54367] [meta-bug] lambda expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 Bug 54367 depends on bug 63207, which changed state. Bug 63207 Summary: [5 regression] ICE in expand_expr_real_l when instantiating a template with a lambda that captures a const variable with a dependent initializer https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63207 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug other/63504] [5 Regression] Issues found by --enable-checking=valgrind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63504 --- Comment #3 from Markus Trippelsdorf --- (In reply to Markus Trippelsdorf from comment #2) > To reproduce issue 3) run: > > valgrind --track-origins=yes --trace-children=yes gfortran > gcc/testsuite/gfortran.dg/actual_array_result_1.f90 > -fno-diagnostics-show-caret -fdiagnostics-color=never -Os -c on ppc64.
[Bug target/63483] Scheduler performs Invalid move of aliased memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483 --- Comment #19 from Uroš Bizjak --- (In reply to rguent...@suse.de from comment #18) > Looks ok with all the explanation. I wonder when is the appropriate > time to retire support for architectures without byte granular > memory access. Thanks for your discussion! I will prepare a formal patch submission.
[Bug libstdc++/63500] [4.9/5 Regression] bug in debug version of std::make_move_iterator?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63500 --- Comment #5 from François Dumont --- I never understood why safe iterators operators are not simply calling respective operator on the underlying iterator. All operators are respecting this rule except the operator->. So I will try to use this rule and see if it fixes this issue.
[Bug target/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 Richard PALO changed: What|Removed |Added Attachment #33676|0 |1 is obsolete|| --- Comment #19 from Richard PALO --- Created attachment 33680 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33680&action=edit -std= agnostic version
[Bug c++/63497] std::regex can't handle [^class] correctly and cause runtime crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63497
--- Comment #2 from Tim Shen ---
Thanks for reporting :)
This bug is still in trunk, it just somehow can't trigger the segfault or wrong
output.
The line trunk/bits/regex_executor.tcc:297 :
if (__state._M_matches(*_M_current))
doesn't check if _M_current != _M_end.
One way is to create a helper function that may fail to (return a false as a
successfulness of dereference) dereference, but it's less efficient, unless the
compiler can do reasoning + unnecessary predication elimination. I'm not sure
about that.
If you are interested, take a look at _Executor::_M_word_boundary and try to
explode the first *_M_current (line 419 in trunk). My answer is:
regex_match("", regex("\\b"), regex_constants::match_not_eol);
For that case, can the compiler inline and eliminate unnecessary _M_current ==
_M_end, if we blindly check it (through some helper function) everywhere?
Or, as I prefer, I can do a file scope wise check for each direct or indirect
_M_current dereference.
[Bug tree-optimization/63476] [5 Regression] ICE: tree check: expected ssa_name, have var_decl in walk_aliased_vdefs_1, at tree-ssa-alias.c:2689
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63476 --- Comment #3 from Richard Biener --- Author: rguenth Date: Fri Oct 10 11:04:39 2014 New Revision: 216065 URL: https://gcc.gnu.org/viewcvs?rev=216065&root=gcc&view=rev Log: 2014-10-10 Richard Biener PR tree-optimization/63476 * tree-ssa-pre.c (struct bb_bitmap_sets): Add vop_on_exit member. (BB_LIVE_VOP_ON_EXIT): New define. (create_expression_by_pieces): Assign VUSEs to stmts. (compute_avail): Track BB_LIVE_VOP_ON_EXIT. (pass_pre::execute): Assert virtual SSA form is up-to-date after insertion. * g++.dg/torture/pr63476.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr63476.C Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-pre.c
[Bug tree-optimization/63380] [5 Regression] Wrong constant folding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63380 --- Comment #7 from Richard Biener --- Author: rguenth Date: Fri Oct 10 11:05:39 2014 New Revision: 216066 URL: https://gcc.gnu.org/viewcvs?rev=216066&root=gcc&view=rev Log: 2014-10-10 Richard Biener PR tree-optimization/63380 * tree-ssa-tail-merge.c (stmt_local_def): Exclude stmts that may trap. * gcc.dg/torture/pr63380-1.c: New testcase. * gcc.dg/torture/pr63380-2.c: Likewise. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/torture/pr63380-1.c branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/torture/pr63380-2.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/tree-ssa-tail-merge.c
[Bug tree-optimization/63476] [5 Regression] ICE: tree check: expected ssa_name, have var_decl in walk_aliased_vdefs_1, at tree-ssa-alias.c:2689
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63476 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug fortran/59488] [OpenMP] named constant in parallel construct leads to "not specified in enclosing parallel" error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59488 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Fri Oct 10 11:08:37 2014 New Revision: 216067 URL: https://gcc.gnu.org/viewcvs?rev=216067&root=gcc&view=rev Log: PR fortran/59488 * trans-openmp.c (gfc_omp_predetermined_sharing): Return OMP_CLAUSE_DEFAULT_SHARED for parameters or vtables. * gfortran.dg/gomp/pr59488-1.f90: New test. * gfortran.dg/gomp/pr59488-2.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/gomp/pr59488-1.f90 trunk/gcc/testsuite/gfortran.dg/gomp/pr59488-2.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-openmp.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/59488] [OpenMP] named constant in parallel construct leads to "not specified in enclosing parallel" error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59488 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Fri Oct 10 11:09:32 2014 New Revision: 216068 URL: https://gcc.gnu.org/viewcvs?rev=216068&root=gcc&view=rev Log: PR fortran/59488 * trans-openmp.c (gfc_omp_predetermined_sharing): Return OMP_CLAUSE_DEFAULT_SHARED for parameters or vtables. * gfortran.dg/gomp/pr59488-1.f90: New test. * gfortran.dg/gomp/pr59488-2.f90: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/gomp/pr59488-1.f90 branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/gomp/pr59488-2.f90 Modified: branches/gcc-4_9-branch/gcc/fortran/ChangeLog branches/gcc-4_9-branch/gcc/fortran/trans-openmp.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/63375] [4.8/4.9/5 Regression] reordering of reads across fences
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63375 --- Comment #10 from Richard Biener --- No, RTL forwprop1 still breaks the testcase according to comment #4.
[Bug tree-optimization/63379] [4.8/4.9/5 Regression] Incorrect vectorization when enabling SSE and O3, initialises loop with wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63379 --- Comment #5 from Richard Biener --- Author: rguenth Date: Fri Oct 10 11:17:13 2014 New Revision: 216070 URL: https://gcc.gnu.org/viewcvs?rev=216070&root=gcc&view=rev Log: 2014-10-10 Richard Biener PR tree-optimization/63379 * tree-vect-slp.c (vect_get_constant_vectors): Do not compute a neutral operand for min/max when it is not a reduction chain. * gcc.dg/vect/pr63379.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vect/pr63379.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-slp.c
[Bug other/63505] New: [4.8/4.9 Regression] ICE with -fdebug-types-section in should_move_die_to_comdat, at dwarf2out.c:6702
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63505
Bug ID: 63505
Summary: [4.8/4.9 Regression] ICE with -fdebug-types-section in
should_move_die_to_comdat, at dwarf2out.c:6702
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
this might be related to PR57664 and/or PR53860 (but the latter was closed),
seen on today's 4.8 and 4.9 branches, but not on trunk.
test case reduced from https://bugs.debian.org/764624
$ cat test.cc
template struct A {
_Predicate _M_pred;
template bool operator()(_Iterator) { return _M_pred; }
};
template A<_Predicate> __pred_iter(_Predicate) {}
class B {
public:
int begin();
int end();
};
template
void __remove_if(_ForwardIterator, _Predicate p2) {
_ForwardIterator __first;
p2(__first);
}
template
void remove_if(_ForwardIterator, _ForwardIterator p2, _Predicate p3) {
__remove_if(p2, __pred_iter(p3));
}
void tidy_container() {
B env_container;
if (false)
remove_if(env_container.begin(), env_container.end(), [] {});
}
$ g++ -std=gnu++0x -c -g -fdebug-types-section test.cc
test.cc:27:1: internal compiler error: in should_move_die_to_comdat, at
dwarf2out.c:6702
}
^
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug fortran/59488] [OpenMP] named constant in parallel construct leads to "not specified in enclosing parallel" error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59488 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Fri Oct 10 11:24:31 2014 New Revision: 216071 URL: https://gcc.gnu.org/viewcvs?rev=216071&root=gcc&view=rev Log: PR fortran/59488 * trans-openmp.c (gfc_omp_predetermined_sharing): Return OMP_CLAUSE_DEFAULT_SHARED for parameters or vtables. * gfortran.dg/gomp/pr59488-1.f90: New test. * gfortran.dg/gomp/pr59488-2.f90: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/gomp/pr59488-1.f90 branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/gomp/pr59488-2.f90 Modified: branches/gcc-4_8-branch/gcc/fortran/ChangeLog branches/gcc-4_8-branch/gcc/fortran/trans-openmp.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug fortran/59488] [OpenMP] named constant in parallel construct leads to "not specified in enclosing parallel" error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59488 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed for 4.8+.
[Bug tree-optimization/63464] compare one character to many: faster
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63464 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Fri Oct 10 12:15:30 2014 New Revision: 216072 URL: https://gcc.gnu.org/viewcvs?rev=216072&root=gcc&view=rev Log: PR tree-optimization/63464 * tree-switch-conversion.c (struct case_bit_test): Remove hi and lo fields, add wide_int mask field. (emit_case_bit_tests): Add MAXVAL argument, rewrite uses of hi/lo fields into wide_int mask operations, optimize by pretending minval to be 0 if maxval is small enough. (process_switch): Adjust caller. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-switch-conversion.c
[Bug lto/62249] Spurious FORTIFY_SOURCE warning with -flto, poll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62249 Ilya Palachev changed: What|Removed |Added CC||i.palachev at samsung dot com --- Comment #3 from Ilya Palachev --- The bug reproduces for me even without -D_FORTIFY_SOURCE=2.
[Bug lto/62249] Spurious FORTIFY_SOURCE warning with -flto, poll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62249 --- Comment #4 from Zack Weinberg --- The "delta-minimized self-contained test case" should require only `-O2 -flto` to reproduce the problem. The other test case, however, should require `-D_FORTIFY_SOURCE=2` in addition, and to be compiled against recent glibc. Note also that this does not happen with 4.8 or older.
[Bug target/63503] [AArch64] A57 executes fused multiply-add poorly in some situations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63503 Wilco changed: What|Removed |Added CC||wdijkstr at arm dot com --- Comment #6 from Wilco --- I ran the assembler examples on A57 hardware with identical input. The FMADD code is ~20% faster irrespectively of the size of the input. This is not a surprise given that the FMADD latency is lower than the FADD and FMUL latency. The alignment of the loop or scheduling don't matter at all as the FMADD latency dominates by far - with serious optimization this code could run 4-5 times as fast and would only be limited by memory bandwidth on datasets larger than L2. So this particular example shows issues in LLVM, not in GCC.
[Bug libfortran/63471] [5.0 Regression] unix.c:1906:10: error: implicit declaration of function 'ttyname_r'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471 --- Comment #8 from dave.anglin at bell dot net --- On 10/10/2014 3:42 AM, jb at gcc dot gnu.org wrote: > So, are you planning on enabling _REENTRANT in the HP-UX 11 driver like you > did > for 10, or do you want to solve this in some other way? I have it installed for testing and will commit it if I don't see any problems. Dave
[Bug tree-optimization/54488] tree loop invariant motion uses an excessive amount of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54488 Evgeniya Maenkova changed: What|Removed |Added CC||evgeniya.maenkova at gmail dot com --- Comment #1 from Evgeniya Maenkova --- Could you please clarify this bug status? (As I can see PR46590 you applied some patch that fixes memory issues in Jan of 2014). As I can see from the code (I'm very newbie, sorry for mistakes) there are the structures which keep the information about memory accesses in the whole function (for all the loops). When I read you comment in this bug I started to think there is some possibility to keep the only information about individual loop (which I could try to implement). However, the comment in PR46590 says you meant something different.
[Bug target/63503] [AArch64] A57 executes fused multiply-add poorly in some situations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63503 Ramana Radhakrishnan changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-10-10 Ever confirmed|0 |1 --- Comment #7 from Ramana Radhakrishnan --- (In reply to Wilco from comment #6) > I ran the assembler examples on A57 hardware with identical input. The FMADD > code is ~20% faster irrespectively of the size of the input. This is not a > surprise given that the FMADD latency is lower than the FADD and FMUL > latency. > > The alignment of the loop or scheduling don't matter at all as the FMADD > latency dominates by far - with serious optimization this code could run 4-5 > times as fast and would only be limited by memory bandwidth on datasets > larger than L2. > > So this particular example shows issues in LLVM, not in GCC. The difference as to why LLVM puts out an fma vs we don't is probably because of default language standards. GCC defaults to GNU89 while LLVM defaults to C99. If you used -std=c99 with GCC as well you'd get the same sequence as LLVM. As Evandro doesn't mention flags it's hard to say whether there really is a problem here or not. I only know of a separate gotcha with fmadds which is unfortunate but that's not relevant to this discussion. http://comments.gmane.org/gmane.comp.compilers.llvm.cvs/200282 This probably needs more analysis than the current state.
[Bug c++/63506] New: GCC deduces wrong return type of operator*() inside template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63506
Bug ID: 63506
Summary: GCC deduces wrong return type of operator*() inside
template functions
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: steffen.muething at iwr dot uni-heidelberg.de
Created attachment 33681
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33681&action=edit
Minimal working example based on std::vector
When trying to convert some iterators in our numerics library DUNE
(dune-project.org) to return temporaries instead of const refs, I stumbled over
the following bug in GCC 4.8.3 and 4.9.1:
Given a class with an operator*() that returns a temporary:
struct iterator
{
...
proxy operator*() const
{
return ...;
}
proxy get() const
{
return ...;
}
};
the expression 'decltype(*it())' should yield 'proxy', and a variable declared
with 'auto&& x = *it;' should be of type 'proxy&&'. The above is true inside
normal functions:
void bar(iterator it)
{
typedef decltype(*it()) P; // P == proxy
auto&& x = *it; // decltype(x) == proxy&&
}
But inside a function template, 'decltype(*it())' becomes 'proxy&', and 'auto&&
x = *it' fails with a compiler error:
template
void foo(T t, iterator it)
{
typedef decltype(*it()) P; // P == proxy&
auto&& x = *it; // compiler error, see below
}
error: invalid initialization of non-const reference of type 'proxy&' from an
rvalue of type 'proxy'
For some reason, the compiler deduces the wrong type early on and then fails
when it later realizes the correct return type...
This problem can easily be observed with a std::vector, which returns a
proxy from its iterator. I have attached a minimal working example: The
contained code (which creates a vector and iterates over its contents with a
range-based for loop using auto&&) works in main() and in a normal function
bar(), but it fails to compile in foo(), which is a function template.
GCC 4.6 and 4.7 compile foo() correctly.
[Bug c++/63506] GCC deduces wrong return type of operator*() inside template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63506 --- Comment #1 from Steffen Müthing --- I forgot to mention: This problem is specific to operator*(). If you add an equivalent normal member function and replace the dereferencing operations with calls to that function, the problem does not occur.
[Bug c++/63506] GCC deduces wrong return type of operator*() inside template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63506 --- Comment #2 from Marc Glisse --- Do you mean decltype(*it) (without the extra parentheses) everywhere?
[Bug tree-optimization/63379] [4.8 Regression] Incorrect vectorization when enabling SSE and O3, initialises loop with wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63379 Richard Biener changed: What|Removed |Added Known to work||4.9.2, 5.0 Summary|[4.8/4.9/5 Regression] |[4.8 Regression] Incorrect |Incorrect vectorization |vectorization when enabling |when enabling SSE and O3, |SSE and O3, initialises |initialises loop with wrong |loop with wrong value |value | Known to fail|5.0 | --- Comment #6 from Richard Biener --- Fixed on trunk and 4.9 branch sofar.
[Bug tree-optimization/63379] [4.8 Regression] Incorrect vectorization when enabling SSE and O3, initialises loop with wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63379 --- Comment #7 from Richard Biener --- Author: rguenth Date: Fri Oct 10 14:23:35 2014 New Revision: 216086 URL: https://gcc.gnu.org/viewcvs?rev=216086&root=gcc&view=rev Log: 2014-10-10 Richard Biener PR tree-optimization/63379 * tree-vect-slp.c (vect_get_constant_vectors): Do not compute a neutral operand for min/max when it is not a reduction chain. * gcc.dg/vect/pr63379.c: New testcase. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.dg/vect/pr63379.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/testsuite/ChangeLog branches/gcc-4_9-branch/gcc/tree-vect-slp.c
[Bug c++/63419] verify_gimple failed: "vector CONSTRUCTOR element is not a GIMPLE value"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63419 --- Comment #2 from Richard Biener --- Created attachment 33682 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33682&action=edit autoreduced testcase Fix in testing, autoreduced testcase attached (still too big for my taste).
[Bug c++/63506] GCC deduces wrong return type of operator*() inside template functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63506 --- Comment #3 from Steffen Müthing --- Ooops, yes, I did. Actually I meant to write decltype(*iterator()), but decltype(*it()) doesn't make sense, of course. And to avoid further confusion: The function get() in the iterator is just there as an example for a function that avoids the problem (see comment #1).
[Bug tree-optimization/54488] tree loop invariant motion uses an excessive amount of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54488 --- Comment #2 from Richard Biener --- I had patches to implement the suggestion, work on outermost loops separately. Of course it won't help once you wrap all of them in a single outer loop (which is why I didn't end up committing this). Re-measuring state of current trunk would be still nice (I think we must have improved over the 1GB).
[Bug bootstrap/63432] [5 Regression] profiledbootstrap failure with bootstrap-lto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63432 --- Comment #26 from H.J. Lu --- I will find a testcase when it fails again.
[Bug bootstrap/51479] Missing dependency on errors.o causes bootstrap failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51479 H.J. Lu changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.7.0 --- Comment #3 from H.J. Lu --- Fixed.
[Bug rtl-optimization/63491] Ice in LRA with simple vector test case on power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63491 --- Comment #4 from Peter Bergner --- I'll add that we hit this as part of our work on trying to move POWER over to using LRA by default.
[Bug bootstrap/50543] Bootstrap fails to build for latest 4.6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50543 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX Target Milestone|--- |4.6.0 --- Comment #8 from H.J. Lu --- 4.6 branch is closed.
[Bug sanitizer/63507] New: boostrap-asan failure: /usr/bin/ld: /home/max/build/bootstrap-asan/./gcc/liblto_plugin.so: error loading plugin
$ ~/build/bootstrap-asan/gcc$ ./xgcc -v Using built-in specs. COLLECT_GCC=./xgcc Target: x86_64-unknown-linux-gnu Configured with: /home/max/workspace/downloads/gcc/configure --enable-multilib --enable-checking --target=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --build=x86_64-unknown-linux-gnu --prefix=/home/max/install/bootstrap-asan --enable-bootstrap --with-build-config=bootstrap-asan Thread model: posix gcc version 5.0.0 20141010 (experimental) (GCC)
[Bug libstdc++/49561] [C++0x] std::list::size complexity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49561 --- Comment #19 from Jonathan Wakely --- Author: redi Date: Fri Oct 10 15:33:57 2014 New Revision: 216094 URL: https://gcc.gnu.org/viewcvs?rev=216094&root=gcc&view=rev Log: PR libstdc++/49561 * acinclude.m4 (GLIBCXX_ENABLE_LIBSTDCXX_CXX11_ABI): Define. * configure.ac: Use GLIBCXX_ENABLE_LIBSTDCXX_CXX11_ABI. * configure: Regenerate. * include/Makefile.am (stamp-cxx11-abi): New target. (c++config.h): Set _GLIBCXX_USE_CXX11_ABI macro. * include/Makefile.in: Regenerate. * include/bits/c++config: Add _GLIBCXX_USE_CXX11_ABI placeholder and define _GLIBCXX_DEFAULT_ABI_TAG. * include/bits/list.tcc (list::emplace(const_iterator, _Args&...)): Increment size. (list::emplace(const_iterator, const value_type&)): Likewise. (list::merge(list&), list::merge(list&, _StrictWeakOrdering)): Adjust list sizes. * include/bits/stl_list.h (_List_base, list): Add ABI tag macro. (_List_base::_M_size): New data member in cxx11 ABI mode. (_List_base::_S_distance(_List_node_base*, _List_node_base*)): New function. (_List_base::_M_get_size(), _List_base::_M_set_size(size_t), _List_base::_M_inc_size(size_t), _List_base::_M_dec_size(size_t), _List_base::_M_distance, _List_base::_M_node_count): New functions for accessing list size correctly for the ABI mode. (_List_base::_List_base(_List_base&&)): Copy size and reset source. (_List_base::_M_init()): Initialize size member. (list::size()): Use _List_base::_M_node_count. (list::swap(list&)): Swap sizes. (list::splice(iterator, list&)): Update sizes. (list::splice(iterator, list&, iterator)): Likewise. (list::insert(iterator, const value_type&)): Update size. (list::insert(iterator, _Args&&...)): Likewise. (list::_M_erase(iterator)): Likewise. * testsuite/23_containers/list/requirements/dr438/assign_neg.cc: Adjust. * testsuite/23_containers/list/requirements/dr438/constructor_1_neg.cc: Adjust. * testsuite/23_containers/list/requirements/dr438/constructor_2_neg.cc: Adjust. * testsuite/23_containers/list/requirements/dr438/insert_neg.cc: Adjust. * testsuite/ext/profile/mutex_extensions_neg.cc: Adjust. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/configure trunk/libstdc++-v3/configure.ac trunk/libstdc++-v3/include/Makefile.am trunk/libstdc++-v3/include/Makefile.in trunk/libstdc++-v3/include/bits/c++config trunk/libstdc++-v3/include/bits/list.tcc trunk/libstdc++-v3/include/bits/stl_list.h trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/assign_neg.cc trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/constructor_1_neg.cc trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/constructor_2_neg.cc trunk/libstdc++-v3/testsuite/23_containers/list/requirements/dr438/insert_neg.cc trunk/libstdc++-v3/testsuite/ext/profile/mutex_extensions_neg.cc
[Bug target/63347] m68k misoptimisation with -fschedule-insns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63347 Andreas Schwab changed: What|Removed |Added Status|WAITING |NEW --- Comment #6 from Andreas Schwab --- It disappears in the IRA pass.
[Bug sanitizer/63507] boostrap-asan failure: /usr/bin/ld: /home/max/build/bootstrap-asan/./gcc/liblto_plugin.so: error loading plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63507 Markus Trippelsdorf changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-10 CC||trippels at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Markus Trippelsdorf --- This never worked. I think H.J. or Jakub posted a patch for this issue quite some time ago.
[Bug target/63404] [5 Regression] gcc 5 miscompiles linux block layer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63404 --- Comment #12 from Richard Henderson --- Author: rth Date: Fri Oct 10 15:56:07 2014 New Revision: 216096 URL: https://gcc.gnu.org/viewcvs?rev=216096&root=gcc&view=rev Log: PR target/63404 * shrink-wrap.c (move_insn_for_shrink_wrap): Don't use single_set. Restrict the set of expressions we're willing to move. Modified: trunk/gcc/ChangeLog trunk/gcc/shrink-wrap.c
[Bug sanitizer/63507] boostrap-asan failure: /usr/bin/ld: /home/max/build/bootstrap-asan/./gcc/liblto_plugin.so: error loading plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63507 Yury Gribov changed: What|Removed |Added CC||y.gribov at samsung dot com --- Comment #2 from Yury Gribov --- Asan-bootstrap worked for me ~ a month ago.
[Bug libstdc++/49561] [C++0x] std::list::size complexity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49561 Jonathan Wakely changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #20 from Jonathan Wakely --- Fixed for 5.0
[Bug libstdc++/61347] std::distance(list.first(),list.end()) in O(1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61347 Bug 61347 depends on bug 49561, which changed state. Bug 49561 Summary: [C++0x] std::list::size complexity https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49561 What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED
[Bug sanitizer/63507] boostrap-asan failure: /usr/bin/ld: /home/max/build/bootstrap-asan/./gcc/liblto_plugin.so: error loading plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63507 --- Comment #3 from Jakub Jelinek --- r209476 was the change which was supposed to fix it in ~ May. I'm afraid I haven't tried asan bootstrap more recently than that.
[Bug middle-end/63376] [5.0 Regression] ICE: in operator[], at vec.h:736 compiling team.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63376
--- Comment #3 from John David Anglin ---
(gdb) frame 2
#2 0x007eaf1c in
_ZL28evaluate_properties_for_edgeP11cgraph_edgebPjP3vecIP9tree_node7va_heap6vl_ptrES8_PS2_IP21ipa_agg_jump_functionS5_S6_E
(e=0x7afef780,
inline_p=true, clause_ptr=0x7eff0dc0, known_vals_ptr=0x7eff0dc4,
known_binfos_ptr=0x7eff0dc8, known_aggs_ptr=0x7eff0dcc)
at ../../gcc/gcc/ipa-inline-analysis.c:903
903 struct ipa_edge_args *args = IPA_EDGE_REF (e);
(gdb) p e->uid
$5 = 148
(gdb) p *e
$6 = {count = 0, caller = 0x7aefa380, callee = 0x7af860e0, prev_caller = 0x0,
next_caller = 0x0, prev_callee = 0x0, next_callee = 0x0,
call_stmt = 0x7aff8048, indirect_info = 0x0, aux = 0x0,
inline_failed = CIF_FUNCTION_NOT_CONSIDERED, lto_stmt_uid = 0,
frequency = 1000, uid = 148, indirect_inlining_edge = 0,
indirect_unknown_callee = 0, call_stmt_cannot_inline_p = 0,
can_throw_external = 0, speculative = 0, in_polymorphic_cdtor = 0}
(gdb) p *ipa_edge_args_vector
$7 = {m_vecpfx = {m_alloc = 255, m_using_auto_storage = 0, m_num = 148},
m_vecdata = {{jump_functions = 0x0, polymorphic_call_contexts = 0x0}}}
Size of vec is one too small.
[Bug libstdc++/49561] [C++0x] std::list::size complexity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49561 --- Comment #21 from Jonathan Wakely --- Author: redi Date: Fri Oct 10 16:14:52 2014 New Revision: 216097 URL: https://gcc.gnu.org/viewcvs?rev=216097&root=gcc&view=rev Log: PR libstdc++/49561 * acinclude.m4 (GLIBCXX_ENABLE_LIBSTDCXX_CXX11_ABI): Define. * configure.ac: Use GLIBCXX_ENABLE_LIBSTDCXX_CXX11_ABI. * configure: Regenerate. * include/Makefile.am (stamp-cxx11-abi): New target. (c++config.h): Set _GLIBCXX_USE_CXX11_ABI macro. * include/Makefile.in: Regenerate. * include/bits/c++config: Add _GLIBCXX_USE_CXX11_ABI placeholder and define _GLIBCXX_DEFAULT_ABI_TAG. * include/bits/list.tcc (list::emplace(const_iterator, _Args&...)): Increment size. (list::emplace(const_iterator, const value_type&)): Likewise. (list::merge(list&), list::merge(list&, _StrictWeakOrdering)): Adjust list sizes. * include/bits/stl_list.h (_List_base, list): Add ABI tag macro. (_List_base::_M_size): New data member in cxx11 ABI mode. (_List_base::_S_distance(_List_node_base*, _List_node_base*)): New function. (_List_base::_M_get_size(), _List_base::_M_set_size(size_t), _List_base::_M_inc_size(size_t), _List_base::_M_dec_size(size_t), _List_base::_M_distance, _List_base::_M_node_count): New functions for accessing list size correctly for the ABI mode. (_List_base::_List_base(_List_base&&)): Copy size and reset source. (_List_base::_M_init()): Initialize size member. (list::size()): Use _List_base::_M_node_count. (list::swap(list&)): Swap sizes. (list::splice(iterator, list&)): Update sizes. (list::splice(iterator, list&, iterator)): Likewise. (list::insert(iterator, const value_type&)): Update size. (list::insert(iterator, _Args&&...)): Likewise. (list::_M_erase(iterator)): Likewise. * testsuite/23_containers/list/requirements/dr438/assign_neg.cc: Adjust. * testsuite/23_containers/list/requirements/dr438/constructor_1_neg.cc: Adjust. * testsuite/23_containers/list/requirements/dr438/constructor_2_neg.cc: Adjust. * testsuite/23_containers/list/requirements/dr438/insert_neg.cc: Adjust. * testsuite/ext/profile/mutex_extensions_neg.cc: Adjust. # End of auto-generated commit message Fix date and whitespace in libstdc++-v3/ChangeLog Modified: trunk/libstdc++-v3/ChangeLog
[Bug sanitizer/63507] boostrap-asan failure: /usr/bin/ld: /home/max/build/bootstrap-asan/./gcc/liblto_plugin.so: error loading plugin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63507 --- Comment #4 from Markus Trippelsdorf --- For me it fails with: ld: error: /var/tmp/test/./gcc/liblto_plugin.so: could not load plugin library: /var/tmp/test/./gcc/liblto_plugin.so: undefined symbol: __asan_option_detect_stack_use_after_return collect2: error: ld returned 1 exit status
[Bug target/63501] ICE in GCC powerpc64le top of trunk with -mupper-regs-df
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63501 --- Comment #3 from Michael Meissner --- The -mupper-regs-df and -mupper-regs-sf options are a work in progress. I am working on these options right now on a private branch, but the code is not yet ready for incorporation into the tree. I don't know how long it will take to track down the various bugs before the patches are submitted. As I write this, the code in my branch requires the use of the -mlra option (to switch to the LRA register allocator), and -mlra has some issues of its own that we are investigating. I have two spec tests (456.hmmer and 416.gamess) that fail when the -mupper-regs-df -mlra options are used. Of the tests that run, 454.calculix and 470.lbm show about a 6-7% improvement, while 410.bwaves has a 6-7% regression.
[Bug c++/63405] [4.9/5 regression] ICE in cp_perform_integral_promotions, at cp/typeck.c:2084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63405 --- Comment #16 from Gert-jan Los --- 2014-10-08 23:06:21 CEST schrieb jason at gcc dot gnu.org: > --- Comment #12 from Jason Merrill --- > Author: jason > Date: Wed Oct 8 21:05:50 2014 > New Revision: 216013 > > URL: https://gcc.gnu.org/viewcvs?rev=216013&root=gcc&view=rev > Log: > PR c++/63405 > * pt.c (tsubst_pack_expansion): Limit simple expansion to type packs. The 4.9 branch is also fine. gcc version 4.9.2 20141009 (prerelease) (GCC) Thanks again Gert-jan
[Bug c++/63405] [4.9/5 regression] ICE in cp_perform_integral_promotions, at cp/typeck.c:2084
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63405 Markus Trippelsdorf changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #17 from Markus Trippelsdorf --- Fixed.
[Bug target/63352] problem with fmt_g0_1.f08 on i386-pc-solaris2.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63352 --- Comment #20 from Richard PALO --- >From what I've been able to gather, 'f' precision 17 & 18 incorrectly terminate with a '2' where they seemingly need be '1' and '5' respectfully (along with corresponding 'e' with precision 16 & 17). The default rounding is FE_TONEAREST on illumos. The other modes seem okay. Therefore I filed https://www.illumos.org/issues/5224 (with an updated version of the test program). BTW, on a sidenote, with the test program on NetBSD (6.1) I notice that rounding mode seems to be completely ignored. Does gnu-c runtime expect correct behaviour? (NB I made a version of the test program to avoid any constant 1.0/3.0 being used)... It would be interesting to know about other platforms... I came across a sourceware bug where this was supposedly fixed (https://sourceware.org/bugzilla/show_bug.cgi?id=5044)
[Bug target/63483] Scheduler performs Invalid move of aliased memory reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63483 --- Comment #20 from uros at gcc dot gnu.org --- Author: uros Date: Fri Oct 10 17:36:21 2014 New Revision: 216100 URL: https://gcc.gnu.org/viewcvs?rev=216100&root=gcc&view=rev Log: PR rtl-optimization/63483 * alias.c (true_dependence_1): Do not exit early for MEM_READONLY_P references when alignment ANDs are involved. (write_dependence_p): Ditto. (may_alias_p): Ditto. Modified: trunk/gcc/ChangeLog trunk/gcc/alias.c
[Bug c++/63419] verify_gimple failed: "vector CONSTRUCTOR element is not a GIMPLE value"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63419 Markus Trippelsdorf changed: What|Removed |Added CC||trippels at gcc dot gnu.org --- Comment #3 from Markus Trippelsdorf --- Created attachment 33683 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33683&action=edit bit more reduced with Creduce
[Bug c/63495] struct __attribute__ ((aligned (8))) broken on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63495 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Fri Oct 10 17:43:21 2014 New Revision: 216101 URL: https://gcc.gnu.org/viewcvs?rev=216101&root=gcc&view=rev Log: PR c/63495 * stor-layout.c (min_align_of_type): Don't decrease alignment through BIGGEST_FIELD_ALIGNMENT or ADJUST_FIELD_ALIGN if TYPE_USER_ALIGN is set. * gcc.target/i386/pr63495.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr63495.c Modified: trunk/gcc/ChangeLog trunk/gcc/stor-layout.c trunk/gcc/testsuite/ChangeLog
[Bug c/63495] struct __attribute__ ((aligned (8))) broken on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63495 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Fri Oct 10 17:51:14 2014 New Revision: 216102 URL: https://gcc.gnu.org/viewcvs?rev=216102&root=gcc&view=rev Log: PR c/63495 * c-common.c (min_align_of_type): Don't decrease alignment through BIGGEST_FIELD_ALIGNMENT or ADJUST_FIELD_ALIGN if TYPE_USER_ALIGN is set. * gcc.target/i386/pr63495.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr63495.c Modified: branches/gcc-4_9-branch/gcc/c-family/ChangeLog branches/gcc-4_9-branch/gcc/c-family/c-common.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug c/63495] struct __attribute__ ((aligned (8))) broken on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63495 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.2 --- Comment #5 from Jakub Jelinek --- Should be fixed now.
[Bug c/63495] struct __attribute__ ((aligned (8))) broken on x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63495 --- Comment #6 from Paul Eggert --- That was fast! Thank you.
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #56 from Oleg Endo --- There are some LRA changes coming ... https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00948.html
[Bug middle-end/63376] [5.0 Regression] ICE: in operator[], at vec.h:736 compiling team.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63376 --- Comment #4 from John David Anglin --- Bug can be reproduced with x86 cross: dave@lux0:~/gnu/gcc/objdir$ gcc/xgcc -Bgcc -v Reading specs from gcc/specs COLLECT_GCC=gcc/xgcc COLLECT_LTO_WRAPPER=gcc/lto-wrapper Target: hppa2.0w-hp-hpux11.11 Configured with: ../gcc/configure --target=hppa2.0w-hp-hpux11.11 --prefix=/home/dave/opt/gnu --with-gnu-as --with-gnu-ld --enable-threads=posix --disable-nls --disable-lto --without-cloog --without-ppl --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --enable-shared --enable-languages=c,c++ --with-sysroot=/home/dave/opt/gnu/hppa2.0w-hp-hpux11.11/root --with-build-sysroot=/home/dave/opt/gnu/hppa2.0w-hp-hpux11.11/root Thread model: posix gcc version 5.0.0 20141010 (experimental) [trunk revision 216098] (GCC) ./gcc/cc1 -fpreprocessed team.i -quiet -dumpbase team.c -auxbase-strip .libs/team.o -g -O2 -Wall -Werror -version -frandom-seed=fixed-seed -fPIC -o team.s dave@lux0:~/gnu/gcc/objdir$ ./gcc/cc1 -fpreprocessed team.i -quiet -dumpbase team.c -auxbase-strip .libs/team.o -g -O2 -Wall -Werror -version -frandom-seed=fixed-seed -fPIC -o team.s GNU C (GCC) version 5.0.0 20141010 (experimental) [trunk revision 216098] (hppa2.0w-hp-hpux11.11) compiled by GNU C version 4.8.2, GMP version 5.1.3, MPFR version 3.1.2-p3, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 GNU C (GCC) version 5.0.0 20141010 (experimental) [trunk revision 216098] (hppa2.0w-hp-hpux11.11) compiled by GNU C version 4.8.2, GMP version 5.1.3, MPFR version 3.1.2-p3, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 5a99bebc29a6c53ba66845410ca575d2 ../../../gcc/libgomp/team.c:947:1: internal compiler error: in operator[], at vec.h:736 0x80ed53e vec::operator[](unsigned int) ../../gcc/gcc/vec.h:736 0x848dfcf vec::operator[](unsigned int) ../../gcc/gcc/vec.h:1072 0x848dfcf evaluate_properties_for_edge ../../gcc/gcc/ipa-inline-analysis.c:903 0x8490e27 do_estimate_edge_size(cgraph_edge*) ../../gcc/gcc/ipa-inline-analysis.c:3736 0x8490fef estimate_edge_size ../../gcc/gcc/ipa-inline.h:288 0x8490fef estimate_edge_growth ../../gcc/gcc/ipa-inline.h:301 0x8490fef do_estimate_growth_1 ../../gcc/gcc/ipa-inline-analysis.c:3849 0x8289844 cgraph_node::call_for_symbol_thunks_and_aliases(bool (*)(cgraph_node*, void*), void*, bool) ../../gcc/gcc/cgraph.c:2120 0x84914e9 do_estimate_growth(cgraph_node*) ../../gcc/gcc/ipa-inline-analysis.c:3863 0x8a01df1 estimate_growth ../../gcc/gcc/ipa-inline.h:275 0x8a01df1 inline_small_functions ../../gcc/gcc/ipa-inline.c:1586 0x8a01df1 ipa_inline ../../gcc/gcc/ipa-inline.c:2175 0x8a01df1 execute ../../gcc/gcc/ipa-inline.c:2535 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug target/63501] ICE in GCC powerpc64le top of trunk with -mupper-regs-df
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63501 --- Comment #4 from Peter Bergner --- (In reply to Michael Meissner from comment #3) > The -mupper-regs-df and -mupper-regs-sf options are a work in progress. I > am working on these options right now on a private branch, but the code is > not yet ready for incorporation into the tree. I don't know how long it > will take to track down the various bugs before the patches are submitted. Meaning, don't use the -mupper-regs-df and -mupper-regs-sf options until Mike has his patch(es) upstream.
[Bug sanitizer/59758] [4.9/5 Regression] bootstrap failure in libsanitizer/asan on sparc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59758 Richard Henderson changed: What|Removed |Added CC||rth at gcc dot gnu.org --- Comment #12 from Richard Henderson --- (In reply to David S. Miller from comment #10) > Created attachment 32723 [details] > Fix for libsanitizer build on sparc > > This adjusted patch fixes the build for me. Looks good to me. Given the lack of attention the sanitizers are getting, perhaps you should just check this in. Especially to the branch.
[Bug middle-end/63376] [5.0 Regression] ICE: in operator[], at vec.h:736 compiling team.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63376
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-10-10
CC||marxin at gcc dot gnu.org,
||trippels at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #5 from Markus Trippelsdorf ---
void __attribute__ ((constructor)) __attribute__ ((destructor)) fn1 () {}
[Bug libfortran/63471] [5.0 Regression] unix.c:1906:10: error: implicit declaration of function 'ttyname_r'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63471 Francois-Xavier Coudert changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #9 from Francois-Xavier Coudert --- (In reply to Janne Blomqvist from comment #7) > I'm not sure we care about OS X 10.4 anymore? Newer versions apparently > provide the POSIX ttyname_r. I confirm that 10.5 and later Mac OS versions provide ttyname_r with the correct signature, and we don't care about 10.4 anymore.
[Bug c++/63497] std::regex can't handle [^class] correctly and cause runtime crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63497 --- Comment #3 from Yue Wang --- Hi guys! Thx for replying. To be honest,as a newbie I'm not good enough to understand @Tim's reply... Thx again for the efforts, hoping that gcc's std::regex would be better and better.
[Bug c++/63437] [4.9/5 regression][C++14] Parenthesized "movable but not copyable" object doesn't compile in return statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63437 --- Comment #5 from Jason Merrill --- Author: jason Date: Fri Oct 10 20:35:18 2014 New Revision: 216106 URL: https://gcc.gnu.org/viewcvs?rev=216106&root=gcc&view=rev Log: PR c++/63437 * cp-tree.h (REF_PARENTHESIZED_P): Also allow INDIRECT_REF. * semantics.c (force_paren_expr): And set it. * typeck.c (check_return_expr): And handle it. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/cpp1y/paren1.C Modified: branches/gcc-4_9-branch/gcc/cp/ChangeLog branches/gcc-4_9-branch/gcc/cp/cp-tree.h branches/gcc-4_9-branch/gcc/cp/semantics.c branches/gcc-4_9-branch/gcc/cp/typeck.c
[Bug c++/63415] [4.9/5 Regression] internal compiler error: unexpected expression ‘static_cast(std::is_same{})’ of kind static_cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63415 --- Comment #5 from Jason Merrill --- Author: jason Date: Fri Oct 10 20:35:26 2014 New Revision: 216107 URL: https://gcc.gnu.org/viewcvs?rev=216107&root=gcc&view=rev Log: PR c++/63415 * pt.c (value_dependent_expression_p) [CONSTRUCTOR]: Check the type. (iterative_hash_template_arg): Likewise. Added: branches/gcc-4_9-branch/gcc/testsuite/g++.dg/cpp0x/constexpr-initlist8.C Modified: branches/gcc-4_9-branch/gcc/cp/ChangeLog branches/gcc-4_9-branch/gcc/cp/pt.c
[Bug c++/63415] [4.9/5 Regression] internal compiler error: unexpected expression ‘static_cast(std::is_same{})’ of kind static_cast_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63415 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #6 from Jason Merrill --- Fixed.
[Bug libstdc++/63500] [4.9/5 Regression] bug in debug version of std::make_move_iterator?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63500 --- Comment #6 from François Dumont --- Sorry, I reproduced the problem and it is not in _Safe_iterator operator-> so my previous remark is out of subject.
[Bug c++/63437] [4.9/5 regression][C++14] Parenthesized "movable but not copyable" object doesn't compile in return statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63437 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 Target Milestone|--- |4.9.2 --- Comment #6 from Jason Merrill --- Fixed.
[Bug c++/63485] [5 Regression] ICE: canonical types differ for identical types A::type and const char_type [3]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63485 Jason Merrill changed: What|Removed |Added CC||ai.azuma at gmail dot com --- Comment #4 from Jason Merrill --- *** Bug 63454 has been marked as a duplicate of this bug. ***
[Bug c++/63454] [5 Regression] internal compiler error: canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63454 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #4 from Jason Merrill --- Fixed by patch for bug 63485. *** This bug has been marked as a duplicate of bug 63485 ***
[Bug c++/63497] std::regex can't handle [^class] correctly and cause runtime crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63497 --- Comment #4 from Tim Shen --- Hi Yue Wang, I'm sorry if my last reply looks scary. I should have put it in libstdc++ list. I didn't mean to reply you with all implementation details. Anyway, the cause is clear, and it will be fixed in trunk (and I believe that it can be backported to 4.9 branch). Thanks for reporting :)
[Bug c++/63485] [5 Regression] ICE: canonical types differ for identical types A::type and const char_type [3]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63485 Jason Merrill changed: What|Removed |Added CC||dcb314 at hotmail dot com --- Comment #5 from Jason Merrill --- *** Bug 63275 has been marked as a duplicate of this bug. ***
[Bug c++/63275] [5 Regression] ice in is_base_type with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63275 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jason Merrill --- Fixed by the patch for 63485. *** This bug has been marked as a duplicate of bug 63485 ***
[Bug libstdc++/61909] Small function optimization not applied to small objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61909 Jonathan Wakely changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #9 from Jonathan Wakely --- And as of https://gcc.gnu.org/ml/gcc-bugs/2014-10/msg00717.html the lambda case should also be allocation-free.
[Bug c++/63508] New: ICE when using bracketed initializer on pointer to member function of a templated class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63508
Bug ID: 63508
Summary: ICE when using bracketed initializer on pointer to
member function of a templated class
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: mlang at delysid dot org
Target: x86_64-linux-gnu
With -std=c++11, using bracketed initialisation on a pointer to member function
inside a templated class crashes GCC with an ICE segfault:
fx:~/src/wikiwordfreq% LC_MESSAGES=C g++ -std=c++11 bug.cpp
bug.cpp: In instantiation of ‘c::c() [with T = int]’:
bug.cpp:14:23: required from here
bug.cpp:7:22: internal compiler error: Segmentation fault
auto x = m{&c::mf};
^
[Bug c++/63508] ICE when using bracketed initializer on pointer to member function of a templated class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63508 --- Comment #1 from Mario Lang --- Created attachment 33684 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33684&action=edit bug.cpp g++ -std=c++11 bug.cpp
[Bug middle-end/63376] [5.0 Regression] ICE: in operator[], at vec.h:736 compiling team.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63376 Martin Liška changed: What|Removed |Added CC||mliska at suse dot cz --- Comment #6 from Martin Liška --- Fixed in r216110.
[Bug go/63493] libgo: write power64 version of reflect.MakeFunc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63493 --- Comment #1 from Ian Lance Taylor --- Note: if Richard Henderson's patch series at https://gcc.gnu.org/ml/gcc-patches/2014-10/msg01009.html is committed, then the this will need to be implemented in libffi, not libgo.
[Bug other/63509] New: Misleading error message when building gcc without C++ compiler installed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63509 Bug ID: 63509 Summary: Misleading error message when building gcc without C++ compiler installed Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: sajarvis at bu dot edu Created attachment 33685 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33685&action=edit Full output during make. When building gcc with no C++ compiler installed, configuration succeeds, then make fails with error message: configure: error: error verifying int64_t uses long long Steps to cause: 1) Don't install a C++ compiler 2) $ ./configure --prefix=$HOME/dev/gcc/bld --enable-multilib 3) $ make I think the error should be more specific to the issue (no C++ compiler found) and probably caught earlier. System: Fedora 20, Linux 3.16 building gcc trunk, version r216105 More of the log (full log attached): [...] checking for int16_t... yes checking for int32_t... yes checking for int64_t... yes checking for long long int... yes checking for intmax_t... yes checking for intptr_t... yes checking for uint8_t... yes checking for uint16_t... yes checking for uint32_t... yes checking for uint64_t... yes checking for unsigned long long int... yes checking for uintmax_t... yes checking for uintptr_t... yes checking for int64_t underlying type... long long configure: error: error verifying int64_t uses long long make[2]: *** [configure-stage1-gcc] Error 1 make[2]: Leaving directory `/home/sjarvis/dev/gcc/srcdir' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/sjarvis/dev/gcc/srcdir' make: *** [all] Error 2
[Bug c++/63194] [5 Regression] ICE in maybe_explain_implicit_delete, at cp/method.c:1552
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63194 --- Comment #3 from Jason Merrill --- Author: jason Date: Sat Oct 11 02:26:33 2014 New Revision: 216114 URL: https://gcc.gnu.org/viewcvs?rev=216114&root=gcc&view=rev Log: PR c++/63194 * method.c (defaulted_late_check): Call maybe_instantiate_noexcept. Added: trunk/gcc/testsuite/g++.dg/cpp0x/noexcept25.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/method.c
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 Kazumoto Kojima changed: What|Removed |Added Attachment #33526|0 |1 is obsolete|| --- Comment #57 from Kazumoto Kojima --- Created attachment 33686 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33686&action=edit revised patch for the problem in c#25
[Bug target/55212] [SH] Switch to LRA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55212 --- Comment #58 from Kazumoto Kojima --- (In reply to Kazumoto Kojima from comment #57) > revised patch for the problem in c#25 I've looked into the remained ICEs for usual sh4-unknown-linux-gnu test and got that they are similar to the ICE in c#25. The original insn is a move insn from/to a memory with base+index addressing which requires r0 for index reg on SH. The other operand of that insn has an equivalence with a memory of which load/store uses r0 for some reason. The tipical example is a memory of which addressing is base+index and base+a_small_display_constant which can fit to mov.[bwl] r0,@(disp,rm)/@(disp,rm),r0 instructions. The patch introduces a new tergetm fuction and hides equivalences for such cases. The default tergetm fuction simply do nothing and shouldn't impact the other targets. The patch might be a bit overkill for SH. We need to see the code quality. With c#29 + c#55 + c#57 patches, all ICEs went away on sh4-linux. compare_tests against trunk rev.215912 says -- New tests that FAIL: g++.dg/cpp1y/feat-cxx14.C -std=gnu++1y (test for excess errors) gcc.target/sh/pr50749-sf-postinc-1.c scan-assembler-times fmov.s\\t@r[0-9]++,fr[0-9]+ 1 gcc.target/sh/pr50749-sf-postinc-3.c scan-assembler-times fmov.s\\t@r[0-9]++,fr[0-9]+ 1 Old tests that failed, that have disappeared: (Eeek!) gcc.dg/atomic/c11-atomic-exec-4.c -Os (internal compiler error) gcc.dg/atomic/c11-atomic-exec-4.c -Os (test for excess errors) libgomp.fortran/udr14.f90 -O3 -g (internal compiler error) libgomp.fortran/udr14.f90 -O3 -g (test for excess errors) -- The first new FAIL looks a test glitch and it turned out that pr50749-sf-postinc-1.c FAILs can be easily fixed. It looks that the LRA change suggested in c#56 is related about the optimization based with equivalences. I'd like to try it on sh-lra.
[Bug rtl-optimization/51366] [cygwin] ICE in maybe_record_trace_start, at dwarf2cfi.c:2244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51366 Richard Henderson changed: What|Removed |Added Status|WAITING |RESOLVED CC||rth at gcc dot gnu.org Resolution|--- |WORKSFORME --- Comment #8 from Richard Henderson --- As requested.
