[Bug middle-end/79374] missing sometimes-uninitialized warning in switch statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79374 Andrew Pinski changed: What|Removed |Added Component|c |middle-end Depends on||44042 --- Comment #1 from Andrew Pinski --- This is a dup of bug 44042. Basically we try to reduce the number of false positives by optimizing before reporting a warning. This one case happens that way. LLVM might have some false positives due to not optimizing first. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44042 [Bug 44042] [4.1/4.2/4.4/4.5/4.6 Regression] Missing warning for unitialized varaible in switch statement
[Bug tree-optimization/79338] [6/7 Regression] Memory leak in tree-parloops.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79338 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Sat Feb 4 07:44:13 2017 New Revision: 245183 URL: https://gcc.gnu.org/viewcvs?rev=245183&root=gcc&view=rev Log: PR tree-optimization/79338 * tree-parloops.c (gather_scalar_reductions): Don't call vect_analyze_loop_form for loop->inner before destroying loop's loop_vinfo. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-parloops.c
[Bug c/79374] New: missing sometimes-uninitialized warning in switch statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79374 Bug ID: 79374 Summary: missing sometimes-uninitialized warning in switch statement Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: hermantenbrugge at home dot nl Target Milestone: --- The code below: int tst(int); int tst (int sel) { int rv; switch (sel) { case 1: break; default: rv = 0; break; } return rv; } compiled with 'gcc -S -O3 -Wall tst.c' results in no warning in gcc 6.3.1 and gcc 7.0.1 (head) When compiled with clang 3.8.1 with same compiler options I get: tst.c:9:8: warning: variable 'rv' is used uninitialized whenever switch case is taken [-Wsometimes-uninitialized] case 1: break; ^ tst.c:13:10: note: uninitialized use occurs here return rv; ^~ tst.c:6:9: note: initialize the variable 'rv' to silence this warning int rv; ^ = 0 1 warning generated. This is a very reduced test case and in the real code it was much harder to see that rv was uninitialized. I now that bug '44042' was closed as 'RESOLVED WONTFIX' but clang gives the correct warning.
[Bug target/79366] wrong result in cast to unsigned int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79366 --- Comment #9 from Jakub Jelinek --- Because =undefined only includes undefined behavior, which neither float-divide-by-zero nor float-cast-overflow doesn't satisfy. This is all documented.
[Bug target/79366] wrong result in cast to unsigned int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79366 --- Comment #8 from Bernd Edlinger --- (In reply to Jakub Jelinek from comment #7) > (In reply to Jonathan Wakely from comment #3) > > Clang's ubsan diagnoses this, but ours doesn't: > > > > u.cc:4:25: runtime error: value -1 is outside the range of representable > > values of type 'unsigned int' > > We do diagnose it as well, but only with -fsanitize=float-cast-overflow, > which is intentionally not included in -fsanitize=undefined. Oh really. And what was the rationale behind that decision?
[Bug c++/79373] For loop optimization bug: condition ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79373 --- Comment #2 from Steven Pigeon --- (In reply to Andrew Pinski from comment #1) > I am suspecting this: > t*=65793; > > overflows. > > Can you try with -fsanitize=undefined ? The bug disappears with g++ -fsanitize=undefined -O3 -std=c++11 test-wave-stream.cpp Yes, it overflows for some values (and is undefined behavior?). But it shouldn't affect the for-loop. At worse, the returned values should be random-looking and the unit test should fail with a message.
[Bug c++/79373] For loop optimization bug: condition ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79373 --- Comment #1 from Andrew Pinski --- I am suspecting this: t*=65793; overflows. Can you try with -fsanitize=undefined ?
[Bug c++/79373] New: For loop optimization bug: condition ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79373 Bug ID: 79373 Summary: For loop optimization bug: condition ignored Product: gcc Version: 5.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: steven.p.pigeon at gmail dot com Target Milestone: --- Created attachment 40668 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40668&action=edit Collected data for bug (followed collection instructions) The condition in the following for-loop is ignored when the following program is optimized with -O3: for (int i=-32768; i<32768; i++) { int w=wstream::_16_to_24(i); int j=wstream::_24_to_16(w); if (i!=j) std::cout << " failed on: " << i << " = " << j << std::endl; } with functions (in class wstream) static int32_t _16_to_24(int16_t x) { int32_t t=x; t+=(1u<<15); t*=65793; t/=256; return t-(1u<<23); } static int16_t _24_to_16(int32_t x) { return ((x+(1u<<23))*257)/65793-(1u<<15); } with *no* side-effects. Program works properly when optimizations are disabled (-O0), or functions modified slightly (ignore the fact that both function aren't exactly inverse of each other). Attached is an archive with full program, Makefile used to generate code, and collected information as directed for a bug report (gcc -v -save-temps ...).
[Bug c++/79372] New: ICE on C++ code with illegal decomposition declaration on x86_64-linux-gnu: in tsubst_decomp_names, at cp/pt.c:15599
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79372 Bug ID: 79372 Summary: ICE on C++ code with illegal decomposition declaration on x86_64-linux-gnu: in tsubst_decomp_names, at cp/pt.c:15599 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: su at cs dot ucdavis.edu Target Milestone: --- $ g++-trunk -v Using built-in specs. COLLECT_GCC=g++-trunk COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto --prefix=/usr/local/gcc-trunk --disable-bootstrap Thread model: posix gcc version 7.0.1 20170203 (experimental) [trunk revision 245142] (GCC) $ $ g++-trunk -c -std=c++1z small.cpp small.cpp: In member function ‘void S::f()’: small.cpp:4:20: error: cannot decompose non-array non-class type ‘int’ void f () { auto [x] = 0; } ^~~ small.cpp: In instantiation of ‘void S::f() [with T = int]’: small.cpp:10:8: required from here small.cpp:4:20: internal compiler error: in tsubst_decomp_names, at cp/pt.c:15599 0x70aa06 tsubst_decomp_names ../../gcc-source-trunk/gcc/cp/pt.c:15599 0x6f56db tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc-source-trunk/gcc/cp/pt.c:15773 0x6f1da3 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) ../../gcc-source-trunk/gcc/cp/pt.c:15879 0x6ef204 instantiate_decl(tree_node*, bool, bool) ../../gcc-source-trunk/gcc/cp/pt.c:22818 0x73e5a2 instantiate_pending_templates(int) ../../gcc-source-trunk/gcc/cp/pt.c:22939 0x783a01 c_parse_final_cleanups() ../../gcc-source-trunk/gcc/cp/decl2.c:4525 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. $ - template < typename T > struct S { enum E { A }; void f () { auto [x] = 0; } }; int main () { S < int > s; s.f (); return 0; }
[Bug fortran/78958] FAIL: gfortran.dg/alloc_comp_class_5.f03 - Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78958 --- Comment #5 from dave.anglin at bell dot net --- On 2017-01-30, at 4:38 AM, vehre at gmx dot de wrote: > The attached patch fixes the issue at least on x86_64-linux and the sanitizer > does not report any further issues. Please test. The patch also fixes the test failure on 32-bit hpux. -- John David Anglin dave.ang...@bell.net
[Bug testsuite/79356] XPASS in attr-alloc_size-11.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79356 Martin Sebor changed: What|Removed |Added Target|s390x |s390x, powepc64le-linux Host|s390x |s390x, powepc64le-linux --- Comment #2 from Martin Sebor --- Looks like the assertions are also XPASSing on powerpc64le-linux: https://gcc.gnu.org/ml/gcc-testresults/2017-02/msg00390.html
[Bug c++/79371] New: ICE on valid C++14 code on x86_64-linux-gnu: in build_class_member_access_expr, at cp/typeck.c:2296
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79371 Bug ID: 79371 Summary: ICE on valid C++14 code on x86_64-linux-gnu: in build_class_member_access_expr, at cp/typeck.c:2296 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: su at cs dot ucdavis.edu Target Milestone: --- This ICE seems to be a recent regression. The code is mistakenly rejected by GCC 6.x and earlier. It is correctly accepted by Clang and crashes ICC. $ g++-trunk -v Using built-in specs. COLLECT_GCC=g++-trunk COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto --prefix=/usr/local/gcc-trunk --disable-bootstrap Thread model: posix gcc version 7.0.1 20170203 (experimental) [trunk revision 245148] (GCC) $ $ clang++ -c -std=c++14 small.cpp $ icc -c -std=c++14 small.cpp small.cpp(6): internal error: assertion failed at: "shared/cfe/edgcpfe/class_decl.c", line 3575 int b = S().a < int >; ^ compilation aborted for small.cpp (code 4) $ $ g++-trunk -c -std=c++14 small.cpp small.cpp:6:13: internal compiler error: in build_class_member_access_expr, at cp/typeck.c:2296 int b = S().a < int >; ^ 0x80a0cc build_class_member_access_expr(cp_expr, tree_node*, tree_node*, bool, int) ../../gcc-source-trunk/gcc/cp/typeck.c:2296 0x80a48a finish_class_member_access_expr(cp_expr, tree_node*, bool, int) ../../gcc-source-trunk/gcc/cp/typeck.c:2900 0x7c47b4 cp_parser_postfix_dot_deref_expression ../../gcc-source-trunk/gcc/cp/parser.c:7443 0x7c1d44 cp_parser_postfix_expression ../../gcc-source-trunk/gcc/cp/parser.c:7046 0x7bdcbc cp_parser_unary_expression ../../gcc-source-trunk/gcc/cp/parser.c:8098 0x7caa17 cp_parser_cast_expression ../../gcc-source-trunk/gcc/cp/parser.c:8775 0x7caff3 cp_parser_binary_expression ../../gcc-source-trunk/gcc/cp/parser.c:8876 0x7cb8e4 cp_parser_assignment_expression ../../gcc-source-trunk/gcc/cp/parser.c:9163 0x7cbd2a cp_parser_constant_expression ../../gcc-source-trunk/gcc/cp/parser.c:9433 0x7cc584 cp_parser_initializer_clause ../../gcc-source-trunk/gcc/cp/parser.c:21569 0x7ce093 cp_parser_initializer ../../gcc-source-trunk/gcc/cp/parser.c:21509 0x7ddf80 cp_parser_init_declarator ../../gcc-source-trunk/gcc/cp/parser.c:19328 0x7de7e1 cp_parser_simple_declaration ../../gcc-source-trunk/gcc/cp/parser.c:12776 0x7df52a cp_parser_block_declaration ../../gcc-source-trunk/gcc/cp/parser.c:12594 0x7e77f4 cp_parser_declaration ../../gcc-source-trunk/gcc/cp/parser.c:12491 0x7e7b66 cp_parser_declaration_seq_opt ../../gcc-source-trunk/gcc/cp/parser.c:12367 0x7e7e84 cp_parser_translation_unit ../../gcc-source-trunk/gcc/cp/parser.c:4366 0x7e7e84 c_parse_file() ../../gcc-source-trunk/gcc/cp/parser.c:38382 0x94d6f2 c_common_parse_file() ../../gcc-source-trunk/gcc/c-family/c-opts.c:1107 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. $ struct S { template < typename > static int &a; }; int b = S().a < int >;
[Bug target/79370] Cortex-A7 hardware division switched on for -mcpu but not -mtune
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79370 PeteVine changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from PeteVine --- Oops, the meaning of -mcpu and -mtune must have switched places in my head :)
[Bug fortran/79344] [7 Regression] segmentation faults and run-time errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79344 --- Comment #6 from Jürgen Reuter --- Also the three remaining test failures are now understood as resulting from an allocate (A, source = B), where A and B are allocatable arrays of a derived type with allocatable components, e.g. iso_varying_string.
[Bug c++/79360] [5.4/6/7 Regression] ICE with NSDMI and enum in union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79360 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org --- Comment #2 from Patrick Palka --- (In reply to Martin Liška from comment #1) > Confirmed, started with r234443. Oops, I didn't know that TYPE_FIELDS could contain things other than FIELD_DECLs. Testing this: diff --git a/gcc/cp/typeck2.c b/gcc/cp/typeck2.c index 014de5c..1e0354d 100644 --- a/gcc/cp/typeck2.c +++ b/gcc/cp/typeck2.c @@ -1510,7 +1510,8 @@ process_init_constructor_union (tree type, tree init, { for (tree field = TYPE_FIELDS (type); field; field = TREE_CHAIN (field)) { - if (DECL_INITIAL (field)) + if (TREE_CODE (field) == FIELD_DECL + && DECL_INITIAL (field) != NULL_TREE) { CONSTRUCTOR_APPEND_ELT (CONSTRUCTOR_ELTS (init), field,
[Bug target/79370] New: Cortex-A7 hardware division switched on for -mcpu but not -mtune
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79370 Bug ID: 79370 Summary: Cortex-A7 hardware division switched on for -mcpu but not -mtune Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: tulipawn at gmail dot com Target Milestone: --- Created attachment 40667 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40667&action=edit Preprocessed source Compiling the attachment (produced from http://pastebin.com/X3ZTp1c0) only emits sdiv instructions for -mcpu=cortex-a7 but not for the more logical case of -mtune=cortex-a7 FWIW, running the produced "tuned" code on a Cortex-A53 (32bit mode) incurs a 6x penalty compared with -mcpu which is fully consistent with targeting a soft-division CPU. gcc version 7.0.1 20170127, switches used: -Ofast -mtune=cortex-a7 -marm -mfloat-abi=hard -mfpu=vfpv4
[Bug sanitizer/79096] [7 Regression] address sanitizer and jni does not work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79096 --- Comment #4 from physiker at toast2 dot net --- > Could you please raise a bug in LLVM bug tracker (https://llvm.org/bugs/)? > All changes to sanitizer runtime library should go to LLVM and after they > fix this bug we can backport corresponding patch to GCC. > I submitted a bug report to the LLVM bug tracker. The bug id is 31861.
[Bug c++/79362] internal compiler error: Segmentation fault - mmap: Cannot allocate memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79362 --- Comment #2 from Fabio Alemagna --- I had looked for possible duplicates but found none, sorry about that and glad to know it's already been fixed. Thanks for your time!
[Bug c++/79362] internal compiler error: Segmentation fault - mmap: Cannot allocate memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79362 David Malcolm changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #1 from David Malcolm --- I'm able to reproduce the segfault with various builds up to and including r244591, but it works from r244592 onwards. Hence this would seem to be a dup of PR c++/78488. The traceback was: (gdb) bt #0 0x005f1261 in build_over_call (cand=cand@entry=0x1db33f0, flags=, complain=, complain@entry=3) at ../../src/gcc/cp/call.c:7900 #1 0x005ec3bb in build_new_method_call_1 (complain=3, complain@entry=-248443568, fn_p=0x0, flags=, conversion_path=, args=0x7131c1a0, fns=, instance=0x714995a0) at ../../src/gcc/cp/call.c:8778 #2 build_new_method_call (instance=instance@entry=0x714995a0, fns=0x71310d50, args=args@entry=0x7fffd850, conversion_path=, flags=flags@entry=1, fn_p=fn_p@entry=0x0, complain=complain@entry=3) at ../../src/gcc/cp/call.c:8848 #3 0x005ecf14 in build_special_member_call (instance=instance@entry=0x714995a0, name=0x7132c478, args=args@entry=0x7fffd850, binfo=binfo@entry=0x7131c1a0, flags=flags@entry=1, complain=complain@entry=3) at ../../src/gcc/cp/call.c:8379 #4 0x006c6fa8 in expand_default_init (complain=3, flags=1, init=, exp=0x714995a0, true_exp=0x714995a0, binfo=) at ../../src/gcc/cp/init.c:1780 #5 expand_aggr_init_1 (binfo=, true_exp=true_exp@entry=0x714995a0, exp=exp@entry=0x714995a0, init=, init@entry=, flags=flags@entry=1, complain=complain@entry=3) at ../../src/gcc/cp/init.c:1894 #6 0x006c781d in build_aggr_init (exp=exp@entry=0x714995a0, init=init@entry=0x0, flags=flags@entry=1, complain=complain@entry=3) at ../../src/gcc/cp/init.c:1633 #7 0x005ff1fd in build_aggr_init_full_exprs (flags=1, init=0x0, decl=0x714995a0) at ../../src/gcc/cp/decl.c:6159 #8 check_initializer (decl=decl@entry=0x714995a0, init=0x0, flags=flags@entry=1, cleanups=cleanups@entry=0x7fffd9b0) at ../../src/gcc/cp/decl.c:6307 #9 0x0060e6b6 in cp_finish_decl (decl=decl@entry=0x714995a0, init=init@entry=, init_const_expr_p=, asmspec_tree=, asmspec_tree@entry=, flags=) at ../../src/gcc/cp/decl.c:7019 #10 0x0069f13d in cp_parser_init_declarator (parser=parser@entry=0x77ffbbd0, decl_specifiers=decl_specifiers@entry=0x7fffdb20, checks=checks@entry=0x0, function_definition_allowed_p=function_definition_allowed_p@entry=true, member_p=member_p@entry=false, declares_class_or_enum=, function_definition_p=function_definition_p@entry=0x7fffdbb0, maybe_range_for_decl=maybe_range_for_decl@entry=0x0, init_loc=init_loc@entry=0x7fffdb04, auto_result=auto_result@entry=0x7fffdc40) at ../../src/gcc/cp/parser.c:19339 #11 0x0069f8f8 in cp_parser_simple_declaration (parser=parser@entry=0x77ffbbd0, function_definition_allowed_p=true, maybe_range_for_decl=maybe_range_for_decl@entry=0x0) at ../../src/gcc/cp/parser.c:12765 #12 0x006a03d9 in cp_parser_block_declaration (parser=parser@entry=0x77ffbbd0, statement_p=statement_p@entry=false) at ../../src/gcc/cp/parser.c:12592 #13 0x006a4929 in cp_parser_declaration (parser=0x77ffbbd0) at ../../src/gcc/cp/parser.c:12489 #14 0x006a4d30 in cp_parser_declaration_seq_opt (parser=parser@entry=0x77ffbbd0) at ../../src/gcc/cp/parser.c:12365 #15 0x006a5060 in cp_parser_translation_unit (parser=0x77ffbbd0) at ../../src/gcc/cp/parser.c:4369 #16 c_parse_file () at ../../src/gcc/cp/parser.c:38313 #17 0x0077f986 in c_common_parse_file () at ../../src/gcc/c-family/c-opts.c:1098 #18 0x00b4f44a in compile_file () at ../../src/gcc/toplev.c:463 #19 0x005e3fb0 in do_compile () at ../../src/gcc/toplev.c:1983 #20 toplev::main (this=this@entry=0x7fffdf60, argc=argc@entry=13, argv=argv@entry=0x7fffe068) at ../../src/gcc/toplev.c:2117 #21 0x005e5d99 in main (argc=13, argv=0x7fffe068) at ../../src/gcc/main.c:39
[Bug c++/78334] [7 Regression] [C++1z] P0127R2 related ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78334 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #6 from Jason Merrill --- This seems to have been fixed; I've added the reduced testcase to the testsuite. --- Comment #7 from Jason Merrill --- Author: jason Date: Fri Feb 3 23:19:46 2017 New Revision: 245174 URL: https://gcc.gnu.org/viewcvs?rev=245174&root=gcc&view=rev Log: PR c++/78334 * g++.dg/cpp1z/nontype-auto7.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp1z/nontype-auto7.C
[Bug c++/78334] [7 Regression] [C++1z] P0127R2 related ICE: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78334 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WORKSFORME --- Comment #6 from Jason Merrill --- This seems to have been fixed; I've added the reduced testcase to the testsuite.
[Bug testsuite/79356] XPASS in attr-alloc_size-11.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79356 Martin Sebor changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-03 Component|c |testsuite Ever confirmed|0 |1 Severity|normal |minor --- Comment #1 from Martin Sebor --- Confirmed. It seems that the XFAIL target could be restricted to exclude s390x.
[Bug fortran/79344] [7 Regression] segmentation faults and run-time errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79344 --- Comment #5 from Jürgen Reuter --- >From the full test case I posted below, all the failing unit test and all but three failing functional tests can be traced back to allocate (A, source = B) problems. Three tests are not yet understood: smtest_3, smtest_11, and lhef_7.
[Bug c++/79368] [7 Regression] ICE with pointer to unnamed struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79368 David Malcolm changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #1 from David Malcolm --- I wasn't able to reproduce this with r245173. What command-line options are you using to trigger the ICE, and what version are you using? Thanks.
[Bug c/79357] Doubling a single complex float gives inefficient code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79357 --- Comment #1 from Raphael C --- I omitted .L_2il0floatpacket.1: .long 0x4000,0x4000,0x,0x .long 0x4000,0x from the assembly. In other words it just multiplies by 2.0f.
[Bug tree-optimization/79327] [7 Regression] wrong code at -O2 and -fprintf-return-value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79327 --- Comment #8 from Martin Sebor --- Author: msebor Date: Fri Feb 3 22:47:35 2017 New Revision: 245173 URL: https://gcc.gnu.org/viewcvs?rev=245173&root=gcc&view=rev Log: PR tree-optimization/79327 - wrong code at -O2 and -fprintf-return-value gcc/ChangeLog: * gimple-ssa-sprintf.c (tree_digits): Avoid adding the base prefix when precision has resulted in leading zeros. (format_integer): Adjust the likely counter to assume an unknown argument that may be zero is non-zero. gcc/testsuite/ChangeLog: * gcc.dg/tree-ssa/builtin-sprintf-warn-1.c: Adjust. * gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-13.c: New test. * gcc/testsuite/gcc.dg/tree-ssa/pr79327-2.c: Ditto. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-13.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr79327-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-sprintf.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c
[Bug c++/78689] [7 Regression] ICE (segfault) within cleanup_dead_labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78689 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org --- Comment #8 from Jason Merrill --- Fixed.
[Bug c++/72775] [6 Regression] internal compiler error: in finish_expr_stmt, at cp/semantics.c:677
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72775 Jason Merrill changed: What|Removed |Added Status|RESOLVED|ASSIGNED Resolution|FIXED |--- --- Comment #17 from Jason Merrill --- Reopening, as this is still a GCC 6 regression.
[Bug tree-optimization/79340] [7 Regression] Memory leaks in tree-vect-slp.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79340 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Fixed.
[Bug c++/78689] [7 Regression] ICE (segfault) within cleanup_dead_labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78689 --- Comment #7 from Jason Merrill --- Author: jason Date: Fri Feb 3 22:42:37 2017 New Revision: 245172 URL: https://gcc.gnu.org/viewcvs?rev=245172&root=gcc&view=rev Log: PR c++/78689 - ICE on constructor with label gcc/ * tree-inline.c (copy_tree_body_r) [COND_EXPR]: Revert change to avoid copying non-taken branch. gcc/cp/ * optimize.c (maybe_clone_body): Replace omitted parameters with null lvalues. * class.c (build_clone): Fix logic for omitting inherited parms. Added: trunk/gcc/testsuite/g++.dg/init/ctor12.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/optimize.c trunk/gcc/testsuite/g++.dg/cpp1z/inh-ctor23.C trunk/gcc/tree-inline.c
[Bug tree-optimization/79340] [7 Regression] Memory leaks in tree-vect-slp.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79340 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Fri Feb 3 22:36:29 2017 New Revision: 245171 URL: https://gcc.gnu.org/viewcvs?rev=245171&root=gcc&view=rev Log: PR tree-optimization/79340 * tree-vect-loop.c (vectorizable_reduction): Release vec_defs elements after safe_splicing them into other vectors. Formatting fixes. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug target/79366] wrong result in cast to unsigned int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79366 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- (In reply to Jonathan Wakely from comment #3) > Clang's ubsan diagnoses this, but ours doesn't: > > u.cc:4:25: runtime error: value -1 is outside the range of representable > values of type 'unsigned int' We do diagnose it as well, but only with -fsanitize=float-cast-overflow, which is intentionally not included in -fsanitize=undefined.
[Bug c++/79363] [6/7 Regression] ICE with NSDMI and array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79363 Martin Sebor changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code Status|NEW |ASSIGNED See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=72775 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #2 from Martin Sebor --- The test case is equivalent to (though not exactly the same as) the one in bug 72775. After some debate on gcc-patches it was decided that the test case there was invalid, and so is this one, for the same reason. Thus: ice-on-invalid-code. (FWIW, I'd like to revisit the decision for the case in that bug but I'm not sure that I'd also like to see it extended to this case where the array would have no elements.)
[Bug testsuite/68972] g++.dg/cpp1y/vla-initlist1.C test case fails on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68972 --- Comment #11 from Eric Botcazou --- The test really needs to be fixed at this point...
[Bug c++/79367] ICE on valid C++11 code on x86_64-linux-gnu: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79367 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-03 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, also 4.7.0 (with checking enabled) ICEs.
[Bug c++/79363] [6/7 Regression] ICE with NSDMI and array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79363 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-03 CC||marxin at gcc dot gnu.org, ||msebor at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r233126.
[Bug c++/79369] namespace definition with qualified id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79369 Nathan Sidwell changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-02-03 Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/79369] New: namespace definition with qualified id
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79369 Bug ID: 79369 Summary: namespace definition with qualified id Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nathan at gcc dot gnu.org Target Milestone: --- namespaces are magically conjured up if you use a qualified name: namespace X::Y::Z { } X::Y must already be a namespace, but we don't complain. Also, we do the strong using dance on reopenings of a inline namespace. We only need to do it on creation.
[Bug c++/79360] [5.4/6/7 Regression] ICE with NSDMI and enum in union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79360 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-02-03 CC||marxin at gcc dot gnu.org, ||ppalka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed, started with r234443.
[Bug c++/79368] New: [7 Regression] ICE with pointer to unnamed struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79368 Bug ID: 79368 Summary: [7 Regression] ICE with pointer to unnamed struct Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: reichelt at gcc dot gnu.org Target Milestone: --- The following valid code snippet triggers an ICE on trunk: === typedef struct{}* X; template void foo(X, T) {} void bar() { foo(0, 0); } === bug.cc: In instantiation of 'void foo(X, T) [with T = int]': bug.cc:3:27: required from here bug.cc:3:27: internal compiler error: in write_unnamed_type_name, at cp/mangle.c:1623 template void foo(X, T) {} ^~~ 0x825126 write_unnamed_type_name ../../gcc/gcc/cp/mangle.c:1623 0x825126 write_unqualified_name ../../gcc/gcc/cp/mangle.c:1382 0x825bbf write_name ../../gcc/gcc/cp/mangle.c:939 0x826f7f write_class_enum_type ../../gcc/gcc/cp/mangle.c:2769 0x826f7f write_type ../../gcc/gcc/cp/mangle.c:2187 0x826186 write_type ../../gcc/gcc/cp/mangle.c:2267 0x828a24 write_method_parms ../../gcc/gcc/cp/mangle.c:2756 0x828c96 write_bare_function_type ../../gcc/gcc/cp/mangle.c:2698 0x828e12 write_encoding ../../gcc/gcc/cp/mangle.c:848 0x8303ac mangle_decl_string ../../gcc/gcc/cp/mangle.c:3743 0x830762 get_mangled_id ../../gcc/gcc/cp/mangle.c:3765 0x830762 mangle_decl(tree_node*) ../../gcc/gcc/cp/mangle.c:3835 0x103021e decl_assembler_name(tree_node*) ../../gcc/gcc/tree.c:671 0x1055fbd assign_assembler_name_if_neeeded(tree_node*) ../../gcc/gcc/tree.c:5920 0x997d8b cgraph_node::analyze() ../../gcc/gcc/cgraphunit.c:619 0x99afb9 analyze_functions ../../gcc/gcc/cgraphunit.c:1087 0x99c012 symbol_table::finalize_compilation_unit() ../../gcc/gcc/cgraphunit.c:2562 Please submit a full bug report, [etc.]
[Bug target/79366] wrong result in cast to unsigned int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79366 --- Comment #6 from Bernd Edlinger --- FYI, the original problem was that libxml2 was unable to convert a date value 1601-01-01T00:00:00.000+00:01 which should underflow from 1601 to 1600, but we got the wrong date 1601-12-31T23:59:00.000 here and that made one unit test fail. libxml2-2.9.4 has this in xmlschemastypes.c #define FQUOTIENT(a,b) (floor(((double)a/(double)b))) #define FQUOTIENT_RANGE(a,low,high) (FQUOTIENT((a-low),(high-low))) long temp = 0; r->year = r->year + (unsigned int) FQUOTIENT_RANGE(temp, 1, 13); r->year is a long with value 1601
[Bug target/63264] Internal error due to invalid assembler register specification
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63264 mikulas at artax dot karlin.mff.cuni.cz changed: What|Removed |Added Version|4.9.1 |6.3.0 --- Comment #1 from mikulas at artax dot karlin.mff.cuni.cz --- This bug still happens with GCC 6.
[Bug lto/64543] gcc fails to build due to undefined references to functions in libiberty
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64543 mikulas at artax dot karlin.mff.cuni.cz changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #3 from mikulas at artax dot karlin.mff.cuni.cz --- This bug doesn't happen with gcc-6.3. So we can close this.
[Bug c++/79300] Wrong diagnostics position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79300 David Malcolm changed: What|Removed |Added Target Milestone|--- |8.0 --- Comment #3 from David Malcolm --- Deferring to gcc 8.
[Bug target/79366] wrong result in cast to unsigned int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79366 --- Comment #5 from joseph at codesourcery dot com --- Annex F makes it an unspecified value (i.e. each execution that occurs in the abstract machine has to act as if it produces some definite value representable in the resulting type, but that value might be different for different executions), with the "invalid" exception raised.
[Bug target/79366] wrong result in cast to unsigned int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79366 --- Comment #4 from Bernd Edlinger --- Ah, I see, you mean C89: 3.2.1.3 Floating and integral When a value of floating type is converted to integral type, the fractional part is discarded. If the value of the integral part cannot be represented by the integral type, the behavior is undefined. /23/
[Bug target/79366] wrong result in cast to unsigned int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79366 --- Comment #3 from Jonathan Wakely --- Clang's ubsan diagnoses this, but ours doesn't: u.cc:4:25: runtime error: value -1 is outside the range of representable values of type 'unsigned int'
[Bug c++/79077] [7 regression][new inheriting ctors] bad code for inherited ctor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79077 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- This has been indeed fixed with r244728.
[Bug c++/78689] [7 Regression] ICE (segfault) within cleanup_dead_labels
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78689 --- Comment #6 from Jason Merrill --- (In reply to Jakub Jelinek from comment #4) > _ZN1XCI21WEi emitted in _ZN1XCI21WEi comdat, without _ZN1XCI11WEi alias, > which has the argument only in GCC (bug?), e.g. as seen with -O0 saves 3 > arguments to stack instead of 2: > movq%rdi, -8(%rbp) > movq%rsi, -16(%rbp) > movl%edx, -20(%rbp) > but callers actually provide 2: > X::X (_2, _3); Oops, not sure how that broke. That's why reverting the tree-inline hunk doesn't break anything. I'll fix this issue. And indeed there won't be any user labels in the branch we want to omit here. But perhaps we can do better in the front end.
[Bug testsuite/68972] g++.dg/cpp1y/vla-initlist1.C test case fails on powerpc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68972 seurer at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org, ||seurer at gcc dot gnu.org --- Comment #10 from seurer at gcc dot gnu.org --- This is now failing again as of r245132: spawn /home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../ /home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp1y/vla-initlist1.C -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++ -I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward -I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++11 -Wno-vla -L/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs -B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs -B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libitm/ -L/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libitm/.libs -lm -o ./vla-initlist1.exe PASS: g++.dg/cpp1y/vla-initlist1.C -std=gnu++11 (test for excess errors) Setting LD_LIBRARY_PATH to .:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libitm/.libs:/home/seurer/gcc/build/gcc-test2/gcc:.:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libitm/.libs:/home/seurer/gcc/build/gcc-test2/gcc:/home/seurer/gcc/install/gcc-5.4.0/lib64 spawn [open ...] FAIL: g++.dg/cpp1y/vla-initlist1.C -std=gnu++11 execution test Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../ /home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp1y/vla-initlist1.C -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++ -I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward -I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++14 -Wno-vla -L/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs -B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs -B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libitm/ -L/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libitm/.libs -lm-o ./vla-initlist1.exe(timeout = 300) spawn /home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../xg++ -B/home/seurer/gcc/build/gcc-test2/gcc/testsuite/g++/../../ /home/seurer/gcc/gcc-test2/gcc/testsuite/g++.dg/cpp1y/vla-initlist1.C -fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++ -I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu -I/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++ -I/home/seurer/gcc/gcc-test2/libstdc++-v3/include/backward -I/home/seurer/gcc/gcc-test2/libstdc++-v3/testsuite/util -fmessage-length=0 -std=gnu++14 -Wno-vla -L/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs -B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs -L/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs -B/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libitm/ -L/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libitm/.libs -lm -o ./vla-initlist1.exe PASS: g++.dg/cpp1y/vla-initlist1.C -std=gnu++14 (test for excess errors) Setting LD_LIBRARY_PATH to .:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gcc/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libstdc++-v3/src/.libs:/home/seurer/gcc/bu
[Bug rtl-optimization/68664] [6/7 Regression] Speculative sqrt in c-ray main loop causes large slow down
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68664 Segher Boessenkool changed: What|Removed |Added Status|NEW |ASSIGNED Component|middle-end |rtl-optimization Assignee|unassigned at gcc dot gnu.org |segher at gcc dot gnu.org
[Bug testsuite/79270] FAIL: obj-c++.dg/property/at-property-23.mm -fgnu-runtime (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79270 John David Anglin changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #3 from John David Anglin --- Fixed.
[Bug c++/79331] ICE on valid C++14 code (with initialized lambda capture) on x86_64-linux-gnu: in canonicalize_component_ref, at gimplify.c:2451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79331 Nathan Sidwell changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org
[Bug target/79364] some variadic functions with an empty struct miscompiled with C++ (at least for x64 targets)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79364 --- Comment #2 from Guillaume Knispel --- Note: I hit that bug after cleaning some real code after a cppcheck static analysis. The original code sometimes had "..." after references, which is technically forbidden (but seems to work with g++, for now) One of the "natural" ways to avoid this theoretical UB (... after a ref) is to create an allowed type just to prefix the ... in those cases. Technically, an empty struct seems to be allowed by the standard, so it's a good candidate. After I got some additional crashes following that change and traced back their origin to it, I switched my vatag type to typedef void* in order to workaround that compiler bug.
[Bug target/79366] wrong result in cast to unsigned int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79366 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > It is unspecified what is the value of an out of range conversion from > double to unsigned will be. Actually it is not just unspecified but undefined.
[Bug c++/79294] [7 Regression] ICE in convert_nontype_argument, at cp/pt.c:6812
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79294 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jason Merrill --- Fixed.
[Bug c/12245] [5/6/7 regression] Uses lots of memory when compiling large initialized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12245 --- Comment #64 from Jason Merrill --- Author: jason Date: Fri Feb 3 19:44:27 2017 New Revision: 245169 URL: https://gcc.gnu.org/viewcvs?rev=245169&root=gcc&view=rev Log: PR c++/12245 - excessive memory use * constexpr.c (maybe_constant_value): Fold maybe_constant_value_1 back in. Don't cache constants. (maybe_constant_init): Don't cache constants. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c
[Bug target/79366] wrong result in cast to unsigned int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79366 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- It is unspecified what is the value of an out of range conversion from double to unsigned will be.
[Bug c++/79367] New: ICE on valid C++11 code on x86_64-linux-gnu: verify_gimple failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79367 Bug ID: 79367 Summary: ICE on valid C++11 code on x86_64-linux-gnu: verify_gimple failed Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: su at cs dot ucdavis.edu Target Milestone: --- All 4.8.x and later ICE, but not 4.7.x. The code is correctly accepted by Clang. $ g++-trunk -v Using built-in specs. COLLECT_GCC=g++-trunk COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../gcc-source-trunk/configure --enable-languages=c,c++,lto --prefix=/usr/local/gcc-trunk --disable-bootstrap Thread model: posix gcc version 7.0.1 20170203 (experimental) [trunk revision 245148] (GCC) $ $ clang++ -c -std=c++11 small.cpp $ $ g++-trunk -c -std=c++11 small.cpp small.cpp: In lambda function: small.cpp:6:5: error: Local declaration from a different function [&] { decltype (b) c; } (); ^ D.2056 small.cpp:6:22: note: in statement [&] { decltype (b) c; } (); ^ _1 = (sizetype) D.2056; small.cpp:6:5: error: Local declaration from a different function [&] { decltype (b) c; } (); ^ D.2056 small.cpp:6:22: note: in statement [&] { decltype (b) c; } (); ^ _5 = (sizetype) D.2056; small.cpp:6:5: internal compiler error: verify_gimple failed [&] { decltype (b) c; } (); ^ 0xe5e15d verify_gimple_in_cfg(function*, bool) ../../gcc-source-trunk/gcc/tree-cfg.c:5266 0xd3ac27 execute_function_todo ../../gcc-source-trunk/gcc/passes.c:1966 0xd3b595 execute_todo ../../gcc-source-trunk/gcc/passes.c:2016 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. $ --- int a = 1; void foo () { int b[a]; [&] { decltype (b) c; } (); }
[Bug c++/79294] [7 Regression] ICE in convert_nontype_argument, at cp/pt.c:6812
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79294 --- Comment #2 from Jason Merrill --- Author: jason Date: Fri Feb 3 19:44:21 2017 New Revision: 245168 URL: https://gcc.gnu.org/viewcvs?rev=245168&root=gcc&view=rev Log: PR c++/79294 - ICE with invalid template argument * pt.c (convert_nontype_argument_function): Check value-dependence. (convert_nontype_argument): Don't check it here for function ptrs. Added: trunk/gcc/testsuite/g++.dg/template/error57.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug target/79366] New: wrong result in cast to unsigned int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79366 Bug ID: 79366 Summary: wrong result in cast to unsigned int Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: bernd.edlinger at hotmail dot de Target Milestone: --- the following returns an unexpected result: cat test.c double f = -1.0; int main() { int g = (unsigned int)(f); __builtin_printf("%d\n", g); } gcc test.c ./a.out 0 that is only on arm-Linux-gnueabihf other targets return -1 here. Dump of assembler code for function main: 0x000103c0 <+0>: push{r11, lr} 0x000103c4 <+4>: add r11, sp, #4 0x000103c8 <+8>: sub sp, sp, #8 => 0x000103cc <+12>:movwr3, #1440 ; 0x5a0 0x000103d0 <+16>:movtr3, #2 0x000103d4 <+20>:vldrd7, [r3] 0x000103d8 <+24>:vcvt.u32.f64s15, d7 0x000103dc <+28>:vmovr3, s15 0x000103e0 <+32>:str r3, [r11, #-8] 0x000103e4 <+36>:ldr r1, [r11, #-8] 0x000103e8 <+40>:movwr0, #1140 ; 0x474 0x000103ec <+44>:movtr0, #1 0x000103f0 <+48>:bl 0x102a0 0x000103f4 <+52>:mov r3, #0 0x000103f8 <+56>:mov r0, r3 0x000103fc <+60>:sub sp, r11, #4 0x00010400 <+64>:pop {r11, pc}
[Bug target/78838] msp430 option -mcode-region=either, -ffunction-sections, and interrupt function attributes cause incorrect section to be created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78838 Jozef Lawrynowicz changed: What|Removed |Added CC||jozef.l at somniumtech dot com --- Comment #1 from Jozef Lawrynowicz --- Reproduced with GCC 6.2.1.
[Bug target/79364] some variadic functions with an empty struct miscompiled with C++ (at least for x64 targets)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79364 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code --- Comment #1 from Andrew Pinski --- I thought there was another bug filed for this. Basically x86_64 back-end is treating this empty struct incorrectly. In the case of C++, empty struct sizeof cannot be 0 so it is 1. But GNU C defines the sizeof of an empty struct to be 0. There is some confusion in either the calleer or callee part of argument passing.
[Bug target/79365] New: tile*: incorrect result for expressions where result of a vector compare is used as a scalar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79365 Bug ID: 79365 Summary: tile*: incorrect result for expressions where result of a vector compare is used as a scalar Product: gcc Version: 7.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: walt at tilera dot com Target Milestone: --- The following code is miscompiled by gcc: unsigned long foo(unsigned long v, unsigned char byte) { return __insn_v1cmpeq (v, byte) >> 1; } __insn_v1cmpeq is the intrinsic for byte-wise vector compare. This gets compiled to: movei r0, 0 jrp lr The v1cmpeq has been incorrectly eliminated. This bug shows up in our target-optimized strcmp routines in glibc.
[Bug tree-optimization/79327] [7 Regression] wrong code at -O2 and -fprintf-return-value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79327 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Jakub Jelinek --- Fixed. Martin is going to adjust plans for some warning tweaks, but both wrong-code issues should be fixed now.
[Bug libstdc++/66145] [5/6/7 Regression] std::ios_base::failure objects thrown from libstdc++.so use old ABI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66145 --- Comment #31 from Jonathan Wakely --- Author: redi Date: Fri Feb 3 19:26:51 2017 New Revision: 245167 URL: https://gcc.gnu.org/viewcvs?rev=245167&root=gcc&view=rev Log: PR libstdc++/66145 ensure new ABI for ios::failure tests PR libstdc++/66145 * testsuite/27_io/basic_ios/copyfmt/char/1.cc: Restore ABI override so new ios::failure can be caught even when old ABI is the default. * testsuite/27_io/basic_ios/exceptions/char/1.cc: Likewise. * testsuite/27_io/basic_istream/extractors_arithmetic/char/ exceptions_failbit.cc: Likewise. * testsuite/27_io/basic_istream/extractors_arithmetic/wchar_t/ exceptions_failbit.cc: Likewise. * testsuite/27_io/basic_istream/extractors_other/char/ exceptions_null.cc: Likewise. * testsuite/27_io/basic_istream/extractors_other/wchar_t/ exceptions_null.cc: Likewise. * testsuite/27_io/basic_istream/sentry/char/12297.cc: Likewise. * testsuite/27_io/basic_istream/sentry/wchar_t/12297.cc: Likewise. * testsuite/27_io/basic_ostream/inserters_other/char/ exceptions_null.cc: Likewise. * testsuite/27_io/basic_ostream/inserters_other/wchar_t/ exceptions_null.cc: Likewise. * testsuite/27_io/ios_base/storage/2.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/27_io/basic_ios/copyfmt/char/1.cc trunk/libstdc++-v3/testsuite/27_io/basic_ios/exceptions/char/1.cc trunk/libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/char/exceptions_failbit.cc trunk/libstdc++-v3/testsuite/27_io/basic_istream/extractors_arithmetic/wchar_t/exceptions_failbit.cc trunk/libstdc++-v3/testsuite/27_io/basic_istream/extractors_other/char/exceptions_null.cc trunk/libstdc++-v3/testsuite/27_io/basic_istream/extractors_other/wchar_t/exceptions_null.cc trunk/libstdc++-v3/testsuite/27_io/basic_istream/sentry/char/12297.cc trunk/libstdc++-v3/testsuite/27_io/basic_istream/sentry/wchar_t/12297.cc trunk/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/char/exceptions_null.cc trunk/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_other/wchar_t/exceptions_null.cc trunk/libstdc++-v3/testsuite/27_io/ios_base/storage/2.cc
[Bug c++/79331] ICE on valid C++14 code (with initialized lambda capture) on x86_64-linux-gnu: in canonicalize_component_ref, at gimplify.c:2451
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79331 --- Comment #3 from Zhendong Su --- (In reply to Richard Biener from comment #2) > rejected with GCC 6: > > t.C: In function ‘int bar()’: > t.C:5:12: error: invalid initialization of non-const reference of type ‘int > (*&)()’ from an rvalue of type ‘int (*)()’ > return [&f (foo)] > ^ > > and clang: > > t.C:5:12: error: expected expression > return [&f (foo)] >^ This is valid C++14 code, and correctly accepted by both Clang and ICC: $ icc -c -std=c++14 small.cpp $ clang++ -c -std=c++14 small.cpp $ $ g++-6.2 -c -std=c++14 small.cpp small.cpp: In function ‘int bar()’: small.cpp:5:10: error: invalid initialization of non-const reference of type ‘int (*&)()’ from an rvalue of type ‘int (*)()’ return [&f (foo)] ^ $
[Bug c++/79364] New: some variadic functions miscompiled (at least for x64 targets)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79364 Bug ID: 79364 Summary: some variadic functions miscompiled (at least for x64 targets) Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: xilun0 at gmail dot com Target Milestone: --- Hello, G++ miscompiles the following program at least for x64, at least from gcc 4.7 to 7.0 20170115 Compiling with or without O2 changes the observed behavior (segfault or garbage) but the program is miscompiled in both cases. gcc seems to compile the corresponding C program correctly. The expected output is: 1 2 3 4 5 6 coucou The actual "output" is a segfault or some garbage instead of "coucou" Cheers! #include #include struct vatag {}; void tst(vatag tag, ...) { int i; va_list ap; va_start(ap, tag); #define P_INT i = va_arg(ap, int); printf("%i ", i); P_INT P_INT P_INT P_INT P_INT P_INT const char* s = va_arg(ap, char*); printf("%s\n", s); va_end(ap); } int main(void) { tst(vatag{}, 1, 2, 3, 4, 5, 6, "coucou"); }
[Bug tree-optimization/79327] [7 Regression] wrong code at -O2 and -fprintf-return-value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79327 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Fri Feb 3 19:16:39 2017 New Revision: 245166 URL: https://gcc.gnu.org/viewcvs?rev=245166&root=gcc&view=rev Log: PR tree-optimization/79327 * gimple-ssa-sprintf.c (adjust_range_for_overflow): If returning true, always set *argmin and *argmax to TYPE_{MIN,MAX}_VALUE of dirtype. (format_integer): Use wide_int_to_tree instead of build_int_cst + to_?hwi. If argmin is NULL, just set argmin and argmax to TYPE_{MIN,MAX}_VALUE of argtype. Simplify and fix computation of shortest and longest sequence. * gcc.dg/tree-ssa/pr79327.c: New test. * gcc.dg/tree-ssa/builtin-sprintf-warn-1.c (test_sprintf_chk_hh_nonconst): Don't expect 2 bogus warnings. * gcc.dg/tree-ssa/builtin-sprintf-warn-3.c (test_sprintf_chk_range_schar): Adjust dg-message. * gcc.dg/tree-ssa/builtin-sprintf-warn-12.c: New test. * gcc.c-torture/execute/pr79327.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr79327.c trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-12.c trunk/gcc/testsuite/gcc.dg/tree-ssa/pr79327.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-ssa-sprintf.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-1.c trunk/gcc/testsuite/gcc.dg/tree-ssa/builtin-sprintf-warn-3.c
[Bug testsuite/65484] FAIL: g++.dg/vect/pr36648.cc on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65484 Bill Schmidt changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Bill Schmidt --- Fixed everywhere.
[Bug testsuite/65484] FAIL: g++.dg/vect/pr36648.cc on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65484 --- Comment #5 from Bill Schmidt --- Author: wschmidt Date: Fri Feb 3 19:08:10 2017 New Revision: 245165 URL: https://gcc.gnu.org/viewcvs?rev=245165&root=gcc&view=rev Log: 2017-02-03 Bill Schmidt Backport from mainline 2017-01-27 Bill Schmidt PR target/65484 * g++.dg/vect/pr36648.cc: Modify to reflect that the loop is not vectorized on POWER unless hardware misaligned loads are available. Modified: branches/gcc-6-branch/gcc/testsuite/ChangeLog branches/gcc-6-branch/gcc/testsuite/g++.dg/vect/pr36648.cc
[Bug testsuite/65484] FAIL: g++.dg/vect/pr36648.cc on powerpc64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65484 --- Comment #4 from Bill Schmidt --- Author: wschmidt Date: Fri Feb 3 19:06:58 2017 New Revision: 245164 URL: https://gcc.gnu.org/viewcvs?rev=245164&root=gcc&view=rev Log: 2017-02-03 Bill Schmidt Backport from mainline 2017-01-27 Bill Schmidt PR target/65484 * g++.dg/vect/pr36648.cc: Modify to reflect that the loop is not vectorized on POWER unless hardware misaligned loads are available. Modified: branches/gcc-5-branch/gcc/testsuite/ChangeLog branches/gcc-5-branch/gcc/testsuite/g++.dg/vect/pr36648.cc
[Bug libstdc++/60936] [5/6/7 Regression] Binary code bloat with std::string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60936 --- Comment #27 from Jonathan Wakely --- Author: redi Date: Fri Feb 3 18:59:05 2017 New Revision: 245162 URL: https://gcc.gnu.org/viewcvs?rev=245162&root=gcc&view=rev Log: PR libstdc++/60936 reduce coupling between objects in libstdc++.a Move explicit instantiation definitions for string I/O functions into their own files so that iostream and locale definitions are not needed for uses of strings without I/O. Move functions for throwing C++11 exceptions into the individual files defining the exception types, so that using any of the functions from functexcept.cc doesn't pull in large pieces of the C++11 library. Finally, avoid using __int_to_char in snprintf_lite.cc to avoid pulling in locale-inst.cc for one function. PR libstdc++/60936 * src/c++11/Makefile.am: Add new files. * src/c++11/Makefile.in: Regenerate. * src/c++11/cow-string-inst.cc [!_GLIBCXX_USE_CXX11_ABI] (operator<<, operator>>, getline): Move explicit instantiations to ... * src/c++11/cow-string-io-inst.cc: ... new file. * src/c++11/cow-wstring-inst.cc [!_GLIBCXX_USE_CXX11_ABI] (operator<<, operator>>, getline): Move explicit instantiations to ... * src/c++11/cow-wstring-io-inst.cc: ... new file. * src/c++11/functexcept.cc (__throw_ios_failure, __throw_system_error) (__throw_future_error, __throw_bad_function_call): (__throw_regex_error): Move functions for C++11 exceptions to the files that define the exception types. * src/c++11/functional.cc (__throw_bad_function_call): Move here. * src/c++11/future.cc (__throw_future_error): Likewise. * src/c++11/ios.cc (__throw_ios_failure): Likewise. * src/c++11/regex.cc (__throw_regex_error): Likewise. * src/c++11/snprintf_lite.cc (__concat_size_t): Print decimal representation directly instead of calling __int_to_char. * src/c++11/sso_string.cc (__sso_string): New file for definition of __sso_string type. * src/c++11/string-io-inst.cc [_GLIBCXX_USE_CXX11_ABI]: New file for explicit instantiations of narrow string I/O functions. * src/c++11/system_error.cc (__throw_system_error): Move here. (__sso_string): Move to new file. * src/c++11/wstring-io-inst.cc [_GLIBCXX_USE_CXX11_ABI]: New file for explicit instantiations of wide string I/O functions. * src/c++98/misc-inst.cc [_GLIBCXX_USE_CXX11_ABI] (operator<<) (operator>>, getline): Remove explicit instantiations from here. Added: trunk/libstdc++-v3/src/c++11/cow-string-io-inst.cc - copied, changed from r245159, trunk/libstdc++-v3/src/c++11/cow-wstring-inst.cc trunk/libstdc++-v3/src/c++11/cow-wstring-io-inst.cc - copied, changed from r245159, trunk/libstdc++-v3/src/c++11/cow-wstring-inst.cc trunk/libstdc++-v3/src/c++11/sso_string.cc - copied, changed from r245159, trunk/libstdc++-v3/src/c++11/system_error.cc trunk/libstdc++-v3/src/c++11/string-io-inst.cc - copied, changed from r245159, trunk/libstdc++-v3/src/c++11/functional.cc trunk/libstdc++-v3/src/c++11/wstring-io-inst.cc - copied, changed from r245159, trunk/libstdc++-v3/src/c++11/cow-wstring-inst.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/src/c++11/Makefile.am trunk/libstdc++-v3/src/c++11/Makefile.in trunk/libstdc++-v3/src/c++11/cow-string-inst.cc trunk/libstdc++-v3/src/c++11/cow-wstring-inst.cc trunk/libstdc++-v3/src/c++11/functexcept.cc trunk/libstdc++-v3/src/c++11/functional.cc trunk/libstdc++-v3/src/c++11/future.cc trunk/libstdc++-v3/src/c++11/ios.cc trunk/libstdc++-v3/src/c++11/regex.cc trunk/libstdc++-v3/src/c++11/snprintf_lite.cc trunk/libstdc++-v3/src/c++11/system_error.cc trunk/libstdc++-v3/src/c++98/misc-inst.cc
[Bug target/78862] tile*: ICE with -fstack-protetor-strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78862 --- Comment #2 from walt at gcc dot gnu.org --- Author: walt Date: Fri Feb 3 18:46:57 2017 New Revision: 245160 URL: https://gcc.gnu.org/viewcvs?rev=245160&root=gcc&view=rev Log: PR target/78862 * config/tilegx/tilegx.md (tilegx_expand_prologue): Add blockage after initial stackframe link reg save. * config/tilepro/tilepro.md (tilepro_expand_prologue): Likewise. Modified: branches/gcc-6-branch/gcc/ChangeLog branches/gcc-6-branch/gcc/config/tilegx/tilegx.c branches/gcc-6-branch/gcc/config/tilepro/tilepro.c
[Bug target/78862] tile*: ICE with -fstack-protetor-strong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78862 --- Comment #1 from walt at gcc dot gnu.org --- Author: walt Date: Fri Feb 3 18:41:57 2017 New Revision: 245159 URL: https://gcc.gnu.org/viewcvs?rev=245159&root=gcc&view=rev Log: PR target/78862 * config/tilegx/tilegx.md (tilegx_expand_prologue): Add blockage after initial stackframe link reg save. * config/tilepro/tilepro.md (tilepro_expand_prologue): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/tilegx/tilegx.c trunk/gcc/config/tilepro/tilepro.c
[Bug c++/79363] New: [6/7 Regression] ICE with NSDMI and array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79363 Bug ID: 79363 Summary: [6/7 Regression] ICE with NSDMI and array Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: reichelt at gcc dot gnu.org Target Milestone: --- The following valid code snippet triggers an ICE since GCC 6.1.0: == struct A {}; struct B { B() {} int i; A a[]{}; }; == bug.cc: In constructor 'B::B()': bug.cc:5:7: internal compiler error: tree check: expected tree that contains 'common' structure, have 'constructor' in perform_member_init, at cp/init.c:725 B() {} ^ 0x10301f4 tree_contains_struct_check_failed(tree_node const*, tree_node_structure_enum, char const*, int, char const*) ../../gcc/gcc/tree.c:9986 0x7c3da2 contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*) ../../gcc/gcc/tree.h:3174 0x7c3da2 perform_member_init ../../gcc/gcc/cp/init.c:725 0x7c3da2 emit_mem_initializers(tree_node*) ../../gcc/gcc/cp/init.c:1203 0x76a3d6 cp_parser_ctor_initializer_opt ../../gcc/gcc/cp/parser.c:14016 0x76a3d6 cp_parser_ctor_initializer_opt_and_function_body ../../gcc/gcc/cp/parser.c:21423 0x772dc1 cp_parser_function_definition_after_declarator ../../gcc/gcc/cp/parser.c:26206 0x77319c cp_parser_late_parsing_for_member ../../gcc/gcc/cp/parser.c:27088 0x74f9c9 cp_parser_class_specifier_1 ../../gcc/gcc/cp/parser.c:22292 0x750a59 cp_parser_class_specifier ../../gcc/gcc/cp/parser.c:22318 0x750a59 cp_parser_type_specifier ../../gcc/gcc/cp/parser.c:16409 0x751827 cp_parser_decl_specifier_seq ../../gcc/gcc/cp/parser.c:13326 0x778901 cp_parser_simple_declaration ../../gcc/gcc/cp/parser.c:12647 0x779845 cp_parser_block_declaration ../../gcc/gcc/cp/parser.c:12592 0x752527 cp_parser_declaration ../../gcc/gcc/cp/parser.c:12489 0x782c8b cp_parser_declaration_seq_opt ../../gcc/gcc/cp/parser.c:12365 0x782f6a cp_parser_translation_unit ../../gcc/gcc/cp/parser.c:4369 0x782f6a c_parse_file() ../../gcc/gcc/cp/parser.c:38356 0x8df643 c_common_parse_file() ../../gcc/gcc/c-family/c-opts.c:1107 Please submit a full bug report, [etc.]
[Bug c++/79362] New: internal compiler error: Segmentation fault - mmap: Cannot allocate memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79362 Bug ID: 79362 Summary: internal compiler error: Segmentation fault - mmap: Cannot allocate memory Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: falemagn at gmail dot com Target Milestone: --- I cannot reproduce the bug locally, so I cannot provide more details, but it does happen on godbolt where I was experimenting with the adherence to the standard of various compilers. This is the code that fails: struct Base { }; struct Derived: Base { using Base::Base; Derived(int value): m_value(value) {} int m_value; }; Derived t; The error given reads like this: :14:9: internal compiler error: Segmentation fault Derived t; ^ mmap: Cannot allocate memory Locally, I've traced the compiler with the massif valgrind's tool, but the maximum amount of memory allocated was at around 1MiB. You can check gcc7 output on godbolt at this link: https://godbolt.org/g/FnyE9N
[Bug rtl-optimization/64081] [5/6/7 Regression] r217827 prevents RTL loop unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081 --- Comment #36 from David Edelsohn --- The DBX_CONTIN patch should be in gcc/xcoffout.h, not in rs6000.h. The patch originally was added 2015-02-06.
[Bug target/79354] [7 Regression] -mcpu=power8 -O2 generates power9 instruction on powerpc64le-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79354 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jakub Jelinek --- Fixed.
[Bug target/79353] [7 regression] ICE in curr_insn_transform, at lra-constraints.c:3773
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79353 Eric Botcazou changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org --- Comment #4 from Eric Botcazou --- Fixing.
[Bug target/79353] [7 regression] ICE in curr_insn_transform, at lra-constraints.c:3773
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79353 Eric Botcazou changed: What|Removed |Added Status|WAITING |NEW --- Comment #3 from Eric Botcazou --- > This was reduced from parfor.c with the help of creduce. To reproduce > (minimal set of flags I found): > > /home/jrtc27/src/gcc/obj/./gcc/xgcc -B/home/jrtc27/src/gcc/obj/./gcc/ > -B/usr/local/sparc64-unknown-linux-gnu/bin/ > -B/usr/local/sparc64-unknown-linux-gnu/lib/ -m32 -fPIC -O2 -c parfor.i -o > /tmp/parfor.o Thanks, I can reproduce with -mcpu=v8.
[Bug c/79358] gcc.dg/c99-stdint-1.c fails with excess error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358 --- Comment #11 from Jakub Jelinek --- OT, the gcc/config/s390/linux.h SIZE_TYPE definition looks weird: (TARGET_64BIT ? "long unsigned int" : "long unsigned int") As both strings are the same, it would be much cleaner to just say "long unsigned int" Now everybody reading it will just try to spot the changes between those 2 strings.
[Bug c++/79361] New: [5/6/7 Regression] ICE redefining a template function as defaulted or deleted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79361 Bug ID: 79361 Summary: [5/6/7 Regression] ICE redefining a template function as defaulted or deleted 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: reichelt at gcc dot gnu.org Target Milestone: --- The following two invalid testcases trigger ICEs on trunk: === template void foo(T); template<> void foo(int) {} template<> void foo(int) = delete; === bug.cc:4:17: error: redefinition of 'void foo(T) [with T = int]' template<> void foo(int) = delete; ^~~~ bug.cc:3:17: note: 'void foo(T) [with T = int]' previously declared here template<> void foo(int) {} ^~~~ bug.cc: In function 'void foo(T) [with T = int]': bug.cc:3:17: internal compiler error: tree check: expected block, have error_mark in lower_function_body, at gimple-low.c:98 0x102f4bc tree_check_failed(tree_node const*, char const*, int, char const*, ...) ../../gcc/gcc/tree.c:9814 0x14904c7 tree_check(tree_node*, char const*, int, char const*, tree_code) ../../gcc/gcc/tree.h:3060 0x14904c7 lower_function_body ../../gcc/gcc/gimple-low.c:98 0x14904c7 execute ../../gcc/gcc/gimple-low.c:181 Please submit a full bug report, [etc.] === template void foo(T); template<> void foo(int) {} template<> void foo(int) = default; === bug.cc:4:17: error: redefinition of 'void foo(T) [with T = int]' template<> void foo(int) = default; ^~~~ bug.cc:3:17: note: 'void foo(T) [with T = int]' previously declared here template<> void foo(int) {} ^~~~ bug.cc:4:33: error: a template cannot be defaulted template<> void foo(int) = default; ^~~ bug.cc: In function 'void foo(T) [with T = int]': bug.cc:3:17: internal compiler error: Segmentation fault template<> void foo(int) {} ^~~~ 0xd9292f crash_signal ../../gcc/gcc/toplev.c:333 0x14901ae tree_check(tree_node*, char const*, int, char const*, tree_code) ../../gcc/gcc/tree.h:3059 0x14901ae lower_function_body ../../gcc/gcc/gimple-low.c:98 0x14901ae execute ../../gcc/gcc/gimple-low.c:181 Please submit a full bug report, [etc.] These bugs appeared in GCC 4.5.0.
[Bug c/79358] gcc.dg/c99-stdint-1.c fails with excess error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358 --- Comment #10 from Jakub Jelinek --- It is a pitty glibc headers didn't use __SIZE_MAX__ if available, because that appears to be correct.
[Bug c/79358] gcc.dg/c99-stdint-1.c fails with excess error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- What glibc do you have? E.g. glibc 2.24 has in stdint.h # if __WORDSIZE == 64 # define SIZE_MAX (18446744073709551615UL) # else # ifdef __WORDSIZE32_SIZE_ULONG # define SIZE_MAX (4294967295UL) # else # define SIZE_MAX (4294967295U) # endif # endif and it seems s390 defines the right macros: ./sysdeps/s390/s390-32/bits/wordsize.h:# define __WORDSIZE32_SIZE_ULONG 1 ./sysdeps/s390/s390-64/bits/wordsize.h:# define __WORDSIZE32_SIZE_ULONG 1 so even SIZE_MAX should be unsigned long. While e.g. RHEL7 glibc (2.17) has: # if __WORDSIZE == 64 # define SIZE_MAX (18446744073709551615UL) # else # define SIZE_MAX (4294967295U) # endif so it seems this test actually tests libc rather than gcc if stdint.h is provided by libc and not gcc.
[Bug target/79354] [7 Regression] -mcpu=power8 -O2 generates power9 instruction on powerpc64le-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79354 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Fri Feb 3 17:34:56 2017 New Revision: 245157 URL: https://gcc.gnu.org/viewcvs?rev=245157&root=gcc&view=rev Log: PR target/79354 * config/rs6000/rs6000.md (movsi_from_sf): Use wb constraint instead of wu for stxssp alternative. * gcc.target/powerpc/pr79354.c: New test. * gcc.c-torture/execute/pr79354.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr79354.c trunk/gcc/testsuite/gcc.target/powerpc/pr79354.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.md trunk/gcc/testsuite/ChangeLog
[Bug c++/68858] Cannot use fold expression in requirements with two parameters packs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68858 --- Comment #1 from Casey Carter --- This seems to be a duplicate of PR 68812.
[Bug c/79358] gcc.dg/c99-stdint-1.c fails with excess error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358 --- Comment #8 from Dominik Vogt --- Gdb says: (gdb) ptype __typeof__(size_t) type = unsigned long (gdb) ptype __typeof__(SIZE_MAX) type = unsigned int Two different types for unsigned 32 bit integers.
[Bug c/79358] gcc.dg/c99-stdint-1.c fails with excess error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358 --- Comment #7 from Dominik Vogt --- Or even -- #include #include #define FOO(TYPE, EXPR) __typeof__(EXPR) a; __typeof__((TYPE)0 + 0) *b = &a; void foo (void) { FOO(__SIZE_TYPE__, (SIZE_MAX)); } -- So __typeof__(SIZE_MAX) is different from __typeof__(__SIZE_TYPE__) when using -m31.
[Bug c/79358] gcc.dg/c99-stdint-1.c fails with excess error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358 --- Comment #6 from Dominik Vogt --- (In reply to Andreas Krebbel from comment #2) > The reduced testcase fails with -m31 and -m64 but the original probably only > with -m31 - right?! Sorry, you're right. I was doing too many things in parallel. Another attempt at reduction: -- #include #include #define CHECK_UNSIGNED(TYPE) \ do { TYPE a; int b[(TYPE)-1 < 0 ? -1 : 1]; } while (0) #define CHECK_EXPR_TYPE(TYPE, EXPR) \ do { __typeof__(EXPR) a; __typeof__((TYPE)0 + 0) *b = &a; } while (0) #define UNSIGNED_MAX_COND(TYPE, EXPR) \ ((EXPR) == (TYPE)-1) #define CHECK_UNSIGNED_LIMITS_2(TYPE, MAX, MAXBD) \ CHECK_UNSIGNED(TYPE); \ CHECK_EXPR_TYPE(TYPE, (MAX)); \ do { int a[(UNSIGNED_MAX_COND(TYPE, (MAX))\ && (MAX) >= (MAXBD)) ? 1 : -1]; } while (0) void test_misc_limits (void) { CHECK_UNSIGNED_LIMITS_2(__SIZE_TYPE__, SIZE_MAX, 65535U); } --
[Bug c/79358] gcc.dg/c99-stdint-1.c fails with excess error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358 --- Comment #5 from joseph at codesourcery dot com --- On Fri, 3 Feb 2017, vogt at linux dot vnet.ibm.com wrote: > void > foo (void) > { > __typeof__((4294967295U)) a; > __typeof__((long unsigned int)0 + 0) *b = &a; > } That's not a meaningful reduction. The relevant reduction would be to just one of the CHECK_* macro calls in the test, which would show which macro (in the system's header) has an incorrect definition. You could then consider fixing this with a fixincludes fix for buggy system headers (as well as fixing the headers upstream).
[Bug c++/79360] New: [5.4/6/7 Regression] ICE with NSDMI and enum in union
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79360 Bug ID: 79360 Summary: [5.4/6/7 Regression] ICE with NSDMI and enum in union Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: reichelt at gcc dot gnu.org Target Milestone: --- Compiling the following valid code results in a crash === union U { enum E { e }; }; struct A { U u{}; }; === bug3.cc:8:7: internal compiler error: in process_init_constructor_union, at cp/typeck2.c:1562 U u{}; ^ 0x6f222d process_init_constructor_union ../../gcc/gcc/cp/typeck2.c:1561 0x6f222d process_init_constructor ../../gcc/gcc/cp/typeck2.c:1616 0x6f222d digest_init_r ../../gcc/gcc/cp/typeck2.c:1125 0x6f4230 digest_init_flags(tree_node*, tree_node*, int, int) ../../gcc/gcc/cp/typeck2.c:1170 0x6f4230 digest_nsdmi_init(tree_node*, tree_node*) ../../gcc/gcc/cp/typeck2.c:1186 0x76539f cp_parser_late_parse_one_default_arg ../../gcc/gcc/cp/parser.c:27167 0x74f693 cp_parser_late_parsing_nsdmi ../../gcc/gcc/cp/parser.c:27200 0x74f693 cp_parser_class_specifier_1 ../../gcc/gcc/cp/parser.c:22265 0x750a59 cp_parser_class_specifier ../../gcc/gcc/cp/parser.c:22318 0x750a59 cp_parser_type_specifier ../../gcc/gcc/cp/parser.c:16409 0x751827 cp_parser_decl_specifier_seq ../../gcc/gcc/cp/parser.c:13326 0x778901 cp_parser_simple_declaration ../../gcc/gcc/cp/parser.c:12647 0x779845 cp_parser_block_declaration ../../gcc/gcc/cp/parser.c:12592 0x752527 cp_parser_declaration ../../gcc/gcc/cp/parser.c:12489 0x782c8b cp_parser_declaration_seq_opt ../../gcc/gcc/cp/parser.c:12365 0x782f6a cp_parser_translation_unit ../../gcc/gcc/cp/parser.c:4369 0x782f6a c_parse_file() ../../gcc/gcc/cp/parser.c:38356 0x8df643 c_common_parse_file() ../../gcc/gcc/c-family/c-opts.c:1107 Please submit a full bug report, [etc.] This bug appears in GCC 5.4.0, 6.x, 7.0, but not in GCC 5.3.0 or before.
[Bug tree-optimization/79352] [7 Regression] -fprintf-return-value doesn't handle flexible-like array members properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79352 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Sebor --- Fix committed in r245156.
[Bug tree-optimization/79352] [7 Regression] -fprintf-return-value doesn't handle flexible-like array members properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79352 --- Comment #3 from Martin Sebor --- Author: msebor Date: Fri Feb 3 16:38:15 2017 New Revision: 245156 URL: https://gcc.gnu.org/viewcvs?rev=245156&root=gcc&view=rev Log: PR tree-optimization/79352 - -fprintf-return-value doesn't handle flexible-like array members properly gcc/ChangeLog: PR tree-optimization/79352 * gimple-fold.c (get_range_strlen): Add argument. (get_range_strlen): Change return type to bool. (get_maxval_strlen): Pass in a dummy argument. * gimple-fold.h (get_range_strlen): Change return type to bool. * gimple-ssa-sprintf.c (get_string_length): Set unlikely counter. * tree.h (array_at_struct_end_p): Add argument. * tree.c (array_at_struct_end_p): Handle it. gcc/testsuite/ChangeLog: PR tree-optimization/79352 * gcc.dg/tree-ssa/pr79352.c: New test. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr79352.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-fold.c trunk/gcc/gimple-fold.h trunk/gcc/gimple-ssa-sprintf.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree.c trunk/gcc/tree.h
[Bug target/77333] Incorrect stack adjust in epilogue when targeting i686-w64-mingw32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77333 --- Comment #17 from Martin Jambor --- OK, so it turns out I botched my testing and the patch from the previous commit cause PR57330 and we would need something like the patch below (with a big fat comment why the condition is necessary, if we go this way at all, that is). Still, I need someone to test this really helps to fix the problem and to do a testsuite run. [PR 77333] Set clone call fntype to callee type 2017-02-03 Martin Jambor PR target/77333 * cgraph.c (redirect_call_stmt_to_callee): Set call stmt fntype to type of the decl if lhs has compatible type. diff --git a/gcc/cgraph.c b/gcc/cgraph.c index ef2dc50282c..b91de6788c7 100644 --- a/gcc/cgraph.c +++ b/gcc/cgraph.c @@ -1425,7 +1425,15 @@ cgraph_edge::redirect_call_stmt_to_callee (void) new_stmt = chkp_copy_call_skip_bounds (new_stmt); gimple_call_set_fndecl (new_stmt, e->callee->decl); - gimple_call_set_fntype (new_stmt, gimple_call_fntype (e->call_stmt)); + + tree lhs = gimple_call_lhs (new_stmt); + tree decl_restype = TREE_TYPE (TREE_TYPE (e->callee->decl)); + if (lhs + && (VOID_TYPE_P (decl_restype) + || !useless_type_conversion_p (TREE_TYPE (lhs), decl_restype))) + gimple_call_set_fntype (new_stmt, gimple_call_fntype (e->call_stmt)); + else + gimple_call_set_fntype (new_stmt, TREE_TYPE (e->callee->decl)); if (gimple_vdef (new_stmt) && TREE_CODE (gimple_vdef (new_stmt)) == SSA_NAME)
[Bug rtl-optimization/64081] [5/6/7 Regression] r217827 prevents RTL loop unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081 --- Comment #35 from Aldy Hernandez --- Hmmm, I see the changes in gcc/dbxout.h may override the DBX_* changes I made to config/rs6000/rs6000.h. I'll attempt to patch gcc/dbxout.h instead. I will report back. BTW David, if there's a point in the GCC history with stabs continuation support you suggest I start my bisection, let me know. Hopefully that will also exhibit a bootstrap failure with the RTL patch in this PR.
[Bug middle-end/78468] [7 regression] libgomp.c/reduction-10.c and many more FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78468 --- Comment #35 from Dominik Vogt --- (In reply to Eric Botcazou from comment #34) > > I still disagree with reverting the patch. There was plenty of time to > > identify and fix affected backends instead of doing nothing for half five > > months and then claiming that the patch is potentially too disruptive at > > this point in the release cycle. > > That was your job though and apparently you didn't do it. Don't be silly. I've fixed all regresseions that have shown up, except the one on Sparc because you refused to accept changes to the Sparc backend. It's all documented in this discussion thread, so please stop inventing excuses to put the blame on others.
[Bug c/79358] gcc.dg/c99-stdint-1.c fails with excess error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358 --- Comment #4 from Dominik Vogt --- I.e. this is a Glibc related problem? The test machine has Glibc-2.18.
[Bug c/79358] gcc.dg/c99-stdint-1.c fails with excess error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79358 --- Comment #3 from Dominik Vogt --- > The reduced testcase fails with -m31 and -m64 but the original probably only > with -m31 - right?! The unreduced testcase fails with -m31 and -m64. I've tried the reduced test case only with -m64.
[Bug rtl-optimization/64081] [5/6/7 Regression] r217827 prevents RTL loop unroll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64081 --- Comment #34 from Aldy Hernandez --- (In reply to David Edelsohn from comment #32) > How far are you going back in the bisection effort? You may be earlier than > the point at which GCC on AIX generated stab strings continuation lines. At > worst you manually can apply the continuation code from gcc/xcoffout.h > > /* XCOFF32 maximum length is 64K; XLC limits to 16K. */ > #define DBX_CONTIN_LENGTH 16384 > > /* XLC uses '?' as continuation character. */ > #define DBX_CONTIN_CHAR '?' David, thanks for your input here, BTW. Same problem, even if I add your above two lines to rs6000.h. I am starting with r219827 as suggested here: https://gcc.gnu.org/ml/gcc-patches/2016-02/msg00451.html The aforementioned revision gets us around January 18, 2015, which is around the time y'all were discussing the bootstrap failure. My tree contains: 1. The rtl patch being discussed 2. A patch for r233572 to get GCC 6.x to build GCC 5.x (see BZ#69959). 3. Your suggested changes for xcoff continuation. I am attaching the changes to r219827 that still exhibit STABSTRING ERROR problems while bootstrapping. These are in comment 33. Any tips greatly appareciated.