[Bug debug/84637] New: gcc/dbxout.c:684:14: runtime error: negation of -9223372036854775808 cannot be represented in type 'long int'; cast to an unsigned type to negate this value to itself
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84637 Bug ID: 84637 Summary: gcc/dbxout.c:684:14: runtime error: negation of -9223372036854775808 cannot be represented in type 'long int'; cast to an unsigned type to negate this value to itself Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- UBSAN boostrap compiler sees: $ UBSAN_OPTIONS="print_stacktrace=1" ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/debug/trivial.c -c -gstabs -fno-diagnostics-show-caret -fdiagnostics-color=never -gstabs -S -o trivial.S ../../gcc/dbxout.c:684:14: runtime error: negation of -9223372036854775808 cannot be represented in type 'long int'; cast to an unsigned type to negate this value to itself #0 0xd673a5 in stabstr_D ../../gcc/dbxout.c:684 #1 0xd73400 in dbxout_range_type ../../gcc/dbxout.c:1745 #2 0xd6eba8 in dbxout_type ../../gcc/dbxout.c:2042 #3 0xd75c43 in dbxout_symbol(tree_node*, int) ../../gcc/dbxout.c:2865 #4 0xd783b2 in dbxout_init ../../gcc/dbxout.c:1079 #5 0x74faa0 in lang_dependent_init ../../gcc/toplev.c:1920 #6 0x74faa0 in do_compile ../../gcc/toplev.c:2118 #7 0x74faa0 in toplev::main(int, char**) ../../gcc/toplev.c:2267 #8 0x751cba in main ../../gcc/main.c:39 #9 0x7fb2075a06e4 in __libc_start_main (/lib64/libc.so.6+0x206e4) #10 0x751de8 in _start (/home/marxin/Programming/gcc/objdir/gcc/cc1+0x751de8)
[Bug c++/84636] New: internal compiler error: Segmentation fault (identifier_p()/grokdeclarator())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84636 Bug ID: 84636 Summary: internal compiler error: Segmentation fault (identifier_p()/grokdeclarator()) Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: vegard.nossum at gmail dot com Target Milestone: --- Input: typedef void a(); struct { a: 1; }; Output: $ xgcc -x c++ -S - :3:6: internal compiler error: Segmentation fault 0x3150de9 crash_signal /home/vegard/git/gcc/gcc/toplev.c:325 0xc0c2f1 identifier_p(tree_node*) /home/vegard/git/gcc/gcc/cp/cp-tree.h:573 0xc0c2f1 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*, decl_context, int, tree_node**) /home/vegard/git/gcc/gcc/cp/decl.c:11934 0xc47de0 grokbitfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*, tree_node*, tree_node*) /home/vegard/git/gcc/gcc/cp/decl2.c:1038 0xfe10e5 cp_parser_member_declaration /home/vegard/git/gcc/gcc/cp/parser.c:23730 0xf160fb cp_parser_member_specification_opt /home/vegard/git/gcc/gcc/cp/parser.c:23363 0xf160fb cp_parser_class_specifier_1 /home/vegard/git/gcc/gcc/cp/parser.c:22505 0xf2501b cp_parser_class_specifier /home/vegard/git/gcc/gcc/cp/parser.c:22757 0xf2501b cp_parser_type_specifier /home/vegard/git/gcc/gcc/cp/parser.c:16763 0xf8aa5a cp_parser_decl_specifier_seq /home/vegard/git/gcc/gcc/cp/parser.c:13625 0xfa6620 cp_parser_simple_declaration /home/vegard/git/gcc/gcc/cp/parser.c:12934 0xfae548 cp_parser_block_declaration /home/vegard/git/gcc/gcc/cp/parser.c:12879 0x1001295 cp_parser_declaration /home/vegard/git/gcc/gcc/cp/parser.c:12776 0xff826b cp_parser_declaration_seq_opt /home/vegard/git/gcc/gcc/cp/parser.c:12652 0xff9893 cp_parser_translation_unit /home/vegard/git/gcc/gcc/cp/parser.c:4559 0xff9893 c_parse_file() /home/vegard/git/gcc/gcc/cp/parser.c:38880 0x15a51f5 c_common_parse_file() /home/vegard/git/gcc/gcc/c-family/c-opts.c:1132 $ xgcc --version xgcc (GCC) 8.0.1 20180228 (experimental) Built from git fd1990b25777e5f1307eac1447e8fb5fefe747b4 (r258063). Seems like versions all the way back to 4.4.7 (the oldest gcc on godbolt.org) segfault. I haven't tested older compilers. Test case was reduced by C-Reduce.
[Bug rtl-optimization/84635] New: gcc/regrename.c:1706:64: runtime error: index -1 out of bounds for type 'machine_mode [30]'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84635 Bug ID: 84635 Summary: gcc/regrename.c:1706:64: runtime error: index -1 out of bounds for type 'machine_mode [30]' Product: gcc Version: unknown Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Following test-case: $ cat error.i a () { a (); } $ UBSAN_OPTIONS="print_stacktrace=1" /dev/shm/objdir/gcc/xgcc -B /dev/shm/objdir/gcc/ -O1 -funroll-loops -c error.i -fmax-errors=1 error.i:1:1: warning: return type defaults to ‘int’ [-Wimplicit-int] a () { a (); } ^ /home/marxin/Programming/gcc2/gcc/regrename.c:1706:64: runtime error: index -1 out of bounds for type 'machine_mode [30]' #0 0x169bea1 in build_def_use /home/marxin/Programming/gcc2/gcc/regrename.c:1706 #1 0x1694d2f in regrename_analyze(bitmap_head*) /home/marxin/Programming/gcc2/gcc/regrename.c:742 #2 0x169dace in regrename_optimize /home/marxin/Programming/gcc2/gcc/regrename.c:1934 #3 0x169dbc6 in execute /home/marxin/Programming/gcc2/gcc/regrename.c:1971 #4 0x1598c61 in execute_one_pass(opt_pass*) /home/marxin/Programming/gcc2/gcc/passes.c:2497 #5 0x159942b in execute_pass_list_1 /home/marxin/Programming/gcc2/gcc/passes.c:2586 #6 0x15994a2 in execute_pass_list_1 /home/marxin/Programming/gcc2/gcc/passes.c:2587 #7 0x15994a2 in execute_pass_list_1 /home/marxin/Programming/gcc2/gcc/passes.c:2587 #8 0x1599522 in execute_pass_list(function*, opt_pass*) /home/marxin/Programming/gcc2/gcc/passes.c:2597 #9 0xc40833 in cgraph_node::expand() /home/marxin/Programming/gcc2/gcc/cgraphunit.c:2139 #10 0xc41740 in expand_all_functions /home/marxin/Programming/gcc2/gcc/cgraphunit.c:2275 #11 0xc430b8 in symbol_table::compile() /home/marxin/Programming/gcc2/gcc/cgraphunit.c:2624 #12 0xc43639 in symbol_table::finalize_compilation_unit() /home/marxin/Programming/gcc2/gcc/cgraphunit.c:2717 #13 0x18a7f43 in compile_file /home/marxin/Programming/gcc2/gcc/toplev.c:480 #14 0x18abd24 in do_compile /home/marxin/Programming/gcc2/gcc/toplev.c:2132 #15 0x18ac208 in toplev::main(int, char**) /home/marxin/Programming/gcc2/gcc/toplev.c:2267 #16 0x31e0f41 in main /home/marxin/Programming/gcc2/gcc/main.c:39 #17 0x75cfbf49 in __libc_start_main (/lib64/libc.so.6+0x20f49) #18 0x81e9d9 in _start (/dev/shm/objdir/gcc/cc1+0x81e9d9)
[Bug tree-optimization/84634] [8 Regression] gcc/tree-vect-stmts.c:6786:19: runtime error: member access within null pointer of type 'struct _loop_vec_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84634 Martin Liška changed: What|Removed |Added Target Milestone|--- |8.0
[Bug tree-optimization/84634] New: [8 Regression] gcc/tree-vect-stmts.c:6786:19: runtime error: member access within null pointer of type 'struct _loop_vec_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84634 Bug ID: 84634 Summary: [8 Regression] gcc/tree-vect-stmts.c:6786:19: runtime error: member access within null pointer of type 'struct _loop_vec_info Product: gcc Version: unknown Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: richard.sandiford at linaro dot org Target Milestone: --- Started probable since Richard's r256625: $ UBSAN_OPTIONS="print_stacktrace=1" ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gcc.c-torture/execute/20020129-1.c -O3 ../../gcc/tree-vect-stmts.c:6786:19: runtime error: member access within null pointer of type 'struct _loop_vec_info' #0 0x2b6462b in vectorizable_store ../../gcc/tree-vect-stmts.c:6786 #1 0x2ba7d19 in vect_transform_stmt(gimple*, gimple_stmt_iterator*, bool*, _slp_tree*, _slp_instance*) ../../gcc/tree-vect-stmts.c:9482 #2 0x2c91d42 in vect_schedule_slp_instance ../../gcc/tree-vect-slp.c:4187 #3 0x2c98669 in vect_schedule_slp(vec_info*) ../../gcc/tree-vect-slp.c:4256 #4 0x2cabcad in vect_slp_bb(basic_block_def*) ../../gcc/tree-vect-slp.c:3250 #5 0x2cba557 in execute ../../gcc/tree-vectorizer.c:978 #6 0x1b8f0ac in execute_one_pass(opt_pass*) ../../gcc/passes.c:2497 #7 0x1b92bc7 in execute_pass_list_1 ../../gcc/passes.c:2586 #8 0x1b92c0e in execute_pass_list_1 ../../gcc/passes.c:2587 #9 0x1b92c0e in execute_pass_list_1 ../../gcc/passes.c:2587 #10 0x1b92ce8 in execute_pass_list(function*, opt_pass*) ../../gcc/passes.c:2597 #11 0xce8eba in cgraph_node::expand() ../../gcc/cgraphunit.c:2139 #12 0xcee454 in expand_all_functions ../../gcc/cgraphunit.c:2275 #13 0xcee454 in symbol_table::compile() ../../gcc/cgraphunit.c:2624 #14 0xcf89c6 in symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.c:2717 #15 0x208763c in compile_file ../../gcc/toplev.c:480 #16 0x74ee29 in do_compile ../../gcc/toplev.c:2132 #17 0x74ee29 in toplev::main(int, char**) ../../gcc/toplev.c:2267 #18 0x751cba in main ../../gcc/main.c:39 #19 0x7fa721d2b6e4 in __libc_start_main (/lib64/libc.so.6+0x206e4) #20 0x751de8 in _start (/home/marxin/Programming/gcc/objdir/gcc/cc1+0x751de8) Can be easily triggered with: diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c index a98e0e5e259..db14c8063c4 100644 --- a/gcc/tree-vect-stmts.c +++ b/gcc/tree-vect-stmts.c @@ -6783,6 +6783,7 @@ vectorizable_store (gimple *stmt, gimple_stmt_iterator *gsi, gimple **vec_stmt, prev_stmt_info = NULL; tree vec_mask = NULL_TREE; + gcc_assert (loop_vinfo); vec_loop_masks *masks = &LOOP_VINFO_MASKS (loop_vinfo); for (j = 0; j < ncopies; j++) {
[Bug c/84631] make check in fixincludes fails seemingly due to star in directory names, on WSL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84631 --- Comment #2 from Jay --- Err oops let me look again. Failure must be something else then.
[Bug ipa/84628] attribute(warning/error) functions should not be merged together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84628 --- Comment #9 from Andrew Pinski --- deprecated deprecated (msg) The deprecated attribute results in a warning if the function is used anywhere in the source file. This is useful when identifying functions that are expected to be removed in a future version of a program. The warning also includes the location of the declaration of the deprecated function, to enable users to easily find further information about why the function is deprecated, or what they should do instead. Note that the warnings only occurs for uses: int old_fn () __attribute__ ((deprecated)); int old_fn (); int (*fn_ptr)() = old_fn; results in a warning on line 3 but not line 2. The optional msg argument, which must be a string, is printed in the warning if present. The deprecated attribute can also be used for variables and types (see Variable Attributes, see Type Attributes.)
[Bug c++/84633] New: internal compiler error: in lvalue_kind, at cp/tree.c:206
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84633 Bug ID: 84633 Summary: internal compiler error: in lvalue_kind, at cp/tree.c:206 Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: vegard.nossum at gmail dot com Target Milestone: --- Input: a (void[sizeof(0 = auto)]); Output: $ xgcc -x c++ -S -fpermissive - :1:20: error: expected primary-expression before 'auto' :1:19: error: expected ')' before 'auto' :1:26: internal compiler error: in lvalue_kind, at cp/tree.c:206 0x132aa6f lvalue_kind(tree_node const*) /home/vegard/git/gcc/gcc/cp/tree.c:206 0x132b560 bitfield_p(tree_node const*) /home/vegard/git/gcc/gcc/cp/tree.c:331 0x138f97a cxx_sizeof_expr /home/vegard/git/gcc/gcc/cp/typeck.c:1700 0x138f97a cxx_sizeof_or_alignof_expr(tree_node*, tree_code, bool) /home/vegard/git/gcc/gcc/cp/typeck.c:1802 0xf2c443 cp_parser_unary_expression /home/vegard/git/gcc/gcc/cp/parser.c:8017 0xec1cba cp_parser_cast_expression /home/vegard/git/gcc/gcc/cp/parser.c:9086 0xec42e6 cp_parser_binary_expression /home/vegard/git/gcc/gcc/cp/parser.c:9187 0xec80ba cp_parser_assignment_expression /home/vegard/git/gcc/gcc/cp/parser.c:9482 0xecde93 cp_parser_constant_expression /home/vegard/git/gcc/gcc/cp/parser.c:9766 0xf5da83 cp_parser_direct_declarator /home/vegard/git/gcc/gcc/cp/parser.c:20114 0xf621c0 cp_parser_declarator /home/vegard/git/gcc/gcc/cp/parser.c:19855 0xfb99c3 cp_parser_parameter_declaration /home/vegard/git/gcc/gcc/cp/parser.c:21555 0xfbc09a cp_parser_parameter_declaration_list /home/vegard/git/gcc/gcc/cp/parser.c:21307 0xfbed30 cp_parser_parameter_declaration_clause /home/vegard/git/gcc/gcc/cp/parser.c:21228 0xf5ad8f cp_parser_direct_declarator /home/vegard/git/gcc/gcc/cp/parser.c:19981 0xfa10a8 cp_parser_declarator /home/vegard/git/gcc/gcc/cp/parser.c:19855 0xfa137e cp_parser_init_declarator /home/vegard/git/gcc/gcc/cp/parser.c:19381 0xfa8357 cp_parser_simple_declaration /home/vegard/git/gcc/gcc/cp/parser.c:13061 0xfae548 cp_parser_block_declaration /home/vegard/git/gcc/gcc/cp/parser.c:12879 0x1001295 cp_parser_declaration /home/vegard/git/gcc/gcc/cp/parser.c:12776 $ xgcc --version xgcc (GCC) 8.0.1 20180228 (experimental) Built from git fd1990b25777e5f1307eac1447e8fb5fefe747b4 (r258063). Similar message to #52596 but that is an old bug. 7.3.0 seems fine. Test case was reduced by C-Reduce.
[Bug ipa/84628] attribute(warning/error) functions should not be merged together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84628 --- Comment #8 from Jay --- Aha, kinda the same thing, but before or after analysis. And this “deprecated” somewhat matches msvc - I was wondering about that but didn’t see it. It’d be nice to be able to customize the deprecated message but hopefully we’ll keep the baby despite the bathwater. (Msvc added that option later.) Thank you.
[Bug c/84631] make check in fixincludes fails seemingly due to star in directory names, on WSL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84631 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #1 from Andrew Pinski --- * is special as it is regex character and this won't be fixed as a good idea never to have files with * as the shells will always treat * as a wild card. Note a similar issue is with @ too.
[Bug c++/84616] funsafe-math-optimizations leads to incorrect results for 4x4 matrix inversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84616 --- Comment #2 from michael at moekadu dot de --- Created attachment 43532 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43532&action=edit Preprocessed test-program Here the preprocessed test-programmed (g++ -Ieigen test.cpp -O3 -funsafe-math-optimizations -E > test_prep.cpp) Sorry, that I had to pack it to satisfy the file size limit.
[Bug c++/84632] New: internal compiler error: tree check: expected record_type or union_type or qual_union_type, have array_type in reduced_constant_expression_p, at cp/constexpr.c:1778
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84632 Bug ID: 84632 Summary: internal compiler error: tree check: expected record_type or union_type or qual_union_type, have array_type in reduced_constant_expression_p, at cp/constexpr.c:1778 Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: vegard.nossum at gmail dot com Target Milestone: --- Input: class { &&a; } b[] = b Output: $ xgcc -x c++ -S -fpermissive - :2:5: warning: ISO C++ forbids declaration of 'a' with no type [-fpermissive] :3:3: error: initializer fails to determine size of 'b' :3:9: internal compiler error: tree check: expected record_type or union_type or qual_union_type, have array_type in reduced_constant_expression_p, at cp/constexpr.c:1778 0x65f8d0 tree_check_failed(tree_node const*, char const*, int, char const*, ...) /home/vegard/git/gcc/gcc/tree.c:9337 0xa157d9 tree_check3(tree_node*, char const*, int, char const*, tree_code, tree_code, tree_code) /home/vegard/git/gcc/gcc/tree.h:3172 0xa157d9 reduced_constant_expression_p(tree_node*) /home/vegard/git/gcc/gcc/cp/constexpr.c:1778 0xa159cc verify_constant /home/vegard/git/gcc/gcc/cp/constexpr.c:1822 0xa4e0c3 cxx_eval_outermost_constant_expr /home/vegard/git/gcc/gcc/cp/constexpr.c:4829 0xa5cf6c maybe_constant_init_1 /home/vegard/git/gcc/gcc/cp/constexpr.c:5152 0x142bf0e store_init_value(tree_node*, tree_node*, vec**, int) /home/vegard/git/gcc/gcc/cp/typeck2.c:836 0xb48848 check_initializer /home/vegard/git/gcc/gcc/cp/decl.c:6427 0xbdccae cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int) /home/vegard/git/gcc/gcc/cp/decl.c:7081 0xfa35d9 cp_parser_init_declarator /home/vegard/git/gcc/gcc/cp/parser.c:19720 0xfa8357 cp_parser_simple_declaration /home/vegard/git/gcc/gcc/cp/parser.c:13061 0xfae548 cp_parser_block_declaration /home/vegard/git/gcc/gcc/cp/parser.c:12879 0x1001295 cp_parser_declaration /home/vegard/git/gcc/gcc/cp/parser.c:12776 0xff826b cp_parser_declaration_seq_opt /home/vegard/git/gcc/gcc/cp/parser.c:12652 0xff9893 cp_parser_translation_unit /home/vegard/git/gcc/gcc/cp/parser.c:4559 0xff9893 c_parse_file() /home/vegard/git/gcc/gcc/cp/parser.c:38880 0x15a51f5 c_common_parse_file() /home/vegard/git/gcc/gcc/c-family/c-opts.c:1132 $ xgcc --version xgcc (GCC) 8.0.1 20180228 (experimental) Built from git fd1990b25777e5f1307eac1447e8fb5fefe747b4 (r258063). Looks like bug #84424 but that has been fixed in r257924 and I'm using r258063. 7.3.0 seems fine. Test case was reduced by C-Reduce.
[Bug c++/84630] internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in tsubst_lambda_expr, at cp/pt.c:17141
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84630 Andrew Pinski changed: What|Removed |Added Keywords||error-recovery, ||ice-on-invalid-code --- Comment #1 from Andrew Pinski --- Does not look like a regression from 7.x This: :1: confused by earlier errors, Just means there was an internal error after an normal error has been emitted (with checking disabled or release checking). The trunk has checking enabled by default.
[Bug ipa/84628] attribute(warning/error) functions should not be merged together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84628 --- Comment #7 from Jakub Jelinek --- The warning/error attributes have been added for purposes like glibc memset inline, which does: if (__builtin_constant_p (__len) && __len == 0 && (!__builtin_constant_p (__ch) || __ch != 0)) { __warn_memset_zero_len (); return __dest; } where __warn_memset_zero_len has the warning attribute. This only works if it is after optimization. If you want a diagnostics whenever you reference some function, you are looking for the deprecated attribute instead.
[Bug c/84631] New: make check in fixincludes fails seemingly due to star in directory names, on WSL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84631 Bug ID: 84631 Summary: make check in fixincludes fails seemingly due to star in directory names, on WSL Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jay.krell at cornell dot edu Target Milestone: --- make check in fixincludes fails, seemingly due to "*" in directory names. This is on WSL (Windows Subsystem for Linux). I think Posix says stuff, like, / and \0 are the only special characters, but for portability use a reduced set.
[Bug c++/84630] New: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in tsubst_lambda_expr, at cp/pt.c:17141
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84630 Bug ID: 84630 Summary: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in tsubst_lambda_expr, at cp/pt.c:17141 Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: vegard.nossum at gmail dot com Target Milestone: --- I was quite sure I had submitted this one but I have searched and cannot see it anywhere, my apologies if it turns out to be a duplicate. Input: template struct c { template __attribute__((noinline([] {}))) b() {} }; c<> a; Output: $ xgcc -x c++ -S - :2:13: error: ISO C++ forbids declaration of 'parameter' with no type [-fpermissive] :2:55: error: ISO C++ forbids declaration of 'b' with no type [-fpermissive] : In member function 'int c< >::b()': :2:58: warning: no return statement in function returning non-void [-Wreturn-type] : In instantiation of 'struct c<>': :4:5: required from here :2:53: internal compiler error: tree check: expected class 'type', have 'exceptional' (error_mark) in tsubst_lambda_expr, at cp/pt.c:17141 0x6602e9 tree_class_check_failed(tree_node const*, tree_code_class, char const*, int, char const*) /home/vegard/git/gcc/gcc/tree.c:9388 0x11dd0a0 tree_class_check(tree_node*, tree_code_class, char const*, int, char const*) /home/vegard/git/gcc/gcc/tree.h:3255 0x11dd0a0 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*) /home/vegard/git/gcc/gcc/cp/pt.c:17141 0x10f640b tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) /home/vegard/git/gcc/gcc/cp/pt.c:18479 0x10f408a tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) /home/vegard/git/gcc/gcc/cp/pt.c:18168 0x10bfe06 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool) /home/vegard/git/gcc/gcc/cp/pt.c:16973 0x1164bbf tsubst_attribute /home/vegard/git/gcc/gcc/cp/pt.c:10327 0x1174e7c apply_late_template_attributes /home/vegard/git/gcc/gcc/cp/pt.c:10428 0x117ef90 tsubst_function_decl /home/vegard/git/gcc/gcc/cp/pt.c:12687 0x1184e90 tsubst_template_decl /home/vegard/git/gcc/gcc/cp/pt.c:12804 0x1155421 tsubst_decl /home/vegard/git/gcc/gcc/cp/pt.c:12906 0x1105c06 tsubst(tree_node*, tree_node*, int, tree_node*) /home/vegard/git/gcc/gcc/cp/pt.c:13798 0x11e2760 instantiate_class_template_1 /home/vegard/git/gcc/gcc/cp/pt.c:10743 0x11ef20b instantiate_class_template(tree_node*) /home/vegard/git/gcc/gcc/cp/pt.c:11041 0x138b930 complete_type(tree_node*) /home/vegard/git/gcc/gcc/cp/typeck.c:136 0xb38193 start_decl_1(tree_node*, bool) /home/vegard/git/gcc/gcc/cp/decl.c:5244 0xc1a64f start_decl(cp_declarator const*, cp_decl_specifier_seq*, int, tree_node*, tree_node*, tree_node**) /home/vegard/git/gcc/gcc/cp/decl.c:5207 0xfa251c cp_parser_init_declarator /home/vegard/git/gcc/gcc/cp/parser.c:19589 0xfa8357 cp_parser_simple_declaration /home/vegard/git/gcc/gcc/cp/parser.c:13061 0xfae548 cp_parser_block_declaration /home/vegard/git/gcc/gcc/cp/parser.c:12879 $ xgcc --version xgcc (GCC) 8.0.1 20180228 (experimental) Built from git fd1990b25777e5f1307eac1447e8fb5fefe747b4 (r258063). 7.3.0 says: :2:13: error: ISO C++ forbids declaration of 'parameter' with no type [-fpermissive] template __attribute__((noinline([] {}))) b() {} ^ :2:55: error: ISO C++ forbids declaration of 'b' with no type [-fpermissive] template __attribute__((noinline([] {}))) b() {} ^ :1: confused by earlier errors, bailing out Compiler returned: 1 Test case was reduced by C-Reduce.
[Bug ipa/84628] attribute(warning/error) functions should not be merged together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84628 --- Comment #6 from Jay --- Misplaced comment: But, the thing is, because optimization can remove the use of such functions, people are now advocating that we noinline along with the attribute, which hypothetically is unwarranted damage. Noinline being a partial disabling of optimization, not complete. See here: https://github.com/mono/mono/pull/7353 But it isn't clear as I said, if it is worth warning/error for what the source states, vs. what the optimizer divines from the code.
[Bug sanitizer/84629] sanitizer warnings and errors on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84629 --- Comment #4 from Jay --- -disable-multilib fixed the errors. I didn't watch for the warnings.
[Bug target/44002] need to #include unistd.h for pid_t on alpha-dec-vms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44002 --- Comment #4 from Jay --- Incorrect bug.
[Bug ipa/84628] attribute(warning/error) functions should not be merged together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84628 --- Comment #5 from Jay --- I know. We just noticed and were surprised. It isn't clear if this is what users would expect or not. Warn because they wrote code that "merely looks bad", or only if the compiler decides after analysis that it really is bad? Anyway, there are two points here I think. One is far more arguable than the other. I don't think the small case shown should error.
[Bug ipa/84628] attribute(warning/error) functions should not be merged together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84628 --- Comment #4 from Andrew Pinski --- (In reply to Jay from comment #3) > The original case said something about "localalias" in the error, so aliases > don't seem to address it. I can dig that up probably. > > Shouldn't it warn for: > if (0) >banned_function() > ? > > I believe we want it to. > You know, strive for equal warnings/errors w/ or w/o optimization, but I > know that is impossible in general, because optimization==analysis. The documentation is explicit here though: " call to such a function is not eliminated through dead code elimination or other optimizations"
[Bug target/44002] need to #include unistd.h for pid_t on alpha-dec-vms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44002 --- Comment #3 from Jay --- But, the thing is, because optimization can remove the use of such functions, people are now advocating that we noinline along with the attribute, which hypothetically is unwarranted damage. Noinline being a partial disabling of optimization, not complete. See here: https://github.com/mono/mono/pull/7353
[Bug ipa/84628] attribute(warning/error) functions should not be merged together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84628 --- Comment #3 from Jay --- The original case said something about "localalias" in the error, so aliases don't seem to address it. I can dig that up probably. Shouldn't it warn for: if (0) banned_function() ? I believe we want it to. You know, strive for equal warnings/errors w/ or w/o optimization, but I know that is impossible in general, because optimization==analysis. I believe attribute(error) should be like pragma poison except: - easier to implement the deprecated function - can provide custom error - works with C++ overloads -- attach attribute to full declaration, not just identifier But yeah, another option is to optimize a little less, on a case by case basis. Or actually remove the attribute, or don't warn, if the compiler essentially introduced the use.
[Bug inline-asm/84625] [6/7/8 Regression] ICE with empty constraint and vector constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84625 Jakub Jelinek changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-03-01 Version|unknown |7.0 Target Milestone|--- |6.5 Summary|ICE with empty constraint |[6/7/8 Regression] ICE with |and vector constant |empty constraint and vector ||constant Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- This used to be rejected before r151701: pr84625.c: In function ‘foo’: pr84625.c:5:3: warning: asm operand 0 probably doesn’t match constraints pr84625.c:5:3: error: impossible constraint in ‘asm’ and started to ICE with r188665.
[Bug inline-asm/84625] ICE with empty constraint and vector constant
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84625 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Summary|ICE with constexpr and |ICE with empty constraint |inline asm |and vector constant --- Comment #1 from Jakub Jelinek --- That has nothing to do with constexpr and everything to do with the invalid (empty) constraint. void foo () { typedef int V __attribute__((vector_size (16))); asm ("%0" : : "" ((V) { 1, 2, 3, 4 })); } ICEs the same.
[Bug sanitizer/84629] sanitizer warnings and errors on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84629 --- Comment #3 from Jay --- This is ubuntu xenial I think, on WSL. Which doesn't have multi-arch. So I'll try configure -disable-multilib.
[Bug ipa/84628] attribute(warning/error) functions should not be merged together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84628 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-03-01 CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Of course it has to be evaluated after optimization, that is the whole point of these attributes. In this case just IPA ICF should not try to fold error1 with error2 if it can't use aliases and the functions involved have warning or error attributes.
[Bug sanitizer/84629] sanitizer warnings and errors on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84629 --- Comment #2 from Jakub Jelinek --- The __NR_* macros are actually provided by kernel headers rather than glibc, /usr/include/asm*/unistd*.h So this looks like a distro bug to me.
[Bug sanitizer/84629] sanitizer warnings and errors on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84629 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-03-01 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- What target is this? Also what version of glibc are you using?
[Bug target/71657] Wrong code on trunk gcc (std::out_of_range), westmere
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71657 Tom de Vries changed: What|Removed |Added Status|SUSPENDED |NEW --- Comment #13 from Tom de Vries --- > Suspended until the infrastructure is ready. With PR83327 fixed, it may make sense to reenable ix86_spill_class and see if the problems are gone. Tentatively setting status to NEW.
[Bug regression/84623] [8 Regression] "-fcompare-debug failure (length)" testing pr46066.c start with r257826 on mips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84623 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Hasn't r257993 fixed this already?
[Bug sanitizer/84629] New: sanitizer warnings and errors on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84629 Bug ID: 84629 Summary: sanitizer warnings and errors on Linux Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: jay.krell at cornell dot edu CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- ^ /s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc:230:44: note: in expansion of macro 'SYSCALL' HANDLE_EINTR(res, (sptr)internal_syscall(SYSCALL(ftruncate), fd, ^~~ /s/gccgit/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:15:24: note: suggested alternative: 'SYS_ftruncat ' # define SYSCALL(name) __NR_ ## name ^ /s/gccgit/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:377:14: note: in definition of macro 'HANDLE_EINTR' res = (f); \ ^ /s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc:230:44: note: in expansion of macro 'SYSCALL' HANDLE_EINTR(res, (sptr)internal_syscall(SYSCALL(ftruncate), fd, ^~~ In file included from /s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc:152: /s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc: In function '__sanitizer::uptr __sanitizer::internal_stat(const char*, void*)': /s/gccgit/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:15:24: error: '__NR_stat64' was not declared in this scope # define SYSCALL(name) __NR_ ## name ^ /s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc:322:30: note: in expansion of macro 'SYSCALL' int res = internal_syscall(SYSCALL(stat64), path, &buf64); ^~~ /s/gccgit/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:15:24: note: suggested alternative: '__lxstat64' # define SYSCALL(name) __NR_ ## name ^ /s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc:322:30: note: in expansion of macro 'SYSCALL' int res = internal_syscall(SYSCALL(stat64), path, &buf64); ^~~ /s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc: In function '__sanitizer::uptr __sanitizer::internal_lstat(const char*, void*)': /s/gccgit/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:15:24: error: '__NR_lstat64' was not declared in this scope # define SYSCALL(name) __NR_ ## name ^ /s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc:349:30: note: in expansion of macro 'SYSCALL' int res = internal_syscall(SYSCALL(lstat64), path, &buf64); ^~~ /s/gccgit/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:15:24: note: suggested alternative: '__lxstat64' # define SYSCALL(name) __NR_ ## name ^ /s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc:349:30: note: in expansion of macro 'SYSCALL' int res = internal_syscall(SYSCALL(lstat64), path, &buf64); ^~~ /s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc: In function '__sanitizer::uptr __sanitizer::internal_dup2(int, int)': /s/gccgit/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:15:24: error: '__NR_dup2' was not declared in this scope # define SYSCALL(name) __NR_ ## name ^ /s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc:385:27: note: in expansion of macro 'SYSCALL' return internal_syscall(SYSCALL(dup2), oldfd, newfd); ^~~ /s/gccgit/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:15:24: note: suggested alternative: 'SYS_dup2' # define SYSCALL(name) __NR_ ## name ^ /s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc:385:27: note: in expansion of macro 'SYSCALL' return internal_syscall(SYSCALL(dup2), oldfd, newfd); ^~~ /s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc: In function '__sanitizer::uptr __sanitizer::internal_readlink(const char*, char*, __sanitizer::uptr)': /s/gccgit/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:15:24: error: '__NR_readlink' was not declared in this scope # define SYSCALL(name) __NR_ ## name ^ /s/gccgit/libsanitizer/sanitizer_common/sanitizer_linux.cc:396:27: note: in expansion of macro 'SYSCALL' return internal_syscall(SYSCALL(readlink), (uptr)path, (uptr)buf, bufsize); ^~~ /s/gccgit/libsanitizer/sanitizer_common/sanitizer_syscall_generic.inc:15:24: note: suggested alternative: 'SYS_readl
[Bug rtl-optimization/83327] Spilling into hard regs not taken into account in lra liveness analysis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83327 Tom de Vries changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |vries at gcc dot gnu.org Target Milestone|--- |8.0 --- Comment #14 from Tom de Vries --- Patch tested on MIPS16 and committed. Marking resolved-fixed.
[Bug rtl-optimization/83327] Spilling into hard regs not taken into account in lra liveness analysis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83327 --- Comment #13 from Tom de Vries --- Author: vries Date: Thu Mar 1 05:51:08 2018 New Revision: 258093 URL: https://gcc.gnu.org/viewcvs?rev=258093&root=gcc&view=rev Log: Fix liveness analysis in lra for spilled-into hard regs 2018-03-01 Tom de Vries PR rtl-optimization/83327 * lra-int.h (hard_regs_spilled_into): Declare. * lra.c (hard_regs_spilled_into): Define. (init_reg_info): Init hard_regs_spilled_into. * lra-spills.c (assign_spill_hard_regs): Update hard_regs_spilled_into. * lra-lives.c (make_hard_regno_born, make_hard_regno_dead) (process_bb_lives): Handle hard_regs_spilled_into. (lra_create_live_ranges_1): Before doing liveness propagation, clear regs in all_hard_regs_bitmap if set in hard_regs_spilled_into. Modified: trunk/gcc/ChangeLog trunk/gcc/lra-int.h trunk/gcc/lra-lives.c trunk/gcc/lra-spills.c trunk/gcc/lra.c
[Bug c/84628] attribute(warning/error) should be evaluated before optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84628 --- Comment #1 from Jay --- Also occurs with git trunk ef8d0c5bff3c11a5d67617df2f43775f7a26fad2 8.0.1 20180228.
[Bug c/84628] New: attribute(warning/error) should be evaluated before optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84628 Bug ID: 84628 Summary: attribute(warning/error) should be evaluated before optimization Product: gcc Version: 7.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jay.krell at cornell dot edu Target Milestone: --- This code should not error. It is derived from real world code. $ cat object.c #define ERROR __attribute__ ((__error__ ("do not call this"))) int (*f1)(); int f2 () { return f1 (); } ERROR int error1 () { return f2(); } ERROR int error2 () { return f2(); } $ $HOME/gcc720/bin/gcc -v Using built-in specs. COLLECT_GCC=/home/jay/gcc720/bin/gcc COLLECT_LTO_WRAPPER=/home/jay/gcc720/libexec/gcc/x86_64-pc-linux-gnu/7.2.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /src/gcc-7.2.0/configure -prefix=/home/jay/gcc720 -enable-languages=objc,obj-c++,go,fortran -disable-multilib Thread model: posix gcc version 7.2.0 (GCC) $ $HOME/gcc720/bin/gcc -c -O2 object.c object.c: In function ‘error2’: cc1: error: call to ‘error1’ declared with attribute error: do not call this I will try trunk.
[Bug target/84627] powerpc excess padding generated for POWER9 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84627 --- Comment #2 from Nicholas Piggin --- Ah sorry, target is powerpc64le
[Bug target/84627] powerpc excess padding generated for POWER9 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84627 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Target||powerpc --- Comment #1 from Andrew Pinski --- Is this little endian or big-endian? 32bit or 64bit?
[Bug target/84627] New: powerpc excess padding generated for POWER9 target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84627 Bug ID: 84627 Summary: powerpc excess padding generated for POWER9 target Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: npiggin at gmail dot com Target Milestone: --- gcc version 8.0.1 20180207 (experimental) [trunk revision 257435] (Debian 8-20180207-2): Test case: void test(void (*fn)(void), unsigned long i) { while (i--) fn(); } Generates code with -O2 -mcpu=power9: 2c: 18 00 41 f8 std r2,24(r1) 30: 00 00 00 60 nop 34: 00 00 00 60 nop 38: 00 00 00 60 nop 3c: 00 00 42 60 ori r2,r2,0 40: 78 f3 cc 7f mr r12,r30 44: a6 03 c9 7f mtctr r30 48: ff ff ff 3b addir31,r31,-1 4c: 21 04 80 4e bctrl 50: 18 00 41 e8 ld r2,24(r1) 54: ff ff bf 2f cmpdi cr7,r31,-1 58: e8 ff 9e 40 bne cr7,40 On power9, I wonder if nops and ori should be avoided? Aligning to quad word boundary is reasonable for fetch, but is there any advantage for dispatch to add the extra padding?
[Bug target/84626] powerpc toc register is reloaded unnecessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84626 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Target||powerpc Severity|normal |enhancement
[Bug target/84626] New: powerpc toc register is reloaded unnecessarily
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84626 Bug ID: 84626 Summary: powerpc toc register is reloaded unnecessarily Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: npiggin at gmail dot com Target Milestone: --- gcc version 8.0.1 20180207 (experimental) [trunk revision 257435] (Debian 8-20180207-2): Test case: void test(void (*fn)(void), unsigned long i) { while (i--) fn(); } Generates code: 2c: 18 00 41 f8 std r2,24(r1) 30: 00 00 00 60 nop 34: 00 00 00 60 nop 38: 00 00 00 60 nop 3c: 00 00 42 60 ori r2,r2,0 40: 78 f3 cc 7f mr r12,r30 44: a6 03 c9 7f mtctr r30 48: ff ff ff 3b addir31,r31,-1 4c: 21 04 80 4e bctrl 50: 18 00 41 e8 ld r2,24(r1) 54: ff ff bf 2f cmpdi cr7,r31,-1 58: e8 ff 9e 40 bne cr7,40 The r2 load could be moved out of the loop.
[Bug inline-asm/84625] New: ICE with constexpr and inline asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84625 Bug ID: 84625 Summary: ICE with constexpr and inline asm Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: inline-asm Assignee: unassigned at gcc dot gnu.org Reporter: SztfG at yandex dot ru Target Milestone: --- testcase: #include void crasher() { constexpr __m128 w = {1,2,3,4}; asm ("addps %[w], %[w]" : : [w] ""(w)); }
[Bug tree-optimization/84624] New: bogus -Wstringop-truncation in a catch statement and nul assignment outside it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84624 Bug ID: 84624 Summary: bogus -Wstringop-truncation in a catch statement and nul assignment outside it Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- The -Wstringop-truncation warning for the strncpy call below should have been suppressed by the subsequent assignment to d but the suppression logic is thwarted by the __cxa_end_catch () call. $ cat b.C && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout b.C char d[3]; void f (); void g (const char *s) { try { f (); } catch (...) { __builtin_strncpy (d, s, sizeof d); // bogus warning } d[sizeof d - 1] = 0; // because of this } b.C: In function ‘void g(const char*)’: b.C:13:25: warning: ‘char* __builtin_strncpy(char*, const char*, long unsigned int)’ specified bound 3 equals destination size [-Wstringop-truncation] __builtin_strncpy (d, s, sizeof d); // bogus warning ~~^~~~ ;; Function g (_Z1gPKc, funcdef_no=0, decl_uid=2362, cgraph_uid=0, symbol_order=1) g (const char * s) { void * _1; [local count: 1073741825]: f (); [local count: 1073741825]: d[2] = 0; return; [count: 0]: : _1 = __builtin_eh_pointer (1); __cxa_begin_catch (_1); __builtin_strncpy (&d, s_7(D), 3); __cxa_end_catch (); goto ; [100.00%] }
[Bug regression/84623] New: [8 Regression] "-fcompare-debug failure (length)" testing pr46066.c start with r257826 on mips
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84623 Bug ID: 84623 Summary: [8 Regression] "-fcompare-debug failure (length)" testing pr46066.c start with r257826 on mips Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression Assignee: unassigned at gcc dot gnu.org Reporter: paul.hua.gm at gmail dot com Target Milestone: --- paulhua@erpro8-fsf2:~/GCC/build/gcc-r257826_obj$ ./gcc/xgcc -B./gcc /home/paulhua/GCC/gcc_git_trunk/gcc/testsuite/gcc.dg/autopar/pr46066.c -fno-diagnostics-show-caret -fdiagnostics-color=never -fcompare-debug -O -ftree-parallelize-loops=4 -S -o pr46066.s xgcc: error: /home/paulhua/GCC/gcc_git_trunk/gcc/testsuite/gcc.dg/autopar/pr46066.c: -fcompare-debug failure (length) Start with r257826. Can not reproduce with cross compiler. On gcc23 gcc config with: ../configure --prefix=/opt/gcc-8 MISSING=texinfo MAKEINFO=missing --target=mips64el-linux-gnu --enable-languages=c,c++
[Bug fortran/84622] [F08] gfortran accepts invalid intent(out) polymorphic dummy argument with coarray component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84622 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-03-01 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed from 4.9 up to trunk (8.0). I get an ICE with 4.8.
[Bug fortran/84622] New: [F08] gfortran accepts invalid intent(out) polymorphic dummy argument with coarray component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84622 Bug ID: 84622 Summary: [F08] gfortran accepts invalid intent(out) polymorphic dummy argument with coarray component Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: damian at sourceryinstitute dot org Target Milestone: --- gfortran 7 and 8 accept the following invalid code when the dummy argument is declared with "class" but give the correct error message when "type" replaces "class": type foo logical, allocatable :: bar[:] end type contains subroutine foobar(this) class(foo), intent(out) :: this end subroutine end
[Bug c++/84294] attributes on a function template redeclaration silently discarded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84294 Martin Sebor changed: What|Removed |Added Keywords||patch Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #2 from Martin Sebor --- Patch: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01625.html
[Bug c++/84621] bogus -Wreturn-type on a template instantiated on a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84621 Martin Sebor changed: What|Removed |Added Keywords||diagnostic Summary|bogus -Wresturn-type on a |bogus -Wreturn-type on a |template instantiated on a |template instantiated on a |function|function Known to fail||4.1.0, 4.5.4, 4.8.3, 4.9.4, ||5.4.0, 6.3.0, 7.3.0, 8.0 --- Comment #1 from Martin Sebor --- This never worked as expected so it's not a regresion.
[Bug c++/84621] New: bogus -Wresturn-type on a template instantiated on a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84621 Bug ID: 84621 Summary: bogus -Wresturn-type on a template instantiated on a function Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- When a non-void function template that doesn't return value and that is parameterized on a function pointer is instantiated on the address of a noreturn function calls the function, G++ issues a bogus -Wreturn-type warning even though it successfully eliminates statements after the call to the noreturn function (as it should). Interestingly, other compilers suffer the same or similar problem. Clang and ICC issue the same bogus warning while also eliminating the second call, and MSVC doesn't warn or eliminate the call. $ cat b.C && gcc -O -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout b.C template int ff () { f (); f (); // eliminated } // bogus -Wreturn-type void __attribute__ ((noreturn)) f (); template int ff(); b.C: In function ‘int ff()’: b.C:6:1: warning: no return statement in function returning non-void [-Wreturn-type] } // bogus -Wreturn-type ^ ;; Function ff (_Z2ffIXadL_Z1fvEEEiv, funcdef_no=1, decl_uid=2366, cgraph_uid=0, symbol_order=0) ff () { [local count: 1073741825]: f (); }
[Bug c++/71784] [6/7/8 Regression] ICE on valid code in push_access_scope, at cp/pt.c:229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71784 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #18 from Jason Merrill --- Fixed.
[Bug c++/71784] [6/7/8 Regression] ICE on valid code in push_access_scope, at cp/pt.c:229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71784 --- Comment #17 from Jason Merrill --- Author: jason Date: Wed Feb 28 21:34:56 2018 New Revision: 258087 URL: https://gcc.gnu.org/viewcvs?rev=258087&root=gcc&view=rev Log: PR c++/71784 - ICE with ref-qualifier and explicit specialization. * pt.c (determine_specialization): Check ref-qualifier. Added: branches/gcc-6-branch/gcc/testsuite/g++.dg/cpp0x/ref-qual18.C Modified: branches/gcc-6-branch/gcc/cp/ChangeLog branches/gcc-6-branch/gcc/cp/pt.c
[Bug c++/71784] [6/7/8 Regression] ICE on valid code in push_access_scope, at cp/pt.c:229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71784 --- Comment #15 from Jason Merrill --- Author: jason Date: Wed Feb 28 21:34:07 2018 New Revision: 258085 URL: https://gcc.gnu.org/viewcvs?rev=258085&root=gcc&view=rev Log: PR c++/71784 - ICE with ref-qualifier and explicit specialization. * pt.c (determine_specialization): Check ref-qualifier. Added: trunk/gcc/testsuite/g++.dg/cpp0x/ref-qual18.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/71784] [6/7/8 Regression] ICE on valid code in push_access_scope, at cp/pt.c:229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71784 --- Comment #16 from Jason Merrill --- Author: jason Date: Wed Feb 28 21:34:31 2018 New Revision: 258086 URL: https://gcc.gnu.org/viewcvs?rev=258086&root=gcc&view=rev Log: PR c++/71784 - ICE with ref-qualifier and explicit specialization. * pt.c (determine_specialization): Check ref-qualifier. Added: branches/gcc-7-branch/gcc/testsuite/g++.dg/cpp0x/ref-qual18.C Modified: branches/gcc-7-branch/gcc/cp/ChangeLog branches/gcc-7-branch/gcc/cp/pt.c
[Bug middle-end/52285] [6/7/8 Regression] libgcrypt _gcry_burn_stack slowdown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52285 --- Comment #21 from Vladimir Makarov --- (In reply to Jakub Jelinek from comment #20) > Vlad, your thoughts on this? Can it be done in LRA or postreload-gcse or > some other post-LRA pass (if they do have loops)? I don't think it can be done easily after RA. There are no optimizations working with loops after IRA. postreload-gcse is very simple pass working with loads/stores. It is hard to modify it (e.g. into PRE) to do invariant motion. Probably we could repeat loop invariant motion pass again after LRA but it needs investigation and running such heavy pass for rare cases may be doubtful. I don't think that this PR will be fixed for GCC-8 or even later. It will be hard to justify compilation slowdown without visible performance improvements for example on SPEC.
[Bug c++/84610] [6/7/8 Regression] ICE in synthesize_implicit_template_parm, at cp/parser.c:38843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84610 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |6.5 Summary|[5/6/7/8 Regression] ICE in |[6/7/8 Regression] ICE in |synthesize_implicit_templat |synthesize_implicit_templat |e_parm, at |e_parm, at |cp/parser.c:38843 |cp/parser.c:38843
[Bug rtl-optimization/84614] [8 Regression] wrong code with u16->u128 extension at aarch64 -fno-split-wide-types -g3 --param=max-combine-insns=3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84614 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |8.0
[Bug c++/84618] [8 Regression] ICE in build_capture_proxy, at cp/lambda.c:460
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84618 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|--- |8.0
[Bug target/52991] [6/7/8 Regression] attribute packed broken on mingw32?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991 --- Comment #34 from Benjamin Robin --- Thank you a lot for the fix. I have no idea what I did yesterday when I did test bf-ms-layout-2.c (Yes the test was wrong, and by default cannot compile under Visual Studio VC) The test can be slightly improved by replacing: #ifdef __GNUC__ #define ATTR __attribute__ ((ms_struct)) #endif By: #ifdef __GNUC__ # ifdef _TEST_MS_LAYOUT # define ATTR __attribute__ ((ms_struct)) # else # define ATTR __attribute__ ((gcc_struct)) # endif #else # define ATTR #endif Otherwise the else branch of "#if defined (_TEST_MS_LAYOUT) || defined (_MSC_VER)" cannot be tested easily. And even more important, it can be directly compiled with Visual Studio VC (VC does not known what is ATTR)
[Bug c++/71784] [6/7/8 Regression] ICE on valid code in push_access_scope, at cp/pt.c:229
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71784 Jason Merrill changed: What|Removed |Added Priority|P4 |P2 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug target/70321] [6/7/8 Regression] STV generates less optimized code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70321 --- Comment #17 from H.J. Lu --- (In reply to Jakub Jelinek from comment #16) > We didn't do that in stage1, stage4 is too risky for that. Can somebody > from Intel try that for GCC9 stage1? > I'm willing to help, but will have lots of work on OpenMP 5.0, so can't > drive that. We will look into it. Thanks.
[Bug target/84014] [6/7 Regression] ICE in setup_min_max_allocno_live_range_point, at ira-build.c:2762
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84014 --- Comment #4 from David Edelsohn --- Author: dje Date: Wed Feb 28 19:53:24 2018 New Revision: 258081 URL: https://gcc.gnu.org/viewcvs?rev=258081&root=gcc&view=rev Log: PR target/84014 * gcc.target/powerpc/pr84014.c: Use ilp32, not -m32 option. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/powerpc/pr84014.c
[Bug target/82258] [8 regression] allocate_zerosize_3.f fails since r251949
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82258 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org --- Comment #16 from Jakub Jelinek --- armeb-*-* is neither primary nor secondary target.
[Bug c++/84616] funsafe-math-optimizations leads to incorrect results for 4x4 matrix inversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84616 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-02-28 CC||dmalcolm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Please can you attach the preprocessed source (via -E), so that we're all looking at the same thing. Thanks.
[Bug target/70321] [6/7/8 Regression] STV generates less optimized code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70321 Jakub Jelinek changed: What|Removed |Added CC||itsimbal at gcc dot gnu.org Target Milestone|8.0 |9.0 --- Comment #16 from Jakub Jelinek --- We didn't do that in stage1, stage4 is too risky for that. Can somebody from Intel try that for GCC9 stage1? I'm willing to help, but will have lots of work on OpenMP 5.0, so can't drive that.
[Bug c++/84610] [5/6/7/8 Regression] ICE in synthesize_implicit_template_parm, at cp/parser.c:38843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84610 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-28 CC||dmalcolm at gcc dot gnu.org Summary|internal compiler error: in |[5/6/7/8 Regression] ICE in |synthesize_implicit_templat |synthesize_implicit_templat |e_parm, at |e_parm, at |cp/parser.c:38843 |cp/parser.c:38843 Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Confirmed on trunk, 5, 6 and 7 (with an explicit -std=c++14 needed for gcc 5). Failing in synthesize_implicit_template_parm (parser=0x77ffbbd0, constr=) at ../../src/gcc/cp/parser.c:3 3 gcc_assert (current_binding_level->kind == sk_function_parms); (gdb) p cfun $2 = (function *) 0x0 (gdb) p scope_chain->bindings->kind $5 = sk_template_parms Started with r208426 (with -std=c++14).
[Bug c++/84609] [8 Regression] internal compiler error: in cp_parser_abort_tentative_parse, at cp/parser.c:28960 (cp_parser_member_declaration())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84609 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Jakub Jelinek --- Fixed.
[Bug c++/84618] [8 Regression] ICE in build_capture_proxy, at cp/lambda.c:460
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84618 --- Comment #2 from David Malcolm --- Failing here in build_capture_proxy (member=, init=) at ../../src/gcc/cp/lambda.c:458: 458 gcc_assert (VAR_P (init) || TREE_CODE (init) == PARM_DECL); where init is a component_ref.
[Bug c++/84611] [5/67/8 Regression] ICE in operator[], at vec.h:826 (local_class_index())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84611 David Malcolm changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-28 CC||dmalcolm at gcc dot gnu.org Summary|internal compiler error: in |[5/67/8 Regression] ICE in |operator[], at vec.h:826|operator[], at vec.h:826 |(local_class_index()) |(local_class_index()) Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Confirmed. 826 gcc_checking_assert (ix < m_vecpfx.m_num); (gdb) p ix $1 = 1 (gdb) p m_vecpfx.m_num $2 = 1 at: 1921 tree type = (*local_classes)[ix]; Bisecting with pre-built cc1plus binaries shows the ICE starts somewhere between r19 and r190022. Doesn't ICE on my builds of 7, 6, or 5 (presumably due to checking being disabled), but running each of these under valgrind shows the bogus read: ==19292== Invalid read of size 8 ==19292==at 0x783FF4: local_class_index(tree_node*) (mangle.c:1958) ==19292==by 0x78726A: write_name(tree_node*, int) (mangle.c:1990) ==19292==by 0x787B16: write_type(tree_node*) (mangle.c:2841) ==19292==by 0x78EBDA: mangle_special_for_type(tree_node*, char const*) (mangle.c:4032) ==19292==by 0x7302AF: get_tinfo_decl(tree_node*) (rtti.c:417) ==19292==by 0x747A77: expand_start_catch_block(tree_node*) (except.c:380) ==19292==by 0x75ED8C: finish_handler_parms(tree_node*, tree_node*) (semantics.c:1327)
[Bug c++/84609] [8 Regression] internal compiler error: in cp_parser_abort_tentative_parse, at cp/parser.c:28960 (cp_parser_member_declaration())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84609 --- Comment #5 from Jakub Jelinek --- Author: jakub Date: Wed Feb 28 18:57:38 2018 New Revision: 258080 URL: https://gcc.gnu.org/viewcvs?rev=258080&root=gcc&view=rev Log: PR c++/84609 * parser.c (cp_parser_attributes_opt): Formatting fix. (cp_parser_skip_balanced_tokens, cp_parser_skip_gnu_attributes_opt, cp_parser_skip_std_attribute_spec_seq, cp_parser_skip_attributes_opt): New functions. (cp_parser_member_declaration): Use cp_parser_skip_attributes_opt instead of tentative parse to peek over optional attribute tokens to check for CPP_COLON after them. * g++.dg/cpp0x/pr84609.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr84609.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog
[Bug c++/83503] [8 Regression] bogus -Wattributes for const and pure on function template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83503 --- Comment #23 from Jakub Jelinek --- Author: jakub Date: Wed Feb 28 18:56:36 2018 New Revision: 258079 URL: https://gcc.gnu.org/viewcvs?rev=258079&root=gcc&view=rev Log: PR c++/83871 PR c++/83503 * pt.c (INCLUDE_STRING): Remove define. (warn_spec_missing_attributes): Use pretty_printer instead of std::string. Fix up inform call so that the list of attributes is in %s argument. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug c++/83871] wrong code for attribute const and pure on distinct template specializations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83871 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Wed Feb 28 18:56:36 2018 New Revision: 258079 URL: https://gcc.gnu.org/viewcvs?rev=258079&root=gcc&view=rev Log: PR c++/83871 PR c++/83503 * pt.c (INCLUDE_STRING): Remove define. (warn_spec_missing_attributes): Use pretty_printer instead of std::string. Fix up inform call so that the list of attributes is in %s argument. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c
[Bug tree-optimization/80293] [6/7 Regression] unnecessary code at -O2 (-O1 is fine)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80293 Jakub Jelinek changed: What|Removed |Added CC||peter at cordes dot ca --- Comment #11 from Jakub Jelinek --- *** Bug 80837 has been marked as a duplicate of this bug. ***
[Bug target/80837] [7/8 regression] x86 accessing a member of a 16-byte atomic object generates terrible code: splitting/merging the bytes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80837 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #9 from Jakub Jelinek --- Actually managed to reproduce today using godbolt's -E output. This is something that got fixed with r247104 on the trunk and backported to 7.2 as r248724. So I believe this is fixed. The choice to emit __atomic_load_16 calls is intentional, see the overlong thread about it from the last week or so on gcc at gcc.gnu.org mailing list. *** This bug has been marked as a duplicate of bug 80293 ***
[Bug c++/84618] [8 Regression] ICE in build_capture_proxy, at cp/lambda.c:460
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84618 David Malcolm changed: What|Removed |Added Keywords||error-recovery, ||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-28 CC||dmalcolm at gcc dot gnu.org Summary|internal compiler error: in |[8 Regression] ICE in |build_capture_proxy, at |build_capture_proxy, at |cp/lambda.c:460 |cp/lambda.c:460 Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Confirmed. Started with r253265.
[Bug testsuite/84617] [8 Regression] new test cases g++.dg/ext/attr-const.C and g++.dg/ext/attr-pure.C fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84617 Martin Sebor changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Martin Sebor --- Fixed via r258077.
[Bug testsuite/84617] [8 Regression] new test cases g++.dg/ext/attr-const.C and g++.dg/ext/attr-pure.C fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84617 --- Comment #3 from Martin Sebor --- Author: msebor Date: Wed Feb 28 18:28:53 2018 New Revision: 258077 URL: https://gcc.gnu.org/viewcvs?rev=258077&root=gcc&view=rev Log: PR testsuite/84617 - new test cases g++.dg/ext/attr-const.C and g++.dg/ext/attr-pure.C fail gcc/cp/ChangeLog: * decl.c (duplicate_decls): Fully merge attributes const, pure, and malloc. gcc/testsuite/ChangeLog: * g++.dg/ext/attr-malloc-3.C: New test. * g++.dg/ext/attr-const.C: Adjust. Xfail assertions failing due to pre-existing problems. * g++.dg/ext/attr-pure.C: Same. Added: trunk/gcc/testsuite/g++.dg/ext/attr-malloc-3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ext/attr-const.C trunk/gcc/testsuite/g++.dg/ext/attr-pure.C
[Bug tree-optimization/84562] -faggressive-loop-optimizations makes decisions based on weak data structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84562 --- Comment #8 from rguenther at suse dot de --- On February 28, 2018 6:44:43 PM GMT+01:00, "jnordholz at sect dot tu-berlin.de" wrote: >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84562 > >--- Comment #7 from Jan Nordholz >--- >(In reply to Richard Biener from comment #5) >> Btw, the behavior is the way you describe since forever. That GCC >looks at >> the constant initializer for the array is just a direct consequence >of it >> looking at the constant initializer of the scalar. > >And my point is that the compiler shouldn't look at the initializer of >weak >objects in the first place. :) How long this behaviour already exists >or what >the competition is doing doesn't really change my feeling that this is >the >Wrong Thing To Do. But it's your bugtracker, I won't argue if you >insist that >this should be flagged as invalid. > >If I (or somebody else who happens to find this bug report) would come >up with >a patch to fix this inconsistency (as Alexander has showcased even more >concisely in comment #3), would this be considered by the project? I guess yes.
[Bug fortran/84594] Warning: Use of the NUMERIC_STORAGE_SIZE named constant from intrinsic module ISO_FORTRAN_ENV at (1) is incompatible with option -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84594 --- Comment #5 from Steve Kargl --- On Wed, Feb 28, 2018 at 04:41:00PM +, dominiq at lps dot ens.fr wrote: > > Do you at least agree that > > (a) || flag_default_real_10 || flag_default_real_16 should be added > to flag_default_integer || flag_default_real_8 in module.c, Yes, those should probably be added. > > (b) the warning should be documented? > I thought that there was a warning in the -fdefault-* documentation about these options changing the ABI, which could cause problems. So, yes, there should be something like Warning: This option conflicts with NUMERIC_STORAGE_SIZE from ISO_FORTRAN_ENV module because it effects the underlying storage association between numeric types. It may also cause problems with changes in a library's ABI and interoperability with the C language.
[Bug tree-optimization/84562] -faggressive-loop-optimizations makes decisions based on weak data structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84562 --- Comment #7 from Jan Nordholz --- (In reply to Richard Biener from comment #5) > Btw, the behavior is the way you describe since forever. That GCC looks at > the constant initializer for the array is just a direct consequence of it > looking at the constant initializer of the scalar. And my point is that the compiler shouldn't look at the initializer of weak objects in the first place. :) How long this behaviour already exists or what the competition is doing doesn't really change my feeling that this is the Wrong Thing To Do. But it's your bugtracker, I won't argue if you insist that this should be flagged as invalid. If I (or somebody else who happens to find this bug report) would come up with a patch to fix this inconsistency (as Alexander has showcased even more concisely in comment #3), would this be considered by the project?
[Bug ipa/80899] [6/7/8 Regression] Devirtualization causes incorrect code generation with placement new in some cases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80899 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Having placement new represented in the IL is something I've suggested several times (e.g. to be able to be more aggressive on TBAA in loops which don't contain any placement new), but Richard didn't like that.
[Bug c++/84612] Overload resolution of operator* fails for valarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84612 --- Comment #2 from Jonathan Wakely --- For completeness, the standard says that the operator is defined like this: template valarray operator*(const valarray&, const T&); That's what libstdc++ provides, and it fails to deduce T in your example. The libc++ version looks like: template valarray operator*(const valarray&, const typename valarray::value_type&); This only deduces T from the valarray argument, so the test case works. But that is a non-standard behaviour, it's not a bug that GCC doesn't compile this test case, because we are following the standard. I've filed a new issue with the standard committee proposing to change the standard to do what libc++ does, and if that happens we will change GCC's implementation.
[Bug tree-optimization/57534] [6/7/8 Regression]: Performance regression versus 4.7.3, 4.8.1 is ~15% slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534 Jeffrey A. Law changed: What|Removed |Added Target Milestone|6.5 |9.0 --- Comment #30 from Jeffrey A. Law --- OK. Moving to gcc-9. Note I think there's multiple instances of this issue that would likely be helped if we can get IVOPTS to DTRT here. I'll try to link them via "See Also" the next time I come across them.
[Bug fortran/83901] [8 Regression] ICE in fold_convert_loc, at fold-const.c:2402
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83901 --- Comment #3 from Paul Thomas --- Author: pault Date: Wed Feb 28 17:36:20 2018 New Revision: 258076 URL: https://gcc.gnu.org/viewcvs?rev=258076&root=gcc&view=rev Log: 2018-02-28 Paul Thomas PR fortran/83901 * trans-stmt.c (trans_associate_var): Make sure that the se expression is a pointer type before converting it to the symbol backend_decl type. 2018-02-28 Paul Thomas PR fortran/83901 * gfortran.dg/associate_37.f90: New test. PR fortran/83344 * gfortran.dg/associate_36.f90: Add Steve Kargl as contributer. Added: trunk/gcc/testsuite/gfortran.dg/associate_37.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/associate_36.f90
[Bug fortran/83344] Use of uninitialized memory with ASSOCIATE and strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83344 --- Comment #14 from Paul Thomas --- Author: pault Date: Wed Feb 28 17:36:20 2018 New Revision: 258076 URL: https://gcc.gnu.org/viewcvs?rev=258076&root=gcc&view=rev Log: 2018-02-28 Paul Thomas PR fortran/83901 * trans-stmt.c (trans_associate_var): Make sure that the se expression is a pointer type before converting it to the symbol backend_decl type. 2018-02-28 Paul Thomas PR fortran/83901 * gfortran.dg/associate_37.f90: New test. PR fortran/83344 * gfortran.dg/associate_36.f90: Add Steve Kargl as contributer. Added: trunk/gcc/testsuite/gfortran.dg/associate_37.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/associate_36.f90
[Bug middle-end/52285] [6/7/8 Regression] libgcrypt _gcry_burn_stack slowdown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52285 --- Comment #20 from Jakub Jelinek --- Vlad, your thoughts on this? Can it be done in LRA or postreload-gcse or some other post-LRA pass (if they do have loops)?
[Bug c++/84294] attributes on a function template redeclaration silently discarded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84294 Martin Sebor changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2018-02-28 Summary|missing warning for ignored |attributes on a function |attribute on a function |template redeclaration |template declaration|silently discarded Ever confirmed|0 |1 Known to fail||6.4.0, 7.3.0, 8.0 --- Comment #1 from Martin Sebor --- I'll confirm this bug because it was the indirect cause of a number of test suite regressions recently (bug 84617). The problem is also not just one of a missing diagnostic but rather one of G++ failing to apply attributes specified on a function template re-declaration that were not specified on the first declaration of the template. I.e., it's a missed optimization opportunity. An enhanced test case: $cat b.C && gcc -O2 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout b.C int f (); int __attribute__ ((const)) f (); void ff () { int i0 = f (); int i1 = f (); if (i0 != i1) // folded to false __builtin_abort (); } template int g (); template int __attribute__ ((const)) g (); void gg () { int i0 = g(); int i1 = g(); if (i0 != i1) // not folded __builtin_abort (); } template int __attribute__ ((const)) h (); template int h (); void hh () { int i0 = h(); int i1 = h(); if (i0 != i1) // folded to false __builtin_abort (); } ;; Function ff (_Z2ffv, funcdef_no=0, decl_uid=2361, cgraph_uid=0, symbol_order=0) ff () { [local count: 1073741825]: return; } ;; Function gg (_Z2ggv, funcdef_no=1, decl_uid=2371, cgraph_uid=1, symbol_order=1) gg () { int _3; int _5; [local count: 1073741825]: _3 = g (); _5 = g (); if (_3 != _5) goto ; [0.00%] else goto ; [99.96%] [count: 0]: __builtin_abort (); [local count: 1073312327]: return; } ;; Function hh (_Z2hhv, funcdef_no=4, decl_uid=2382, cgraph_uid=2, symbol_order=2) hh () { [local count: 1073741825]: return; }
[Bug debug/84620] New: DW_AT_GNU_entry_view should not use address class forms, but constant forms
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84620 Bug ID: 84620 Summary: DW_AT_GNU_entry_view should not use address class forms, but constant forms Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: mark at gcc dot gnu.org CC: aoliva at gcc dot gnu.org Target Milestone: --- In some situations gcc will emit the view index in DWARF as a DW_FORM_addr (or DW_FORM_GNU_addr_index). This is confusing to DWARF consumers which might process address class attributes specially. A view number really is a constant class attribute. Ideally it should use DW_FORM_udata. But if a constant sized form is needed, it could also use DW_FORM_data1, DW_FORM_data2, DW_FORM_data4 or DW_FORM_data8. The issue seems to come from gcc dwarf2out.c internally using dw_val_class_lbl_id, which seems to be used for the special DW_AT_high_pc case where it could be either an address or an (constant) offset from low_pc (so it can be represented either as address class or constant class). It seems view numbers are always constant class and so should use a different (or new) dw_val_class in dwarf2out.
[Bug c/84619] Segmentation fault when running a c-program which is calling a fortran subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84619 --- Comment #2 from Janne Blomqvist --- size_t is the documented type, but for various reasons due to idiosyncrasies in the gfortran frontend, for the moment it emits a signed type the same size as size_t. Just use size_t, that should work fine.
[Bug target/52991] [6/7/8 Regression] attribute packed broken on mingw32?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #33 from Jakub Jelinek --- Hopefully fixed in GCC 8. It is an ABI change, so not going to backport it.
[Bug target/52991] [6/7/8 Regression] attribute packed broken on mingw32?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991 --- Comment #32 from Jakub Jelinek --- Author: jakub Date: Wed Feb 28 17:17:29 2018 New Revision: 258075 URL: https://gcc.gnu.org/viewcvs?rev=258075&root=gcc&view=rev Log: PR target/52991 * stor-layout.c (update_alignment_for_field): For targetm.ms_bitfield_layout_p (rli->t), if !is_bitfield && !DECL_PACKED (field), do the alignment update, just use only desired_align instead of MAX (type_align, desired_align) as the alignment. (place_field): Don't do known_align < desired_align handling early if targetm.ms_bitfield_layout_p (rli->t) and rli->prev_field is non-NULL, instead do it after rli->prev_field handling and only if not within a bitfield word. For DECL_PACKED (field) use type_align of BITS_PER_UNIT. * gcc.dg/bf-ms-layout.c: Revert 2012-04-26 changes. * gcc.dg/bf-ms-layout-2.c: Revert 2012-02-23 changes. * gcc.dg/bf-ms-layout-4.c: New test. * gcc.dg/bf-ms-layout-5.c: New test. Added: trunk/gcc/testsuite/gcc.dg/bf-ms-layout-4.c trunk/gcc/testsuite/gcc.dg/bf-ms-layout-5.c Modified: trunk/gcc/ChangeLog trunk/gcc/stor-layout.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/bf-ms-layout-2.c trunk/gcc/testsuite/gcc.dg/bf-ms-layout.c
[Bug tree-optimization/57534] [6/7/8 Regression]: Performance regression versus 4.7.3, 4.8.1 is ~15% slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534 --- Comment #29 from amker at gcc dot gnu.org --- (In reply to Jeffrey A. Law from comment #28) > BTW, ISTM that we need Bin to chime in on the complexity of improving this > in IVOPTS -- ie, is it gcc-8 or gcc-9 material. If the latter, then we > should adjust the target milestone. Yes, it's more like a GCC9 stuff. For the record, I think this could be generalized to cover addressing mode issue revealed by PR84037. That is, not only non-iv addresses, but also addresses after iv_rewrite could be refined for best selection of addressing mode.
[Bug testsuite/84617] [8 Regression] new test cases g++.dg/ext/attr-const.C and g++.dg/ext/attr-pure.C fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84617 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #2 from Martin Sebor --- Patch: Patch: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01603.html
[Bug c++/84609] [8 Regression] internal compiler error: in cp_parser_abort_tentative_parse, at cp/parser.c:28960 (cp_parser_member_declaration())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84609 --- Comment #4 from Jason Merrill --- (In reply to Jakub Jelinek from comment #3) > Created attachment 43529 [details] > gcc8-pr84609.patch > > Untested fix. Looks good.
[Bug c/84619] Segmentation fault when running a c-program which is calling a fortran subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84619 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org, ||jb at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from Jakub Jelinek --- There is nothing strange on it, gfortran changed ABI in GCC 8, so on 64-bit architectures your C prototype for the function defined in Fortran is no longer valid. void get3_ (int* ih, char* cp, char* cx, double* res, int* ier, int cp_len, int cx_len); doesn't match what we actually emit, which is: void get3_ (int* ih, char* cp, char* cx, double* res, int* ier, long cp_len, long cx_len); long should work on Linux, but might not work e.g. on 64-bit Windows, not really sure if the lengths there are 64-bit or 32-bit. If 64-bit, probably intptr_t is better (if you include stdint.h), though PR78534 claims it is size_t.
[Bug c++/84590] [7/8 Regression] -fsanitize=undefined internal compiler error: tree check: expected constructor, have target_expr in split_nonconstant_init_1, at cp/typeck2.c:629
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84590 --- Comment #5 from Jason Merrill --- (In reply to Jakub Jelinek from comment #3) > assumes that at least for non-vector cp_fully_fold of a CONSTRUCTOR will > yield again a CONSTRUCTOR as well, but that is generally not the case. > It could (at least in theory) result in error_mark_node, or VIEW_CONVERT_EXPR > around the CONSTRUCTOR: > or a TARGET_EXPR around the CONSTRUCTOR: Hmm, I think cp_fully_fold should probably strip those.
[Bug tree-optimization/57534] [6/7/8 Regression]: Performance regression versus 4.7.3, 4.8.1 is ~15% slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534 --- Comment #28 from Jeffrey A. Law --- BTW, ISTM that we need Bin to chime in on the complexity of improving this in IVOPTS -- ie, is it gcc-8 or gcc-9 material. If the latter, then we should adjust the target milestone.
[Bug tree-optimization/57534] [6/7/8 Regression]: Performance regression versus 4.7.3, 4.8.1 is ~15% slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534 --- Comment #27 from Jeffrey A. Law --- WRT c#21. There is a good paper from Click on an integrated GVN/GCM/reassoc. "Combining Analyses, Combining Optimizations" It was published in PLDI. I've probably got a copy here if you want it.
[Bug fortran/84594] Warning: Use of the NUMERIC_STORAGE_SIZE named constant from intrinsic module ISO_FORTRAN_ENV at (1) is incompatible with option -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84594 --- Comment #4 from Dominique d'Humieres --- > > (1) AFAICT this not documented. Is NUMERIC_STORAGE_SIZE the only parameter > > in > > ISO_FORTRAN_ENV triggering a warning? > > Don't know. But, it is obviously a correct warning > as -fdefault-integer-8 applies to only the default > integer kind while NUMERIC_STORAGE_SIZE applies to > all numeric types. > > > (2) The warning is not emitted with -fdefault-real-10 nor with > > -fdefault-real-16. I guess this was overlooked when these options were > > added. > > > > (3) The options -finteger-4-integer-8 and -freal-*-real-* don't trigger the > > warning. Is it because they change all the occurrences of INT or REAL, while > > -fdefault-* only change the implicit ones? > AFAIK, Yes. INTEGER(4) is known to the compiler with -finteger-4-integer-8, > the user simply cannot use it as internally gfortran map everything > to INTEGER(8) as-if the user actually ported the code. In other words, > storage association isn't broken by these options. Do you at least agree that (a) || flag_default_real_10 || flag_default_real_16 should be added to flag_default_integer || flag_default_real_8 in module.c, (b) the warning should be documented?
[Bug c/84619] New: Segmentation fault when running a c-program which is calling a fortran subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84619 Bug ID: 84619 Summary: Segmentation fault when running a c-program which is calling a fortran subroutine Product: gcc Version: 8.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: mario-baumann at web dot de Target Milestone: --- Created attachment 43531 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43531&action=edit contains the 4 sources: lnx_c.c, lnx_f.f, mac_c.c and mac_f.f I have a strange segmentation fault when running the c-programm which is calling a fortran subroutine. The strip down created slightly different codes on linux and macOS. GCC revision: 258059 Tested on: (1) linux > /Gcc/8.0.1/bin/gcc -v Using built-in specs. COLLECT_GCC=/Gcc/8.0.1/bin/gcc COLLECT_LTO_WRAPPER=/opt/Gcc/8.0.1/bin/../libexec/gcc/x86_64-pc-linux-gnu/8.0.1/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /Gcc/8.0.1/.src/configure --prefix=/Gcc/8.0.1 --enable-languages=c,c++,fortran --enable-lto --disable-nls --disable-libquadmath --disable-libquadmath-support Thread model: posix gcc version 8.0.1 20180228 (experimental) (GCC) > /Gcc/8.0.1/bin/gcc -c -m64 -march=nocona -O1 lnx_c.c > /Gcc/8.0.1/bin/gfortran -o z_lnx -m64 -march=nocona lnx_c.o lnx_f.f > ./z_lnx Segmentation fault (core dumped) (2) macOS > /Gcc/8.0.1/bin/gcc -v Using built-in specs. COLLECT_GCC=/Gcc/8.0.1/bin/gcc COLLECT_LTO_WRAPPER=/Gcc/8.0.1/libexec/gcc/x86_64-apple-darwin17/8.0.1/lto-wrapper Target: x86_64-apple-darwin17 Configured with: /Gcc/8.0.1/.src/configure --prefix=/Gcc/8.0.1 --build=x86_64-apple-darwin17 --enable-languages=c,c++,fortran --enable-lto --enable-stage1-checking --enable-libstdcxx-time --disable-nls --disable-libquadmath --disable-libquadmath-support --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --with-as=/opt/local/bin/as --with-system-zlib --with-pkgversion=svn-revision-258059 Thread model: posix gcc version 8.0.1 20180228 (experimental) (svn-revision-258059) > /Gcc/8.0.1/bin/gcc -c -m64 -march=nocona -O1 mac_c.c > /Gcc/8.0.1/bin/gfortran -o z_mac -m64 -march=nocona mac_c.o mac_f.f > ./z_mac Segmentation fault: 11 Findings: (1) -O2 instead of -O1 crashes too (2) -O0 works fiine (3) gcc-7.3 works fine with -O0, -O1 and -O2 (4) valgrind complains about: ==11458==at 0x501846A: _gfortran_string_index (string_intrinsics_inc.c:254) ==11458==at 0x5018483: _gfortran_string_index (string_intrinsics_inc.c:270)
[Bug debug/84550] [8 Regression] stepping through gcc does not work with gdb 8.0.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84550 --- Comment #6 from Pedro Alves --- I see the same thing with your reduced testcase: ~~~ infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x400580 infrun: stepped into subroutine infrun: inserting step-resume breakpoint at 0x400410 infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 13966] at 0x400580 ~~~ 0x400410 is never hit. With: (gdb) disassemble /s qux Dump of assembler code for function qux(C*): t.c: 33if (!p->c) __builtin_abort (); 0x00400410 <+0>: callq 0x400400 0x00400415: nopw %cs:0x0(%rax,%rax,1) 0x0040041f: nop ... 0x00400578 <+16>:nopl 0x0(%rax,%rax,1) 9 return false; 0x00400580 <+0>: xor%eax,%eax 0x00400582 <+2>: retq 0x00400583: nopl (%rax) 0x00400586: nopw %cs:0x0(%rax,%rax,1) ---Type to continue, or q to quit--- ... we see that "foo" is sharing the tail end of qux? And we see that "0x400410", where GDB things foo's prologue ends, is actually the end of qux's prologue: (gdb) disassemble /s foo Dump of assembler code for function qux(C*): t.c: 33if (!p->c) __builtin_abort (); 0x00400410 <+0>: callq 0x400400 0x00400415: nopw %cs:0x0(%rax,%rax,1) 0x0040041f: nop When we do "b foo", gdb sets a breakpoint at 0x400580 instead (passed foo's prologue). I don't know why it gets it wrong when stepping into the function.