[Bug tree-optimization/77975] [6 Regression] Missed optimization for some small constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77975 Jakub Jelinek changed: What|Removed |Added Summary|[6/7 Regression] Missed |[6 Regression] Missed |optimization for some small |optimization for some small |constants |constants --- Comment #7 from Jakub Jelinek --- Fixed on the trunk, probably not worth/desirable for backporting.
[Bug tree-optimization/79972] ICE in tree check: expected ssa_name, have var_decl in get_range_info, at tree-ssanames.c:377 w/ -Walloca -Wvla-larger-than=364854541
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79972 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug middle-end/79909] [7 Regression] ICE error: invalid rtl sharing found in the insn on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79909 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/79981] Forwprop not working for __atomic_compare_exchange_n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79981
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-03-10
Ever confirmed|0 |1
--- Comment #2 from Richard Biener ---
No, the reason is really the FE implements (_Bool) int as int != 0 while
fold_builtin_atomic_compare_exchange emits (_Bool) int in the IL which
isn't forwarded the same way:
if (oldlhs)
{
g = gimple_build_assign (make_ssa_name (itype), IMAGPART_EXPR,
build1 (IMAGPART_EXPR, itype, lhs));
if (throws)
{
gsi_insert_on_edge_immediate (e, g);
*gsi = gsi_for_stmt (g);
}
else
gsi_insert_after (gsi, g, GSI_NEW_STMT);
g = gimple_build_assign (oldlhs, NOP_EXPR, gimple_assign_lhs (g));
gsi_insert_after (gsi, g, GSI_NEW_STMT);
(gdb) p debug_tree (oldlhs)
unit size
align 8 symtab 0 alias set -1 canonical type 0x768bab28 precision 1
min max >
visited
def_stmt _1 = (_Bool) _13;
version 1>
Note we do not have any folding/match.pd to transform (_Bool) whatever to
!= 0 (or the other way around) so we're clearly missing some canonicalization
here. Note that the above code also misses to fold the stmts it generates
(it should use gimple_build (...) which would do this).
Sth like
(simplify
(convert @1)
(if (INTEGRAL_TYPE_P (TREE_TYPE (@1))
&& INTEGRAL_TYPE_P (type)
&& (TREE_CODE (type) == BOOLEAN_TYPE
|| TYPE_PRECISION (type) == 1))
(ne @1 { build_zero_cst (TREE_TYPE (@1)); })))
might do this (but I'm somewhat leaning towards making the canonicalization
the other way around which would mean fixing the forwarding of the comparison
instead).
Thus, for a "quick" fix simply change what we emit from
fold_builtin_atomic_compare_exchange ...
Index: gcc/gimple-fold.c
===
--- gcc/gimple-fold.c (revision 245976)
+++ gcc/gimple-fold.c (working copy)
@@ -3581,7 +3581,8 @@ fold_builtin_atomic_compare_exchange (gi
}
else
gsi_insert_after (gsi, g, GSI_NEW_STMT);
- g = gimple_build_assign (oldlhs, NOP_EXPR, gimple_assign_lhs (g));
+ g = gimple_build_assign (oldlhs, NE_EXPR, gimple_assign_lhs (g),
+ build_zero_cst (TREE_TYPE (gimple_assign_lhs
(g;
gsi_insert_after (gsi, g, GSI_NEW_STMT);
}
g = gimple_build_assign (make_ssa_name (itype), REALPART_EXPR,
of course needs to be conditional on oldlhs being bool and lhs being
integral.
[Bug tree-optimization/79958] Missed tree DSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79958 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-03-10 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- First thing I notice (but unrelated to this bug) is that domwalk walks non-optimally when walking in postdom order (all the tricks to use a RPO dom order only were implemented for dominator walks). Here the issue is that the walk over immediate uses of VDEFs finds two stmts, one in the EH region and one in the fallthru block. For simplicity (cost reasons) we do not look for uses in more than one block (yeah, the code is _really_ simple...).
[Bug tree-optimization/79958] Missed tree DSE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79958
--- Comment #2 from Richard Biener ---
Small C testcase:
struct X { int i; };
void bar ();
void foo (int b)
{
struct X x;
x.i = 1;
if (b)
{
bar ();
__builtin_abort ();
}
bar ();
}
You need to provide -fno-tree-dce as DCE is able to catch these cases
(in your case only one-by-one as for addressable vars it uses stupid
analysis).
[Bug c++/77581] [5/6/7 Regression] ICE: instantiate_template_1, cp/pt.c:17391
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77581 --- Comment #4 from Paolo Carlini --- Seems already fixed in trunk.
[Bug libstdc++/62045] __gnu_pbds::priority_queue, binary_heap_tag> is too slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62045
--- Comment #3 from Xi Ruoyao ---
Both Tobias' and my thought was wrong. In the entry of
__gnu_pbds::detail::binary_heap::push_heap, the array
m_a_entries[0..m_size-2] contains a heap, and
m_a_entries[m_size-1] contains the element being pushed
into the heap. So is_heap would return false most likely.
Then make_heap would be call and std::push_heap *won't* be
call.
It's easy to find out using gcov.
~~~
-: 272: void
100: 273: push_heap()
-: 274: {
100: 275:if (!is_heap())
99: 276: make_heap();
-: 277:else
-: 278: {
1: 279:const entry_cmp& m_cmp =
static_cast(*this);
1: 280:entry_pointer end = m_a_entries + m_size;
1: 281:std::push_heap(m_a_entries, end, m_cmp);
-: 282: }
100: 283: }
~~~
This is certainly a bug making priority_queue::push O(n^2).
Since it works correctly in GCC 4.6, it's a regression.
Making a patch...
[Bug libstdc++/62045] __gnu_pbds::priority_queue, binary_heap_tag> is too slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62045 --- Comment #4 from Xi Ruoyao --- > This is certainly a bug making priority_queue::push O(n^2). > Since it works correctly in GCC 4.6, it's a regression. Sorry. s/O(n^2)/O(n)/.
[Bug c++/77581] [5/6 Regression] ICE: instantiate_template_1, cp/pt.c:17391
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77581 Jakub Jelinek changed: What|Removed |Added Summary|[5/6/7 Regression] ICE: |[5/6 Regression] ICE: |instantiate_template_1, |instantiate_template_1, |cp/pt.c:17391 |cp/pt.c:17391 --- Comment #5 from Jakub Jelinek --- This got fixed with r244988 aka PR78771 fix. Do we want the testcase in the testsuite or is it sufficiently similar to the PR78771 one?
[Bug rtl-optimization/79985] New: ICE in code_motion_path_driver, at sel-sched.c:6580
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79985
Bug ID: 79985
Summary: ICE in code_motion_path_driver, at sel-sched.c:6580
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Host: x86_64-linux-gnu
Target: ppc64le-linux-gnu
I spotted following ICE on trunk:
$ cat memmove.i
long a;
int b;
void
c ()
{
__asm("" : "=r"(a) : "0"(c));
__asm("" : "=r"(b));
}
$ ppc64le-linux-gnu-gcc -fselective-scheduling -O3 -fselective-scheduling
memmove.i -c
memmove.i: In function ‘c’:
memmove.i:8:1: internal compiler error: in code_motion_path_driver, at
sel-sched.c:6580
}
^
0x9ceac0 code_motion_path_driver
.././../gcc/sel-sched.c:6580
0x9ceeb3 move_op
.././../gcc/sel-sched.c:6704
0x9ceeb3 move_exprs_to_boundary
.././../gcc/sel-sched.c:5227
0x9ceeb3 schedule_expr_on_boundary
.././../gcc/sel-sched.c:5440
0x9d2741 fill_insns
.././../gcc/sel-sched.c:5582
0x9d2741 schedule_on_fences
.././../gcc/sel-sched.c:7356
0x9d2741 sel_sched_region_2
.././../gcc/sel-sched.c:7494
0x9d5319 sel_sched_region_1
.././../gcc/sel-sched.c:7536
0x9d5319 sel_sched_region(int)
.././../gcc/sel-sched.c:7637
0x9d5cf9 run_selective_scheduling()
.././../gcc/sel-sched.c:7713
0x9b58fd rest_of_handle_sched
.././../gcc/sched-rgn.c:3708
0x9b58fd execute
.././../gcc/sched-rgn.c:3818
[Bug ada/79441] [7 regression] gnat.dg/pack9.adb fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79441 --- Comment #3 from Eric Botcazou --- The difference with other main 64-bit platforms (x86-64, SPARC64, Alpha) comes from the BIGGEST_ALIGNMENT setting, which is only 64 on s390x instead of 128.
[Bug c++/79967] ICE on non-type template argument declared noreturn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79967 Marek Polacek changed: What|Removed |Added Keywords|ice-on-invalid-code |ice-on-valid-code Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- It seems to be valid, clang++ accepts it and G++ too (with my patch).
[Bug tree-optimization/79981] Forwprop not working for __atomic_compare_exchange_n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79981 --- Comment #3 from Dominik Vogt --- (In reply to Richard Biener from comment #2) > of course needs to be conditional on oldlhs being bool and lhs being > integral. Like so? -- diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c index 9fd45d1..e5e448e 100644 --- a/gcc/gimple-fold.c +++ b/gcc/gimple-fold.c @@ -3581,7 +3581,12 @@ fold_builtin_atomic_compare_exchange (gimple_stmt_iterator *gsi) } else gsi_insert_after (gsi, g, GSI_NEW_STMT); - g = gimple_build_assign (oldlhs, NOP_EXPR, gimple_assign_lhs (g)); + if (TREE_CODE (TREE_TYPE (oldlhs)) == BOOLEAN_TYPE + && INTEGRAL_TYPE_P (itype)) + g = gimple_build_assign (oldlhs, NE_EXPR, gimple_assign_lhs (g), +build_zero_cst (TREE_TYPE (gimple_assign_lhs (g; + else + g = gimple_build_assign (oldlhs, NOP_EXPR, gimple_assign_lhs (g)); gsi_insert_after (gsi, g, GSI_NEW_STMT); } g = gimple_build_assign (make_ssa_name (itype), REALPART_EXPR, -- Lhs has COMPLEX_TYPE, so itype needs to be checked instead, but is it really necessary? Itype comes from the function declaration and should be guaranteed to be of integral type anyway: tree fndecl = gimple_call_fndecl (stmt); tree parmt = TYPE_ARG_TYPES (TREE_TYPE (fndecl)); tree itype = TREE_VALUE (TREE_CHAIN (TREE_CHAIN (parmt))); This eliminates the _Bool and finally results in _8 = IMAGPART_EXPR <_7>; if (_8 != 0) (but not regression tested yet).
[Bug c++/79986] New: [6/7 Regression][CHKP] ICE in fold_convert_loc with a flexiable array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79986 Bug ID: 79986 Summary: [6/7 Regression][CHKP] ICE in fold_convert_loc with a flexiable array Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: msebor at gcc dot gnu.org Target Milestone: --- Following test-case ICEs since r231665: $ g++ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/flexary11.C -fcheck-pointer-bounds -mmpx /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/flexary11.C: In function ‘void f.chkp()’: /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/flexary11.C:19:1: internal compiler error: Segmentation fault } ^ 0xdf216f crash_signal ../../gcc/toplev.c:337 0xb0b540 contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*) ../../gcc/tree.h:3177 0xb0b540 fold_convert_loc(unsigned int, tree_node*, tree_node*) ../../gcc/fold-const.c:2215 0xb11d22 fold_build_pointer_plus_loc(unsigned int, tree_node*, tree_node*) ../../gcc/fold-const.c:14408 0xeb18dd chkp_process_stmt ../../gcc/tree-chkp.c:4093 0xeb2863 chkp_instrument_function ../../gcc/tree-chkp.c:4316 0xeb2863 chkp_execute ../../gcc/tree-chkp.c:4529 0xeb2863 execute ../../gcc/tree-chkp.c:4588 Martin can you please help?
[Bug tree-optimization/79981] Forwprop not working for __atomic_compare_exchange_n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79981 --- Comment #4 from Jakub Jelinek --- (In reply to Dominik Vogt from comment #3) > (In reply to Richard Biener from comment #2) > > of course needs to be conditional on oldlhs being bool and lhs being > > integral. > > Like so? > > -- > diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c > index 9fd45d1..e5e448e 100644 > --- a/gcc/gimple-fold.c > +++ b/gcc/gimple-fold.c > @@ -3581,7 +3581,12 @@ fold_builtin_atomic_compare_exchange > (gimple_stmt_iterator *gsi) > } >else > gsi_insert_after (gsi, g, GSI_NEW_STMT); > - g = gimple_build_assign (oldlhs, NOP_EXPR, gimple_assign_lhs (g)); > + if (TREE_CODE (TREE_TYPE (oldlhs)) == BOOLEAN_TYPE > + && INTEGRAL_TYPE_P (itype)) > + g = gimple_build_assign (oldlhs, NE_EXPR, gimple_assign_lhs (g), > + build_zero_cst (TREE_TYPE (gimple_assign_lhs > (g; > + else > + g = gimple_build_assign (oldlhs, NOP_EXPR, gimple_assign_lhs (g)); >gsi_insert_after (gsi, g, GSI_NEW_STMT); > } >g = gimple_build_assign (make_ssa_name (itype), REALPART_EXPR, That looks like a pessimization instead of optimization, perhaps optimizers then do a better job at that, but maybe in other cases don't. Wouldn't it be better to look after building the NOP_EXPR at the immediate uses of oldlhs and if any of them is oldlhs != 0 or oldlhs == 0 comparison, forward propagate there immediately the rhs1 of the nop and adjust the other operand?
[Bug tree-optimization/79987] New: [CHKP] ICE in gimplify_expr, at gimplify.c:12151
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79987 Bug ID: 79987 Summary: [CHKP] ICE in gimplify_expr, at gimplify.c:12151 Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- We ICE on following test-case: $ cat /home/marxin/BIG/Programming/llvm-project/clang/test/CodeGen/2009-07-14-VoidPtr.c // RUN: %clang_cc1 -emit-llvm %s -o - // PR4556 extern void foo; void *bar = &foo; $ gcc /home/marxin/BIG/Programming/llvm-project/clang/test/CodeGen/2009-07-14-VoidPtr.c -fcheck-pointer-bounds -mmpx /home/marxin/BIG/Programming/llvm-project/clang/test/CodeGen/2009-07-14-VoidPtr.c:5:13: warning: taking address of expression of type ‘void’ void *bar = &foo; ^ /home/marxin/BIG/Programming/llvm-project/clang/test/CodeGen/2009-07-14-VoidPtr.c: In function ‘_GLOBAL__sub_B_00102_1_bar’: /home/marxin/BIG/Programming/llvm-project/clang/test/CodeGen/2009-07-14-VoidPtr.c:5:1: internal compiler error: in gimplify_expr, at gimplify.c:12151 void *bar = &foo; ^~~~ 0x7f75f1 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) .././../gcc/gimplify.c:12151 0x7fc904 gimplify_expr .././../gcc/gimplify.c:12199 0x7fd685 gimplify_call_expr .././../gcc/gimplify.c:3259 0x7f56cf gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) .././../gcc/gimplify.c:11170 0x7f4055 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) .././../gcc/gimplify.c:11927 0x7f6803 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) .././../gcc/gimplify.c:11918 0x7fde82 gimplify_modify_expr .././../gcc/gimplify.c:5457 0x7f5359 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) .././../gcc/gimplify.c:11198 0x7f7658 gimplify_stmt(tree_node**, gimple**) .././../gcc/gimplify.c:6478 0x7f503b gimplify_statement_list .././../gcc/gimplify.c:1716 0x7f503b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) .././../gcc/gimplify.c:11626 0x7f7658 gimplify_stmt(tree_node**, gimple**) .././../gcc/gimplify.c:6478 0x7f8977 gimplify_body(tree_node*, bool) .././../gcc/gimplify.c:12395 0x7f8d25 gimplify_function_tree(tree_node*) .././../gcc/gimplify.c:12553 0x875bdc cgraph_build_static_cdtor_1 .././../gcc/ipa.c:980 0xa86935 chkp_finish_file() .././../gcc/tree-chkp.c:3887
[Bug c++/79986] [6/7 Regression][CHKP] ICE in fold_convert_loc with a flexiable array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79986 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-03-10 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed. The bug seems to be that chkp_process_stmt won't handle char[] arrays. I don't know if chkp should skip them or process somehow.
[Bug middle-end/79988] New: [7 Regression][CHKP] ICE in tree check: accessed operand 5 of call_expr with 4 operands in ix86_expand_builtin, at config/i386/i386.c:36851
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79988 Bug ID: 79988 Summary: [7 Regression][CHKP] ICE in tree check: accessed operand 5 of call_expr with 4 operands in ix86_expand_builtin, at config/i386/i386.c:36851 Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Starting from r238709, we ICE on: $ timeout 3 gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr79723.c -fcheck-pointer-bounds -mmpx /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr79723.c: In function ‘memset_pattern_seg_gs.chkp’: /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr79723.c:7:10: internal compiler error: Segmentation fault s[i] = 0; ~^~~ 0x9fc2ef crash_signal .././../gcc/toplev.c:337 0x77e7f0 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) .././../gcc/expr.c:8064 0xc9fb4a expand_normal .././../gcc/expr.h:282 0xc9fb4a ix86_expand_builtin .././../gcc/config/i386/i386.c:36854 0x67eea9 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int) .././../gcc/builtins.c:6362 0x77d28e expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) .././../gcc/expr.c:10822 0x69b0ee expand_expr .././../gcc/expr.h:276 0x69b0ee expand_call_stmt .././../gcc/cfgexpand.c:2658 0x69b0ee expand_gimple_stmt_1 .././../gcc/cfgexpand.c:3571 0x69b0ee expand_gimple_stmt .././../gcc/cfgexpand.c:3737 0x69bf8f expand_gimple_basic_block .././../gcc/cfgexpand.c:5744 0x6a0546 execute .././../gcc/cfgexpand.c:6357
[Bug c++/79986] [6/7 Regression][CHKP] ICE in fold_convert_loc with a flexiable array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79986 --- Comment #2 from Martin Liška --- CHKP should somehow handle flexible arrays, thus hopefully it's fixable.
[Bug tree-optimization/79981] Forwprop not working for __atomic_compare_exchange_n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79981 --- Comment #5 from Dominik Vogt --- The knowledge that the integer can only assume the values 0 and 1 seems to be hard coded. Is it possible to add value range information? With that, all conditions and arithmetics could be done with the integer, and the boolean value would only be useful if the return value is explicitly stored in memory or so. Doing calculations with the boolean type (QImode) is something we really need to avoid on s390x because it eventually results in widening the value to SImode with bit arithmetics and clobbering the condition code as a side effect.
[Bug middle-end/79989] New: [7 Regression][CHKP] ICE in assign_temp, at function.c:968
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79989
Bug ID: 79989
Summary: [7 Regression][CHKP] ICE in assign_temp, at
function.c:968
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: nathan at gcc dot gnu.org
Target Milestone: ---
Starting from r244728, we ICE on:
$ g++
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-conv10.C
-mmpx -fcheck-pointer-bounds
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-conv10.C:
In static member function ‘static EmptyValue
User::User()_FUN.chkp(Value,
\xe2\x80\x98pointer_bounds_typ\xe2\x80\x99 not supported by dump_type#, void, ...)’:
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-conv10.C:30:51:
internal compiler error: in assign_temp, at function.c:968
Value().call([](Value) { return EmptyValue(); });
^
0x8ce881 assign_temp(tree_node*, int, int)
.././../gcc/function.c:968
0x792481 initialize_argument_information
.././../gcc/calls.c:1816
0x792481 expand_call(tree_node*, rtx_def*, int)
.././../gcc/calls.c:3269
0x884c9d expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
.././../gcc/expr.c:10825
0x88e4aa store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
.././../gcc/expr.c:5552
0x88f0be expand_assignment(tree_node*, tree_node*, bool)
.././../gcc/expr.c:5321
0x7a1905 expand_call_stmt
.././../gcc/cfgexpand.c:2656
0x7a1905 expand_gimple_stmt_1
.././../gcc/cfgexpand.c:3571
0x7a1905 expand_gimple_stmt
.././../gcc/cfgexpand.c:3737
0x7a2abf expand_gimple_basic_block
.././../gcc/cfgexpand.c:5744
0x7a7076 execute
.././../gcc/cfgexpand.c:6357
[Bug middle-end/79990] New: [CHKP] ICE in expand_expr_addr_expr_1, at expr.c:7790
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79990 Bug ID: 79990 Summary: [CHKP] ICE in expand_expr_addr_expr_1, at expr.c:7790 Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Starting from GCC 5 (when MPX was introduced), we ICE on: $ gcc /home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/vector-subscript-5.c -fcheck-pointer-bounds -mmpx /home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/vector-subscript-5.c: In function ‘foo.chkp’: /home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/vector-subscript-5.c:6:1: internal compiler error: in expand_expr_addr_expr_1, at expr.c:7790 foo (int i) ^~~ 0x78598d expand_expr_addr_expr_1 .././../gcc/expr.c:7790 0x77bf8e expand_expr_addr_expr .././../gcc/expr.c:7903 0x77bf8e expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) .././../gcc/expr.c:11047 0xc9ea65 expand_normal .././../gcc/expr.h:282 0xc9ea65 ix86_expand_builtin .././../gcc/config/i386/i386.c:36788 0x67eea9 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int) .././../gcc/builtins.c:6362 0x77d28e expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) .././../gcc/expr.c:10822 0x785faa store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool, tree_node*) .././../gcc/expr.c:5552 0x786bbe expand_assignment(tree_node*, tree_node*, bool) .././../gcc/expr.c:5321 0x69add5 expand_call_stmt .././../gcc/cfgexpand.c:2656 0x69add5 expand_gimple_stmt_1 .././../gcc/cfgexpand.c:3571 0x69add5 expand_gimple_stmt .././../gcc/cfgexpand.c:3737 0x69bf8f expand_gimple_basic_block .././../gcc/cfgexpand.c:5744 0x6a0546 execute .././../gcc/cfgexpand.c:6357
[Bug libstdc++/62045] __gnu_pbds::priority_queue, binary_heap_tag> is too slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62045 --- Comment #5 from Xi Ruoyao --- Patch proposal: https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00516.html
[Bug libstdc++/62045] __gnu_pbds::priority_queue, binary_heap_tag> is too slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62045 --- Comment #7 from Jonathan Wakely --- Please note that libstdc++ patches need to be sent to the libstdc++ list as well, see the policies at https://gcc.gnu.org/lists.html
[Bug libstdc++/62045] __gnu_pbds::priority_queue, binary_heap_tag> is too slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62045 --- Comment #6 from Xi Ruoyao --- Created attachment 40941 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40941&action=edit performance test result with the patch
[Bug middle-end/79988] [7 Regression][CHKP] ICE in tree check: accessed operand 5 of call_expr with 4 operands in ix86_expand_builtin, at config/i386/i386.c:36851
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79988
Richard Biener changed:
What|Removed |Added
Keywords||wrong-code
Target||x86_64-*-*, i?86-*-*
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-03-10
Target Milestone|--- |7.0
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Well, the call to __builtin_ia32_bndcl is not compatible and thus not detected
as builtin here because the argument is pointing to a different address-space
than the prototype.
I'm unsure if MPX handles pointers to different address-spaces and how to
handle this case in general. Simply stripping address-space qualifiers
for the gimple_builtin_call_types_compatible_p check is similarly bogus
I guess.
The specific check in chkp_gimple_call_builtin_p can of course be
reverted back to skip this checking via
Index: gcc/tree-chkp.c
===
--- gcc/tree-chkp.c (revision 246023)
+++ gcc/tree-chkp.c (working copy)
@@ -433,7 +433,9 @@ chkp_gimple_call_builtin_p (gimple *call
enum built_in_function code)
{
tree fndecl;
- if (gimple_call_builtin_p (call, BUILT_IN_MD)
+ if (is_gimple_call (call)
+ && (fndecl = gimple_call_fndecl (call)) != NULL
+ && DECL_BUILT_IN_CLASS (fndecl) == BUILT_IN_MD
&& (fndecl = targetm.builtin_chkp_function (code))
&& (DECL_FUNCTION_CODE (gimple_call_fndecl (call))
== DECL_FUNCTION_CODE (fndecl)))
but then if the resulting code makes any sense I don't know. It does
.L3:
movq%rdx, %rax
leaq(%rsi,%rdx), %rcx
bndcl (%rdx), %bnd0
bndcu (%rdi,%rcx), %bnd0
movq$0, %gs:(%rdx)
bndstx %bnd1, (%rdx,%r8)
addq$8, %rdx
which looks like wrong-code to me (bndcl of (%rdx) rather than %gs:(%rdx)).
I'd say ICE is better than wrong-code but YMMV ;)
[Bug c++/71569] [5/6/7 regression] Crash: External definition of template member from template struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71569
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #2 from Marek Polacek ---
We crash on the assert here:
2072 /* We shouldn't be specializing a member template of an
2073 unspecialized class template; we already gave an error in
2074 check_specialization_scope, now avoid crashing. */
2075 if (template_count && DECL_CLASS_SCOPE_P (decl)
2076 && template_class_depth (DECL_CONTEXT (decl)) > 0)
2077 {
2078 gcc_assert (errorcount);
2079 return error_mark_node;
2080 }
but seems check_specialization_scope was never called.
[Bug libstdc++/62045] __gnu_pbds::priority_queue, binary_heap_tag> is too slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62045 --- Comment #8 from Jonathan Wakely --- I'm guessing this probably regressed with r174100
[Bug gcov-profile/79891] Wrong count of line coverage in case of gcov -a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79891 --- Comment #5 from Richard Biener --- The instrumentation looks ok to me, we can recover all individual BB counts from that. What is the issue is likely the association of BB 5 (the merger block of if (false_var)) with line 13. Not sure where that is done.
[Bug libstdc++/62045] [5/6/7 Regression] __gnu_pbds::priority_queue, binary_heap_tag> is too slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62045 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-03-10 Known to work||4.6.4 Summary|__gnu_pbds::priority_queue< |[5/6/7 Regression] |int, less, |__gnu_pbds::priority_queue< |binary_heap_tag> is too |int, less, |slow|binary_heap_tag> is too ||slow Ever confirmed|0 |1 Known to fail||4.7.4, 4.8.5, 4.9.4, 5.4.0, ||6.3.0, 7.0
[Bug libstdc++/62045] [5/6/7 Regression] __gnu_pbds::priority_queue, binary_heap_tag> is too slow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62045 --- Comment #9 from Xi Ruoyao --- > Please note that libstdc++ patches need to be sent to the libstdc++ list as > well, see the policies at https://gcc.gnu.org/lists.html Sorry. I didn't notice that. Resent thread: https://gcc.gnu.org/ml/libstdc++/2017-03/msg00034.html
[Bug tree-optimization/79981] Forwprop not working for __atomic_compare_exchange_n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79981
--- Comment #6 from Richard Biener ---
(In reply to Jakub Jelinek from comment #4)
> (In reply to Dominik Vogt from comment #3)
> > (In reply to Richard Biener from comment #2)
> > > of course needs to be conditional on oldlhs being bool and lhs being
> > > integral.
> >
> > Like so?
> >
> > --
> > diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c
> > index 9fd45d1..e5e448e 100644
> > --- a/gcc/gimple-fold.c
> > +++ b/gcc/gimple-fold.c
> > @@ -3581,7 +3581,12 @@ fold_builtin_atomic_compare_exchange
> > (gimple_stmt_iterator *gsi)
> > }
> >else
> > gsi_insert_after (gsi, g, GSI_NEW_STMT);
> > - g = gimple_build_assign (oldlhs, NOP_EXPR, gimple_assign_lhs (g));
> > + if (TREE_CODE (TREE_TYPE (oldlhs)) == BOOLEAN_TYPE
> > + && INTEGRAL_TYPE_P (itype))
> > + g = gimple_build_assign (oldlhs, NE_EXPR, gimple_assign_lhs (g),
> > +build_zero_cst (TREE_TYPE (gimple_assign_lhs
> > (g;
> > + else
> > + g = gimple_build_assign (oldlhs, NOP_EXPR, gimple_assign_lhs (g));
> >gsi_insert_after (gsi, g, GSI_NEW_STMT);
> > }
> >g = gimple_build_assign (make_ssa_name (itype), REALPART_EXPR,
>
> That looks like a pessimization instead of optimization, perhaps optimizers
> then do a better job at that, but maybe in other cases don't.
As said, we miss canonicalization here and yes, likely it's a pessimization
in some cases.
> Wouldn't it be better to look after building the NOP_EXPR at the immediate
> uses of oldlhs and if any of them is oldlhs != 0 or oldlhs == 0 comparison,
> forward propagate there immediately the rhs1 of the nop and adjust the other
> operand?
You can't do this from folding (looking at immediate uses).
There is the possibility to enhance combine_cond_expr_cond
to handle the if ((_Bool) int != 0) case. In this case it looks like
a missed canonicalization to me given we simplify this to (_Bool) int:
Index: gcc/gimple.c
===
--- gcc/gimple.c(revision 246023)
+++ gcc/gimple.c(working copy)
@@ -2084,8 +2084,16 @@ canonicalize_cond_expr_cond (tree t)
== BOOLEAN_TYPE))
t = TREE_OPERAND (t, 0);
+ /* For (bool)x use x != 0. */
+ if (CONVERT_EXPR_P (t)
+ && TREE_CODE (TREE_TYPE (t)) == BOOLEAN_TYPE)
+{
+ tree top0 = TREE_OPERAND (t, 0);
+ t = build2 (NE_EXPR, TREE_TYPE (t),
+ top0, build_int_cst (TREE_TYPE (top0), 0));
+}
/* For !x use x == 0. */
- if (TREE_CODE (t) == TRUTH_NOT_EXPR)
+ else if (TREE_CODE (t) == TRUTH_NOT_EXPR)
{
tree top0 = TREE_OPERAND (t, 0);
t = build2 (EQ_EXPR, TREE_TYPE (t),
fixes the testcase.
[Bug rtl-optimization/63191] [5/6/7 Regression] 32-bit gcc uses excessive memory during dead store elimination with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63191
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||uros at gcc dot gnu.org
--- Comment #11 from Jakub Jelinek ---
Given say:
typedef int X;
struct Z {
Z(const X* x1, X x2, X x3) : x1_(x1), x2_(x2), x3_(x3) {}
const X* x1_;
X x2_;
X x3_;
};
static const X Xs0[] = {};
static const X Xs1[] = {};
static const X Xs2[] = {};
static const X Xs3[] = {};
static const X Xs4[] = {};
static const X Xs5[] = {};
static const X Xs6[] = {};
static const X Xs7[] = {};
static const X Xs8[] = {};
static const X Xs9[] = {};
static const Z Zs[] = {
Z(Xs1,1,1),
Z(Xs2,2,1),
Z(Xs3,2,1),
Z(Xs4,1,1),
Z(Xs5,1,1),Z(Xs6,8,1),
Z(Xs7,1,1),Z(Xs8,5,1),
Z(Xs9,1,1),Z(Xs0,7,1) };
const Z *p = &Zs[0];
(the last line is there so that everything is not optimized away), I'm seeing
that on x86_64-linux with -m64 -O2 -fpic we actually CSE all those
(symbol_ref:DI "_ZL2Zs"), because it has cost of 6 (rtx_cost on that
(symbol_ref, DImode, SET, 1) yields 3), while with -m32 -O2 -fpic we don't,
because it has cost of 0.
But it is more confusing that we actually return 3 on -m64 -fpic,
x86_64_nonimmediate_operand has:
/* For certain code models, the symbolic references are known to fit.
in CM_SMALL_PIC model we know it fits if it is local to the shared
library. Don't count TLS SYMBOL_REFs here, since they should fit
only if inside of UNSPEC handled below. */
return (ix86_cmodel == CM_SMALL || ix86_cmodel == CM_KERNEL
|| (ix86_cmodel == CM_MEDIUM && !SYMBOL_REF_FAR_ADDR_P (op)));
So it talks about ix86_cmodel of CM_SMALL_PIC, but then actually doesn't do
anything for it.
Perhaps it is right that foo(%rip) is not considered
x86_64_nonimmediate_operand, but perhaps it should still have zero cost.
That would of course make this PR likely worse even on x86_64 -m64.
[Bug c++/79986] [6/7 Regression][CHKP] ICE in fold_convert_loc with a flexiable array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79986 Richard Biener changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* Target Milestone|--- |6.4
[Bug middle-end/79989] [7 Regression][CHKP] ICE in assign_temp, at function.c:968
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79989 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0
[Bug rtl-optimization/63191] [5/6/7 Regression] 32-bit gcc uses excessive memory during dead store elimination with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63191 Jakub Jelinek changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #12 from Jakub Jelinek --- For the C++ FE, the question here is why we actually emit dynamic initialization at all. If constexpr is added to the ctor, then we just emit the initializer, but even without the constexpr I'd think that if the ctor has empty body and trivial mem initializers and if all arguments of the ctors are constants, as an optimization we should handle it as if it was declared constexpr. Jason?
[Bug rtl-optimization/63191] [5/6/7 Regression] 32-bit gcc uses excessive memory during dead store elimination with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63191 --- Comment #13 from Richard Biener --- (In reply to Jakub Jelinek from comment #12) > For the C++ FE, the question here is why we actually emit dynamic > initialization at all. If constexpr is added to the ctor, then we just emit > the initializer, but even without the constexpr I'd think that if the ctor > has empty body and trivial mem initializers and if all arguments of the > ctors are constants, as an optimization we should handle it as if it was > declared constexpr. Jason? I think there is a PR somewhere suggesting C++ should (for all initializers) try constexpr evaluation. It's much harder to do this in the middle-end.
[Bug rtl-optimization/63191] [5/6/7 Regression] 32-bit gcc uses excessive memory during dead store elimination with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63191 --- Comment #14 from Jakub Jelinek --- (In reply to Richard Biener from comment #13) > (In reply to Jakub Jelinek from comment #12) > > For the C++ FE, the question here is why we actually emit dynamic > > initialization at all. If constexpr is added to the ctor, then we just emit > > the initializer, but even without the constexpr I'd think that if the ctor > > has empty body and trivial mem initializers and if all arguments of the > > ctors are constants, as an optimization we should handle it as if it was > > declared constexpr. Jason? > > I think there is a PR somewhere suggesting C++ should (for all initializers) > try constexpr evaluation. It's much harder to do this in the middle-end. Note clang++ seems to implement that (i.e. constexpr isn't needed there in order to get a static initializer).
[Bug c++/79393] [7 Regression] cc1plus rejects valid code with noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79393 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug c++/66139] destructor not called for members of partially constructed anonymous struct/array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66139 Mikhail Kremnyov changed: What|Removed |Added CC||officesamurai at gmail dot com --- Comment #1 from Mikhail Kremnyov --- This issue is also present in GCC 5.x, 6.x and the trunk. I wonder if it's possible to increase its priority since it makes it impossible to guarantee code exception safety.
[Bug c++/79652] [5/6/7 Regression] ICE on invalid c++ code in warn_extern_redeclared_static in cp/decl.c:1231
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79652 Richard Biener changed: What|Removed |Added Priority|P3 |P5
[Bug bootstrap/79771] [7 Regression] in-tree zlib breaks build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79771 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug fortran/79886] [5/6/7 Regression] ICE in pp_format, at pretty-print.c:681
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79886 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/79896] [5/6/7 Regression] ICE in gimplify_expr, at gimplify.c:11950 on non-int128 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79896 Richard Biener changed: What|Removed |Added Keywords||ice-on-invalid-code Priority|P3 |P5 Target Milestone|7.0 |5.5
[Bug bootstrap/79952] [7 Regression] ICE in test_loading_cfg in read-rtl-function.c:2016 targeting hppa2.0w-hp-hpux11.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79952 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug libfortran/79956] [7 Regression] many new -Wmaybe-uninitialized warnings with bootstrap-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79956 --- Comment #13 from Richard Biener --- Again, changing loop exists from n == sdim to n >= sdim might help.
[Bug c++/79960] [5/6/7 Regression] Class template partial specializations for const volatile types don't match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79960 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug gcov-profile/79891] Wrong count of line coverage in case of gcov -a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79891 --- Comment #6 from Martin Liška --- Yes, the merged is the issue, but looks it's created at the very beginning: test.c.004t.gimple: ... : if (false_var != 0) goto ; else goto ; : ret = 111; : goto ; : ret = 999; : D.2320 = ret; return D.2320;
[Bug ipa/79966] [6/7 Regression] run time more than twice slower when using -fipa-cp-clone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79966 Richard Biener changed: What|Removed |Added Priority|P3 |P2 CC||hubicka at gcc dot gnu.org, ||rguenth at gcc dot gnu.org --- Comment #3 from Richard Biener --- Inlining difference shows: Inlining mysum to tp_sum with frequency 1000 Inlining tp_sum to runtptests with frequency 99000 Inlining mysum to runtptests with frequency 10 vs. just Inlining mysum.constprop to tp_sum with frequency 1000 We don't even consider to inline tp_sum when -fipa-cp-clone is enabled.
[Bug gcov-profile/79891] Wrong count of line coverage in case of gcov -a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79891 --- Comment #7 from rguenther at suse dot de --- On Fri, 10 Mar 2017, marxin at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79891 > > --- Comment #6 from Martin Liška --- > Yes, the merged is the issue, but looks it's created at the very beginning: No, the merged block isn't the issue, the issue is in coverage computation (or where it associates the bogus source line to the BB).
[Bug c++/79986] [6/7 Regression][CHKP] ICE in fold_convert_loc with a flexiable array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79986 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug gcov-profile/79891] Wrong count of line coverage in case of gcov -a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79891 --- Comment #8 from Martin Liška --- (In reply to rguent...@suse.de from comment #7) > On Fri, 10 Mar 2017, marxin at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79891 > > > > --- Comment #6 from Martin Liška --- > > Yes, the merged is the issue, but looks it's created at the very beginning: > > No, the merged block isn't the issue, the issue is in coverage computation > (or where it associates the bogus source line to the BB). I see, that should be fixable, the merger should not belong to any line in source file. I'll fix that.
[Bug target/65705] ICE: SIGSEGV in contains_struct_check with -fsanitize=null -fcheck-pointer-bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65705 --- Comment #7 from Martin Liška --- Author: marxin Date: Fri Mar 10 13:24:45 2017 New Revision: 246027 URL: https://gcc.gnu.org/viewcvs?rev=246027&root=gcc&view=rev Log: MPX: Fix option handling. 2017-03-10 Martin Liska PR target/65705 PR target/69804 * toplev.c (process_options): Enable MPX with LSAN and UBSAN. * tree-chkp.c (chkp_walk_pointer_assignments): Verify that FIELD != NULL. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/gcc.target/i386/pr71458.c trunk/gcc/toplev.c trunk/gcc/tree-chkp.c
[Bug target/69804] [5/6] ICE with -fsanitize=undefined -fcheck-pointer-bounds -mmpx
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69804 --- Comment #7 from Martin Liška --- Author: marxin Date: Fri Mar 10 13:24:45 2017 New Revision: 246027 URL: https://gcc.gnu.org/viewcvs?rev=246027&root=gcc&view=rev Log: MPX: Fix option handling. 2017-03-10 Martin Liska PR target/65705 PR target/69804 * toplev.c (process_options): Enable MPX with LSAN and UBSAN. * tree-chkp.c (chkp_walk_pointer_assignments): Verify that FIELD != NULL. Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/gcc.target/i386/pr71458.c trunk/gcc/toplev.c trunk/gcc/tree-chkp.c
[Bug rtl-optimization/63191] [5/6/7 Regression] 32-bit gcc uses excessive memory during dead store elimination with -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63191
--- Comment #15 from Jakub Jelinek ---
Anyway, as far as memory consumption goes (compile time is still the same), the
following patch helps a lot:
--- gcc/config/i386/i386.c.jj 2017-03-07 20:04:52.0 +0100
+++ gcc/config/i386/i386.c 2017-03-10 13:46:12.482704787 +0100
@@ -17257,8 +17257,9 @@ ix86_delegitimize_tls_address (rtx orig_
necessary to remove references to the PIC label from RTL stored by
the DWARF output code. */
-static rtx
-ix86_delegitimize_address (rtx x)
+template
+static inline rtx
+ix86_delegitimize_address_1 (rtx x)
{
rtx orig_x = delegitimize_mem_from_attrs (x);
/* addend is NULL or some rtx if x is something+GOTOFF where
@@ -17361,7 +17362,7 @@ ix86_delegitimize_address (rtx x)
if (! result)
return ix86_delegitimize_tls_address (orig_x);
- if (const_addend)
+ if (const_addend && !base_term)
result = gen_rtx_CONST (Pmode, gen_rtx_PLUS (Pmode, result,
const_addend));
if (reg_addend)
result = gen_rtx_PLUS (Pmode, reg_addend, result);
@@ -17399,6 +17400,12 @@ ix86_delegitimize_address (rtx x)
return result;
}
+static rtx
+ix86_delegitimize_address (rtx x)
+{
+ return ix86_delegitimize_address_1 (x);
+}
+
/* If X is a machine specific address (i.e. a symbol or label being
referenced as a displacement from the GOT implemented using an
UNSPEC), then return the base term. Otherwise return X. */
@@ -17424,7 +17431,7 @@ ix86_find_base_term (rtx x)
return XVECEXP (term, 0, 0);
}
- return ix86_delegitimize_address (x);
+ return ix86_delegitimize_address_1 (x);
}
static void
Without the patch (just the major time or memory consumers):
tree DSE: 40.53 ( 9%) usr 0.00 ( 0%) sys 40.51 ( 9%) wall
0 kB ( 0%) ggc
dead store elim1: 244.65 (55%) usr 1.10 (46%) sys 245.75 (55%) wall
5879136 kB (47%) ggc
dead store elim2: 3.12 ( 1%) usr 0.01 ( 0%) sys 3.12 ( 1%) wall
252045 kB ( 2%) ggc
reload CSE regs : 106.15 (24%) usr 0.01 ( 0%) sys 106.15 (24%) wall
4496830 kB (36%) ggc
TOTAL : 444.45 2.38 447.46
1240 kB
and with the patch:
tree DSE: 40.52 (10%) usr 0.00 ( 0%) sys 40.51 (10%) wall
0 kB ( 0%) ggc
dead store elim1: 223.84 (55%) usr 0.00 ( 0%) sys 223.84 (55%) wall
4653 kB ( 0%) ggc
dead store elim2: 2.92 ( 1%) usr 0.00 ( 0%) sys 2.92 ( 1%) wall
175766 kB ( 7%) ggc
reload CSE regs : 98.58 (24%) usr 0.46 (53%) sys 99.04 (24%) wall
2130309 kB (83%) ggc
TOTAL : 407.95 0.86 409.33
2558609 kB
(both completely unoptimized compilers with checking etc.).
The thing is that ix86_find_base_term calls ix86_delegitimize_address that
often creates some RTL that the caller then immediately throws away.
ix86_find_base_term is called a lot on expressions like:
(plus:SI (value:SI 1:1 @0x2c60f50/0x2c50f40)
(const:SI (plus:SI (unspec:SI [
(symbol_ref:SI ("_ZL2Zs") [flags 0x2] )
] UNSPEC_GOTOFF)
(const_int 8 [0x8]
on which it returns
(const:SI (plus:SI (symbol_ref:SI ("_ZL2Zs") [flags 0x2] )
(const_int 8 [0x8])))
but in reality, the caller only cares about the SYMBOL_REF, CONST_INT operand
on PLUS is ignored by find_base_term.
The other option is to duplicate and adjust ix86_delegitimize_address into
ix86_find_base_term.
With the above template, we can share the code, just (for now in one spot, but
likely in more spots later).
As for more spots later, e.g. both find_base_value and find_base_term (the only
users of ix86_find_base_term)
only care about MEM with arg_pointer_rtx or plus arg_pointer_rtx something.
So, in other cases it doesn't
make sense to replace_equiv_address_nv. Thus I think
if (GET_CODE (x) == CONST
&& GET_CODE (XEXP (x, 0)) == PLUS
&& GET_MODE (XEXP (x, 0)) == Pmode
&& CONST_INT_P (XEXP (XEXP (x, 0), 1))
&& GET_CODE (XEXP (XEXP (x, 0), 0)) == UNSPEC
&& XINT (XEXP (XEXP (x, 0), 0), 1) == UNSPEC_PCREL)
{
rtx x2 = XVECEXP (XEXP (XEXP (x, 0), 0), 0, 0);
x = gen_rtx_PLUS (Pmode, XEXP (XEXP (x, 0), 1), x2);
if (MEM_P (orig_x))
x = replace_equiv_address_nv (orig_x, x);
return x;
}
isn't really useful if base_term && MEM_P (orig_x).
[Bug tree-optimization/77498] [7 regression] Performance drop after r239414 on spec2000/172mgrid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77498
--- Comment #7 from Richard Biener ---
Ok, so given we can't have PRE do as good as predcom and a "cost model" for PRE
is out of the question for GCC 7 the following dumbs down PRE again. It does
so in the very much simplest way rather than trying to block this only during
elimination / insertion. This should be definitely revisited for GCC 8.
Index: gcc/tree-ssa-pre.c
===
--- gcc/tree-ssa-pre.c (revision 246026)
+++ gcc/tree-ssa-pre.c (working copy)
@@ -1468,10 +1468,20 @@ phi_translate_1 (pre_expr expr, bitmap_s
leader for it. */
if (constant->kind != CONSTANT)
{
- unsigned value_id = get_expr_value_id (constant);
- constant = find_leader_in_sets (value_id, set1, set2);
- if (constant)
- return constant;
+ /* Do not allow simplifications to non-constants over
+ backedges as this will likely result in a loop PHI node
+ to be inserted and increased register pressure.
+ See PR77498 - this avoids doing predcoms work in
+ a less efficient way. */
+ if (find_edge (pred, phiblock)->flags & EDGE_DFS_BACK)
+ ;
+ else
+ {
+ unsigned value_id = get_expr_value_id (constant);
+ constant = find_leader_in_sets (value_id, set1, set2);
+ if (constant)
+ return constant;
+ }
}
else
return constant;
[Bug c++/51350] [4.7 Regression] Bogus -Wstrict-overflow warning: assuming signed overflow does not occur when assuming that (X + c) < X is always false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51350 Mic changed: What|Removed |Added CC||micwinx at web dot de --- Comment #2 from Mic --- I encountered the same issue on a similar code block with gcc-4.8.4 and it is still there with gcc-5.3.0 and gcc-6.1.0. I still think this is a bug; this is because even when doing "forwprop" and "jump-threading" over the while loop you are only checking this particular case. In my opinion gcc should only warn if you could do the if conversion from if (suffix < pattern_length) to if (0) in all cases, in particular also in the case where the while loop condition evaluates to true. In more general I think gcc should not warn about certain things when just looking at some snippet (which is here clearly done by just "jump threading over the while loop) and not the full code block. (I could also imagine that "forwprop" and "jump threading" are used for some optimization techniques, still this should not lead to a warning.) Why to warn about this if condition while the warning does not apply for the general case in this code example is clearly bad behavior. In particular when compiling with "(-Wall) -Werror" the code won't compile anymore which is pretty bad and it's quite annoying to get around it. Maybe you could rethink about this and fix this issue. Thank you.
[Bug c++/77509] [5/6/7 Regression] ICE on invalid C++ code: in finish_class_member_access_expr, at cp/typeck.c:2783
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77509 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #3 from Marek Polacek --- Fixed by r244832.
[Bug target/79907] ICE in extract_constrain_insn, at recog.c:2213 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79907 --- Comment #1 from Pat Haugen --- Author: pthaugen Date: Fri Mar 10 14:32:42 2017 New Revision: 246029 URL: https://gcc.gnu.org/viewcvs?rev=246029&root=gcc&view=rev Log: PR target/79907 * config/rs6000/rs6000.c (rs6000_init_hard_regno_mode_ok): Test TARGET_UPPER_REGS_DI when setting 'wi' constraint regclass. * gcc.target/powerpc/pr79907.c: New. Added: trunk/gcc/testsuite/gcc.target/powerpc/pr79907.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/testsuite/ChangeLog
[Bug target/79907] ICE in extract_constrain_insn, at recog.c:2213 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79907 Pat Haugen changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Pat Haugen --- Fixed.
[Bug libstdc++/79980] Possible bug in codecvt.cpp bitmask setting code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79980 --- Comment #2 from Jonathan Wakely --- Apparently so is min vs max: maxcode = std::max(max_single_utf16_unit, maxcode);
[Bug tree-optimization/79981] Forwprop not working for __atomic_compare_exchange_n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79981 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Created attachment 40942 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40942&action=edit gcc7-pr79981.patch Untested fix. With this patch the vrp1 difference is: _8 = ATOMIC_COMPARE_EXCHANGE (lock_4(D), 0, 1, 260, 2, 0); - # RANGE [0, 4294967295] + # RANGE [0, 1] NONZERO 1 _9 = IMAGPART_EXPR <_8>; # RANGE [0, 1] _1 = (_Bool) _9; - if (_1 != 0) + if (_9 != 0)
[Bug bootstrap/79771] [7 Regression] in-tree zlib breaks build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79771 --- Comment #5 from Jakub Jelinek --- Do you really need even the zlib.def change? That part has been added 5 years ago, so it would surprise me if it didn't build even with that. If that works, the gzguts.h and zlib.h changes is something we can apply to gcc's copy until it is resolved upstream.
[Bug testsuite/79356] XPASS in attr-alloc_size-11.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79356 --- Comment #8 from Segher Boessenkool --- Author: segher Date: Fri Mar 10 15:23:06 2017 New Revision: 246032 URL: https://gcc.gnu.org/viewcvs?rev=246032&root=gcc&view=rev Log: testsuite: attr-alloc_size-11.c (PR79356) As stated in the PR (and elsewhere), this test now passes on aarch64, ia64, mips, powerpc, sparc, and s390x. This patch disables the xfails for those targets. PR testsuite/79356 * gcc.dg/attr-alloc_size-11.c: Don't xfail on aarch64, ia64, mips, powerpc, sparc, or s390x. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/attr-alloc_size-11.c
[Bug tree-optimization/79981] Forwprop not working for __atomic_compare_exchange_n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79981
--- Comment #8 from Marc Glisse ---
(In reply to Richard Biener from comment #2)
> (simplify
> (convert @1)
> (if (INTEGRAL_TYPE_P (TREE_TYPE (@1))
> && INTEGRAL_TYPE_P (type)
> && (TREE_CODE (type) == BOOLEAN_TYPE
> || TYPE_PRECISION (type) == 1))
> (ne @1 { build_zero_cst (TREE_TYPE (@1)); })))
I thought casting int to _Bool, internally in gcc, had the same semantics as
any other integer cast, i.e. keep only the low bit, which is not the same thing
as != 0 (unless get_range_info says so). Am I misremembering?
[Bug c++/79896] [5/6/7 Regression] ICE in gimplify_expr, at gimplify.c:11950 on non-int128 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79896 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Fri Mar 10 15:28:26 2017 New Revision: 246034 URL: https://gcc.gnu.org/viewcvs?rev=246034&root=gcc&view=rev Log: PR c++/79896 * decl.c (finish_enum_value_list): If value is error_mark_node, don't copy it and change its type. * init.c (constant_value_1): Return error_mark_node if DECL_INITIAL of CONST_DECL is error_mark_node. * g++.dg/ext/int128-5.C: New test. Added: trunk/gcc/testsuite/g++.dg/ext/int128-5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/init.c trunk/gcc/testsuite/ChangeLog
[Bug c++/79899] ICE in ctor_omit_inherited_parms at gcc/cp/method.c:576 on ARM target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79899 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Fri Mar 10 15:33:04 2017 New Revision: 246038 URL: https://gcc.gnu.org/viewcvs?rev=246038&root=gcc&view=rev Log: PR c++/79899 * optimize.c (maybe_thunk_body): Don't ICE if fns[0] is NULL. Use XALLOCAVEC macro. * g++.dg/other/friend7.C: New test. Added: trunk/gcc/testsuite/g++.dg/other/friend7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/optimize.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/77498] [7 regression] Performance drop after r239414 on spec2000/172mgrid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77498
Thomas Preud'homme changed:
What|Removed |Added
CC||thopre01 at gcc dot gnu.org
--- Comment #8 from Thomas Preud'homme ---
(In reply to Richard Biener from comment #7)
> Ok, so given we can't have PRE do as good as predcom and a "cost model" for
> PRE is out of the question for GCC 7 the following dumbs down PRE again. It
> does so in the very much simplest way rather than trying to block this only
> during elimination / insertion. This should be definitely revisited for GCC
> 8.
>
> Index: gcc/tree-ssa-pre.c
> ===
> --- gcc/tree-ssa-pre.c (revision 246026)
> +++ gcc/tree-ssa-pre.c (working copy)
> @@ -1468,10 +1468,20 @@ phi_translate_1 (pre_expr expr, bitmap_s
>leader for it. */
> if (constant->kind != CONSTANT)
> {
> - unsigned value_id = get_expr_value_id (constant);
> - constant = find_leader_in_sets (value_id, set1, set2);
> - if (constant)
> - return constant;
> + /* Do not allow simplifications to non-constants over
> + backedges as this will likely result in a loop PHI
> node
> + to be inserted and increased register pressure.
> + See PR77498 - this avoids doing predcoms work in
> + a less efficient way. */
> + if (find_edge (pred, phiblock)->flags & EDGE_DFS_BACK)
> + ;
> + else
> + {
> + unsigned value_id = get_expr_value_id (constant);
> + constant = find_leader_in_sets (value_id, set1,
> set2);
> + if (constant)
> + return constant;
> + }
> }
> else
> return constant;
I don't know for Yuri's issue but at least it sadly does not help with the
problem reported by Andre for arm-none-eabi [1]. I'll try to come up with a
testcase next week.
[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77498#c2
[Bug ipa/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77333 --- Comment #21 from Martin Jambor --- I have proposed two ways to fix this on the mailing list: https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00535.html (I have not yet looked at how much back-portable they are but I do not expect any issues.)
[Bug c++/79967] ICE on non-type template argument declared noreturn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79967 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek --- Fixed.
[Bug c++/79967] ICE on non-type template argument declared noreturn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79967 --- Comment #3 from Marek Polacek --- Author: mpolacek Date: Fri Mar 10 15:36:00 2017 New Revision: 246039 URL: https://gcc.gnu.org/viewcvs?rev=246039&root=gcc&view=rev Log: PR c++/79967 * decl.c (grokdeclarator): Check ATTRLIST before dereferencing it. * g++.dg/cpp0x/gen-attrs-63.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/gen-attrs-63.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/78972] [5/6/7 Regression] poor x86 simd instruction scheduling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78972 Bernd Schmidt changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |bernds at gcc dot gnu.org --- Comment #10 from Bernd Schmidt --- I have a patch I'll submit for gcc-8.
[Bug c++/79896] [5/6 Regression] ICE in gimplify_expr, at gimplify.c:11950 on non-int128 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79896 Jakub Jelinek changed: What|Removed |Added Summary|[5/6/7 Regression] ICE in |[5/6 Regression] ICE in |gimplify_expr, at |gimplify_expr, at |gimplify.c:11950 on |gimplify.c:11950 on |non-int128 target |non-int128 target --- Comment #5 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c++/79899] ICE in ctor_omit_inherited_parms at gcc/cp/method.c:576 on ARM target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79899 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug target/79185] [5/6/7 Regression] register allocation in the addition of two 128 bit ints
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79185 Bernd Schmidt changed: What|Removed |Added CC||bernds at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |bernds at gcc dot gnu.org --- Comment #7 from Bernd Schmidt --- Will investigate at least a little. I have a feeling this should be working...
[Bug tree-optimization/78972] [5/6/7 Regression] poor x86 simd instruction scheduling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78972 Jeffrey A. Law changed: What|Removed |Added Target Milestone|7.0 |8.0
[Bug target/79941] [7 Regression] Altivec vec_vmuleub regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79941 --- Comment #2 from Will Schmidt --- Author: willschm Date: Fri Mar 10 16:18:44 2017 New Revision: 246040 URL: https://gcc.gnu.org/viewcvs?rev=246040&root=gcc&view=rev Log: gcc: 2017-03-10 Will Schmidt PR target/79941 * config/rs6000/rs6000.c (builtin_function_type): Add VMUL*U[HB] entries to the case statement that marks unsigned arguments to overloaded functions. testsuite: 2017-03-10 Will Schmidt PR target/79941 * gcc.target/powerpc/fold-vec-mult-even_odd_misc.c: New test. * gcc.target/powerpc/fold-vec-mult-even_odd_char.c: New test. * gcc.target/powerpc/fold-vec-mult-even_odd_short.c: New test. Added: trunk/gcc/testsuite/gcc.target/powerpc/fold-vec-mule-char.c trunk/gcc/testsuite/gcc.target/powerpc/fold-vec-mule-misc.c trunk/gcc/testsuite/gcc.target/powerpc/fold-vec-mule-short.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c trunk/gcc/testsuite/ChangeLog
[Bug target/79941] [7 Regression] Altivec vec_vmuleub regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79941 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jakub Jelinek --- Fixed, thanks.
[Bug testsuite/79356] XPASS in attr-alloc_size-11.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79356 Segher Boessenkool changed: What|Removed |Added Target|s390x-*-*, powerpc*-*-*,|s390x-*-*, powerpc*-*-*, |ia64-*-*, aarch64-*-*, |ia64-*-*, aarch64-*-*, |sparc*-*-* |sparc*-*-*, mips*-*-* Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Segher Boessenkool --- This is fixed on all identified targets now.
[Bug bootstrap/79771] [7 Regression] in-tree zlib breaks build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79771 --- Comment #6 from Yaakov Selkowitz --- (In reply to Jakub Jelinek from comment #5) > Do you really need even the zlib.def change? For standalone zlib, yes; if you try to export a symbol which doesn't exist, ld errors out. > That part has been added 5 years ago, so it would surprise me if it didn't > build even with that. For standalone zlib, no, we've just been patching it out all this time. Note that my patch was for the standalone zlib. OTOH, in-tree zlib should be built static-only, so zlib.def isn't used either way. > If that works, the gzguts.h and zlib.h changes is something we can apply to > gcc's copy until it is resolved upstream. Ultimately, IMHO we should be encouraging --with-system-zlib on Cygwin (like most other *NIX), but by all means, feel free to take the patch.
[Bug c++/79967] ICE on non-type template argument declared noreturn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79967 --- Comment #5 from Martin Sebor --- (In reply to Marek Polacek from comment #2) > It seems to be valid, clang++ accepts it and G++ too (with my patch). I don't have a strong opinion whether this should or should not be accepted but in comment #0 I said I thought it was "(presumably) ill-formed" because C++ specifies in [dcl.attr.noreturn] that: The attribute may be applied to the declarator-id in a function declaration. I don't think a template parameter is a "function declaration" but Jason might read it differently. We recently discussed what exactly the term "function declaration" is meant to cover in this context: https://gcc.gnu.org/ml/gcc-patches/2017-02/msg01075.html. If this code should be valid I think the standard needs to be clarified to list all the contexts where the attribute may be applied and what it means in each (where it isn't obvious). For instance, what does the attribute mean in the reported test case? It seems that it's ignored. Shouldn't GCC report -Wignored-attributes?
[Bug c++/79960] [5/6/7 Regression] Class template partial specializations for const volatile types don't match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79960 --- Comment #4 from Jason Merrill --- Author: jason Date: Fri Mar 10 17:35:54 2017 New Revision: 246042 URL: https://gcc.gnu.org/viewcvs?rev=246042&root=gcc&view=rev Log: PR c++/79960 - alias templates and partial ordering * pt.c (comp_template_args): Add partial_order parm. (template_args_equal): Likewise. (comp_template_args_porder): New. (get_partial_spec_bindings): Use it. Added: trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-57.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c
[Bug target/78543] [6 Regression] ICE in push_reload, at reload.c:1349 on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78543 Peter Bergner changed: What|Removed |Added CC||uweigand at gcc dot gnu.org --- Comment #15 from Peter Bergner --- (In reply to Peter Bergner from comment #14) > Patch submitted. Uli commented that the patch needs reworking, so I'm back to digging into this.
[Bug rtl-optimization/79985] ICE in code_motion_path_driver, at sel-sched.c:6580
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79985
Alexander Monakov changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-03-10
CC||abel at gcc dot gnu.org,
||amonakov at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Alexander Monakov ---
Thanks for the nice minimal testcase. We choose to schedule the bottom asm
first (it doesn't depend on anything else), but then while moving it up we
notice a use/set conflict with the upper asm in undo_transformations. Somehow
register 110 (vscr) is added to set/use regsets for insns representing asms via
DF:
Breakpoint 2, setup_id_reg_sets (id=0x1d71e28, insn=0x718af400) at
gcc/sel-sched-ir.c:2677
2677 struct df_insn_info *insn_info = DF_INSN_INFO_GET (insn);
(gdb) c
Continuing.
Breakpoint 2, setup_id_reg_sets (id=0x1dcedf8, insn=0x718af6c0) at
gcc/sel-sched-ir.c:2677
2677 struct df_insn_info *insn_info = DF_INSN_INFO_GET (insn);
(gdb)
Continuing.
Breakpoint 2, setup_id_reg_sets (id=0x1dcf058, insn=0x718af480) at
gcc/sel-sched-ir.c:2677
2677 struct df_insn_info *insn_info = DF_INSN_INFO_GET (insn);
(gdb) call debug_rtx(insn)
(insn 8 14 5 2 (parallel [
(set (reg:DI 155)
(asm_operands:DI ("") ("=r") 0 [
(reg:DI 155)
]
[
(asm_input:DI ("0") t.c:6)
]
[] t.c:6))
(clobber (reg:SI 76 ca))
]) "t.c":6 -1
(expr_list:REG_UNUSED (reg:SI 76 ca)
(nil)))
(gdb) n
2679 regset tmp = get_clear_regset_from_pool ();
(gdb)
2681 FOR_EACH_INSN_INFO_DEF (def, insn_info)
(gdb)
2683 unsigned int regno = DF_REF_REGNO (def);
(gdb)
2686 if (DF_REF_FLAGS_IS_SET (def, (DF_REF_MUST_CLOBBER
(gdb) p regno
$15 = 110
[Bug bootstrap/79952] [7 Regression] ICE in test_loading_cfg in read-rtl-function.c:2016 targeting hppa2.0w-hp-hpux11.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79952 --- Comment #6 from David Malcolm --- Author: dmalcolm Date: Fri Mar 10 18:39:52 2017 New Revision: 246044 URL: https://gcc.gnu.org/viewcvs?rev=246044&root=gcc&view=rev Log: Fix out-of-bounds write in RTL function reader (PR bootstrap/79952) gcc/ChangeLog: PR bootstrap/79952 * read-rtl-function.c (function_reader::read_rtx_operand): Update x with result of extra_parsing_for_operand_code_0. (function_reader::extra_parsing_for_operand_code_0): Convert return type from void to rtx, returning x. When reading SYMBOL_REF with SYMBOL_FLAG_HAS_BLOCK_INFO, reallocate x to the larger size containing struct block_symbol. Modified: trunk/gcc/ChangeLog trunk/gcc/read-rtl-function.c
[Bug other/79991] New: typo in params.def, PARAM_VECT_MAX_PEELING_FOR_ALIGNMENT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79991 Bug ID: 79991 Summary: typo in params.def, PARAM_VECT_MAX_PEELING_FOR_ALIGNMENT Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- from params.def: DEFPARAM(PARAM_VECT_MAX_PEELING_FOR_ALIGNMENT, "vect-max-peeling-for-alignment", "Max number of loop peels to enhancement alignment of data references in a loop.", -1, -1, 64) As the German translator, I could not make sense of "enhancement alignment", therefore I decided this was a typo and interpreted it as "enhance alignment". If I'm correct, it should be fixed.
[Bug libstdc++/79511] Convertation issues in std::codecvt_utf8_utf16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79511
--- Comment #11 from Jonathan Wakely ---
I think this is the fix for comment 9:
--- a/libstdc++-v3/src/c++11/codecvt.cc
+++ b/libstdc++-v3/src/c++11/codecvt.cc
@@ -1483,7 +1483,11 @@ do_in(state_type&, const extern_type* __from, const
extern_type* __from_end,
{
range from{ __from, __from_end };
range to{ __to, __to_end };
- auto res = utf16_in(from, to, _M_maxcode, _M_mode);
+ codecvt_mode mode = codecvt_mode(_M_mode &
(consume_header|generate_header));
+#if __BYTE_ORDER__ != __ORDER_BIG_ENDIAN__
+ mode = codecvt_mode(mode | little_endian);
+#endif
+ auto res = utf16_in(from, to, _M_maxcode, mode);
__from_next = from.next;
__to_next = to.next;
return res;
[Bug bootstrap/79952] [7 Regression] ICE in test_loading_cfg in read-rtl-function.c:2016 targeting hppa2.0w-hp-hpux11.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79952 --- Comment #7 from David Malcolm --- Should be fixed by r246044. Jeff: does this fix the issue you mentioned in comment #2?
[Bug bootstrap/79952] [7 Regression] ICE in test_loading_cfg in read-rtl-function.c:2016 targeting hppa2.0w-hp-hpux11.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79952 --- Comment #8 from Jeffrey A. Law --- I was just about to test it... Results shortly :-)
[Bug bootstrap/79952] [7 Regression] ICE in test_loading_cfg in read-rtl-function.c:2016 targeting hppa2.0w-hp-hpux11.11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79952 --- Comment #9 from Jeffrey A. Law --- It does!
[Bug c/79921] missing translation for "...this statement, but the latter is misleadingly indented"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79921 --- Comment #2 from David Malcolm --- Author: dmalcolm Date: Fri Mar 10 19:09:02 2017 New Revision: 246045 URL: https://gcc.gnu.org/viewcvs?rev=246045&root=gcc&view=rev Log: c-indentation.c: workaround xgettext limitation (PR c/79921) gcc/c-family/ChangeLog: PR c/79921 * c-indentation.c (warn_for_misleading_indentation): Remove parens from inform's message, so that xgettext can locate it. Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-indentation.c
[Bug c/79921] missing translation for "...this statement, but the latter is misleadingly indented"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79921 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Message fixed in source as of r246045; should be fixed in gcc.pot next time Joseph regenerates it. Marking as RESOLVED.
[Bug driver/79875] diagnostics: missing question mark after "did you mean"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79875 --- Comment #2 from David Malcolm --- Author: dmalcolm Date: Fri Mar 10 19:22:35 2017 New Revision: 246047 URL: https://gcc.gnu.org/viewcvs?rev=246047&root=gcc&view=rev Log: Add missing punctuation to message (PR driver/79875) gcc/ChangeLog: PR driver/79875 * opts.c (parse_sanitizer_options): Add missing question mark to "did you mean" message. Modified: trunk/gcc/ChangeLog trunk/gcc/opts.c
[Bug driver/79875] diagnostics: missing question mark after "did you mean"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79875 David Malcolm changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from David Malcolm --- Should be fixed as of r246047.
[Bug libfortran/79956] [7 Regression] many new -Wmaybe-uninitialized warnings with bootstrap-O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79956 --- Comment #14 from Thomas Koenig --- Author: tkoenig Date: Fri Mar 10 19:42:46 2017 New Revision: 246053 URL: https://gcc.gnu.org/viewcvs?rev=246053&root=gcc&view=rev Log: 2017-03-10 Thomas Koenig PR libfortran/79956 * m4/iforeach.m4: Change exit condition from loop for increasing dimension to >=. Fix type in comment. * m4/ifunction.m4: Likewise. * m4/ifunction_logical.m4: Likewise. * generated/all_l1.c: Regenerated. * generated/all_l16.c: Regenerated. * generated/all_l2.c: Regenerated. * generated/all_l4.c: Regenerated. * generated/all_l8.c: Regenerated. * generated/any_l1.c: Regenerated. * generated/any_l16.c: Regenerated. * generated/any_l2.c: Regenerated. * generated/any_l4.c: Regenerated. * generated/any_l8.c: Regenerated. * generated/count_16_l.c: Regenerated. * generated/count_1_l.c: Regenerated. * generated/count_2_l.c: Regenerated. * generated/count_4_l.c: Regenerated. * generated/count_8_l.c: Regenerated. * generated/iall_i1.c: Regenerated. * generated/iall_i16.c: Regenerated. * generated/iall_i2.c: Regenerated. * generated/iall_i4.c: Regenerated. * generated/iall_i8.c: Regenerated. * generated/iany_i1.c: Regenerated. * generated/iany_i16.c: Regenerated. * generated/iany_i2.c: Regenerated. * generated/iany_i4.c: Regenerated. * generated/iany_i8.c: Regenerated. * generated/iparity_i1.c: Regenerated. * generated/iparity_i16.c: Regenerated. * generated/iparity_i2.c: Regenerated. * generated/iparity_i4.c: Regenerated. * generated/iparity_i8.c: Regenerated. * generated/maxloc0_16_i1.c: Regenerated. * generated/maxloc0_16_i16.c: Regenerated. * generated/maxloc0_16_i2.c: Regenerated. * generated/maxloc0_16_i4.c: Regenerated. * generated/maxloc0_16_i8.c: Regenerated. * generated/maxloc0_16_r10.c: Regenerated. * generated/maxloc0_16_r16.c: Regenerated. * generated/maxloc0_16_r4.c: Regenerated. * generated/maxloc0_16_r8.c: Regenerated. * generated/maxloc0_4_i1.c: Regenerated. * generated/maxloc0_4_i16.c: Regenerated. * generated/maxloc0_4_i2.c: Regenerated. * generated/maxloc0_4_i4.c: Regenerated. * generated/maxloc0_4_i8.c: Regenerated. * generated/maxloc0_4_r10.c: Regenerated. * generated/maxloc0_4_r16.c: Regenerated. * generated/maxloc0_4_r4.c: Regenerated. * generated/maxloc0_4_r8.c: Regenerated. * generated/maxloc0_8_i1.c: Regenerated. * generated/maxloc0_8_i16.c: Regenerated. * generated/maxloc0_8_i2.c: Regenerated. * generated/maxloc0_8_i4.c: Regenerated. * generated/maxloc0_8_i8.c: Regenerated. * generated/maxloc0_8_r10.c: Regenerated. * generated/maxloc0_8_r16.c: Regenerated. * generated/maxloc0_8_r4.c: Regenerated. * generated/maxloc0_8_r8.c: Regenerated. * generated/maxloc1_16_i1.c: Regenerated. * generated/maxloc1_16_i16.c: Regenerated. * generated/maxloc1_16_i2.c: Regenerated. * generated/maxloc1_16_i4.c: Regenerated. * generated/maxloc1_16_i8.c: Regenerated. * generated/maxloc1_16_r10.c: Regenerated. * generated/maxloc1_16_r16.c: Regenerated. * generated/maxloc1_16_r4.c: Regenerated. * generated/maxloc1_16_r8.c: Regenerated. * generated/maxloc1_4_i1.c: Regenerated. * generated/maxloc1_4_i16.c: Regenerated. * generated/maxloc1_4_i2.c: Regenerated. * generated/maxloc1_4_i4.c: Regenerated. * generated/maxloc1_4_i8.c: Regenerated. * generated/maxloc1_4_r10.c: Regenerated. * generated/maxloc1_4_r16.c: Regenerated. * generated/maxloc1_4_r4.c: Regenerated. * generated/maxloc1_4_r8.c: Regenerated. * generated/maxloc1_8_i1.c: Regenerated. * generated/maxloc1_8_i16.c: Regenerated. * generated/maxloc1_8_i2.c: Regenerated. * generated/maxloc1_8_i4.c: Regenerated. * generated/maxloc1_8_i8.c: Regenerated. * generated/maxloc1_8_r10.c: Regenerated. * generated/maxloc1_8_r16.c: Regenerated. * generated/maxloc1_8_r4.c: Regenerated. * generated/maxloc1_8_r8.c: Regenerated. * generated/maxval_i1.c: Regenerated. * generated/maxval_i16.c: Regenerated. * generated/maxval_i2.c: Regenerated. * generated/maxval_i4.c: Regenerated. * generated/maxval_i8.c: Regenerated. * generated/maxval_r10.c: Regenerated. * generated/maxval_r16.c: Regenerated. * generated/maxval_r4.c: Regenerated. * generated/maxval_r8.c: Regenerated. * generated/minloc0_16_i1.c: Regenerated. * generated/
[Bug tree-optimization/79981] Forwprop not working for __atomic_compare_exchange_n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79981 --- Comment #9 from Jakub Jelinek --- Author: jakub Date: Fri Mar 10 19:47:44 2017 New Revision: 246054 URL: https://gcc.gnu.org/viewcvs?rev=246054&root=gcc&view=rev Log: PR tree-optimization/79981 * tree-vrp.c (extract_range_basic): Handle IMAGPART_EXPR of ATOMIC_COMPARE_EXCHANGE ifn result. (stmt_interesting_for_vrp, vrp_visit_stmt): Handle IFN_ATOMIC_COMPARE_EXCHANGE. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vrp.c
[Bug middle-end/79992] accessing storage member of lambda via pointer with -no-pie causes the next function to overwrite the pointer's data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79992 --- Comment #1 from Yanai Eliyahu --- Created attachment 40943 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40943&action=edit the .cpp that has the bug
[Bug libstdc++/79511] Convertation issues in std::codecvt_utf8_utf16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79511
--- Comment #12 from Jonathan Wakely ---
And this is the fix for comment 3:
--- a/libstdc++-v3/src/c++11/codecvt.cc
+++ b/libstdc++-v3/src/c++11/codecvt.cc
@@ -315,7 +315,7 @@ namespace
{
static_assert(sizeof(C) >= 2, "a code unit must be at least 16-bit");
-if (codepoint < max_single_utf16_unit)
+if (codepoint <= max_single_utf16_unit)
{
if (to.size() > 0)
{
[Bug middle-end/79992] New: accessing storage member of lambda via pointer with -no-pie causes the next function to overwrite the pointer's data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79992 Bug ID: 79992 Summary: accessing storage member of lambda via pointer with -no-pie causes the next function to overwrite the pointer's data Product: gcc Version: 6.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: yanai.eli11 at gmail dot com Target Milestone: --- See attached file for code, and compile it with `-no-pie`; I tried `-fno-strict-aliasing -fwrapv` and the problem still reproduces. Language: C++ Exact GCC version: 6.2.0 20161005 (Ubuntu 6.2.0-5ubuntu12) OS: Ubuntu Overall the problem is that when getting a pointer of member of lambda in certain flow, the pointer will point to the stack, and provoke other functions to overwrite it. I proved it by printing the variable twice without a gap, and it printed something else the second time.
