[Bug c++/68628] New: [concepts] ICE: segmentation fault in crash_signal, toplev.c:334
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68628
Bug ID: 68628
Summary: [concepts] ICE: segmentation fault in crash_signal,
toplev.c:334
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucdanton at free dot fr
Target Milestone: ---
The source program was mechanically reduced.
$ g++-trunk --version
g++-trunk (GCC) 6.0.0 20151130 (experimental)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ cat prepro.ii
template struct is_convertible;
auto functor = [] {};
void forward();
namespace internal {
template Type constant;
struct A {
template static auto impl();
};
template struct B : A {
template
auto operator()(F, Args... args) requires
is_convertible::value;
};
}
using internal::constant;
namespace functors {
using internal::B;
}
template auto invoke_as = constant>;
template bool Invokable{invoke_as(forward)};
static_assert ( Invokable < decltype ( functor ), int >
$ g++-trunk -std=c++1z prepro.ii
prepro.ii: In instantiation of 'bool Invokable<, int>':
prepro.ii:21:17: required from here
prepro.ii:12:40: internal compiler error: Segmentation fault
is_convertible::value;
^
0xab2e5f crash_signal
../../gcc/gcc/toplev.c:334
0x5a61ee resolve_args
../../gcc/gcc/cp/call.c:3956
0x5b0eeb build_new_method_call_1
../../gcc/gcc/cp/call.c:8161
0x5b0eeb build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../gcc/gcc/cp/call.c:8445
0x692ee0 finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/gcc/cp/semantics.c:2360
0x5e9117 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:16451
0x5e9ba8 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:13379
0x5f1d0a tsubst_template_args
../../gcc/gcc/cp/pt.c:11077
0x5f220f tsubst_aggr_type
../../gcc/gcc/cp/pt.c:11274
0x5ea0f3 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/gcc/cp/pt.c:12743
0x5e6774 tsubst_qualified_id
../../gcc/gcc/cp/pt.c:13573
0x5e7531 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/gcc/cp/pt.c:16028
0x5e2b07 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/gcc/cp/pt.c:15620
0x6ea5ba satisfy_predicate_constraint
../../gcc/gcc/cp/constraint.cc:1794
0x6ea5ba satisfy_constraint_1
../../gcc/gcc/cp/constraint.cc:1998
0x6eaa86 satisfy_constraint
../../gcc/gcc/cp/constraint.cc:2049
0x6eab67 constraints_satisfied_p(tree_node*)
../../gcc/gcc/cp/constraint.cc:2156
0x5aff95 add_function_candidate
../../gcc/gcc/cp/call.c:1994
0x5b061c add_template_candidate_real
../../gcc/gcc/cp/call.c:3118
0x5b0a23 add_template_candidate
../../gcc/gcc/cp/call.c:3160
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug fortran/68598] Ponter Function as LValue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68598 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Dominique d'Humieres --- Without the requested information, this PR can only be resolved as INVALID.
[Bug ada/68590] [6 Regression] FAIL: gnat.dg/loop_optimization19.adb scan-tree-dump-not optimized "Index_Check"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68590 --- Comment #11 from Richard Biener --- (In reply to Eric Botcazou from comment #10) > > So the original compliant was that if we do that we pessimize code-gen > > because we un-CSE a possibly large sub-expression. > > Then maybe the "possibly large sub-expression" should be taken into account. > We already try by means of skip_simple_arithmetic, but it's too simple. > > > So you say that any tree-shared expr is only expanded once (as if it were > > wrapped in a save-expr)? > > No, it will be reexpanded if it has no TREE_SIDE_EFFECTS. What I'm saying > is that you control it by means of TREE_SIDE_EFFECTS. > > > Oh, so fold is performing CSE here? Shouldn't _that_ folding not set > > TREE_SIDE_EFFECTS on the SAVE_EXPR? Instead of forcing it on every user... > > It's not just fold, it's the way SAVE_EXPR works in GENERIC. You need to be > able to control when the variable is initialized at run time, otherwise it's > a recipe for disaster. Btw, removing TREE_SIDE_EFFECTS passes bootstrap for all languages but causes (not double-checked whether they are really caused by the change but they are new to my eyes): === acats tests === FAIL: c64107a FAIL: cc3007b === g++ tests === FAIL: g++.dg/ext/vla9.C -std=gnu++11 execution test FAIL: g++.dg/ext/vla9.C -std=gnu++14 execution test FAIL: g++.dg/ext/vla9.C -std=gnu++98 execution test FAIL: g++.dg/pr58950.C -std=gnu++11 (test for warnings, line 6) FAIL: g++.dg/pr58950.C -std=gnu++11 (test for excess errors) FAIL: g++.dg/pr58950.C -std=gnu++14 (test for warnings, line 6) FAIL: g++.dg/pr58950.C -std=gnu++14 (test for excess errors) FAIL: g++.dg/pr58950.C -std=gnu++98 (test for warnings, line 6) FAIL: g++.dg/pr58950.C -std=gnu++98 (test for excess errors) FAIL: c-c++-common/ubsan/save-expr-3.c -O0 (test for excess errors) FAIL: c-c++-common/ubsan/save-expr-3.c -O1 (test for excess errors) FAIL: c-c++-common/ubsan/save-expr-3.c -O2 (test for excess errors) FAIL: c-c++-common/ubsan/save-expr-3.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) FAIL: c-c++-common/ubsan/save-expr-3.c -O3 -g (test for excess errors) FAIL: c-c++-common/ubsan/save-expr-3.c -Os (test for excess errors) FAIL: c-c++-common/ubsan/save-expr-4.c -O0 (test for excess errors) FAIL: c-c++-common/ubsan/save-expr-4.c -O1 (test for excess errors) FAIL: c-c++-common/ubsan/save-expr-4.c -O2 (test for excess errors) FAIL: c-c++-common/ubsan/save-expr-4.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) FAIL: c-c++-common/ubsan/save-expr-4.c -O3 -g (test for excess errors) FAIL: c-c++-common/ubsan/save-expr-4.c -Os (test for excess errors) === gcc tests === FAIL: gcc.dg/c99-bool-1.c execution test FAIL: c-c++-common/gomp/atomic-12.c (test for excess errors) FAIL: c-c++-common/gomp/atomic-13.c (test for excess errors) FAIL: c-c++-common/ubsan/save-expr-3.c -O0 (test for excess errors) FAIL: c-c++-common/ubsan/save-expr-3.c -O1 (test for excess errors) FAIL: c-c++-common/ubsan/save-expr-3.c -O2 (test for excess errors) FAIL: c-c++-common/ubsan/save-expr-3.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) FAIL: c-c++-common/ubsan/save-expr-3.c -O3 -g (test for excess errors) FAIL: c-c++-common/ubsan/save-expr-3.c -Os (test for excess errors) FAIL: c-c++-common/ubsan/save-expr-4.c -O0 (test for excess errors) FAIL: c-c++-common/ubsan/save-expr-4.c -O1 (test for excess errors) FAIL: c-c++-common/ubsan/save-expr-4.c -O2 (test for excess errors) FAIL: c-c++-common/ubsan/save-expr-4.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) FAIL: c-c++-common/ubsan/save-expr-4.c -O3 -g (test for excess errors) FAIL: c-c++-common/ubsan/save-expr-4.c -Os (test for excess errors)
[Bug ada/68590] [6 Regression] FAIL: gnat.dg/loop_optimization19.adb scan-tree-dump-not optimized "Index_Check"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68590 --- Comment #12 from Richard Biener --- Author: rguenth Date: Tue Dec 1 08:52:58 2015 New Revision: 231100 URL: https://gcc.gnu.org/viewcvs?rev=231100&root=gcc&view=rev Log: 2015-12-01 Richard Biener PR middle-end/68590 * match.pd: Merge (eq @0 @0) and (ge/le @0 @0) patterns. Modified: trunk/gcc/ChangeLog trunk/gcc/match.pd
[Bug ada/68590] [6 Regression] FAIL: gnat.dg/loop_optimization19.adb scan-tree-dump-not optimized "Index_Check"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68590 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Richard Biener --- Fixed.
[Bug rtl-optimization/68194] [4.9/5/6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68194 --- Comment #18 from Jakub Jelinek --- *** Bug 68189 has been marked as a duplicate of this bug. ***
[Bug rtl-optimization/68189] [4.9/5/6 Regression] wrong code at -Os and above on x86_64-linux-gnu by RTL if-conversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68189 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #10 from Jakub Jelinek --- Dup. *** This bug has been marked as a duplicate of bug 68194 ***
[Bug testsuite/68629] New: FAIL: c-c++-common/attr-simd-3.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68629 Bug ID: 68629 Summary: FAIL: c-c++-common/attr-simd-3.c Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: thopre01 at gcc dot gnu.org Target Milestone: --- Target: arm-none-eabi Hi, When cross-compiling forarm-none-eabi targets with current trunk, attr-simd-3.c fails with: xgcc: error: unrecognized command line option '-pthread' The test would not have been run if it was with the other cilk-plus tests in c-c++-common/cilk-plus where it would be controlled by cilk-plus.exp instead of dg.exp.
[Bug c++/68630] New: [concepts] internal compiler error: in add_expr, at tree.c:7828
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68630 Bug ID: 68630 Summary: [concepts] internal compiler error: in add_expr, at tree.c:7828 Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: lucdanton at free dot fr Target Milestone: --- Created attachment 36877 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36877&action=edit Reduced testcase Using 6.0.0 20151201 (experimental). The testcase was reduced mechanically, must be compiled with any level of optimization above -O0 e.g.: $ g++-trunk -std=c++1z -Og prepro.ii The stack trace produced is noticeably similar to the one for PR 68116, but not identical either: prepro.ii:59:22: internal compiler error: in add_expr, at tree.c:7828 &functor(l, &local::get)(), "", l.i, ""); ^ 0xcb5d5d inchash::add_expr(tree_node const*, inchash::hash&) ../../gcc/gcc/tree.c:7828 0xcb5894 inchash::add_expr(tree_node const*, inchash::hash&) ../../gcc/gcc/tree.c:7801 0x8cf1de iterative_hash_expr ../../gcc/gcc/tree.h:4737 0x8cf1de gimplify_hasher::hash(gimple_temp_hash_elt const*) ../../gcc/gcc/gimplify.c:11535 0x8cf1de hash_table::find_slot(gimple_temp_hash_elt* const&, insert_option) ../../gcc/gcc/hash-table.h:408 0x8cf1de lookup_tmp_var ../../gcc/gcc/gimplify.c:523 0x8cf1de internal_get_tmp_var ../../gcc/gcc/gimplify.c:558 0x8cabdc gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gcc/gimplify.c:10982 0x8d1e1a gimplify_modify_expr ../../gcc/gcc/gimplify.c:4687 0x8cb2da gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gcc/gimplify.c:10057 0x8cb379 gimplify_target_expr ../../gcc/gcc/gimplify.c:5525 0x8cb379 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gcc/gimplify.c:10426 0x8cb685 gimplify_addr_expr ../../gcc/gcc/gimplify.c:5053 0x8cb685 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gcc/gimplify.c:10103 0x8d05d8 gimplify_call_expr ../../gcc/gcc/gimplify.c:2506 0x8cb86d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gcc/gimplify.c:10028 0x8d1e1a gimplify_modify_expr ../../gcc/gcc/gimplify.c:4687 0x8cb2da gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gcc/gimplify.c:10057 0x8cb379 gimplify_target_expr ../../gcc/gcc/gimplify.c:5525 0x8cb379 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) ../../gcc/gcc/gimplify.c:10426
[Bug c++/68631] New: -lstdc++fs switch not working on gcc 5.3.0-RC-20151130
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68631 Bug ID: 68631 Summary: -lstdc++fs switch not working on gcc 5.3.0-RC-20151130 Product: gcc Version: 5.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: marqin.pl+gcc at gmail dot com Target Milestone: --- Created attachment 36878 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36878&action=edit GCC output with -v -lstdc++fs switch not working on gcc 5.3.0-RC-20151130 I've tried building code example from here: http://en.cppreference.com/w/cpp/experimental/fs/directory_iterator with this command line: /opt/gcc53/bin/g++ -v -std=c++1z -lstdc++fs -L/opt/gcc53/lib64 test.cpp And I'm getting errors that are in attached output.txt Using nm on libstdc++fs.a show that those symbols are there, so it looks like gcc problem.
[Bug c++/68631] -lstdc++fs switch not working on gcc 5.3.0-RC-20151130
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68631 --- Comment #1 from Hubert Jarosz --- Created attachment 36879 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36879&action=edit .cpp test file
[Bug c++/68631] -lstdc++fs switch not working on gcc 5.3.0-RC-20151130
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68631 --- Comment #2 from Hubert Jarosz --- This GCC was built with 3 stage bootstraping from tarball posted by Richard Biener on GCC maillist: https://gcc.gnu.org/ml/gcc/2015-11/msg00210.html
[Bug testsuite/68632] New: FAIL: gcc.target/arm/lto/pr65837 c_lto_pr65837_0.o assemble, -flto -mfpu=neon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68632 Bug ID: 68632 Summary: FAIL: gcc.target/arm/lto/pr65837 c_lto_pr65837_0.o assemble, -flto -mfpu=neon Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: thopre01 at gcc dot gnu.org Target Milestone: --- Target: arm-none-eabi Hi, The patch fixing this PR65837 added a new test in gcc.target/arm/lto/pr65837_0.c. This test adds -mfpu=neon option but doesn't require an arm_neon_ok effective target which makes the test fail on ARMv7-M arm-none-eabi targets.
[Bug tree-optimization/68625] [6 Regression] Segmentation fault in useless_type_conversion_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68625 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-12-01 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- #1 0x00fccbcd in may_propagate_copy (dest=, orig=) at /space/rguenther/src/svn/trunk3/gcc/tree-ssa-propagate.c:1418 1418 if (!useless_type_conversion_p (type_d, type_o)) (gdb) p debug_tree (orig) $2 = void after copyprop. I will have a looksee.
[Bug tree-optimization/68624] [6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (in 64-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68624 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-01 Target Milestone|--- |6.0 Summary|wrong code at -O2 and -O3 |[6 Regression] wrong code |on x86_64-linux-gnu (in |at -O2 and -O3 on |64-bit mode)|x86_64-linux-gnu (in 64-bit ||mode) Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug c++/68631] -lstdc++fs switch not working on gcc 5.3.0-RC-20151130
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68631 --- Comment #3 from Hubert Jarosz --- I forgot to mention, it was configured with this option: ../configure --prefix=/opt/gcc53 --enable-languages=c,c++ And here is sha sum, so it's from correct tarball: c3e2b79419024867df0788a91ef67b758f546e51d17861ca123b874e85cb0952c3faad590b4e7d3a8034258c0cd1dae4b33248ba6278d9ec2df61c87dde20187 gcc-5.3.0-RC-20151130.tar.gz
[Bug rtl-optimization/67778] [6 Regression] ICE on valid code at -O3 on x86_64-linux-gnu in maybe_record_trace_start, at dwarf2cfi.c:2297
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67778
Jakub Jelinek changed:
What|Removed |Added
CC||bernds at gcc dot gnu.org,
||segher at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
Seems like shrink-wrapping bug. On the #c2 -m32 -Os, we have one bb that needs
prologue (the dominator of the exit block with the printf call, bb10).
Infinite loop in BB 6.
Infinite loop in BB 6.
starting the processing of deferred insns
ending the processing of deferred insns
df_analyze called
Attempting shrink-wrapping optimization.
Block 10 needs the prologue.
After wrapping required blocks, PRO is now 10
Avoiding non-duplicatable blocks, PRO is now 10
Bumping back to anticipatable blocks, PRO is now 9
Performing shrink-wrapping.
but, bb9 is part of an irreducible loop, and by moving the prologue into the
bb9, we end up with the prologue in the middle of a loop, which dwarf2cfi is
obviously strongly unhappy about.
So, the
basic_block last_ok = pro;
while (pro != entry)
{
basic_block pre = get_immediate_dominator (CDI_DOMINATORS, pro);
if (!dominated_by_p (CDI_POST_DOMINATORS, pre, pro))
break;
pro = pre;
if (can_get_prologue (pro, prologue_clobbered))
last_ok = pro;
}
pro = last_ok;
conditions are not sufficient, shall we also test whether pre is not inside of
some loop (loops are freed at this point though)? Shall it be in this loop, or
in can_get_prologue?
[Bug c++/68631] -lstdc++fs switch not working on gcc 5.3.0-RC-20151130
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68631 --- Comment #4 from Richard Biener --- It works for me.
[Bug tree-optimization/68624] [6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (in 64-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68624 Marek Polacek changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Started with r231003.
[Bug c++/68631] -lstdc++fs switch not working on gcc 5.3.0-RC-20151130
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68631 --- Comment #5 from Richard Biener --- You may want to use -Wl,--verbose to check which libstdc++fs the linker ends up using.
[Bug c++/68631] -lstdc++fs switch not working on gcc 5.3.0-RC-20151130
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68631 --- Comment #6 from Marc Glisse --- Did you try putting things in the right order on the command line (i.e. -l flags at the end)?
[Bug c++/68348] [6 regression] ICE: segfault in cxx_eval_constant_expression at cp/constexpr.c:3172
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68348 --- Comment #5 from Uroš Bizjak --- There are some hundred libstdc++ testsuite failures with the same backtrace for alpha-linux-gnu [1] and probably also s390 [2]. [1] https://gcc.gnu.org/ml/gcc-testresults/2015-11/msg03084.html [2] https://gcc.gnu.org/ml/gcc-testresults/2015-11/msg03083.html
[Bug tree-optimization/68552] [5/6 Regression]: ICE in in expand_expr_real_2 with -O2 -ftree-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68552 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed.
[Bug c++/68348] [6 regression] ICE: segfault in cxx_eval_constant_expression at cp/constexpr.c:3172
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68348 --- Comment #6 from Uroš Bizjak --- gdb backtrace: Program received signal SIGSEGV, Segmentation fault. cxx_eval_constant_expression (ctx=0x7fffd2a0, t=0x2e7bf258, lval=false, non_constant_p=0x7fffd78f, overflow_p=0x7fffd78e, jump_target=0x0) at ../../gcc-svn/trunk/gcc/cp/constexpr.c:3180 3180 return (*ctx->values->get (t)); (gdb) list 3175 if (lval) 3176return t; 3177 /* We ask for an rvalue for the RESULT_DECL when indirecting 3178 through an invisible reference, or in named return value 3179 optimization. */ 3180 return (*ctx->values->get (t)); 3181 3182case VAR_DECL: 3183case CONST_DECL: 3184 /* We used to not check lval for CONST_DECL, but darwin.c uses (gdb) bt #0 cxx_eval_constant_expression (ctx=0x7fffd2a0, t=0x2e7bf258, lval=false, non_constant_p=0x7fffd78f, overflow_p=0x7fffd78e, jump_target=0x0) at ../../gcc-svn/trunk/gcc/cp/constexpr.c:3180 #1 0x007a4935 in cxx_eval_indirect_ref (ctx=0x7fffd2a0, t=0x2e8d3780, lval=false, non_constant_p=0x7fffd78f, overflow_p=0x7fffd78e) at ../../gcc-svn/trunk/gcc/cp/constexpr.c:2617 #2 0x0079dba8 in cxx_eval_constant_expression (ctx=0x7fffd2a0, t=0x2e8d3780, lval=false, non_constant_p=0x7fffd78f, overflow_p=0x7fffd78e, jump_target=0x0) at ../../gcc-svn/trunk/gcc/cp/constexpr.c:3372 #3 0x007a64f5 in cxx_eval_component_reference (ctx=0x7fffd2a0, t=0x2e7a8ab0, lval=false, non_constant_p=0x7fffd78f, overflow_p=0x7fffd78e) at ../../gcc-svn/trunk/gcc/cp/constexpr.c:1882 #4 0x0079e500 in cxx_eval_constant_expression (ctx=0x7fffd2a0, t=0x2e7a8ab0, lval=false, non_constant_p=0x7fffd78f, overflow_p=0x7fffd78e, jump_target=0x0) at ../../gcc-svn/trunk/gcc/cp/constexpr.c:3522 #5 0x0079d603 in cxx_eval_constant_expression (ctx=0x7fffd2a0, t=0x2e8d3760, lval=false, non_constant_p=0x7fffd78f, overflow_p=0x7fffd78e, jump_target=0x0) at ../../gcc-svn/trunk/gcc/cp/constexpr.c:3572 #6 0x007a42ad in cxx_eval_store_expression (ctx=0x7fffd760, t=0x2e8d2460, lval=false, non_constant_p=0x7fffd78f, overflow_p=0x7fffd78e) at ../../gcc-svn/trunk/gcc/cp/constexpr.c:2844 #7 0x0079dcae in cxx_eval_constant_expression (ctx=0x7fffd760, t=0x2e8d2460, lval=false, non_constant_p=0x7fffd78f, overflow_p=0x7fffd78e, jump_target=0x0) at ../../gcc-svn/trunk/gcc/cp/constexpr.c:3313 #8 0x0079d790 in cxx_eval_constant_expression (ctx=0x7fffd760, t=0x2e8d3740, lval=false, non_constant_p=0x7fffd78f, overflow_p=0x7fffd78e, jump_target=0x7fffd5f0) at ../../gcc-svn/trunk/gcc/cp/constexpr.c:3326 #9 0x0079d58b in cxx_eval_constant_expression (ctx=0x7fffd760, t=0x2e8d2438, lval=false, non_constant_p=0x7fffd78f, overflow_p=0x7fffd78e, jump_target=0x7fffd5f0) at ../../gcc-svn/trunk/gcc/cp/constexpr.c:3433 #10 0x0079caa7 in cxx_eval_call_expression (ctx=0x7fffd760, t=0x2e8d40e0, lval=false, non_constant_p=0x7fffd78f, overflow_p=0x7fffd78e) at ../../gcc-svn/trunk/gcc/cp/constexpr.c:1396 #11 0x0079d6e8 in cxx_eval_constant_expression (ctx=0x7fffd760, t=0x2e8d40e0, lval=false, non_constant_p=0x7fffd78f, overflow_p=0x7fffd78e, jump_target=0x0) at ../../gcc-svn/trunk/gcc/cp/constexpr.c:3239 #12 0x0079f7ee in cxx_eval_outermost_constant_expr (t=0x2e8d40e0, allow_non_constant=true, strict=, object=0x0) at ../../gcc-svn/trunk/gcc/cp/constexpr.c:3774 #13 0x007a262d in maybe_constant_value_1 (t=0x2e8d40e0, decl=0x0) at ../../gcc-svn/trunk/gcc/cp/constexpr.c:3960 #14 0x007a27d8 in maybe_constant_value (t=0x2e8d40e0, decl=0x0) at ../../gcc-svn/trunk/gcc/cp/constexpr.c:3981 #15 0x00779fca in cp_fold (x=0x2e8d40e0) at ../../gcc-svn/trunk/gcc/cp/cp-gimplify.c:2156 #16 0x007813f5 in cp_fold_r (stmt_p=0x2e8d35f8, walk_subtrees=0x3, data=0x0) at ../../gcc-svn/trunk/gcc/cp/cp-gimplify.c:939 #17 0x00ff1548 in walk_tree_1 (tp=0x2e8d35f8, func=0x7813c0 , data=0x0, pset=0x0, lh= 0x730910 >*)>) at ../../gcc-svn/trunk/gcc/tree.c:11493 #18 0x00ff1887 in walk_tree_1 (tp=0x2e7a8aa0, func=0x7813c0 , data=0x0, pset=0x0, lh=0x730910 >*)>) at ../../gcc-svn/trunk/gcc/tree.c:11598 #19 0x00780d85 in cp_genericize (fndecl=0x2e8d0460) at ../../gcc-svn/trunk/gcc/cp/cp-gimplify.c:1478
[Bug rtl-optimization/68624] [6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (in 64-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68624 ktkachov at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Target||x86_64 Status|NEW |ASSIGNED Component|tree-optimization |rtl-optimization Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot gnu.org Known to fail||6.0 --- Comment #3 from ktkachov at gcc dot gnu.org --- Mine.
[Bug c++/68348] [6 regression] ICE: segfault in cxx_eval_constant_expression at cp/constexpr.c:3172
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68348 Uroš Bizjak changed: What|Removed |Added CC||krebbel at gcc dot gnu.org --- Comment #7 from Uroš Bizjak --- Adding CC for s390 failures.
[Bug target/63870] [Aarch64] [ARM] Errors in use of NEON intrinsics are reported incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63870 Ramana Radhakrishnan changed: What|Removed |Added Target Milestone|--- |6.0 --- Comment #16 from Ramana Radhakrishnan --- set target milestone.
[Bug sanitizer/68580] FAIL: c-c++-common/tsan/pr65400-1.c -O0 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68580 --- Comment #4 from vries at gcc dot gnu.org --- I've observed this failure now in two seperate build & test runs.
[Bug rtl-optimization/68624] [6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (in 64-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68624
--- Comment #4 from Jakub Jelinek ---
We have:
(code_label 37 36 38 8 8 "" [0 uses])
(note 38 37 39 8 [bb 8] NOTE_INSN_BASIC_BLOCK)
(insn 39 38 40 8 (set (reg:SI 94 [ d.8_13 ])
(mem/c:SI (symbol_ref:DI ("d") [flags 0x2] )
[1 d+0 S4 A32])) pr68624.c:12 86 {*movsi_internal}
(nil))
(insn 40 39 102 8 (set (mem/c:SI (symbol_ref:DI ("e") [flags 0x2] ) [1 e+0 S4 A32])
(reg:SI 94 [ d.8_13 ])) pr68624.c:12 86 {*movsi_internal}
(nil))
(insn 102 40 41 8 (set (reg:SI 105 [ a ])
(const_int -4 [0xfffc])) -1
(nil))
(insn 41 102 42 8 (set (mem/c:SI (symbol_ref:DI ("c") [flags 0x2] ) [1 c+0 S4 A32])
(reg:SI 105 [ a ])) -1
(expr_list:REG_DEAD (reg:SI 105 [ a ])
(nil)))
(insn 42 41 43 8 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 94 [ d.8_13 ])
(const_int 0 [0]))) pr68624.c:15 3 {*cmpsi_ccno_1}
(expr_list:REG_DEAD (reg:SI 94 [ d.8_13 ])
(nil)))
(jump_insn 43 42 52 8 (set (pc)
(if_then_else (ne (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref 52)
(pc))) pr68624.c:15 631 {*jcc_1}
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(int_list:REG_BR_PROB 5000 (nil)))
-> 52)
as if_info->test_bb and
(code_label 52 43 53 10 10 "" [1 uses])
(note 53 52 101 10 [bb 10] NOTE_INSN_BASIC_BLOCK)
(insn 101 53 54 10 (set (reg:SI 105 [ a ])
(const_int -5 [0xfffb])) pr68624.c:16 -1
(nil))
(insn 54 101 55 10 (set (mem/c:SI (symbol_ref:DI ("c") [flags 0x2] ) [1 c+0 S4 A32])
(reg:SI 105 [ a ])) pr68624.c:16 -1
(expr_list:REG_DEAD (reg:SI 105 [ a ])
(nil)))
as if_info->test_bb, else_bb is NULL.
emit_a is:
(set (reg:SI 107)
(reg:SI 105 [ a ]))
where the pseudo 107 is tmp_a. Before the patch we've emitted:
(insn 107 42 108 8 (set (reg:SI 107)
(reg:SI 105 [ a ])) pr68624.c:16 86 {*movsi_internal}
(nil))
(insn 108 107 109 8 (set (reg:SI 105 [ a ])
(const_int -5 [0xfffb])) pr68624.c:16 86 {*movsi_internal}
(nil))
(insn 109 108 110 8 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:SI 94 [ d.8_13 ])
(const_int 0 [0]))) pr68624.c:16 3 {*cmpsi_ccno_1}
(nil))
(insn 110 109 111 8 (set (reg:SI 106)
(if_then_else:SI (ne (reg:CCZ 17 flags)
(const_int 0 [0]))
(reg:SI 105 [ a ])
(reg:SI 107))) pr68624.c:16 957 {*movsicc_noc}
(nil))
(insn 111 110 57 8 (set (mem/c:SI (symbol_ref:DI ("c") [flags 0x2] ) [1 c+0 S4 A32])
(reg:SI 106)) pr68624.c:16 86 {*movsi_internal}
(nil))
i.e. tmp_a has been first assigned the original value, then the 105 pseudo
changed. But with the patch it is now broken:
(insn 107 42 108 8 (set (reg:SI 105 [ a ])
(const_int -5 [0xfffb])) pr68624.c:16 86 {*movsi_internal}
(nil))
(insn 108 107 109 8 (set (reg:SI 107)
(reg:SI 105 [ a ])) pr68624.c:16 86 {*movsi_internal}
(nil))
which means that the original value is unconditionally overwritten.
[Bug ipa/68331] [meta-bug] fipa-pta issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68331 --- Comment #1 from vries at gcc dot gnu.org --- > IPA PTA can use a _lot_ of memory and compile-time Doing a non-bootstrap build with -fipa-pta enabled by default gets stuck at: ... PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND 32436 vries 20 0 1697m 1.6g 9812 R 100 3.4 49:24.20 jc1 1393 vries 20 0 1449m 1.4g 9760 R 100 2.9 49:17.13 jc1 20984 vries 20 0 5665m 5.5g 9936 R 100 11.6 47:30.41 jc1 12641 vries 20 0 1122m 1.0g 9880 R 100 2.2 51:43.55 jc1 $ ps fx |grep jc1 | grep -o '[^ ]*\.o ' java/.libs/util.o javax/.libs/swing.o javax/swing/plaf/.libs/basic.o classpath/tools/.libs/libgcj_tools_la-tools.o ...
[Bug middle-end/68595] [6 regression] ice in const_vector_mask_from_tree at expr.c:11455
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68595 --- Comment #9 from Ilya Enkovich --- Author: ienkovich Date: Tue Dec 1 11:04:06 2015 New Revision: 231106 URL: https://gcc.gnu.org/viewcvs?rev=231106&root=gcc&view=rev Log: gcc/ PR middle-end/68595 * tree-vect-stmts.c (vect_init_vector): Cast boolean scalars to a proper value before building a vector. gcc/testsuite/ PR middle-end/68595 * gcc.dg/pr68595.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr68595.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-stmts.c
[Bug middle-end/68595] [6 regression] ice in const_vector_mask_from_tree at expr.c:11455
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68595 Ilya Enkovich changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Ilya Enkovich --- Fixed
[Bug objc++/68511] FAIL: obj-c++.dg/property/dotsyntax-11.mm -fgnu-runtime (test for errors, line 51,56,59)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68511 --- Comment #3 from vries at gcc dot gnu.org --- Noted by Andreas Schwab as well: https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02907.html
[Bug objc++/68511] FAIL: obj-c++.dg/property/dotsyntax-11.mm -fgnu-runtime (test for errors, line 51,56,59)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68511 vries at gcc dot gnu.org changed: What|Removed |Added Keywords||patch --- Comment #4 from vries at gcc dot gnu.org --- https://gcc.gnu.org/ml/gcc-patches/2015-11/msg03521.html
[Bug c++/68449] [5/6 Regression] ICE in cxx_eval_constant_expression on atomic_load in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68449 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |5.3 Summary|ICE in |[5/6 Regression] ICE in |cxx_eval_constant_expressio |cxx_eval_constant_expressio |n on atomic_load in C++ |n on atomic_load in C++ --- Comment #2 from Jakub Jelinek --- Of course it is a regression, started with r217663.
[Bug ipa/68331] [meta-bug] fipa-pta issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68331 --- Comment #2 from rguenther at suse dot de --- On Tue, 1 Dec 2015, vries at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68331 > > --- Comment #1 from vries at gcc dot gnu.org --- > > IPA PTA can use a _lot_ of memory and compile-time > > Doing a non-bootstrap build with -fipa-pta enabled by default gets stuck at: > ... > PID USER PR NI VIRT RES SHR S %CPU %MEMTIME+ COMMAND > > 32436 vries 20 0 1697m 1.6g 9812 R 100 3.4 49:24.20 jc1 > 1393 vries 20 0 1449m 1.4g 9760 R 100 2.9 49:17.13 jc1 > 20984 vries 20 0 5665m 5.5g 9936 R 100 11.6 47:30.41 jc1 > 12641 vries 20 0 1122m 1.0g 9880 R 100 2.2 51:43.55 jc1 > > $ ps fx |grep jc1 | grep -o '[^ ]*\.o ' > java/.libs/util.o > javax/.libs/swing.o > javax/swing/plaf/.libs/basic.o > classpath/tools/.libs/libgcj_tools_la-tools.o > ... Yeah, Java basically does "compile-all-in-one". IPA PTA survives a LTO bootstrap (without libjava ...) though. At least it did so in the past. Likewise it survives SPEC CPU 2006 with LTO. Note that IPA PTA runs as "late" IPA pass during LTRANS and not on the full program there. I suspect we wouldn't survive -flto-partition=none builds.
[Bug target/68633] New: [i386, AVX-512] Spec2006/434. miscompares when executed on KNL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68633 Bug ID: 68633 Summary: [i386, AVX-512] Spec2006/434. miscompares when executed on KNL Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: kyukhin at gcc dot gnu.org Target Milestone: --- Created attachment 36880 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36880&action=edit Reproducer Attached test case is reduced version of the problem. To reproduce: $ ./build-x86_64-linux/gcc/xgcc -B./build-x86_64-linux/gcc ~/test.c -O3 -march=knl $ ~/sde/sde-internal-rs-7.31.0-2015-09-25-lin/sde64 -- ./a.out libc: Fatal signal 6 (SIGABRT), code -6 in tid 34536^@ Aborted (core dumped) This is most likely recent introduction of scalar masking. I suspect that order of operands is incorrect in the pattern
[Bug ipa/68470] [4.9/5/6 Regression] Internal Compiler Error observed by g++-4.9.2 and a few other versions (reported to Debian)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68470 --- Comment #7 from Richard Biener --- Author: rguenth Date: Tue Dec 1 11:35:21 2015 New Revision: 231108 URL: https://gcc.gnu.org/viewcvs?rev=231108&root=gcc&view=rev Log: 2015-12-01 Richard Biener PR ipa/68470 * ipa-split.c (split_function): Handle main part not returning. * g++.dg/torture/pr68470.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/torture/pr68470.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-split.c trunk/gcc/testsuite/ChangeLog
[Bug lto/68626] Compiling with "-flto -fuse-linker-plugin" gives libtool error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68626 john.frankish at outlook dot com changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #10 from john.frankish at outlook dot com --- Yeah - the symlink is in the gcc package, which is why binutils nm cannot find it. If I move the symlink to the binutils package, I'll break gcc-nm... 'Seems a solution is to copy binutils ar, ranlib and nm to the root file system on loading the package. Anyway, not a gcc/binutils bug - thanks for your help with this.
[Bug rtl-optimization/68624] [6 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (in 64-bit mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68624
--- Comment #5 from ktkachov at gcc dot gnu.org ---
Thanks, I've come to the same conclusion.
The code in noce_cmove_arith that checks for overlapping writes
among the basic blocks has a bug. In the code:
if (emit_a || modified_in_a)
{
modified_in_b = emit_b != NULL_RTX && modified_in_p (orig_a, emit_b);
if (tmp_b && else_bb)
...
changing the second if to:
if (tmp_a && else_bb)
fixes the testcase. But the whole logic there is becoming somewhat convoluted.
I'll see if I can make the control flow there clearer
[Bug c++/68449] [5/6 Regression] ICE in cxx_eval_constant_expression on atomic_load in C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68449
--- Comment #3 from Jakub Jelinek ---
Slightly improved testcase:
// PR c++/68449
// { dg-do compile }
// { dg-options "-Wsign-compare" }
int
foo (int a)
{
return __extension__ ({ int b; b; }) < 0;
}
It seems that if the ctx->values hash table has a record for certain variable,
but it is uninitialized, it has NULL_TREE in there.
Some spots that call ctx->values->get do check for NULL, but others don't.
This particular case is:
3195 if (VAR_P (r))
3196if (tree *p = ctx->values->get (r))
3197 r = *p;
I wonder if for !*p we just shouldn't keep r the VAR_DECL as is and let the few
lines before complain if needed. So that would be
if (VAR_P (r))
if (tree *p = ctx->values->get (r))
if (*p)
r = *p;
or so.
[Bug target/68634] New: [6 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2284 w/ -O2 -fmodulo-sched
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68634
Bug ID: 68634
Summary: [6 Regression] ICE in maybe_record_trace_start, at
dwarf2cfi.c:2284 w/ -O2 -fmodulo-sched
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-6.0.0-alpha20151129 for target x86_64-pc-linux-gnu ICEs when building the
following reduced case w/ -O2 -fmodulo-sched:
int *pp, *ec;
int ci, ft;
void
ry(void);
int
wp(void)
{
if (ft) {
if (*ec)
return -1;
y0:
ci = 0;
}
if (*pp) {
ry();
return 0;
}
goto y0;
}
% gcc-6.0.0-alpha20151129 -c -O2 -fmodulo-sched oxyvkmdh.c
oxyvkmdh.c: In function 'wp':
oxyvkmdh.c:21:1: internal compiler error: in maybe_record_trace_start, at
dwarf2cfi.c:2284
This seems to be target-specific, as I cannot reproduce it w/ the same snapshot
for powerpc-e500v2-linux-gnuspe.
[Bug c++/68348] [6 regression] ICE: segfault in cxx_eval_constant_expression at cp/constexpr.c:3172
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68348 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- Doesn't seem to be (closely) related to PR68449. In this case the hash table does not have any value for the RESULT_DECL c, while the code seems to assume that RESULT_DECL always has some (and most likely non-NULL, i.e. initialized) entry in the hash table.
[Bug c++/68631] -lstdc++fs switch not working on gcc 5.3.0-RC-20151130
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68631 --- Comment #8 from Hubert Jarosz --- Created attachment 36881 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36881&action=edit GCC output with -v and -Wl,--verbose
[Bug c++/68631] -lstdc++fs switch not working on gcc 5.3.0-RC-20151130
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68631 --- Comment #7 from Hubert Jarosz --- I've added output of: /opt/gcc53/bin/g++ -v -Wl,--verbose -std=c++1z test.cpp -lstdc++fs &> output_2.txt as output_2.txt
[Bug c++/68631] -lstdc++fs switch not working on gcc 5.3.0-RC-20151130
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68631 --- Comment #9 from Hubert Jarosz --- Oh, wait, now it works. So it's a bug when -lstdc++fs is not at the end. On my normal g++/clang++ puting -l flags on the end works well, except for this one on 5.3.
[Bug c++/68631] -lstdc++fs switch not working on gcc 5.3.0-RC-20151130
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68631 --- Comment #10 from Hubert Jarosz --- > On my normal g++/clang++ puting -l flags on the end works well, except for > this one on 5.3. I mean "not puting on the end works"
[Bug ipa/68470] [4.9/5 Regression] Internal Compiler Error observed by g++-4.9.2 and a few other versions (reported to Debian)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68470 Richard Biener changed: What|Removed |Added Known to work||6.0 Summary|[4.9/5/6 Regression]|[4.9/5 Regression] Internal |Internal Compiler Error |Compiler Error observed by |observed by g++-4.9.2 and a |g++-4.9.2 and a few other |few other versions |versions (reported to |(reported to Debian)|Debian) Known to fail|6.0 | --- Comment #8 from Richard Biener --- Fixed on trunk. Let's watch the fireworks.
[Bug middle-end/68122] ICE in gcc/toplev.c:353 with -fsanitize=undefined and -fgnu-tm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68122
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #4 from Marek Polacek ---
The original testcase does not ICE anymore, but e.g. this one does:
int cnt;
int *p;
int main(void)
{
__transaction_atomic {
cnt++;
*p = 6;
}
}
[Bug middle-end/68122] ICE in gcc/toplev.c:353 with -fsanitize=undefined and -fgnu-tm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68122
--- Comment #5 from Marek Polacek ---
And another with a different ICE:
int
main (void)
{
int r[5];
__transaction_atomic
{
r[5] = 4;
}
}
[Bug c/68635] New: IRA: Should update cost when choose an alternative for an insn?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68635 Bug ID: 68635 Summary: IRA: Should update cost when choose an alternative for an insn? Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: Abnerkook at foxmail dot com Target Milestone: --- When I write a pattern for addsi3 as follows: (define_insn "addsi3" [(set (match_operand:SI 0 "register_operand" "=r,r") (plus:SI (match_operand:SI 1 "register_operand" "zra,zrb") (match_operand:SI 2 "register_operand" "zra,zrb")))]) Here, zra and zrb are non-intersect regclass, the selection of alternative is decided by the register allocation. But, sometimes when IRA choosing regclass for operand 2 after already allocated zra to operand 1, because zrb's cost is less than zra, IRA choose zrb for operand 2. To obey the constraint, additional move insn will be emitted which we not expect. So, updating cost when choose an alternative for an insn will be better for this case？ Or, is there some methods to advoid this case? Please give me some advice, I shall be very grateful. Sorry for my poor English.
[Bug rtl-optimization/68636] New: unnecessary unaligned load on mips o32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68636
Bug ID: 68636
Summary: unnecessary unaligned load on mips o32
Product: gcc
Version: 5.2.1
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jan.sm...@alcatel-lucent.com
Target Milestone: ---
typedef unsigned long uintptr_t;;
volatile unsigned int x;
void testTestTest(void)
{
x = *((volatile unsigned int *) (((volatile void
*)((uintptr_t)(0x00800070) | ((0xA000) + (uintptr_t)(0x00800070)) >=
0x0080) && ( { register int zeroIsCavium; asm volatile ( " .setpush
\n" " .setnoreorder \n" " mfc0%0,$15 \n" "
srl %0,%0,16\n" " andi%0,%0,0xff \n" " xori
%0,%0,0x0d \n" " .setpop \n" : "=r" (zeroIsCavium));
(zeroIsCavium == 0); } )) ? 0x2000 : 0));
}
GCC 4.8 (-march=mips2 -O2 (mabi=o32)) generates
:
0: 40027800mfc0v0,$15
4: 00021402srl v0,v0,0x10
8: 304200ffandiv0,v0,0xff
c: 3842000dxoriv0,v0,0xd
10: 1046beqzv0,2c
14: 3c02a080lui v0,0xa080
18: 24420070addiu v0,v0,112
1c: 8c43lw v1,0(v0)
20: 3c02lui v0,0x0
24: 03e8jr ra
28: ac43sw v1,0(v0)
2c: 3c02c080lui v0,0xc080
30: 24420070addiu v0,v0,112
34: 8c43lw v1,0(v0)
38: 3c02lui v0,0x0
3c: 03e8jr ra
40: ac43sw v1,0(v0)
GCC 5.2.1 more or less replaces the LW with LWL+LWR
:
0: 40027800mfc0v0,$15
4: 00021402srl v0,v0,0x10
8: 304200ffandiv0,v0,0xff
c: 3842000dxoriv0,v0,0xd
10: 1048beqzv0,34
14: 3c02a080lui v0,0xa080
18: 24420070addiu v0,v0,112
1c: 8843lwl v1,0(v0)
20: 98430003lwr v1,3(v0)
24: 00601021movev0,v1
28: 3c03lui v1,0x0
2c: 03e8jr ra
30: ac62sw v0,0(v1)
34: 3c02c080lui v0,0xc080
38: 24420070addiu v0,v0,112
3c: 8843lwl v1,0(v0)
40: 98430003lwr v1,3(v0)
44: 00601021movev0,v1
48: 3c03lui v1,0x0
4c: 03e8jr ra
50: ac62sw v0,0(v1)
When taking just the true branch of the inline assembly, thus further reducing
to something like
x = *((volatile unsigned int *) (((volatile void *)((uintptr_t)(0x00800070) |
((0xA000) + 0x2000) ;
then results in exactly the same code in both 4.8 and 5.2.1
:
0: 3c02c080lui v0,0xc080
4: 8c430070lw v1,112(v0)
8: 3c02lui v0,0x0
c: ac43sw v1,0(v0)
10: 03e8jr ra
14: nop
Is there a specific reason it starts using unaligned accesses when the inline
assembly is included? The variable factor is either 0x2000 or 0x0, which
both result in aligned addresses.
Thanks
[Bug middle-end/68122] ICE in gcc/toplev.c:353 with -fsanitize=undefined and -fgnu-tm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68122 --- Comment #6 from Jakub Jelinek --- And another with just -fgnu-tm, same ICE spot as #c5.
[Bug middle-end/68122] ICE in gcc/toplev.c:353 with -fsanitize=undefined and -fgnu-tm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68122
Jakub Jelinek changed:
What|Removed |Added
CC||rth at gcc dot gnu.org,
||torvald at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek ---
Forgot the testcase:
int cnt;
int x, y, *p;
int
main (void)
{
__transaction_atomic
{
cnt += __builtin_add_overflow (x, y, p);
}
}
Basically, all cases in trans-mem.c that use gimple_call_fn are suspect, for
gimple_call_internal_p calls that returns NULL.
is_tm_pure_call handles internal calls by testing ECF_CONST or ECF_PURE for
them, which is fine, the question is what exactly to do about the other spots.
Richard/Torvald, could you please have a look at this?
[Bug debug/68302] [5/6 Regression] ICE with debugging enabled on mips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68302 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Can't reproduce with a gcc-5-branch cross either (but, this is a cross without mips binutils around, so some auto-host.h tests might be different).
[Bug tree-optimization/68625] [6 Regression] Segmentation fault in useless_type_conversion_p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68625
--- Comment #2 from Richard Biener ---
So the copyprop iteration figures out half of the function is unreachable
and thus registers a copy from a value defined in a region that is also
dead (but we figure that out only during substitution and folding via
a match.pd pattern looking at defs). Then cfgcleanup comes along and
processes BBs in random order, removing the wrong unreachable region
(with the def we propagated) first and then another unreachable region
part where a basic-block merging opportunity then causes the propagated
but removed def being a source for propagating out a PHI ...
One fix is to _not_ do remove_edge_and_dominated_blocks in CFG cleanup
but only remove edges and remove unreachable blocks later (which causes
more work of course). Or trying to paper over the issue by checking
for released SSA names (propagating them out anyway) or delaying SSA
name release via registering them for SSA update.
CFG cleanup ordering patch:
Index: gcc/tree-cfgcleanup.c
===
--- gcc/tree-cfgcleanup.c (revision 231101)
+++ gcc/tree-cfgcleanup.c (working copy)
@@ -67,7 +67,7 @@ remove_fallthru_edge (vec *
if (e->flags & EDGE_COMPLEX)
e->flags &= ~EDGE_FALLTHRU;
else
- remove_edge_and_dominated_blocks (e);
+ remove_edge (e);
return true;
}
return false;
@@ -134,7 +134,7 @@ cleanup_control_expr_graph (basic_block
taken_edge->probability += e->probability;
taken_edge->count += e->count;
- remove_edge_and_dominated_blocks (e);
+ remove_edge (e);
retval = true;
}
else
@@ -218,7 +218,7 @@ cleanup_control_flow_bb (basic_block bb)
for (ei = ei_start (bb->succs); (e = ei_safe_edge (ei)); )
{
if (e->dest != target_block)
- remove_edge_and_dominated_blocks (e);
+ remove_edge (e);
else
{
/* Turn off the EDGE_ABNORMAL flag. */
@@ -717,7 +717,13 @@ cleanup_tree_cfg_noloop (void)
changed = false;
}
- changed |= cleanup_tree_cfg_1 ();
+ if (cleanup_tree_cfg_1 ())
+{
+ changed = true;
+ delete_unreachable_blocks ();
+ free_dominance_info (CDI_DOMINATORS);
+ calculate_dominance_info (CDI_DOMINATORS);
+}
gcc_assert (dom_info_available_p (CDI_DOMINATORS));
compact_blocks ();
"Hack" to detect the situation and not ICE (could also be applied to
may_propagate_copy)
Index: gcc/tree-cfg.c
===
--- gcc/tree-cfg.c (revision 231101)
+++ gcc/tree-cfg.c (working copy)
@@ -1865,6 +1865,8 @@ gimple_merge_blocks (basic_block a, basi
tree def = gimple_phi_result (phi), use = gimple_phi_arg_def (phi, 0);
gimple *copy;
bool may_replace_uses = (virtual_operand_p (def)
+ || (TREE_CODE (use) == SSA_NAME
+ && SSA_NAME_IN_FREE_LIST (use))
|| may_propagate_copy (def, use));
/* In case we maintain loop closed ssa form, do not propagate arguments
[Bug middle-end/68122] ICE in gcc/toplev.c:353 with -fsanitize=undefined and -fgnu-tm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68122
--- Comment #8 from Marek Polacek ---
I'm testing the following which skips internal fns, but I don't know if that's
the right thing for TM. At least it fixes all the ICEs I see.
I can post this to ML if it passes testing and we can discuss there.
--- gcc/trans-mem.c
+++ gcc/trans-mem.c
@@ -649,6 +649,8 @@ diagnose_tm_1 (gimple_stmt_iterator *gsi, bool
*handled_ops_p,
case GIMPLE_CALL:
{
tree fn = gimple_call_fn (stmt);
+ if (fn == NULL_TREE)
+ break;
if ((d->summary_flags & DIAG_TM_OUTER) == 0
&& is_tm_may_cancel_outer (fn))
@@ -4316,6 +4318,8 @@ ipa_tm_scan_irr_block (basic_block bb)
break;
fn = gimple_call_fn (stmt);
+ if (fn == NULL_TREE)
+ break;
/* Functions with the attribute are by definition irrevocable. */
if (is_tm_irrevocable (fn))
@@ -5109,6 +5113,10 @@ ipa_tm_transform_calls_redirect (struct cgraph_node
*node,
struct cgraph_edge *e = node->get_edge (stmt);
tree fndecl = gimple_call_fndecl (stmt);
+ /* Skip internal functions. */
+ if (gimple_call_fn (stmt) == NULL_TREE)
+return;
+
/* For indirect calls, pass the address through the runtime. */
if (fndecl == NULL)
{
[Bug ipa/68331] [meta-bug] fipa-pta issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68331
--- Comment #3 from vries at gcc dot gnu.org ---
(In reply to vries from comment #1)
> java/.libs/util.o
After 39 mins of runtime (and at ~1GB of memory usage), we have these stats:
...
(gdb) p stats
$14 = {
total_vars = 49735,
nonpointer_vars = 1490,
unified_vars_static = 12847,
unified_vars_dynamic = 0,
iterations = 3,
num_edges = 167698419,
num_implicit_edges = 75418,
points_to_sets_created = 0
}
...
[Bug target/68634] [6 Regression] ICE in maybe_record_trace_start, at dwarf2cfi.c:2284 w/ -O2 -fmodulo-sched
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68634 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-01 CC||jakub at gcc dot gnu.org, ||segher at gcc dot gnu.org Target Milestone|--- |6.0 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r228022, goes away with -fno-shrink-wrap. Perhaps similar issue to PR67778 ?
[Bug c/68589] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68589 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2015-12-01 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Marek Polacek --- Unfortunately, I can't reproduce this one on x86_64-linux; I've used -O2 -g -O2 -Wall -Wextra -Wcast-qual -Wc++-compat -Wpointer-arith -Wbad-function-cast -Wcast-align -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wmissing-format-attribute -Wmissing-noreturn -std=gnu99 options and tried all supported versions of GCC.
[Bug middle-end/68582] -Wunused-function doesn't warn about unused static __attribute__((noreturn)) functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68582 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Component|c |middle-end Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |6.0 --- Comment #4 from Marek Polacek --- Mine.
[Bug c++/68597] [6 Regression] ice in check_return_expr, at cp/typeck.c:8635
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68597
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2015-12-01
CC||jakub at gcc dot gnu.org,
||jason at gcc dot gnu.org
Target Milestone|--- |6.0
Summary|ice inin check_return_expr, |[6 Regression] ice in
|at cp/typeck.c:8635 |check_return_expr, at
||cp/typeck.c:8635
Ever confirmed|0 |1
--- Comment #2 from Jakub Jelinek ---
Started with r229629. Before that it was rejected:
pr68597.C: In lambda function:
pr68597.C:4:64: error: inconsistent types ‘int’ and ‘double’ deduced for lambda
return type
auto z = [=](double y) { if (y >= 1.0) return 1; else return x; };
^
[Bug ipa/68331] [meta-bug] fipa-pta issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68331
--- Comment #4 from vries at gcc dot gnu.org ---
(In reply to vries from comment #3)
> (In reply to vries from comment #1)
> > java/.libs/util.o
>
> After 39 mins of runtime (and at ~1GB of memory usage), we have these stats:
> ...
And after 1hr of runtime (and at ~1.2GB) when solve_graph is done, we have:
...
(gdb) p stats
$20 = {
total_vars = 49735,
nonpointer_vars = 1490,
unified_vars_static = 12847,
unified_vars_dynamic = 19291,
iterations = 11,
num_edges = 230033242,
num_implicit_edges = 75418,
points_to_sets_created = 1907
}
...
[Bug c++/68631] -lstdc++fs switch not working on gcc 5.3.0-RC-20151130
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68631 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #11 from Jonathan Wakely --- (In reply to Hubert Jarosz from comment #9) > Oh, wait, now it works. So it's a bug when -lstdc++fs is not at the end. It's a bug in your command when you don't put it at the end. > On my normal g++/clang++ puting -l flags on the end works well, except for > this one on 5.3. It (sometimes) works for shared libraries. This is a static library, so must be listed after any objects that need it. This is how linkers work, so not a bug. http://c-faq.com/lib/libsearch.html
[Bug target/68609] PowerPC reciprocal estimate missed opportunities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68609 David Edelsohn changed: What|Removed |Added Target||powerpc-*-* Target Milestone|--- |6.0
[Bug target/68609] PowerPC reciprocal estimate missed opportunities
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68609 David Edelsohn changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-01 Ever confirmed|0 |1 --- Comment #1 from David Edelsohn --- Confirmed.
[Bug libgomp/68579] FAIL: libgomp.c/target-32.c execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68579 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug c++/68604] typeid does not allow an id-expression that denotes a non-static data member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68604 --- Comment #2 from Shafik Yaghmour --- Wandbox has clang 3.8 and we can see that clang accepts this in C++11 mode: http://melpon.org/wandbox/permlink/IzawQ5DDLFyIyQNo but not in C++03 mode: http://melpon.org/wandbox/permlink/IzawQ5DDLFyIyQNo. Note, defect report 613: http://open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#613 has CD1 status.
[Bug c++/68585] [5/6 Regression] c++14 code accepted by 4.9 not accepted by 5 and 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68585 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2015-12-01 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- The code looks valid to me. Preprocessing with 4.9.3 and compiling with trunk fails, so it's a front-end regression (not something in the library). I'll try to reduce it.
[Bug ada/68590] [6 Regression] FAIL: gnat.dg/loop_optimization19.adb scan-tree-dump-not optimized "Index_Check"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68590 --- Comment #14 from Richard Biener --- Author: rguenth Date: Tue Dec 1 14:22:40 2015 New Revision: 231110 URL: https://gcc.gnu.org/viewcvs?rev=231110&root=gcc&view=rev Log: 2015-12-01 Richard Biener PR middle-end/68590 * genmatch.c (struct capture_info): Add match_use_count. (capture_info::walk_match): Increment match_use_count. (dt_simplify::gen_1): For GENERIC, only wrap multi-use replacements in a save_expr if they occur more often than in the original expression. Modified: trunk/gcc/ChangeLog trunk/gcc/genmatch.c
[Bug tree-optimization/68379] [6 Regression] BB vectorization: definition in block 13 follows the use for SSA_NAME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68379 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Richard Biener --- Fixed.
[Bug tree-optimization/68379] [6 Regression] BB vectorization: definition in block 13 follows the use for SSA_NAME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68379 --- Comment #10 from Richard Biener --- Author: rguenth Date: Tue Dec 1 14:24:54 2015 New Revision: 23 URL: https://gcc.gnu.org/viewcvs?rev=23&root=gcc&view=rev Log: 2015-12-01 Richard Biener PR tree-optimization/68379 * tree-vect-stmts.c (vectorizable_load): For BB vectorization always base loads on the first used DR of a group. * tree-vect-data-refs.c (vect_slp_analyze_and_verify_node_alignment): Compute alignment of the first scalar element unconditionally. * gcc.dg/torture/pr68379.c: New testcase. * gfortran.dg/pr68379-1.f90: Likewise. * gfortran.dg/pr68379-2.f: Likewise. Added: trunk/gcc/testsuite/gcc.dg/torture/pr68379.c trunk/gcc/testsuite/gfortran.dg/pr68379-1.f90 trunk/gcc/testsuite/gfortran.dg/pr68379-2.f Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-data-refs.c trunk/gcc/tree-vect-stmts.c
[Bug middle-end/68122] ICE in gcc/toplev.c:353 with -fsanitize=undefined and -fgnu-tm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68122 --- Comment #9 from torvald at gcc dot gnu.org --- Marek, just skipping handling of internal functions is not correct I think. In the worst case, it should treat them as txn-unsafe, unless they are considered txn-pure. Do we have some idea of how many built-ins would be affected? For example I believe it wouldn't be critical if TM wouldn't be compatible with UBSan for now, but if there are builtins for code that would be intuitively txn-safe, supporting them would be good. Regarding UBSan specifically, I believe many of the checks could be handled in a straight-forward way: All values returned by transactional memory accesses will form a consistent snapshot, always. So, for example, an addition-with-check call that takes values as arguments should be tm_pure because it will check values that could have happened in some execution, even if the transaction has to be rolled back later on.
[Bug c++/68585] [5/6 Regression] c++14 code accepted by 4.9 not accepted by 5 and 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68585
--- Comment #3 from Jonathan Wakely ---
Or this version is valid C++11 (and accepted by clang and EDG):
template
struct array
{
T _M_data[N];
};
template
struct integer_sequence
{
};
struct Pos
{
unsigned l;
};
template
constexpr array make_grid_position(integer_sequence)
{
return {{ Pos{Ints}... }};
}
constexpr array make_grid_positions()
{
return make_grid_position(integer_sequence{});
}
template
void generate_sudoku(T)
{
constexpr auto positions = make_grid_positions(); // fail
}
int main()
{
constexpr auto positions = make_grid_positions(); // ok
generate_sudoku(1);
}
[Bug c++/68585] [5/6 Regression] c++14 code accepted by 4.9 not accepted by 5 and 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68585
--- Comment #2 from Jonathan Wakely ---
template
struct array
{
T _M_data[N];
};
template
struct integer_sequence
{
};
struct Pos
{
unsigned l;
};
template
constexpr auto make_grid_position(integer_sequence)
{
return array{{ Pos{Ints}... }};
}
constexpr auto make_grid_positions()
{
return make_grid_position(integer_sequence{});
}
template
void generate_sudoku(T)
{
constexpr auto positions = make_grid_positions(); // fail
}
int main()
{
constexpr auto positions = make_grid_positions(); // ok
generate_sudoku(1);
}
[Bug middle-end/68122] ICE in gcc/toplev.c:353 with -fsanitize=undefined and -fgnu-tm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68122 --- Comment #10 from Jakub Jelinek --- There are lots of internal functions in GCC 6 (older versions had fewer). Many of them are ECF_CONST, which is also treated like txn_pure, right? Other than that, e.g. the remaining UBSAN* handlers are pretty much just report some diagnostics and either terminate the program or return, but in a valid program they should never be called. If we treat them as ECF_TM_PURE, that would worst case mean the diagnostics could be printed multiple times for the same spot in a transaction, if the transaction is restarted, right? Most of them are not reporting the same diagnostics for the same source code location, so I suppose it would be no harm to treat them as tm pure. Just look at internal-fn.def.
[Bug target/68617] arm ice output_operand: invalid %-code for -march=armv6k + thumb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68617 --- Comment #3 from chrbr at gcc dot gnu.org --- Author: chrbr Date: Tue Dec 1 14:50:57 2015 New Revision: 231114 URL: https://gcc.gnu.org/viewcvs?rev=231114&root=gcc&view=rev Log: 2015-12-01 Christian Bruel PR target/68617 * config/arm/arm.opt (unaligned_access): Save. * config/arm/arm-c.c (__ARM_FEATURE_UNALIGNED): Conditionally define. * config/arm/arm.c (arm_option_override): Move unaligned_access setting (arm_option_override_internal): ... here. * config/arm/arm.h (TARGET_32BIT_P): New macro. // testsuite PR target/68617 * gcc.target/arm/attr-unaligned-load-ice.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/attr-unaligned-load-ice.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm-c.c trunk/gcc/config/arm/arm.c trunk/gcc/config/arm/arm.h trunk/gcc/config/arm/arm.opt trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/68474] [6 Regression] ICE: in get_no_error_domain, at tree-call-cdce.c:699 with -funsafe-math-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68474 --- Comment #3 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Tue Dec 1 14:53:53 2015 New Revision: 231115 URL: https://gcc.gnu.org/viewcvs?rev=231115&root=gcc&view=rev Log: PR68474: Fix tree-call-cdce.c:use_internal_fn We'd call gen_shrink_wrap_conditions for functions that it can't handle but edom_only_function can. Tested on x86_64-linux-gnu. gcc/ PR tree-optimization/68474 * tree-call-cdce.c (use_internal_fn): Protect call to gen_shrink_wrap_conditions. gcc/testsuite/ PR tree-optimization/68474 * gcc.dg/pr68474.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr68474.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-call-cdce.c
[Bug c++/68585] [5/6 Regression] c++14 code accepted by 4.9 not accepted by 5 and 6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68585 Jakub Jelinek changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- #c3 started to be rejected with r216750.
[Bug target/68617] arm ice output_operand: invalid %-code for -march=armv6k + thumb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68617 chrbr at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from chrbr at gcc dot gnu.org --- fixed
[Bug middle-end/68616] miscompilation in multi-threaded code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68616 --- Comment #2 from torvald at gcc dot gnu.org --- I basically don't know anything about IPA, so I'll just assume that by "barrier" you mean conditions prohibiting transformations. I'm also not sure whether just CSE is a problem here, so I'll try to give an unspecific but broad answer. I'll assume we're looking at cases of nonatomic accesses to foo (such as ptr in the test case) and calls to the (new) atomic builtins on different variables bar1,bar2,... as synchronization points. Mixed atomic/nonatomic accesses to the same memory location are in most cases a bug, and I believe we discourage it, but they might not generally be incorrect (e.g., if loading through an atomic op and observing a value that indicates we're the only thread accessing it, subsequent nonatomic accesses might be fine); maybe we should just let an atomic access to bar1 be a barrier for all movement/merging across/involving this access. Any old atomic builtins (ie, __synch) can probably be handled like the equivalent calls to the new builtins. I believe we don't need to do includes volatiles, because even if they are used in old-style code, they should have asm compiler barriers around them -- and I hope we're handling those correctly. Because &foo != &bar, atomic stores to bar must be __ATOMIC_RELEASE or stronger, and atomic loads to bar must be __ATOMIC_ACQUIRE or stronger; otherwise, there's no implied ordering relationship between the foo and bar accesses. A good way to find out what transformations are or are not allowed is to consider the data-race-freedom (DRF) requirement and which regions an implementation would be allowed to execute atomically. For example, "foo = 1; bar.store(1, release); foo = 2;": The implementation is allowed to execute that in one atomic step, so there cannot be a nonatomic read of fooin another thread that's triggered by the store to bar because there would be a data race in this case. So, foo=1 can be removed if we assume DRF. (Note that old synchronization code may not be written to guarantee DRF; so perhaps this should be conditional on -std=c11 or such.) "temp=foo; if (bar.load(acquire)) temp2=foo;" is similar. However, this example here (basically the test case) doesn't allow for optimizing across the synchronization: "foo = 1; temp=foo; bar.store(1, release); if (bar.load(acquire)==2) temp2=foo;" This is because both loads of foo cannot be executed in one atomic step, as it needs another thread to increment bar to the value 2; also, there is no nonatomic access to foo between the two atomic accesses, so we cannot derive that those other threads that execute between the atomics don't access foo because of DRF. I hope this helps, though I'm aware it's pretty general. If you have a list of specific transformations, I could look through that and say which ones are correct or not. Perhaps it's okay for now if we assume that all non-relaxed atomics are transformation barriers, as we do elsewhere AFAIK.
[Bug tree-optimization/67916] [6 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67916 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #3 from Marek Polacek --- Seems to be fixed with r228767. I'll add the testcase.
[Bug rtl-optimization/68636] unnecessary unaligned load on mips o32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68636
--- Comment #1 from Richard Biener ---
Ok x86_64 I get
if (zeroIsCavium_2 == 0)
goto ;
else
goto ;
:
:
# PT = nonlocal
# ALIGN = 536870912, MISALIGN = 8388720
# iftmp.0_1 = PHI <3229614192B(2), 2692743280B(3)>
_4 ={v} *iftmp.0_1;
x ={v} _4;
return;
thus alignment should be sufficient and *iftmp.0_1 should expand to an aligned
load. So you have to dig into RTL expansion to see where it goes wrong for
you.
[Bug tree-optimization/68501] [6 Regression] sqrt builtin is not used anymore
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68501 --- Comment #5 from Pat Haugen --- *** Bug 68526 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/68526] [6 Regression] gcc.target/powerpc/recip-4.c fails starting with r230492
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68526 Pat Haugen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Pat Haugen --- Working now after fix for pr68501. *** This bug has been marked as a duplicate of bug 68501 ***
[Bug tree-optimization/64769] ICE: tree check: expected integer_cst, have parm_decl in simd_clone_clauses_extract, at omp-low.c:12503 with -fopenmp-simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64769 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Fixed in r225583, i.e. for GCC 5 and 6.
[Bug tree-optimization/64769] ICE: tree check: expected integer_cst, have parm_decl in simd_clone_clauses_extract, at omp-low.c:12503 with -fopenmp-simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64769 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2015-12-01 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |4.9.4 Ever confirmed|0 |1 --- Comment #2 from Marek Polacek --- I'll add the testcase.
[Bug middle-end/68122] ICE in gcc/toplev.c:353 with -fsanitize=undefined and -fgnu-tm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68122 --- Comment #11 from torvald at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #10) > There are lots of internal functions in GCC 6 (older versions had fewer). > Many of them are ECF_CONST, which is also treated like txn_pure, right? I think it should be (ie, won't access global memory, so is a black box an only output/input is values) -- but I don't know whether we do this everywhere. > Other than that, e.g. the remaining UBSAN* handlers are pretty much just > report some diagnostics and either terminate the program or return, but in a > valid program they should never be called. If we treat them as ECF_TM_PURE, > that would worst case mean the diagnostics could be printed multiple times > for the same spot in a transaction, if the transaction is restarted, right? Yes. > Most of them are not reporting the same diagnostics for the same source code > location, so I suppose it would be no harm to treat them as tm pure. Agreed. Are we running the TM pass before the pass that replaces UBSAN* with real code?
[Bug middle-end/68570] [6 Regression] ICE on valid code at -O1, -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68570 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek --- I'll have a look.
[Bug middle-end/68582] -Wunused-function doesn't warn about unused static __attribute__((noreturn)) functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68582 --- Comment #5 from Marek Polacek --- Author: mpolacek Date: Tue Dec 1 15:44:08 2015 New Revision: 231116 URL: https://gcc.gnu.org/viewcvs?rev=231116&root=gcc&view=rev Log: PR middle-end/68582 * cgraphunit.c (check_global_declaration): Only depend on TREE_THIS_VOLATILE for VAR_DECLs. * c-c++-common/pr68582.c: New test. Added: trunk/gcc/testsuite/c-c++-common/pr68582.c Modified: trunk/gcc/ChangeLog trunk/gcc/cgraphunit.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/68582] -Wunused-function doesn't warn about unused static __attribute__((noreturn)) functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68582 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Marek Polacek --- Fixed for GCC 6.
[Bug tree-optimization/67916] [6 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67916 --- Comment #4 from Marek Polacek --- Author: mpolacek Date: Tue Dec 1 15:47:34 2015 New Revision: 231117 URL: https://gcc.gnu.org/viewcvs?rev=231117&root=gcc&view=rev Log: PR tree-optimization/67916 * gcc.dg/torture/pr67916.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr67916.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/67916] [6 Regression] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67916 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek --- So done.
[Bug middle-end/68570] [6 Regression] ICE on valid code at -O1, -O2 and -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68570 --- Comment #5 from Jakub Jelinek --- Wonder if this isn't related to PR68625.
[Bug tree-optimization/67800] [6 Regression] Missed vectorization opportunity on x86 (DOT_PROD_EXPR in non-reduction)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67800 --- Comment #5 from Alexander Fomin --- Richard, are there any updates on this? If BB vectorization support for reductions does not fit your plans for stage3, we'd like to fix the regression by doing a partial revert described above.
[Bug c/68637] New: Wrong -Wattributes on array of function pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68637
Bug ID: 68637
Summary: Wrong -Wattributes on array of function pointers
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
hjl@gnu-6 gcc]$ cat y.c
typedef void (*func) (int, int) __attribute__ ((regparm (2)));
extern func foo[10];
extern void (*bar[10]) (int, int) __attribute__ ((regparm (2)));
void
xxx (int i)
{
foo[i] (1, 2);
bar[i] (1, 2);
}
[hjl@gnu-6 gcc]$ gcc -S -m32 -O2 y.c
y.c:3:1: warning: ‘regparm’ attribute only applies to function types
[-Wattributes]
extern void (*bar[10]) (int, int) __attribute__ ((regparm (2)));
^
[hjl@gnu-6 gcc]$ /export/build/gnu/llvm-clang/build-x86_64-linux/bin/clang -S
-m32 -O2 y.c
[hjl@gnu-6 gcc]$
[Bug tree-optimization/64769] ICE: tree check: expected integer_cst, have parm_decl in simd_clone_clauses_extract, at omp-low.c:12503 with -fopenmp-simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64769 --- Comment #3 from Marek Polacek --- Author: mpolacek Date: Tue Dec 1 16:22:28 2015 New Revision: 231120 URL: https://gcc.gnu.org/viewcvs?rev=231120&root=gcc&view=rev Log: PR tree-optimization/64769 * c-c++-common/gomp/pr64769.c: New test. Added: trunk/gcc/testsuite/c-c++-common/gomp/pr64769.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug preprocessor/68638] New: [6 Regression] ICE in linemap_macro_map_lookup
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68638
Bug ID: 68638
Summary: [6 Regression] ICE in linemap_macro_map_lookup
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: msebor at gcc dot gnu.org
Target Milestone: ---
The following test case triggers an ICE in linemap_macro_map_lookup, at
libcpp/line-map.c:991 with yesterday's top of trunk. The test case compiles
fine with GCC 5.1 so this is a regression.
$ cat line-map-ice.c && /build/gcc-trunk-svn/gcc/xgcc -B
/build/gcc-trunk-svn/gcc -O2 -S -Wall -fno-diagnostics-show-caret
line-map-ice.c
typedef union tree_node *tree;
struct ht_identifier {
const unsigned char *str;
};
struct tree_identifier {
struct ht_identifier id;
};
union tree_node {
struct tree_identifier identifier;
};
static int foo (void) {
tree val;
return mep_pragma_lex (&val);
}
void bar (void) {
tree val = 0;
if (__extension__ ({val;})->identifier.id.str == 0) foo ();
}
line-map-ice.c: In function ‘foo’:
line-map-ice.c:17:10: warning: implicit declaration of function
‘mep_pragma_lex’ [-Wimplicit-function-declaration]
line-map-ice.c: In function ‘bar’:
line-map-ice.c:20:6: internal compiler error: in linemap_macro_map_lookup, at
libcpp/line-map.c:991
0x1795063 linemap_macro_map_lookup
/home/msebor/scm/fsf/gcc-svn/libcpp/line-map.c:991
0x1794e4e linemap_lookup(line_maps*, unsigned int)
/home/msebor/scm/fsf/gcc-svn/libcpp/line-map.c:925
0x1795fad linemap_unwind_to_first_non_reserved_loc(line_maps*, unsigned int,
line_map const**)
/home/msebor/scm/fsf/gcc-svn/libcpp/line-map.c:1629
0x1774164 expand_location_1
/home/msebor/scm/fsf/gcc-svn/gcc/input.c:159
0x177525d expand_location_to_spelling_point(unsigned int)
/home/msebor/scm/fsf/gcc-svn/gcc/input.c:751
0x1775283 linemap_client_expand_location_to_spelling_point(unsigned int)
/home/msebor/scm/fsf/gcc-svn/gcc/input.c:766
0x1796d6c rich_location::add_range(unsigned int, unsigned int, bool)
/home/msebor/scm/fsf/gcc-svn/libcpp/line-map.c:2011
0x1796e44 rich_location::add_range(source_range, bool)
/home/msebor/scm/fsf/gcc-svn/libcpp/line-map.c:2024
0x1796b7f rich_location::rich_location(line_maps*, unsigned int)
/home/msebor/scm/fsf/gcc-svn/libcpp/line-map.c:1961
0x176d9ca warning_at(unsigned int, int, char const*, ...)
/home/msebor/scm/fsf/gcc-svn/gcc/diagnostic.c:1024
0x1653666 find_explicit_erroneous_behaviour
/home/msebor/scm/fsf/gcc-svn/gcc/gimple-ssa-isolate-paths.c:400
0x16538ef gimple_ssa_isolate_erroneous_paths
/home/msebor/scm/fsf/gcc-svn/gcc/gimple-ssa-isolate-paths.c:505
0x16539e2 execute
/home/msebor/scm/fsf/gcc-svn/gcc/gimple-ssa-isolate-paths.c:556
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug tree-optimization/64769] ICE: tree check: expected integer_cst, have parm_decl in simd_clone_clauses_extract, at omp-low.c:12503 with -fopenmp-simd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64769 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- Testcase added, closing.
[Bug tree-optimization/68639] New: [6 Regression] ICE: Floating point exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68639 Bug ID: 68639 Summary: [6 Regression] ICE: Floating point exception Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: Joost.VandeVondele at mat dot ethz.ch Target Milestone: --- trunk regression: > cat bug.f90 SUBROUTINE makeCoulE0(natorb,Coul) INTEGER, PARAMETER :: dp=8 REAL(KIND=dp), PARAMETER :: fourpi=432.42, oorootpi=13413.3142 INTEGER :: natorb REAL(KIND=dp), DIMENSION(45, 45), & INTENT(OUT):: Coul INTEGER :: gpt, imA, imB, k1, k2, k3, & k4, lp, mp, np REAL(KIND=dp):: alpha, d2f(3,3), & d4f(3,3,3,3), f, ff, w REAL(KIND=dp), DIMENSION(3, 45) :: M1A REAL(KIND=dp), DIMENSION(45) :: M0A DO imA=1, (natorb*(natorb+1))/2 DO imB=1, (natorb*(natorb+1))/2 w= M0A(imA)*M0A(imB) DO k1=1,3 w=w+ M1A(k1,imA)*M1A(k1,imB) ENDDO Coul(imA,imB)=Coul(imA,imB)-4.0_dp*alpha**3*oorootpi*w/3.0_dp ENDDO ENDDO END SUBROUTINE makeCoulE0 > gfortran -c -O3 bug.f90 bug.f90:1:0: SUBROUTINE makeCoulE0(natorb,Coul) internal compiler error: Floating point exception 0xb793ff crash_signal /data/vjoost/toolchain-trunk/build/gcc-master/gcc/toplev.c:334 0xdab9b6 vectorizable_load /data/vjoost/toolchain-trunk/build/gcc-master/gcc/tree-vect-stmts.c:6292 0xdb2ee9 vect_analyze_stmt(gimple*, bool*, _slp_tree*) /data/vjoost/toolchain-trunk/build/gcc-master/gcc/tree-vect-stmts.c:8009 0xdc24ca vect_analyze_loop_operations /data/vjoost/toolchain-trunk/build/gcc-master/gcc/tree-vect-loop.c:1711 0xdc24ca vect_analyze_loop_2 /data/vjoost/toolchain-trunk/build/gcc-master/gcc/tree-vect-loop.c:1998 0xdc24ca vect_analyze_loop(loop*) /data/vjoost/toolchain-trunk/build/gcc-master/gcc/tree-vect-loop.c:2248 0xdd6059 vectorize_loops() /data/vjoost/toolchain-trunk/build/gcc-master/gcc/tree-vectorizer.c:532 Please submit a full bug report, > gfortran -v bug.f90 Driving: gfortran -v bug.f90 -l gfortran -l m -shared-libgcc Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/data/vjoost/toolchain-trunk/install/libexec/gcc/x86_64-pc-linux-gnu/6.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /data/vjoost/toolchain-trunk/build/gcc-master/configure --prefix=/data/vjoost/toolchain-trunk/install --enable-languages=c,c++,fortran --disable-multilib --disable-bootstrap --enable-lto --enable-plugins Thread model: posix gcc version 6.0.0 20151201 (experimental) (GCC)
