[Bug tree-optimization/78692] [7 Regression] ICE (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78692 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-12-06 CC||jakub at gcc dot gnu.org Target Milestone|--- |7.0 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- I think it started with r236274 or around that (I get ICE first with r236276 but that must be some glitch in our bisect seed, because the first change appears in the inline ipa dump and is related to thunks).
[Bug middle-end/78689] [7 Regression] ICE (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78689
prathamesh3492 at gcc dot gnu.org changed:
What|Removed |Added
CC||prathamesh3492 at gcc dot
gnu.org
--- Comment #1 from prathamesh3492 at gcc dot gnu.org ---
Can also be reproduced with:
struct e {
e() {
goto aj;
if (0)
aj:;
}
};
void f()
{
struct e x;
}
bug.cpp: In constructor ‘e::e()’:
bug.cpp:2:3: internal compiler error: Segmentation fault
e() {
^
0xdcbccf crash_signal
../../gcc/gcc/toplev.c:333
0xe02e63 main_block_label
../../gcc/gcc/tree-cfg.c:1380
0xe06759 cleanup_dead_labels()
../../gcc/gcc/tree-cfg.c:1563
0xe13c57 build_gimple_cfg
../../gcc/gcc/tree-cfg.c:237
0xe13c57 execute_build_cfg
../../gcc/gcc/tree-cfg.c:396
0xe13c57 execute
../../gcc/gcc/tree-cfg.c:432
The segfault seems to occur because gimplifier seems to remove
"aj" label, along with the dead if condition.
gimple dump for e::e():
e::e() (struct e * const this)
{
goto aj;
}
Perhaps an issue with gimplification ?
Thanks,
Prathamesh
[Bug c++/78693] New: [6/7 Regression] Bogus 'inconsistent deduction for ‘auto’' error when having a dependent initializer and a nondependent one in the same declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78693
Bug ID: 78693
Summary: [6/7 Regression] Bogus 'inconsistent deduction for
‘auto’' error when having a dependent initializer and
a nondependent one in the same declaration
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
template
void foo (T t) {
auto i = t, j = 1;
}
prog.cc: In function 'void foo(T)':
prog.cc:3:3: error: inconsistent deduction for 'auto': 'auto' and then 'int'
auto i = t, j = 1;
^~~~
Accepted by GCC 5.3, Clang, MSVC (CL 19 on gcc.beta.godbolt.org, whatever that
corresponds to) and ICC 17 (but with a bogus warning). Rejected by 6.1 and 7
(on Wandbox).
[Bug tree-optimization/78692] [7 Regression] ICE (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78692 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 40263 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40263&action=edit gcc7-pr78692.patch Untested fix.
[Bug target/78694] New: [ARM] ICE with -mthumb -ftls-model=local-exec -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78694
Bug ID: 78694
Summary: [ARM] ICE with -mthumb -ftls-model=local-exec -O2
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sebastian.hu...@embedded-brains.de
Target Milestone: ---
Created attachment 40264
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40264&action=edit
Test case
The attached test case generates an ICE during GCC build (libgomp):
/build/git-build/b-gcc-git-arm-rtems4.12/./gcc/xgcc
-B/build/git-build/b-gcc-git-arm-rtems4.12/./gcc/ -mthumb
-ftls-model=local-exec -O2 -S task.i
/home/EB/sebastian_h/archive/gcc-git/libgomp/task.c: In function
'gomp_create_target_task':
/home/EB/sebastian_h/archive/gcc-git/libgomp/task.c:778:1: error: invalid rtl
sharing found in the insn
}
^
(insn 1584 1583 1585 (unspec_volatile [
(const:SI (unspec:SI [
(symbol_ref:SI ("gomp_tls_data") [flags 0xea] )
(const_int 4 [0x4])
] UNSPEC_TLS))
] VUNSPEC_POOL_4) -1
(nil))
/home/EB/sebastian_h/archive/gcc-git/libgomp/task.c:778:1: error: shared rtx
(const:SI (unspec:SI [
(symbol_ref:SI ("gomp_tls_data") [flags 0xea] )
(const_int 4 [0x4])
] UNSPEC_TLS))
/home/EB/sebastian_h/archive/gcc-git/libgomp/task.c:778:1: internal compiler
error: internal consistency failure
0x6852ed verify_rtx_sharing
/home/EB/sebastian_h/archive/gcc-git/gcc/emit-rtl.c:2751
0x68527a verify_rtx_sharing
/home/EB/sebastian_h/archive/gcc-git/gcc/emit-rtl.c:2784
0x68564b verify_insn_sharing
/home/EB/sebastian_h/archive/gcc-git/gcc/emit-rtl.c:2837
0x689d27 verify_rtl_sharing()
/home/EB/sebastian_h/archive/gcc-git/gcc/emit-rtl.c:2860
0x91872b execute_function_todo
/home/EB/sebastian_h/archive/gcc-git/gcc/passes.c:1982
0x919105 execute_todo
/home/EB/sebastian_h/archive/gcc-git/gcc/passes.c:2015
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug middle-end/78691] [7 Regression] ICE compiling Linux boot code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78691 --- Comment #4 from amker at gcc dot gnu.org --- Sorry for the problem, I will investigate it. Thanks,
[Bug tree-optimization/78675] [7 Regression] ICE: verify_gimple failed (error: integral result type precision does not match field size of BIT_FIELD_REF)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78675 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Tue Dec 6 09:21:13 2016 New Revision: 243283 URL: https://gcc.gnu.org/viewcvs?rev=243283&root=gcc&view=rev Log: 2016-12-06 Jakub Jelinek PR tree-optimization/78675 * tree-vect-loop.c (vectorizable_live_operation): For VECTOR_BOOLEAN_TYPE_P vectype use integral type with bitsize precision instead of TREE_TYPE (vectype) for the BIT_FIELD_REF. * gcc.c-torture/execute/pr78675.c: New test. * gcc.target/i386/pr78675-1.c: New test. * gcc.target/i386/pr78675-2.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr78675.c trunk/gcc/testsuite/gcc.target/i386/pr78675-1.c trunk/gcc/testsuite/gcc.target/i386/pr78675-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug c++/71537] GCC rejects consetxpr boolean conversions and comparisons on the result of pointer arithmetic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71537
--- Comment #13 from Jakub Jelinek ---
Author: jakub
Date: Tue Dec 6 09:22:36 2016
New Revision: 243284
URL: https://gcc.gnu.org/viewcvs?rev=243284&root=gcc&view=rev
Log:
PR c++/71537
* fold-const-call.c (fold_const_call): Handle
CFN_BUILT_IN_{INDEX,STRCHR,RINDEX,STRRCHR}.
* g++.dg/cpp0x/constexpr-strchr.C: New test.
Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-strchr.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/fold-const-call.c
trunk/gcc/testsuite/ChangeLog
[Bug c++/71537] GCC rejects consetxpr boolean conversions and comparisons on the result of pointer arithmetic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71537 --- Comment #14 from Jakub Jelinek --- Author: jakub Date: Tue Dec 6 09:23:51 2016 New Revision: 243285 URL: https://gcc.gnu.org/viewcvs?rev=243285&root=gcc&view=rev Log: 2016-12-06 Jakub Jelinek PR c++/71537 * fold-const-call.c (fold_const_call_1): Remove memchr handling here. (fold_const_call) : Formatting improvements. (fold_const_call) : Likewise. If s2 is 0 and arguments have no side-effects, return 0. (fold_const_call): Handle CFN_BUILT_IN_MEMCHR. * g++.dg/cpp0x/constexpr-memchr.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-memchr.C Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const-call.c trunk/gcc/testsuite/ChangeLog
[Bug c++/71537] GCC rejects consetxpr boolean conversions and comparisons on the result of pointer arithmetic.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71537 --- Comment #15 from Jakub Jelinek --- Author: jakub Date: Tue Dec 6 09:24:36 2016 New Revision: 243286 URL: https://gcc.gnu.org/viewcvs?rev=243286&root=gcc&view=rev Log: PR c++/71537 * fold-const.c (fold_comparison): Assume CONSTANT_CLASS_P (base0) plus offset is non-zero. For maybe_nonzero_address decl base0, require indirect_base0. * g++.dg/cpp0x/constexpr-71537.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-71537.C Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog
[Bug target/78694] [ARM] ICE with -mthumb -ftls-model=local-exec -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78694 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #1 from ktkachov at gcc dot gnu.org --- what is the configuration you're trying to build?
[Bug c/78365] [7 Regression] ICE in determine_value_range, at tree-ssa-loo p-niter.c:413
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78365 Jakub Jelinek changed: What|Removed |Added CC||doko at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- *** Bug 78681 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/78681] [7 Regressions] ICE in determine_value_range, at tree-ssa-loop-niter.c:413
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78681 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #5 from Jakub Jelinek --- Dup. *** This bug has been marked as a duplicate of bug 78365 ***
[Bug target/78694] [ARM] ICE with -mthumb -ftls-model=local-exec -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78694 --- Comment #2 from Sebastian Huber --- (In reply to ktkachov from comment #1) > what is the configuration you're trying to build? A bare metal ARM EABI compiler should reproduce the problem. I try to build the arm-rtems4.12-gcc with a patch to enable use of thread-local storage. See also: https://gcc.gnu.org/ml/gcc/2016-12/msg00010.html
[Bug target/78694] [ARM] ICE with -mthumb -ftls-model=local-exec -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78694 --- Comment #3 from ktkachov at gcc dot gnu.org --- I can't reproduce on an arm-none-eabi compiler built with RTL checking. Do you pass any particular --with-arch/cpu/fpu/float options?
[Bug target/77493] [6/7 Regression] -fcrossjumping (-O2) on ppc64le causes segfaults (jump to 0x0) (first bad r230091)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77493
Aldy Hernandez changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2016-12-06
CC||aldyh at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #15 from Aldy Hernandez ---
David, could you verify that this is still happening on trunk?
I can't reproduce on a ppc64le box with a stage1 build. Compilation succeeds:
$ ~/gcc/configure --disable-multilib --disable-bootstrap
$ make all-gcc
$ cd gcc
$ ./xg++ -B./ -O2 ~/MuonTrajectoryUpdator2.ii -c -w
/home/aldyh/MuonTrajectoryUpdator2.ii: In instantiation of ‘class
Basic2DVector’:
/home/aldyh/MuonTrajectoryUpdator2.ii:47851:11: required from here
/home/aldyh/MuonTrajectoryUpdator2.ii:47371:7: note: the layout of aggregates
containing vectors with 32-byte alignment has changed in GCC 5
class Basic2DVector {
^
$
But perhaps what you are mean is that there is a segfault executing your
program, not compiling it. In which case, could you reduce your testcase (a
lot :)), and provide a standalone testcase that runs, that we could use to
reproduce the problem?
[Bug middle-end/78691] [7 Regression] ICE compiling Linux boot code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78691 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |7.0 --- Comment #5 from Jakub Jelinek --- The #c1 testcase ICEs even with -m32 -Os on x86_64-linux. ICE started with r243180.
[Bug c++/78690] [7 Regression] ICE in cxx_incomplete_type_diagnostic, at cp/typeck2.c:552
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78690 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-12-06 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |7.0 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek --- Started with r236221.
[Bug c++/78690] [7 Regression] ICE in cxx_incomplete_type_diagnostic, at cp/typeck2.c:552
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78690 Jakub Jelinek changed: What|Removed |Added Keywords||ice-on-invalid-code --- Comment #2 from Jakub Jelinek --- This is before the first (previously only) error is emitted, so it isn't error-recovery bug.
[Bug c/78666] conflicting attribute alloc_size accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78666 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug middle-end/78566] [7 regression] gcc.dg/uninit-pred-6_[abc]*.c regressions on some non-x86 platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78566 --- Comment #5 from Aldy Hernandez --- Author: aldyh Date: Tue Dec 6 10:33:41 2016 New Revision: 243288 URL: https://gcc.gnu.org/viewcvs?rev=243288&root=gcc&view=rev Log: PR middle-end/78566 * tree-ssa-uninit.c (can_one_predicate_be_invalidated_p): Change argument type to a pred_chain. (can_chain_union_be_invalidated_p): Use pred_chain instead of a worklist. (flatten_out_predicate_chains): Remove. (uninit_uses_cannot_happen): Rename from uninit_ops_invalidate_phi_use. Change logic so that we are checking that the PHI use will invalidate _ALL_ possibly uninitialized operands. (is_use_properly_guarded): Rename call to uninit_ops_invalidate_phi_use into uninit_uses_cannot_happen. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-uninit.c
[Bug middle-end/78548] [7 Regression ]ICE on valid C code on x86_64-linux-gnu at -O2 and -O3 in 64-bit mode with -Wall (*** Error in `/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/cc1': d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78548 --- Comment #8 from Aldy Hernandez --- Author: aldyh Date: Tue Dec 6 10:35:37 2016 New Revision: 243289 URL: https://gcc.gnu.org/viewcvs?rev=243289&root=gcc&view=rev Log: PR middle-end/78548 * tree-ssa-uninit.c (simplify_preds_4): Call release() instead of destroy_predicate_vecs. (uninit_uses_cannot_happen): Make uninit_preds a scalar. Added: trunk/gcc/testsuite/gcc.dg/uninit-pr78548.c Modified: trunk/gcc/ChangeLog trunk/gcc/tree-ssa-uninit.c
[Bug middle-end/78566] [7 regression] gcc.dg/uninit-pred-6_[abc]*.c regressions on some non-x86 platforms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78566 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Aldy Hernandez --- Fixed.
[Bug middle-end/78548] [7 Regression ]ICE on valid C code on x86_64-linux-gnu at -O2 and -O3 in 64-bit mode with -Wall (*** Error in `/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.0/cc1': d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78548 Aldy Hernandez changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Aldy Hernandez --- Fixed.
[Bug middle-end/78689] [7 Regression] ICE (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78689 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-12-06 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |7.0 Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Started with r241765, though this is in C++11, not C++17, and it ICEs with -fno-new-inheriting-ctors as well as -fnew-inheriting-ctors. Reverting just the tree-inline.c hunks fixed this. Thinking about it, it is unsafe not to copy the untaken branch, exactly because it can be entered through goto from other parts of the code. So, either we need some flag on the COND_EXPR from the FE that would guarantee that the non-taken if branch is not entered through labels, or e.g. search it for user labels and if there are any, don't do this? Do you have a testcase for which the tree-inline.c change was needed? I've tried to make check-c++-all RUNTESTFLAGS=dg.exp=*inh*ct* with the tree-inline.c change reverted and saw no failures. It would be good to know if in the if (is_base_ctor) guarded code you can actually have user labels or not. If not, I can handle this easily in tree-inline.c. If yes, then we need to fix it differently.
[Bug c++/78655] gcc doesn't exploit the fact that the result of pointer addition can not be nullptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78655
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-12-06
CC||law at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Confirmed. It might be possible to rely on this nowadays where we make sure
not to transform uintptr_t arithmetic to pointer arithmetic in the IL.
I think that even nullptr + X is invalid.
But for the testcase we'd require threading the jump across the
backedge (FSM threading is not looking at get_ptr_nonnull ()).
VRP parts:
@@ -1145,6 +1147,13 @@ vrp_stmt_computes_nonzero (gimple *stmt,
}
}
+ if (flag_delete_null_pointer_checks
+ && is_gimple_assign (stmt)
+ && is_gimple_assign (stmt)
+ && gimple_assign_rhs_code (stmt) == POINTER_PLUS_EXPR
+ && tree_expr_nonzero_p (gimple_assign_rhs2 (stmt)))
+return true;
+
return false;
}
@@ -4873,7 +4854,13 @@ infer_value_range (gimple *stmt, tree op
return false;
}
- if (infer_nonnull_range (stmt, op))
+ if (infer_nonnull_range (stmt, op)
+ /* PTR + X with X != 0 is invalid when PTR is a null pointer. */
+ || (flag_delete_null_pointer_checks
+ && is_gimple_assign (stmt)
+ && gimple_assign_rhs1 (stmt) == op
+ && gimple_assign_rhs_code (stmt) == POINTER_PLUS_EXPR
+ && tree_expr_nonzero_p (gimple_assign_rhs2 (stmt
{
*val_p = build_int_cst (TREE_TYPE (op), 0);
*comp_code_p = NE_EXPR;
Of course I wonder why the check is here in the first place... Is placement
new valid for nullptr?
[Bug c/78657] Using macro with _Pragma gives error: '#pragma' is not allowed here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78657 --- Comment #1 from Richard Biener --- This isn't how preprocessing works I think (thus INVALID)
[Bug sanitizer/78663] [7 Regression] Hundreds of asan failures on x86_64-apple-darwin10 at r243019
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78663 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0
[Bug tree-optimization/78675] [7 Regression] ICE: verify_gimple failed (error: integral result type precision does not match field size of BIT_FIELD_REF)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78675 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug preprocessor/78680] [7 Regression] ICE in get_substring_ranges_for_loc, at input.c:1398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78680 Richard Biener changed: What|Removed |Added Component|other |preprocessor Target Milestone|--- |7.0 --- Comment #1 from Richard Biener --- Can you try reducing a set of files to reproduce it?
[Bug middle-end/78684] [7 Regression] ICE in create_intersect_range_checks_index, at tree-vect-loop-manip.c:2074
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78684 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0
[Bug target/78694] [ARM] ICE with -mthumb -ftls-model=local-exec -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78694
--- Comment #4 from Sebastian Huber ---
(In reply to ktkachov from comment #3)
> I can't reproduce on an arm-none-eabi compiler built with RTL checking. Do
> you pass any particular --with-arch/cpu/fpu/float options?
I built an arm-eabi-gcc using GCC version
1e15f9a7488be0a7446c364b93430d20621af476.
I get:
arm-eabi-gcc -mthumb -ftls-model=local-exec -O2 -S task.i
/home/EB/sebastian_h/archive/gcc-git/libgomp/task.c: In function
‘gomp_create_target_task’:
/home/EB/sebastian_h/archive/gcc-git/libgomp/task.c:778:1: error: invalid rtl
sharing found in the insn
}
^
(insn 1584 1583 1585 (unspec_volatile [
(const:SI (unspec:SI [
(symbol_ref:SI ("gomp_tls_data") [flags 0xea] )
(const_int 4 [0x4])
] UNSPEC_TLS))
] VUNSPEC_POOL_4) -1
(nil))
/home/EB/sebastian_h/archive/gcc-git/libgomp/task.c:778:1: error: shared rtx
(const:SI (unspec:SI [
(symbol_ref:SI ("gomp_tls_data") [flags 0xea] )
(const_int 4 [0x4])
] UNSPEC_TLS))
/home/EB/sebastian_h/archive/gcc-git/libgomp/task.c:778:1: internal compiler
error: internal consistency failure
0x80f8dd verify_rtx_sharing
/home/EB/sebastian_h/archive/gcc-git/gcc/emit-rtl.c:2751
0x80f86a verify_rtx_sharing
/home/EB/sebastian_h/archive/gcc-git/gcc/emit-rtl.c:2784
0x80fc3b verify_insn_sharing
/home/EB/sebastian_h/archive/gcc-git/gcc/emit-rtl.c:2837
0x814317 verify_rtl_sharing()
/home/EB/sebastian_h/archive/gcc-git/gcc/emit-rtl.c:2860
0xaa2deb execute_function_todo
/home/EB/sebastian_h/archive/gcc-git/gcc/passes.c:1982
0xaa37e5 execute_todo
/home/EB/sebastian_h/archive/gcc-git/gcc/passes.c:2015
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
[Bug debug/78685] -Og generates too many ""s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-12-06 CC||jakub at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- I think it shows that the call-site-parameter stuff doesn't work across one indirection. In call_debugger we want count at the call site but that's only available at its call site it seems. For main() we're unlucky with the register allocation and as the original args are not spilled we're lost (and libc or the crtstuff doesn't have any call-site param stuff - not sure if that would help in this case). So yes, -Og does optimize. Confirmed (for the testcase).
[Bug middle-end/78684] [7 Regression] ICE in create_intersect_range_checks_index, at tree-vect-loop-manip.c:2074
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78684 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-12-06 CC||jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Started with r240412.
[Bug c++/78693] [6/7 Regression] Bogus 'inconsistent deduction for ‘auto’' error when having a dependent initializer and a nondependent one in the same declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78693 Richard Biener changed: What|Removed |Added Target Milestone|--- |6.3
[Bug middle-end/78691] [7 Regression] ICE compiling Linux boot code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78691 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug middle-end/78689] [7 Regression] ICE (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78689 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug target/78695] New: [7 Regression] ICE (segfault) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78695
Bug ID: 78695
Summary: [7 Regression] ICE (segfault) on powerpc64le-linux-gnu
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
Target Milestone: ---
seen with 243219 on powerpc64le-linux-gnu, works with -O2
$ cat cgm.i
void *a();
long b() {
char c[1];
char *d = a(), *e = c;
long f = e ? b(e) : 0;
if (f > 54)
f = 1;
while (f--)
*d++ = *e++;
}
$ gcc -c -O3 cgm.i
cgm.i: In function 'b':
cgm.i:10:1: internal compiler error: Segmentation fault
}
^
0x10756733 crash_signal
../../src/gcc/toplev.c:333
0x10a52ec8 find_alignment_op
../../src/gcc/config/rs6000/rs6000.c:41428
0x10aa2663 recombine_lvx_pattern
../../src/gcc/config/rs6000/rs6000.c:41451
0x10aa2663 recombine_lvx_stvx_patterns
../../src/gcc/config/rs6000/rs6000.c:41557
0x10aa2663 rs6000_analyze_swaps(function*)
../../src/gcc/config/rs6000/rs6000.c:41598
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug middle-end/78684] [7 Regression] ICE in create_intersect_range_checks_index, at tree-vect-loop-manip.c:2074
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78684 Jakub Jelinek changed: What|Removed |Added CC||amker at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- neg_step is true, because DR_STEP (dr_a.dr) is (ssizetype) -8. But idx_step is 0xUL. Note tree_int_cst_compare (idx_step, size_zero_node) < 0 is just weird, why don't you use tree_int_cst_sgn?
[Bug tree-optimization/78687] inefficient code generated for eggs.variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78687
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-12-06
CC||jamborm at gcc dot gnu.org,
||rguenth at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Trunk rejects it with (might be worth another bug?)
t.C: In function ‘ref_proxy >
make_object_4(ref_proxy >&&)’:
t.C:469:39: error: conversion from ‘inplace_ref’ to
‘ref_proxy >’ is ambiguous
return make_object_3(std::move(a0));
^
t.C:394:8: note: candidate: constexpr
inplace_ref::inplace_ref(const inplace_ref&)
struct inplace_ref
^~~
t.C:380:17: note: inherited here
using Base::Base;
^~~~
t.C:394:8: note: candidate: constexpr
inplace_ref::inplace_ref(inplace_ref&&)
struct inplace_ref
^~~
t.C:380:17: note: inherited here
using Base::Base;
^~~~
t.C:387:5: note: candidate: ref_proxy::ref_proxy(Base) [with T =
qual_option; Base = inplace_ref]
ref_proxy(Base ptr)
^
Confirmed with GCC 6.2 - we have quite many aggregate temporaries not optimized
away:
__attribute__((noinline))
ref_proxy > f() ()
{
struct qual_optionD.34988 D.41115;
struct ref_proxyD.34990 D.41114;
struct qual_optionD.34988 innerD.41113;
struct ref_proxyD.34990 typeD.4;
struct ref_proxyD.34990 typeD.41112;
struct ref_proxyD.36874 D.41109;
struct ref_proxyD.36874 ptrD.41110;
struct inplace_refD.37561 D.41107;
struct inplace_refD.37561 ptrD.41106;
:
MEM[(struct ref_proxyD.36874 *)&D.41109 + 40B] = 2;
ptrD.41110 = D.41109;
MEM[(struct &)&D.41114] ={v} {CLOBBER};
MEM[(struct variantD.35001 *)&ptrD.41110 + 40B] = 2;
MEM[(struct variant_refD.34986 *)&D.41114].inner_storage_D.35021 =
ptrD.41110.D.36914.inner_storage_D.35021;
MEM[(struct ref_proxyD.34990 *)&D.41114 + 40B] = 2;
typeD.4 = D.41114;
MEM[(struct ref_proxyD.34990 *)&typeD.4 + 40B] = 2;
typeD.41112 = typeD.4;
MEM[(struct &)&D.41115] ={v} {CLOBBER};
MEM[(struct ref_proxyD.34990 *)&typeD.41112 + 40B] = 2;
D.41115.type_D.36509 = typeD.41112;
MEM[(struct qual_optionD.34988 *)&D.41115 + 40B] = 2;
MEM[(struct qual_optionD.34988 *)&D.41115 + 48B] = 0;
innerD.41113 = D.41115;
MEM[(struct &)&D.41107] ={v} {CLOBBER};
MEM[(struct qual_optionD.34988 *)&innerD.41113 + 48B] = 0;
D.41107.inner_D.37568 = innerD.41113;
D.41115 ={v} {CLOBBER};
D.41114 ={v} {CLOBBER};
MEM[(struct inplace_refD.37561 *)&D.41107 + 48B] = 0;
ptrD.41106 = D.41107;
MEM[(struct &)&] ={v} {CLOBBER};
MEM[(struct inplace_refD.37561 *)&ptrD.41106 + 48B] = 0;
.D.37651 = ptrD.41106;
return ;
}
it usually is SRAs job to do this but it seems to fail in this case:
:
MEM[(struct &)&D.37695] ={v} {CLOBBER};
SR.31_24 = 2;
MEM[(struct ref_proxyD.36874 *)&D.41109 + 40B] = SR.31_24;
SR.34_26 = SR.31_24;
MEM[(struct ref_proxyD.36874 *)&D.41109 + 40B] = SR.34_26;
ptrD.41110 = D.41109;
^^^ aggregate copy not scalarized
ptr$D36914$inner_storage_$_storage$_which_28 = SR.34_26;
MEM[(struct &)&D.41114] ={v} {CLOBBER};
MEM[(struct variantD.35001 *)&ptrD.41110 + 40B] =
ptr$D36914$inner_storage_$_storage$_which_28;
in fact ptrD.41110 is not scalarized at all. Looks like the init from D.41109
makes us fail here.
Martin?
[Bug target/78695] [7 Regression] ICE (segfault) on powerpc64le-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78695 Richard Biener changed: What|Removed |Added Target Milestone|--- |7.0
[Bug target/78694] [ARM] ICE with -mthumb -ftls-model=local-exec -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78694 --- Comment #5 from ktkachov at gcc dot gnu.org --- I cannot reproduce with that revision. Again, how do you configure your gcc. What is the output of arm-eabi-gcc -v that you built?
[Bug target/78694] [ARM] ICE with -mthumb -ftls-model=local-exec -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78694 --- Comment #6 from Sebastian Huber --- (In reply to ktkachov from comment #5) > I cannot reproduce with that revision. > Again, how do you configure your gcc. > What is the output of arm-eabi-gcc -v that you built? arm-eabi-gcc -v Using built-in specs. COLLECT_GCC=arm-eabi-gcc COLLECT_LTO_WRAPPER=/scratch/install-arm-eabi/lib/gcc/arm-eabi/7.0.0/lto-wrapper Target: arm-eabi Configured with: /home/EB/sebastian_h/archive/gcc-git/configure --prefix=/scratch/install-arm-eabi --target=arm-eabi --verbose --enable-languages=c --disable-multilib Thread model: single gcc version 7.0.0 20161206 (experimental) [master revision c59a180:88a522b:8c1527e8f37c8e80912aa3a465d623381aaa41e0] (GCC)
[Bug preprocessor/78680] [7 Regression] ICE in get_substring_ranges_for_loc, at input.c:1398
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78680
Markus Trippelsdorf changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2016-12-06
CC||trippels at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #2 from Markus Trippelsdorf ---
x4 tcptrace-6.6.7 # cat snoop.c
void fn1() {
__builtin_printf("\
%ld.\n\
2\n"); };
x4 tcptrace-6.6.7 # gcc -Wall snoop.c
snoop.c: In function ‘fn1’:
snoop.c:2:3: internal compiler error: in get_substring_ranges_for_loc, at
input.c:1398
[Bug debug/78685] -Og generates too many ""s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685 --- Comment #2 from Jakub Jelinek --- If -Og does not force user variables/parameters to stack nor forces an artificial use of the var at the end of their scope, then it will always happen, the rest is purely best effort, see if the var value can be computed from something else and punt if it can't. The problem is mainly register allocation, if the var is seen by RA as dead after certain point, then the RA doesn't try to keep it alive in some register or memory. In particular on this testcase, DW_OP_GNU_entry_value is emitted (as last resort) for the count variable, and similarly for argc in main (again, it isn't used after the function call). So, in this particular case it might help if glibc tried to provide better debug info for __libc_start_main and/or _start (if the argc and/or argv values can be easily computed; though, e.g. computing argc from argv array might not be correct, because main could have changed it). For the potential -Og change to be more useful, it would mean adding some artificial stmts at the end of scope of user vars (e.g. where we poison vars for -fsanitize-user-after-scope) that would not expand into a real assembly insn(s), but something like (use (var)) and would convince the RA to keep them alive somewhere.
[Bug middle-end/77484] [6/7 Regression] Static branch predictor causes ~6-8% regression of SPEC2000 GAP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484 --- Comment #10 from wilco at gcc dot gnu.org --- (In reply to Jan Hubicka from comment #9) > Created attachment 40217 [details] > predict > > Hi, > here is patch adding the polymorphic case, too. > > Honza Looks good - gap still improves by 12%, SPECINT2k by 0.5%, SPECFP2k flat. So that fixes this issue.
[Bug debug/78685] -Og generates too many ""s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685 --- Comment #3 from rguenther at suse dot de --- On Tue, 6 Dec 2016, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685 > > --- Comment #2 from Jakub Jelinek --- > If -Og does not force user variables/parameters to stack nor forces an > artificial use of the var at the end of their scope, then it will always > happen, the rest is purely best effort, see if the var value can be computed > from something else and punt if it can't. The problem is mainly register > allocation, if the var is seen by RA as dead after certain point, then the RA > doesn't try to keep it alive in some register or memory. > In particular on this testcase, DW_OP_GNU_entry_value is emitted (as last > resort) for the count variable, and similarly for argc in main (again, it > isn't > used after the function call). > So, in this particular case it might help if glibc tried to provide better > debug info for __libc_start_main and/or _start (if the argc and/or argv values > can be easily computed; though, e.g. computing argc from argv array might not > be correct, because main could have changed it). > For the potential -Og change to be more useful, it would mean adding some > artificial stmts at the end of scope of user vars (e.g. where we poison vars > for -fsanitize-user-after-scope) that would not expand into a real assembly > insn(s), but something like (use (var)) and would convince the RA to keep them > alive somewhere. I guess that wouldn't stop at calls but if we want to avoid for locals we could add artificial uses for all vars where they go out of scope... Sth orthogonal to -Og, -fkeep-vars-live=N with some level, default to N > 0 for -Og maybe. Of course it will likely pessimize code as I don't see how we can easily compute whether var-tracking might reverse compute a vars value from sth else.
[Bug tree-optimization/78696] New: [7 Regression] -fprintf-return-value misoptimizes %.Ng where N is greater than 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78696
Bug ID: 78696
Summary: [7 Regression] -fprintf-return-value misoptimizes %.Ng
where N is greater than 10
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jgreenhalgh at gcc dot gnu.org
Target Milestone: ---
For this testcase:
#include
int __attribute__ ((noinline))
wrap_snprintf (char *buffer, size_t size, double value)
{
int ret = snprintf(buffer, size, "%.17g", value);
return ret;
}
int main ()
{
char x[100] = {0};
char y[100] = {0};
int ret = wrap_snprintf (x, 100, 1.0);
int ret2 = wrap_snprintf (y, 100, -1.0);
printf ("%d\t%s\n%d\t%s\n", ret, x, ret2, y);
}
GCC trunk will create (-O3) a binary which prints:
191
19-1
Which is wrong.
GCC 5, and trunk with -fno-printf-return-value prints
1 1
2 -1
The choice of 1.0 is not special, GCC always assumes the size of the string
which will be printed by "%.17g" will be 19 characters long, and optimizes the
return value of wrap_snprintf to 19. 19 is the correct maximum length of the
string, but not the minimum, so this optimization is invalid.
Interestingly, for "%.10g", "%.9g" etc. trunk gets this right. It is "%.11g"
and above that cause issues.
[Bug tree-optimization/78696] [7 Regression] -fprintf-return-value misoptimizes %.Ng where N is greater than 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78696 James Greenhalgh changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-12-06 CC||msebor at gcc dot gnu.org Ever confirmed|0 |1
[Bug debug/78685] -Og generates too many ""s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78685 --- Comment #4 from Jakub Jelinek --- (In reply to rguent...@suse.de from comment #3) > Sth orthogonal to -Og, -fkeep-vars-live=N with some level, default > to N > 0 for -Og maybe. > > Of course it will likely pessimize code as I don't see how we can > easily compute whether var-tracking might reverse compute a vars > value from sth else. Yes, trying to guess whether var-tracking will be able to figure something out is pretty much impossible, perhaps except for easiest cases e.g. where one var is some other user var + const or something similar. And sure, it would pessimize code a lot.
[Bug tree-optimization/78696] [7 Regression] -fprintf-return-value misoptimizes %.Ng where N is greater than 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78696 Markus Trippelsdorf changed: What|Removed |Added Keywords||wrong-code CC||trippels at gcc dot gnu.org --- Comment #1 from Markus Trippelsdorf --- I'm afraid that there might be many more issues of the same kind. I think -fprintf-return-value shouldn't be enabled by default.
[Bug tree-optimization/78687] inefficient code generated for eggs.variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78687 --- Comment #2 from Jakub Jelinek --- >From looking at the testcase, I think it is solely SRA that can help here, if it manages to scalarize everything, we are good, if not, you get terrible code. The classes are huge and largely uninitialized, as can be seen on the llvm's optimized code (first 40 bytes uninitialized, then 12 bytes initialized).
[Bug tree-optimization/78687] inefficient code generated for eggs.variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78687 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- (In reply to Richard Biener from comment #1) > Trunk rejects it with (might be worth another bug?) I can't reproduce that, at least not with trunk from last night, it compiles just fine for me (but SRA doesn't optimize it fully).
[Bug libstdc++/78442] [variant] std::get<...>(Variant) is not constexpr.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78442 Tim Shen changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Tim Shen --- Fixed by r243293.
[Bug tree-optimization/78696] [7 Regression] -fprintf-return-value misoptimizes %.Ng where N is greater than 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78696 Vidya Praveen changed: What|Removed |Added Target||aarch64-none-linux-gnu CC||vp at gcc dot gnu.org Severity|normal |major
[Bug tree-optimization/78696] [7 Regression] -fprintf-return-value misoptimizes %.Ng where N is greater than 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78696 James Greenhalgh changed: What|Removed |Added Target|aarch64-none-linux-gnu |*-*-* --- Comment #2 from James Greenhalgh --- Not an AArch64-specific bug, this will affect everybody.
[Bug tree-optimization/78687] inefficient code generated for eggs.variant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78687 --- Comment #4 from rguenther at suse dot de --- On Tue, 6 Dec 2016, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78687 > > --- Comment #2 from Jakub Jelinek --- > From looking at the testcase, I think it is solely SRA that can help here, if > it manages to scalarize everything, we are good, if not, you get terrible > code. > The classes are huge and largely uninitialized, as can be seen on the llvm's > optimized code (first 40 bytes uninitialized, then 12 bytes initialized). I guess the main issue is that SRA is not flow-sensitive so it would need to materialize all aggregate elements as replacement (later DCE would clean up of course). For this case it's easy though -- only parts of the structures are ever written to (the aggregate assignment might confuse SRA enough here though)
[Bug tree-optimization/78696] [7 Regression] -fprintf-return-value misoptimizes %.Ng where N is greater than 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78696 Richard Biener changed: What|Removed |Added Version|unknown |7.0 Target Milestone|--- |7.0
[Bug tree-optimization/78696] [7 Regression] -fprintf-return-value misoptimizes %.Ng where N is greater than 10
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78696
--- Comment #3 from Jakub Jelinek ---
The g/G handling looks indeed totally broken, not just for the > 10 precisions,
even for %.9g it assumes it will be in between 11 and 13 characters, which is
of course wrong.
But even generally, for all floating point printing, it seems the code doesn't
take into account that various parts of the floating point printing are derived
from locale and might not always have the same size.
Consider:
#include
#include
int __attribute__ ((noinline))
foo (char *x, size_t y, double z)
{
return __builtin_snprintf (x, y, "%.2f", z);
}
int
main ()
{
char x[100], y[100];
setlocale (LC_ALL, "");
int ret = foo (x, 100, 1.5);
int ret2 = foo (y, 100, -1.5);
__builtin_printf ("%d\t%s\n%d\t%s\n", ret, x, ret2, y);
return 0;
}
This prints (with -fno-printf-return-value) in LC_ALL=C as well as
LC_ALL=en_US.UTF-8:
4 1.50
5 -1.50
in LC_ALL=cs_CZ.UTF-8:
4 1,50
5 -1,50
(note, comma used instead of dot, but still the same size), but with
ps_AF.UTF-8 it prints:
5 1٫50
6 -1٫50
because the Pashto decimal point character is U+066B, which is 2 bytes in
UTF-8.
For floating point printing, there can be also thousands grouping etc., again
locale specific.
[Bug middle-end/67335] [6 Regression] ICE in compiling omp simd function with unused argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67335 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/71182] [6/7 Regression] parser.c cp_lexer_previous_token sanitizer detects member call on null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71182 Richard Biener changed: What|Removed |Added Keywords||diagnostic Status|NEW |WAITING --- Comment #3 from Richard Biener --- Can't reproduce on trunk or GCC 6 branch. What options are required?
[Bug libstdc++/71856] [6/7 Regression] _GLIBCXX_DEBUG-mode breaks GNU parallel extension
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71856 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/72808] [6 Regression] ICE on valid c++ code in verify_type (gcc/tree.c:14047)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72808 Richard Biener changed: What|Removed |Added Priority|P3 |P2 Version|unknown |6.1.0
[Bug c++/72813] [6/7 Regression] atomic header cannot be compiled into translation unit with -fkeep-inline-functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72813 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/77284] [5/6/7 Regression] ICE on valid C++11 code using initializer list: in potential_constant_expression_1, at cp/constexpr.c:5480
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77284 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug c++/77347] [6/7 Regression] Incorrect auto deduction failure in template class member function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77347 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/77483] [6/7 regression] gcc.target/i386/mask-unpack.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77483 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|6.4 |6.3 --- Comment #8 from Richard Biener --- Fixed.
[Bug c++/77482] [6 Regression] Segfault when compiling ill-formed constexpr code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77482 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug middle-end/77484] [6/7 Regression] Static branch predictor causes ~6-8% regression of SPEC2000 GAP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[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 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/77591] [6 Regression] decltype(auto) and ternary operator allow returning local reference without a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77591 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/77626] [6 Regression] ICE with -Wall on x86_64-linux-gnu (internal compiler error: Segmentation fault, byte_from_pos, cxx_fold_indirect_ref)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77626 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug c++/71182] [6/7 Regression] parser.c cp_lexer_previous_token sanitizer detects member call on null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71182 --- Comment #4 from Markus Trippelsdorf --- (In reply to Richard Biener from comment #3) > Can't reproduce on trunk or GCC 6 branch. What options are required? You need to use an -fsanitize=undefined instrumented compiler. No options required.
[Bug c++/77639] [6 Regression] ICE on x86_64-linux-gnu (internal compiler error: tree check: accessed elt 1 of tree_vec with 0 elts in unify, at cp/pt.c:19674)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77639 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug c++/77907] [6 Regression] Add "const" to argument of constexpr constructor causes the object to be left in unconstructed state
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77907 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug target/77957] [5/6 Regression] Undefined .LCTOC0 with -fstack-protector-strong -mminimal-toc -O0 on ppc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77957 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug fortran/77973] [6 Regression] ICE in scan_omp_1_op, at omp-low.c:3841
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77973 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/77975] [6/7 Regression] Missed optimization for some small constants
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77975 Richard Biener changed: What|Removed |Added Priority|P3 |P2 CC||rguenth at gcc dot gnu.org
[Bug tree-optimization/78224] [5/6 Regression] g++ ICE at -O2(-O1 on gcc6) and above in verify_loop_structure, at cfgloop.c:1646
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78224 Richard Biener changed: What|Removed |Added CC||ncopa at alpinelinux dot org --- Comment #6 from Richard Biener --- *** Bug 78004 has been marked as a duplicate of this bug. ***
[Bug lto/78407] [5/6/7 Regression] LTO breaks separate overriding of symbol aliases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78407 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/78004] [6/7 Regression] g++ segfaults when compiling qt 4.8.7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78004 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #10 from Richard Biener --- Dup. *** This bug has been marked as a duplicate of bug 78224 ***
[Bug fortran/78299] [6 Regression] ICE in expand_omp_for_static_nochunk, at omp-low.c:9622
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78299 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug middle-end/78540] [6 Regression] ICE: in df_refs_verify, at df-scan.c:4062 with -O -march=core2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78540 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/78343] [6 Regression] Loop is not eliminated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78343 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/78550] [6/7 Regression] bit field and std::initializer_list
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78550 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/78542] [6 Regression] wrong code at -Og results in endless loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78542 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug rtl-optimization/78580] [6/7 Regression] Segfault in gcc with multilib (-m32) and -ffixed-*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78580 Richard Biener changed: What|Removed |Added Target||i?86-*-* Priority|P3 |P2
[Bug c++/78572] [6/7 Regression] internal compiler error: in output_constructor_regular_field, at varasm.c:4968
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78572 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug middle-end/77484] [6/7 Regression] Static branch predictor causes ~6-8% regression of SPEC2000 GAP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77484 --- Comment #11 from Martin Liška --- I'm planning to run SPEC benchmarks late this week to find a proper value for the new predictor.
[Bug target/77439] [6/7 regression] wrong code for sibcall with longcall, APCS frame and VFP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77439 Richard Biener changed: What|Removed |Added Keywords||wrong-code Priority|P1 |P2
[Bug target/77728] [5/6/7 Regression] Miscompilation multiple vector iteration on ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77728 Richard Biener changed: What|Removed |Added Priority|P1 |P2
[Bug target/78255] [5/6/7 regression] Indirect sibling call causing wrong code generation for ARM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78255 Richard Biener changed: What|Removed |Added Priority|P1 |P2
[Bug tree-optimization/78428] [5/6/7 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=78428 Richard Biener changed: What|Removed |Added Priority|P1 |P2
[Bug target/78509] [7 regression] ICE in in excess_precision_type, at tree.c:8875
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78509 --- Comment #14 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #13 from Jakub Jelinek --- > I don't have a box with 3dnow, but the assembly for -m32 -O2 -m3dnow -mno-sse > pr42549.c looks identical on x86_64-linux between gcc 6 and trunk. > So, what exact options (implicit or explicit) you are using, what differences > in assembly do you see on this test compared to 6.x and does it fail there > too? Since 20161201, I'm no longer seeing those failures. No idea what has been wrong there. Rainer
[Bug libstdc++/51785] gets not anymore declared
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51785 andyg1001 at hotmail dot co.uk changed: What|Removed |Added CC||andyg1001 at hotmail dot co.uk --- Comment #28 from andyg1001 at hotmail dot co.uk --- Erm, am I the first to notice that this "solution" is broken? The os_defines.h include that undefines _GLIBCXX_HAVE_GETS is included before _GLIBCXX_HAVE_GETS is (re)defined inside c++config.h. Therefore, _GLIBCXX_HAVE_GETS is still defined when we get to . Seems still to be broken even in trunk.
[Bug c++/71182] [6/7 Regression] parser.c cp_lexer_previous_token sanitizer detects member call on null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71182
Markus Trippelsdorf changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #5 from Markus Trippelsdorf ---
(gdb) l
763 cp_token_position tp = cp_lexer_previous_token_position (lexer);
764
765 /* Skip past purged tokens. */
766 while (tp->purged_p)
767 {
768 gcc_assert (tp != lexer->buffer->address ());
769 tp--;
770 }
771
772 return cp_lexer_token_at (lexer, tp);
(gdb) p *lexer
$1 = {
buffer = 0x0,
last_token = 0x77e0c2f8,
next_token = 0x77e0c298,
saved_tokens = {
m_vec = 0x92c6b20
},
next = 0x75f96480,
debugging_p = false,
in_pragma = false
}
[Bug libobjc/78697] New: --with-target-bdw-gc-include shouldn't be required to be per multilib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78697 Bug ID: 78697 Summary: --with-target-bdw-gc-include shouldn't be required to be per multilib Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libobjc Assignee: unassigned at gcc dot gnu.org Reporter: ro at gcc dot gnu.org CC: doko at gcc dot gnu.org Target Milestone: --- When trying to use the new --with-target-bdw-gc-* options with an external build of gc 7.6.0 on Solaris/SPARC, Solaris/x86, and Linux/x86_64 (each with 32-bit and 64-bit multilibs), I ran into the following error when configuring with --with-target-bdw-gc-include=/vol/gcc/include while ...-gc-lib had two multilibs: checking for bdw garbage collector... using paths configured with --with-target-bdw-gc options configure: error: no multilib path (amd64) found in --with-target-bdw-gc-include Requiring those include paths to be specified explicitly makes no sense: the directories are identical between 32 and 64-bit builds and the different Solaris and Linux trees, so one should be able to get away with a single --with-target-bdw-gc-include for one shared include dir. Of course, having different ones for whatever reason should still be an option, just not a hard requirement. Rainer
[Bug fortran/78686] ICE in gfc_apply_init, at fortran/expr.c:4124
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78686 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2016-12-06 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Confirmed.
[Bug fortran/78226] Fill out location information everywhere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78226 --- Comment #13 from vehre at gcc dot gnu.org --- Author: vehre Date: Tue Dec 6 13:41:46 2016 New Revision: 243300 URL: https://gcc.gnu.org/viewcvs?rev=243300&root=gcc&view=rev Log: gcc/fortran/ChangeLog: 2016-12-06 Andre Vehreschild PR fortran/78226 * class.c (finalize_component): Add missing locus information. (finalization_scalarizer): Likewise. (finalization_get_offset): Likewise. (finalizer_insert_packed_call): Likewise. (generate_finalization_wrapper): Likewise. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c
[Bug c++/71182] [6/7 Regression] parser.c cp_lexer_previous_token sanitizer detects member call on null pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71182
--- Comment #6 from Markus Trippelsdorf ---
So, perhaps:
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 08f5f9e52ef2..f430af97fdf1 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -765,7 +765,7 @@ cp_lexer_previous_token (cp_lexer *lexer)
/* Skip past purged tokens. */
while (tp->purged_p)
{
- gcc_assert (tp != lexer->buffer->address ());
+ gcc_assert (!lexer->buffer || tp != lexer->buffer->address ());
tp--;
}
