[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 #3 from Jay --- The star isn't matching anything, so it tries to create star. I did set -ex to debug but I don't that is causing the problem. Perhaps on other systems it does actually create star, but nobody noticed? I'll have to check.
[Bug c++/84638] New: internal compiler error: verify_gimple failed (error: invalid rhs for gimple memory store)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84638
Bug ID: 84638
Summary: internal compiler error: verify_gimple failed (error:
invalid rhs for gimple memory store)
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(volatile int b) { &b; }
Output:
$ xgcc -x c++ -S -fpermissive -fsanitize=address -
:1:17: warning: ISO C++ forbids declaration of 'a' with no type
[-fpermissive]
: In function 'int a(int)':
:1:25: warning: no return statement in function returning non-void
[-Wreturn-type]
:1:1: error: invalid rhs for gimple memory store
b
b
# .MEM_2 = VDEF <.MEM_1(D)>
b ={v} b;
during GIMPLE pass: sanopt
:1:1: internal compiler error: verify_gimple failed
0x32e110f verify_gimple_in_cfg(function*, bool)
/home/vegard/git/gcc/gcc/tree-cfg.c:5579
0x2b65957 execute_function_todo
/home/vegard/git/gcc/gcc/passes.c:1994
0x2b6e626 do_per_function
/home/vegard/git/gcc/gcc/passes.c:1659
0x2b6e626 execute_todo
/home/vegard/git/gcc/gcc/passes.c:2048
$ xgcc --version
xgcc (GCC) 8.0.1 20180228 (experimental)
Built from git fd1990b25777e5f1307eac1447e8fb5fefe747b4 (r258063).
7.3.0 looks fine to me.
Test case was reduced by C-Reduce.
[Bug c++/84639] New: gcc/c-family/c-attribs.c:1822:27: runtime error: shift exponent -1 is negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84639
Bug ID: 84639
Summary: gcc/c-family/c-attribs.c:1822:27: runtime error: shift
exponent -1 is negative
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jason at gcc dot gnu.org, mpolacek at gcc dot gnu.org,
nathan at gcc dot gnu.org
Target Milestone: ---
UBSAN gcc prints the error:
$ UBSAN_OPTIONS="print_stacktrace=1" ./xg++ -B.
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp0x/alignas12.C
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp0x/alignas12.C:6:10:
error: ‘alignas’ argument has non-integral type ‘’
alignas (f < int >) char c; // { dg-error "non-integral type" }
^
../../gcc/c-family/c-attribs.c:1822:27: runtime error: shift exponent -1 is
negative
#0 0x5e311c in common_handle_aligned_attribute
../../gcc/c-family/c-attribs.c:1822
#1 0xe29d06 in decl_attributes(tree_node**, tree_node*, int, tree_node*)
../../gcc/attribs.c:685
#2 0x991bd9 in cplus_decl_attributes(tree_node**, tree_node*, int)
../../gcc/cp/decl2.c:1546
#3 0x95790d in start_decl(cp_declarator const*, cp_decl_specifier_seq*,
int, tree_node*, tree_node*, tree_node**) ../../gcc/cp/decl.c:5047
#4 0xb95381 in cp_parser_init_declarator ../../gcc/cp/parser.c:19587
#5 0xbaef4d in cp_parser_simple_declaration ../../gcc/cp/parser.c:13053
#6 0xbb230e in cp_parser_block_declaration ../../gcc/cp/parser.c:12878
#7 0xbc4460 in cp_parser_declaration ../../gcc/cp/parser.c:12776
#8 0xbc66a1 in cp_parser_declaration_seq_opt ../../gcc/cp/parser.c:12652
#9 0xbc7628 in cp_parser_translation_unit ../../gcc/cp/parser.c:4559
#10 0xbc7628 in c_parse_file() ../../gcc/cp/parser.c:38880
#11 0xeec35c in c_common_parse_file() ../../gcc/c-family/c-opts.c:1132
#12 0x25a2cdc in compile_file ../../gcc/toplev.c:455
#13 0x77e2e9 in do_compile ../../gcc/toplev.c:2132
#14 0x77e2e9 in toplev::main(int, char**) ../../gcc/toplev.c:2267
#15 0x78117a in main ../../gcc/main.c:39
#16 0x7fd52c3026e4 in __libc_start_main (/lib64/libc.so.6+0x206e4)
#17 0x7812a8 in _start
(/home/marxin/Programming/gcc/objdir/gcc/cc1plus+0x7812a8)
[Bug c++/84638] -fsanitize=address internal compiler error: verify_gimple failed (error: invalid rhs for gimple memory store)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84638 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-03-01 CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Liška --- Confirmed.
[Bug fortran/84640] New: gcc/fortran/simplify.c:2587:9: runtime error: pointer index expression with base 0x0000090de160 overflowed to 0xffffffffc0632960
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84640 Bug ID: 84640 Summary: gcc/fortran/simplify.c:2587:9: runtime error: pointer index expression with base 0x090de160 overflowed to 0xc0632960 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- UBSAN GCC sees: $ UBSAN_OPTIONS="print_stacktrace=1" ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/eoshift.f90 -c ../../gcc/fortran/simplify.c:2586:9: runtime error: pointer index expression with base 0x090e15e0 overflowed to 0xc0635de0 v#0 0xa56cf8 in gfc_simplify_eoshift(gfc_expr*, gfc_expr*, gfc_expr*, gfc_expr*) ../../gcc/fortran/simplify.c:2586 #1 0x8a929d in do_simplify ../../gcc/fortran/intrinsic.c:4433 #2 0x8b6be5 in gfc_intrinsic_func_interface(gfc_expr*, int) ../../gcc/fortran/intrinsic.c:4796 #3 0xa13b36 in resolve_unknown_f ../../gcc/fortran/resolve.c:2870 #4 0xa13b36 in resolve_function ../../gcc/fortran/resolve.c:3179 #5 0xa026da in gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:6709 #6 0x9d8f0b in gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11084 #7 0xa2d2a0 in gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:10131 #8 0x9d94f8 in gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11074 #9 0x9e6f18 in resolve_codes ../../gcc/fortran/resolve.c:16512 #10 0x9e70c3 in gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:16547 #11 0x98a65c in resolve_all_program_units ../../gcc/fortran/parse.c:6060 #12 0x98a65c in gfc_parse_file() ../../gcc/fortran/parse.c:6310 #13 0xac7128 in gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204 #14 0x233d73c in compile_file ../../gcc/toplev.c:455 #15 0x787949 in do_compile ../../gcc/toplev.c:2132 #16 0x787949 in toplev::main(int, char**) ../../gcc/toplev.c:2267 #17 0x78a80a in main ../../gcc/main.c:39 #18 0x7f23797dc6e4 in __libc_start_main (/lib64/libc.so.6+0x206e4) #19 0x78a938 in _start (/home/marxin/Programming/gcc/objdir/gcc/f951+0x78a938) ../../gcc/fortran/simplify.c:2587:9: runtime error: pointer index expression with base 0x090de160 overflowed to 0xc0632960 #0 0xa56d18 in gfc_simplify_eoshift(gfc_expr*, gfc_expr*, gfc_expr*, gfc_expr*) ../../gcc/fortran/simplify.c:2587 #1 0x8a929d in do_simplify ../../gcc/fortran/intrinsic.c:4433 #2 0x8b6be5 in gfc_intrinsic_func_interface(gfc_expr*, int) ../../gcc/fortran/intrinsic.c:4796 #3 0xa13b36 in resolve_unknown_f ../../gcc/fortran/resolve.c:2870 #4 0xa13b36 in resolve_function ../../gcc/fortran/resolve.c:3179 #5 0xa026da in gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:6709 #6 0x9d8f0b in gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11084 #7 0xa2d2a0 in gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:10131 #8 0x9d94f8 in gfc_resolve_code(gfc_code*, gfc_namespace*) ../../gcc/fortran/resolve.c:11074 #9 0x9e6f18 in resolve_codes ../../gcc/fortran/resolve.c:16512 #10 0x9e70c3 in gfc_resolve(gfc_namespace*) ../../gcc/fortran/resolve.c:16547 #11 0x98a65c in resolve_all_program_units ../../gcc/fortran/parse.c:6060 #12 0x98a65c in gfc_parse_file() ../../gcc/fortran/parse.c:6310 #13 0xac7128 in gfc_be_parse_file ../../gcc/fortran/f95-lang.c:204 #14 0x233d73c in compile_file ../../gcc/toplev.c:455 #15 0x787949 in do_compile ../../gcc/toplev.c:2132 #16 0x787949 in toplev::main(int, char**) ../../gcc/toplev.c:2267 #17 0x78a80a in main ../../gcc/main.c:39 #18 0x7f23797dc6e4 in __libc_start_main (/lib64/libc.so.6+0x206e4) #19 0x78a938 in _start (/home/marxin/Programming/gcc/objdir/gcc/f951+0x78a938)
[Bug c++/84638] [8 Regression] -fsanitize=address internal compiler error: verify_gimple failed (error: invalid rhs for gimple memory store)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84638 Martin Liška changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P1 Known to work||7.3.0 Summary|-fsanitize=address internal |[8 Regression] |compiler error: |-fsanitize=address internal |verify_gimple failed|compiler error: |(error: invalid rhs for |verify_gimple failed |gimple memory store)|(error: invalid rhs for ||gimple memory store) Known to fail||8.0 --- Comment #2 from Martin Liška --- Started with my revision r249903.
[Bug ipa/84641] New: gcc/ipa-pure-const.c:1951:22: runtime error: load of value 66, which is not a valid value for type 'bool'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84641 Bug ID: 84641 Summary: gcc/ipa-pure-const.c:1951:22: runtime error: load of value 66, which is not a valid value for type 'bool' Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: jamborm at gcc dot gnu.org, kugan at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- With UBSAN gcc compiler I see: $ UBSAN_OPTIONS="print_stacktrace=1" ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/pr71633.C -c -O3 -mmpx -O2 -std=gnu++11 -fcheck-pointer-bounds ../../gcc/ipa-pure-const.c:1951:22: runtime error: load of value 118, which is not a valid value for type 'bool' #0 0x761403 in propagate_malloc ../../gcc/ipa-pure-const.c:1951 #1 0x761403 in execute ../../gcc/ipa-pure-const.c:2017 #2 0x20c2e9c in execute_one_pass(opt_pass*) ../../gcc/passes.c:2497 #3 0x20c9217 in execute_ipa_pass_list(opt_pass*) ../../gcc/passes.c:2932 #4 0x121c532 in ipa_passes ../../gcc/cgraphunit.c:2476 #5 0x121c532 in symbol_table::compile() ../../gcc/cgraphunit.c:2558 #6 0x1227bd6 in symbol_table::finalize_compilation_unit() ../../gcc/cgraphunit.c:2717 #7 0x25a2ffc in compile_file ../../gcc/toplev.c:480 #8 0x77e2e9 in do_compile ../../gcc/toplev.c:2132 #9 0x77e2e9 in toplev::main(int, char**) ../../gcc/toplev.c:2267 #10 0x78117a in main ../../gcc/main.c:39 #11 0x7f766edbe6e4 in __libc_start_main (/lib64/libc.so.6+0x206e4) #12 0x7812a8 in _start (/home/marxin/Programming/gcc/objdir/gcc/cc1plus+0x7812a8)
[Bug c++/84642] New: internal compiler error: Segmentation fault (tree_check()/synthesize_implicit_template_parm())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84642 Bug ID: 84642 Summary: internal compiler error: Segmentation fault (tree_check()/synthesize_implicit_template_parm()) 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(int(const &&__attribute__((b(auto;) Output: :1:36: internal compiler error: Segmentation fault 0x3150de9 crash_signal /home/vegard/git/gcc/gcc/toplev.c:325 0xe88bdc tree_check(tree_node*, char const*, int, char const*, tree_code) /home/vegard/git/gcc/gcc/tree.h:3131 0xe88bdc synthesize_implicit_template_parm /home/vegard/git/gcc/gcc/cp/parser.c:39093 0xf3126d cp_parser_simple_type_specifier /home/vegard/git/gcc/gcc/cp/parser.c:17021 0xf78c86 cp_parser_postfix_expression /home/vegard/git/gcc/gcc/cp/parser.c:6947 0xf2cc47 cp_parser_unary_expression /home/vegard/git/gcc/gcc/cp/parser.c:8318 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 0xed60f4 cp_parser_parenthesized_expression_list /home/vegard/git/gcc/gcc/cp/parser.c:7760 0xed8bcb cp_parser_gnu_attribute_list /home/vegard/git/gcc/gcc/cp/parser.c:25050 0xed8bcb cp_parser_gnu_attributes_opt /home/vegard/git/gcc/gcc/cp/parser.c:24965 0xfb99d2 cp_parser_parameter_declaration /home/vegard/git/gcc/gcc/cp/parser.c:21559 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 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 Seems potentially related to bug #84610? $ xgcc --version xgcc (GCC) 8.0.1 20180228 (experimental) Built from git fd1990b25777e5f1307eac1447e8fb5fefe747b4 (r258063). Seems to start crashing between 5.5.0 and 6.1.0. Test case was reduced by C-Reduce.
[Bug fortran/84538] [8 Regression] Array of derived type elements incorrectly accessed in function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84538 --- Comment #5 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Thu Mar 1 08:22:06 2018 New Revision: 258094 URL: https://gcc.gnu.org/viewcvs?rev=258094&root=gcc&view=rev Log: Tighten use of HARD_FRAME_POINTER_REGNUM in alias.c (PR 84538) RTL code needs to be consistent about whether it uses the stack pointer, the frame pointer or the argument pointer to access a given part of the frame. alias.c used this to divide accesses into three independent areas. The problem in the PR is that we did this for HARD_FRAME_POINTER_REGNUM even when the register wasn't being used as a frame pointer. We can't do that because the frame pointer is then just any old allocatable register and could certainly point to info accessed through the argument pointer or stack pointer. 2018-03-01 Richard Sandiford gcc/ PR rtl-optimization/84538 * alias.c (init_alias_target): Add commentary. (init_alias_analysis): Only give HARD_FRAME_POINTER_REGNUM a unique base value if the frame pointer is not eliminated to the stack pointer. gcc/testsuite/ PR rtl-optimization/84538 * gcc.dg/torture/pr84538.c: New test. Added: trunk/gcc/testsuite/gcc.dg/torture/pr84538.c Modified: trunk/gcc/ChangeLog trunk/gcc/alias.c trunk/gcc/testsuite/ChangeLog
[Bug rtl-optimization/84643] New: gcc/optabs.c:6549:26: runtime error: load of value 131075, which is not a valid value for type 'memmodel'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84643 Bug ID: 84643 Summary: gcc/optabs.c:6549:26: runtime error: load of value 131075, which is not a valid value for type 'memmodel' Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- UBSAN GCC prints: $ UBSAN_OPTIONS="print_stacktrace=1 halt_on_error=1" ./xgcc -B. /home/marxin/Programming/gcc2/gcc/testsuite/gcc.target/i386/hle-clear-rel.c /home/marxin/Programming/gcc2/gcc/optabs.c:6549:26: runtime error: load of value 131075, which is not a valid value for type 'memmodel' #0 0x1869089 in expand_atomic_store(rtx_def*, rtx_def*, memmodel, bool) /home/marxin/Programming/gcc2/gcc/optabs.c:6549 #1 0x9f2e5b in expand_builtin_atomic_clear /home/marxin/Programming/gcc2/gcc/builtins.c:6352 #2 0xa164b1 in expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int) /home/marxin/Programming/gcc2/gcc/builtins.c:7644 #3 0xf5bb24 in expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) /home/marxin/Programming/gcc2/gcc/expr.c:10987 #4 0xaa67b2 in expand_expr /home/marxin/Programming/gcc2/gcc/expr.h:276 #5 0xaa67b2 in expand_call_stmt /home/marxin/Programming/gcc2/gcc/cfgexpand.c:2690 #6 0xaa67b2 in expand_gimple_stmt_1 /home/marxin/Programming/gcc2/gcc/cfgexpand.c:3624 #7 0xaa67b2 in expand_gimple_stmt /home/marxin/Programming/gcc2/gcc/cfgexpand.c:3790 #8 0xaae4b9 in expand_gimple_basic_block /home/marxin/Programming/gcc2/gcc/cfgexpand.c:5819 #9 0xac55d9 in execute /home/marxin/Programming/gcc2/gcc/cfgexpand.c:6425 #10 0x18f0680 in execute_one_pass(opt_pass*) /home/marxin/Programming/gcc2/gcc/passes.c:2497 #11 0x18f39eb in execute_pass_list_1 /home/marxin/Programming/gcc2/gcc/passes.c:2586 #12 0x18f3aa4 in execute_pass_list(function*, opt_pass*) /home/marxin/Programming/gcc2/gcc/passes.c:2597 #13 0xbe07be in cgraph_node::expand() /home/marxin/Programming/gcc2/gcc/cgraphunit.c:2139 #14 0xbe55fd in output_in_order /home/marxin/Programming/gcc2/gcc/cgraphunit.c:2381 #15 0xbe55fd in symbol_table::compile() /home/marxin/Programming/gcc2/gcc/cgraphunit.c:2623 #16 0xbef497 in symbol_table::compile() /home/marxin/Programming/gcc2/gcc/cgraphunit.c:2720 #17 0xbef497 in symbol_table::finalize_compilation_unit() /home/marxin/Programming/gcc2/gcc/cgraphunit.c:2717 #18 0x1d0af28 in compile_file /home/marxin/Programming/gcc2/gcc/toplev.c:480 #19 0x639b7c in do_compile /home/marxin/Programming/gcc2/gcc/toplev.c:2132 #20 0x639b7c in toplev::main(int, char**) /home/marxin/Programming/gcc2/gcc/toplev.c:2267 #21 0x63c5da in main /home/marxin/Programming/gcc2/gcc/main.c:39 #22 0x75cfbf49 in __libc_start_main (/lib64/libc.so.6+0x20f49) #23 0x63c709 in _start (/dev/shm/objdir/gcc/cc1+0x63c709)
[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 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED CC||rsandifo at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from rsandifo at gcc dot gnu.org --- Mine.
[Bug c++/84644] New: internal compiler error: in warn_misplaced_attr_for_class_type, at cp/decl.c:4718
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84644
Bug ID: 84644
Summary: internal compiler error: in
warn_misplaced_attr_for_class_type, at cp/decl.c:4718
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:
template
struct b {
decltype(a) __attribute__((break));
};
Output:
$ xgcc -x c++ -S -
:3:35: internal compiler error: in warn_misplaced_attr_for_class_type,
at cp/decl.c:4718
0xb37123 warn_misplaced_attr_for_class_type(unsigned int, tree_node*)
/home/vegard/git/gcc/gcc/cp/decl.c:4718
0xb37123 check_tag_decl(cp_decl_specifier_seq*, bool)
/home/vegard/git/gcc/gcc/cp/decl.c:4877
0xfe3a56 cp_parser_member_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:23548
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
0xfa575f cp_parser_single_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:27072
0xfc7fd8 cp_parser_template_declaration_after_parameters
/home/vegard/git/gcc/gcc/cp/parser.c:26761
0xfc65db cp_parser_explicit_template_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:26999
0xfc65db cp_parser_template_declaration_after_export
/home/vegard/git/gcc/gcc/cp/parser.c:27017
0x1001711 cp_parser_declaration
/home/vegard/git/gcc/gcc/cp/parser.c:12725
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 to start crashing between 5.5.0 and 6.1.0.
Test case was reduced by C-Reduce.
[Bug target/84528] [8 Regression] gcc.c-torture/execute/960419-2.c -O3 fails with -fno-omit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84528 --- Comment #7 from rsandifo at gcc dot gnu.org --- Author: rsandifo Date: Thu Mar 1 08:30:20 2018 New Revision: 258095 URL: https://gcc.gnu.org/viewcvs?rev=258095&root=gcc&view=rev Log: 2018-03-01 Richard Sandiford gcc/testsuite/ PR rtl-optimization/84528 * gcc.dg/torture/pr84538.c: Rename to... * gcc.dg/torture/pr84528.c: ...this. Added: trunk/gcc/testsuite/gcc.dg/torture/pr84528.c Removed: trunk/gcc/testsuite/gcc.dg/torture/pr84538.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/84538] [8 Regression] Array of derived type elements incorrectly accessed in function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84538 rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #6 from rsandifo at gcc dot gnu.org --- Sorry about comment 5. Have fixed the changelog and renamed the test.
[Bug target/84528] [8 Regression] gcc.c-torture/execute/960419-2.c -O3 fails with -fno-omit-frame-pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84528 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from rsandifo at gcc dot gnu.org --- Fixed on trunk.
[Bug sanitizer/82484] [8 Regression] ICE in verify_gimple failed w/ -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82484 Martin Liška changed: What|Removed |Added Status|RESOLVED|ASSIGNED Known to work||7.3.0 Resolution|FIXED |--- Known to fail||8.0 --- Comment #3 from Martin Liška --- It's not fixed as I reverted the patch in r253638 (due it was not approved on ML)
[Bug debug/84645] New: -flto -g0 at compile-time vs. -flto -g at link time ICEs in add_dwarf_attr, at dwarf2out.c:4353
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84645 Bug ID: 84645 Summary: -flto -g0 at compile-time vs. -flto -g at link time ICEs in add_dwarf_attr, at dwarf2out.c:4353 Product: gcc Version: 8.0 Status: UNCONFIRMED Keywords: lto Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Blocks: 82005 Target Milestone: --- When building gfortran.dg/namelist_69.f90 with -flto -g0 and linking it with -flto -g we end up ICEing at link-time: /space/rguenther/src/svn/early-lto-debug/gcc/testsuite/gfortran.dg/namelist_69.f90: In function ‘test2’: /space/rguenther/src/svn/early-lto-debug/gcc/testsuite/gfortran.dg/namelist_69.f90:232: internal compiler error: in add_dwarf_attr, at dwarf2out.c:4353 0x98bc53 add_dwarf_attr /space/rguenther/src/svn/early-lto-debug/gcc/dwarf2out.c:4353 0x98c55a add_AT_die_ref /space/rguenther/src/svn/early-lto-debug/gcc/dwarf2out.c:4730 0x9b7ee0 add_type_attribute /space/rguenther/src/svn/early-lto-debug/gcc/dwarf2out.c:21383 0x9bda80 gen_variable_die /space/rguenther/src/svn/early-lto-debug/gcc/dwarf2out.c:23539 0x9c5a67 gen_decl_die /space/rguenther/src/svn/early-lto-debug/gcc/dwarf2out.c:26158 0x9c3fe0 process_scope_var /space/rguenther/src/svn/early-lto-debug/gcc/dwarf2out.c:25614 this sort-of blocks PR82005 which forces -g0 at compile-time (sth usually isn't what people do). Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82005 [Bug 82005] [8 regression] early lto debug creates invalid assembly on Darwin
[Bug debug/84645] -flto -g0 at compile-time vs. -flto -g at link time ICEs in add_dwarf_attr, at dwarf2out.c:4353
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84645 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2018-03-01 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Mine.
[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 Bug 63426 depends on bug 84638, which changed state. Bug 84638 Summary: [8 Regression] -fsanitize=address internal compiler error: verify_gimple failed (error: invalid rhs for gimple memory store) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84638 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE
[Bug sanitizer/82484] [8 Regression] ICE in verify_gimple failed w/ -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82484 Martin Liška changed: What|Removed |Added CC||vegard.nossum at gmail dot com --- Comment #4 from Martin Liška --- *** Bug 84638 has been marked as a duplicate of this bug. ***
[Bug target/82005] [8 regression] early lto debug creates invalid assembly on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82005 --- Comment #31 from Richard Biener --- (In reply to Dominique d'Humieres from comment #30) > > However I have restore my testing of the gfortran test suite with -g -flto > > and I see the following new failures: > > > > FAIL: gfortran.dg/namelist_14.f90 -g -flto (internal compiler error) > > FAIL: gfortran.dg/namelist_14.f90 -g -flto (test for excess errors) > > FAIL: gfortran.dg/namelist_69.f90 -g -flto (internal compiler error) > > FAIL: gfortran.dg/namelist_69.f90 -g -flto (test for excess errors) > > FAIL: gfortran.dg/namelist_70.f90 -g -flto (internal compiler error) > > FAIL: gfortran.dg/namelist_70.f90 -g -flto (test for excess errors) > > This is caused by revision r251448 and "fixed" by restoring the gcc_assert > in r251447. > > I also see > > FAIL: libgomp.fortran/taskloop3.f90 -g -flto (internal compiler error) > > which appeared between r251187 and r251447. Ok, I can reproduce those when compiling with -flto -g0 and linking with -flto -g which is what the patch in comment 26 ends up forcing (-g0 at compile-time). Let's split this out to a separate bug. PR84645. > IMO the patch in comment 26 should be committed. Patch posted, waiting for approval.
[Bug sanitizer/84638] [8 Regression] -fsanitize=address internal compiler error: verify_gimple failed (error: invalid rhs for gimple memory store)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84638 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Martin Liška --- Dup. *** This bug has been marked as a duplicate of bug 82484 ***
[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 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Paul Thomas --- Fixed on trunk. Thanks for the report. Paul
[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 Jay changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WONTFIX |--- --- Comment #4 from Jay --- Changing back to unconfirmed. Something is off here, I just didn't report it correctly.
[Bug fortran/84538] [8 Regression] Array of derived type elements incorrectly accessed in function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84538 --- Comment #7 from Paul Thomas --- Author: pault Date: Thu Mar 1 08:56:31 2018 New Revision: 258097 URL: https://gcc.gnu.org/viewcvs?rev=258097&root=gcc&view=rev Log: 2018-03-01 Paul Thomas PR fortran/84538 * class.c (class_array_ref_detected): Remove the condition that there be no reference after the array reference. (find_intrinsic_vtab): Remove excess whitespace. * trans-array.c (gfc_conv_scalarized_array_ref): Rename 'tmp' as 'base and call build_class_array_ref earlier. 2018-03-01 Paul Thomas PR fortran/84538 * gfortran.dg/class_array_23.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/class_array_23.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/class.c trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog
[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 #31 from rguenther at suse dot de --- On Wed, 28 Feb 2018, law at redhat dot com wrote: > 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. I've googled the thesis but cannot find the paper - so yes, if you have a copy please send it my way.
[Bug c++/71569] [6/7/8 regression] Crash: External definition of template member from template struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71569
Paolo Carlini changed:
What|Removed |Added
Keywords||ice-on-valid-code
--- Comment #5 from Paolo Carlini ---
This is also an ICE on valid. Fro example, from Jason:
template
struct A {
template
static const U u;
};
template
template
const U* A::u = nullptr;
[Bug c++/84612] Overload resolution of operator* fails for valarray
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84612 --- Comment #3 from niva at niisi dot msk.ru --- Thank you very much!
[Bug c++/84639] gcc/c-family/c-attribs.c:1822:27: runtime error: shift exponent -1 is negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84639 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-03-01 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed with an assert.
[Bug c++/84639] gcc/c-family/c-attribs.c:1822:27: runtime error: shift exponent -1 is negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84639
--- Comment #2 from Marek Polacek ---
Can be fixed by moving the checking a bit above:
--- a/gcc/c-family/c-attribs.c
+++ b/gcc/c-family/c-attribs.c
@@ -1818,6 +1818,13 @@ common_handle_aligned_attribute (tree *node, tree name,
tree args, int flags,
/* Log2 of specified alignment. */
int pow2align = check_user_alignment (align_expr, true);
+ if (pow2align == -1
+ || !check_cxx_fundamental_alignment_constraints (*node, pow2align,
flags))
+{
+ *no_add_attrs = true;
+ return NULL_TREE;
+}
+
/* The alignment in bits corresponding to the specified alignment. */
unsigned bitalign = (1U << pow2align) * BITS_PER_UNIT;
@@ -1826,10 +1833,7 @@ common_handle_aligned_attribute (tree *node, tree name,
tree args, int flags,
unsigned curalign = 0;
unsigned lastalign = 0;
- if (pow2align == -1
- || !check_cxx_fundamental_alignment_constraints (*node, pow2align,
flags))
-*no_add_attrs = true;
- else if (is_type)
+ if (is_type)
{
if ((flags & (int) ATTR_FLAG_TYPE_IN_PLACE))
/* OK, modify the type in place. */;
[Bug middle-end/64920] bootstrap-ubsan [build/gengtype -r gtype.state]: libiberty/regex.c:6970:11: runtime error: left shift of negative value -1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64920 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2018-03-01 CC||marxin at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Martin Liška --- Can't see it any longer in boostrap on x86. Can you please re-test it?
[Bug c++/84633] internal compiler error: in lvalue_kind, at cp/tree.c:206
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84633 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-03-01 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed. Even 4.9 ICEs. (In reply to Vegard Nossum from comment #0) > 7.3.0 seems fine. I think you're testing with a compiler built with --enable-checking=release so it doesn't crash for you. Building GCC with --enable-checking=yes would show the ICE.
[Bug c++/84632] 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 Marek Polacek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Can't reproduce this one with r258080.
[Bug c++/84636] internal compiler error: Segmentation fault (identifier_p()/grokdeclarator())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84636 Marek Polacek changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-03-01 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[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 Richard Biener changed: What|Removed |Added 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 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[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 #5 from Jay --- I confirmed. Here is what you can. Build out of tree, of course. cd fixincludes make check while it is printing "fixed...", press control-c ls tests/inc You will see a directory named "*". Creating this works on Mac and presumably Linux, but not WSL. Because like I said * doesn't match anything, so goes through on its own. This stuff does a good job of hiding what it is doing and deleting its tracks btw. It helps to remove the >/dev/null in check.tpl/check.sh. And set -ex in the parenthesized chunk near the top. WSL should try to support this, I guess, but it is a little wonky. Seems maybe an accident here. Maybe it is for in-tree builds? I also see a directory named "sun*" that might cause grief.
[Bug c++/84644] internal compiler error: in warn_misplaced_attr_for_class_type, at cp/decl.c:4718
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84644 Marek Polacek changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-03-01 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/84633] internal compiler error: in lvalue_kind, at cp/tree.c:206
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84633 --- Comment #2 from Vegard Nossum --- (In reply to Marek Polacek from comment #1) > (In reply to Vegard Nossum from comment #0) > > 7.3.0 seems fine. > > I think you're testing with a compiler built with --enable-checking=release > so it doesn't crash for you. Building GCC with --enable-checking=yes would > show the ICE. You are right; I used 7.3 on godbolt.org to verify and I either pasted the wrong reproducer or I missed the error (it does say "confused by earlier errors, bailing out", and in those cases I would usually include this message in the bug report). pinskia also reminded me that this "confused by earlier errors" message is an indication of ICE. My bad!
[Bug target/84616] funsafe-math-optimizations leads to incorrect results for 4x4 matrix inversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84616 Richard Biener changed: What|Removed |Added Keywords||needs-reduction, wrong-code Target||x86_64-*-*, i?86-*-* Status|WAITING |NEW CC||rguenth at gcc dot gnu.org Component|c++ |target Version|unknown |7.3.1 --- Comment #3 from Richard Biener --- Hmm, I get (with local Eigen library) at -O0: 1 -0 0 -0 -0 1 -0 0 0 -0 1 -0 -0 0 -0 1 so it looks like Eigen has issues with signed zeros? I can reproduce your bogus output already with -O -fno-signed-zeros with my eigen version. Your preprocessed source also produces those signed zero issues seen above but requires -funsafe-math-optimizations to reproduce the issue. So, "confirmed", but given the complexity of Eigen I wouldn't rule out issues with the library itself. Interestingly with -m32 -Ofast -mno-sse I see correct results (apart from the signed zeros). Needs to be tracked down to sth simpler than Eigen...
[Bug c++/84632] 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 --- Comment #2 from Vegard Nossum --- (In reply to Marek Polacek from comment #1) > Can't reproduce this one with r258080. I just recompiled r258097 and I still get it: $ xgcc -x c++ -S - [...] :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 $ xgcc --version xgcc (GCC) 8.0.1 20180301 (experimental) $ cc1plus -version GNU C++14 (GCC) version 8.0.1 20180301 (experimental) (x86_64-pc-linux-gnu) compiled by GNU C version 5.4.1 20160904, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version none GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Is there anything else I can do (for example any other information I can give)? I tried running it under valgrind --trace-children=yes and it gives 0 errors.
[Bug c++/84632] 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 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-03-01 Ever confirmed|0 |1 --- Comment #3 from Marek Polacek --- You're right, one of my local patches apparently fixes this ;). Confirmed with vanilla trunk.
[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 #5 from Eric Gallager --- (In reply to Jay from comment #4) > Incorrect bug. Correct place was bug 84628 comment #6, for any confused onlookers
[Bug c/84646] New: Missed optimisation for hoisting conditions outside nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84646
Bug ID: 84646
Summary: Missed optimisation for hoisting conditions outside
nested loops
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: david at westcontrol dot com
Target Milestone: ---
This is a missed optimisation opportunity. In a discussion about the "best"
way to break out of a nested loop, I tested this code with gcc:
int foo(const int * p, const int * q, int m, int n) {
int sum = 0;
bool running = true;
const int max = 2;
for (int i = 0; i < n; i++) {
for (int j = 0; j < m; j++) {
if (running) {
sum += (p[i] * q[j]);
if (sum >= max) {
running = false;
sum = max;
}
}
}
}
return sum;
}
The test for "running" is hoisted outside the inner loop, so that the generated
code is changed to approximately:
int foo(const int * p, const int * q, int m, int n) {
int sum = 0;
bool running = true;
const int max = 2;
for (int i = 0; i < n; i++) {
loop:
if (running) {
for (int j = 0; j < m; j++) {
sum += (p[i] * q[j]);
if (sum >= max) {
running = false;
sum = max;
goto loop;
}
}
}
}
return sum;
}
This is definitely a good step - avoiding the check for "running" in the inner
loop, and breaking out of it when the max condition is reached is a clear win.
But it would be even nicer if the check could be hoisted further - the
"running" flag could be completely eliminated to give the transformation:
int foo(const int * p, const int * q, int m, int n) {
int sum = 0;
//bool running = true;
const int max = 2;
for (int i = 0; i < n; i++) {
for (int j = 0; j < m; j++) {
if (running) {
sum += (p[i] * q[j]);
if (sum >= max) {
//running = false;
sum = max;
goto exit;
}
}
}
}
exit:
return sum;
}
Testing was done with -O2 and -O3, on a variety of gcc versions and targets
(thanks, godbolt.org!) up to version 8.0 (trunk at this time). The generated
code showed approximately the same transformations and optimisations.
[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 Paul Hua changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Paul Hua --- (In reply to Jakub Jelinek from comment #1) > Hasn't r257993 fixed this already? Yes, fixed.
[Bug ipa/84628] attribute(warning/error) functions should not be merged together
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84628 --- Comment #10 from Jakub Jelinek --- Created attachment 43533 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43533&action=edit gcc8-pr84628.patch Untested fix.
[Bug fortran/84219] [8 Regression] ICE: Invalid expression in gfc_target_interpret_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84219 --- Comment #3 from Paul Thomas --- Author: pault Date: Thu Mar 1 11:06:18 2018 New Revision: 258098 URL: https://gcc.gnu.org/viewcvs?rev=258098&root=gcc&view=rev Log: 2018-03-01 Paul Thomas PR fortran/84219 * target-memory.c (gfc_interpret_derived): Assert that BT_VOID components are caf tokens. (gfc_target_interpret_expr): Treat BT_VOID expressions as integers. 2018-03-01 Paul Thomas PR fortran/84219 * gfortran.dg/coarray_47.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/coarray_47.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/target-memory.c trunk/gcc/testsuite/ChangeLog
[Bug bootstrap/64914] [UBSAN/bootstrap-ubsan] With -g3: libiberty/md5.c:336:7: runtime error: load of misaligned address for type 'const md5_uint32', which requires 4 byte alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64914 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2018-03-01 CC||marxin at gcc dot gnu.org Component|sanitizer |bootstrap Ever confirmed|0 |1
[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 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 43534 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43534&action=edit gcc8-pr84625.patch Untested fix.
[Bug bootstrap/64914] [UBSAN/bootstrap-ubsan] With -g3: libiberty/md5.c:336:7: runtime error: load of misaligned address for type 'const md5_uint32', which requires 4 byte alignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64914 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- I've got patch for that, problem is in caller of the function.
[Bug target/82005] [8 regression] early lto debug creates invalid assembly on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82005 Eric Gallager changed: What|Removed |Added Keywords||patch URL||https://gcc.gnu.org/ml/gcc- ||patches/2018-03/msg00010.ht ||ml See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=84645 --- Comment #32 from Eric Gallager --- (In reply to Richard Biener from comment #31) > (In reply to Dominique d'Humieres from comment #30) > > IMO the patch in comment 26 should be committed. > > Patch posted, waiting for approval. Link is here: https://gcc.gnu.org/ml/gcc-patches/2018-03/msg00010.html
[Bug target/82005] [8 regression] early lto debug creates invalid assembly on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82005 Eric Gallager changed: What|Removed |Added See Also|https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=84645 | --- Comment #33 from Eric Gallager --- Oops didn't notice that bug 84645 was already under "Depends on"; guess I didn't need to add it to "See Also" after all; let me remove it...
[Bug c++/84632] [8 Regression] 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 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org Target Milestone|--- |8.0 Summary|internal compiler error:|[8 Regression] internal |tree check: expected|compiler error: tree check: |record_type or union_type |expected record_type or |or qual_union_type, have|union_type or |array_type in |qual_union_type, have |reduced_constant_expression |array_type in |_p, at cp/constexpr.c:1778 |reduced_constant_expression ||_p, at cp/constexpr.c:1778 --- Comment #4 from Jakub Jelinek --- Started with r251948.
[Bug sanitizer/84629] sanitizer warnings and errors on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84629 Jakub Jelinek changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #5 from Jakub Jelinek --- Thus not a GCC bug.
[Bug middle-end/64327] ../../gcc/gcc/rtlanal.c:4881:48: runtime error: shift exponent 4294967295 is too large for 64-bit type 'long unsigned int'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64327 Martin Liška changed: What|Removed |Added Status|NEW |WAITING CC||marxin at gcc dot gnu.org --- Comment #8 from Martin Liška --- Can't reproduce on trunk any longer. Vittorie can you please re-test?
[Bug fortran/61910] undefined computation in trans-expr.c gfc_conv_cst_int_power
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61910 Martin Liška changed: What|Removed |Added Status|NEW |WAITING CC||marxin at gcc dot gnu.org --- Comment #8 from Martin Liška --- Can't reproduce on current trunk. Is it still valid?
[Bug fortran/61907] load of invalid value for 'bool' in trans-array.c trans_array_constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61907 Martin Liška changed: What|Removed |Added Status|NEW |WAITING CC||marxin at gcc dot gnu.org --- Comment #7 from Martin Liška --- Also can't reproduce on current trunk, is it still valid?
[Bug other/59545] Signed integer overflow issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59545 Martin Liška changed: What|Removed |Added Status|NEW |WAITING CC||marxin at gcc dot gnu.org --- Comment #14 from Martin Liška --- Marek and Markus can we close this. Or do you still see any of these UBSAN errors?
[Bug c++/66159] bogus warning for alias-declaration using elaborated-type-specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66159
--- Comment #2 from Jonathan Wakely ---
This keeps biting me in the Filesystem library, where I need to use an
elaborated-type-specifier to refer to struct stat, to disambiguate it from the
function int stat(const char*, struct stat*)
struct stat { };
extern "C" int stat(const char*, struct stat*);
namespace filesystem {
typedef struct ::stat t1;
using t2 = struct ::stat;
}
I could just say "struct stat" instead of using the nested-name-specifier, but
being explicit about the scope seems better.
Would fixing this need another global boolean like
processing_explicit_instantiation, so the warning can be suppressed when
processing_alias_declaration is true?
Would it be OK to make this warning depend on -Wredundant-decls so it can be
disabled with a #pragma?
[Bug other/59545] Signed integer overflow issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59545 --- Comment #15 from Marek Polacek --- I haven't run bootstrap-ubsan in a while so I don't know, but those old logs are definitely useless now. So we can close this I think.
[Bug other/59545] Signed integer overflow issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59545 Martin Liška changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #16 from Martin Liška --- Then marking as fixed.
[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426 Bug 63426 depends on bug 59545, which changed state. Bug 59545 Summary: Signed integer overflow issues https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59545 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug sanitizer/67513] ASAN: Not optimal shadow value check (unlikely condition checked in fast path)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67513 Martin Liška changed: What|Removed |Added Status|NEW |ASSIGNED CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org Target Milestone|--- |9.0 --- Comment #14 from Martin Liška --- Let me write the other approach and test it on some program.
[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 Priority|P3 |P1 --- Comment #2 from Jakub Jelinek --- Started (at least the -fcompare-debug issue) with r255506.
[Bug ipa/84641] gcc/ipa-pure-const.c:1951:22: runtime error: load of value 66, which is not a valid value for type 'bool'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84641 --- Comment #1 from Martin Liška --- Same can be seen with valgrind: $ valgrind --leak-check=yes --trace-children=yes ./xgcc -B. /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/pr71633.C -c -O3 -mmpx -O2 -std=gnu++11 -fcheck-pointer-bounds ==19734== Conditional jump or move depends on uninitialised value(s) ==19734==at 0x1637811: propagate_malloc (ipa-pure-const.c:1951) ==19734==by 0x1637811: (anonymous namespace)::pass_ipa_pure_const::execute(function*) (ipa-pure-const.c:2017) ==19734==by 0xCF27F0: execute_one_pass(opt_pass*) (passes.c:2497) ==19734==by 0xCF37F1: execute_ipa_pass_list(opt_pass*) (passes.c:2932) ==19734==by 0x99816B: ipa_passes (cgraphunit.c:2476) ==19734==by 0x99816B: symbol_table::compile() [clone .part.56] (cgraphunit.c:2558) ==19734==by 0x99A916: compile (cgraphunit.c:2720) ==19734==by 0x99A916: symbol_table::finalize_compilation_unit() (cgraphunit.c:2717) ==19734==by 0xDCF95A: compile_file() (toplev.c:480) ==19734==by 0x608A04: do_compile (toplev.c:2132) ==19734==by 0x608A04: toplev::main(int, char**) (toplev.c:2267) ==19734==by 0x60AFBA: main (main.c:39)
[Bug c++/84647] New: internal compiler error: Segmentation fault (standard_conversion())
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84647 Bug ID: 84647 Summary: internal compiler error: Segmentation fault (standard_conversion()) 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: void (*a)(auto b = c()); Output: xgcc -x c++ -S -fpermissive - :1:20: warning: there are no arguments to 'c' that depend on a template parameter, so a declaration of 'c' must be available [-fpermissive] :1:18: warning: default arguments are only permitted for function parameters [-fpermissive] :1:23: internal compiler error: Segmentation fault 0x3155789 crash_signal /home/vegard/git/gcc/gcc/toplev.c:325 0x8d2e4f standard_conversion /home/vegard/git/gcc/gcc/cp/call.c:1107 0x8fb4f0 implicit_conversion /home/vegard/git/gcc/gcc/cp/call.c:1840 0x8e9ce6 perform_implicit_conversion_flags(tree_node*, tree_node*, int, int) /home/vegard/git/gcc/gcc/cp/call.c:10561 0xb530ec check_default_argument(tree_node*, tree_node*, int) /home/vegard/git/gcc/gcc/cp/decl.c:12644 0xb5488f grokparms(tree_node*, tree_node**) /home/vegard/git/gcc/gcc/cp/decl.c:12817 0xbfca21 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*, decl_context, int, tree_node**) /home/vegard/git/gcc/gcc/cp/decl.c:11247 0xc19118 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int, tree_node*, tree_node*, tree_node**) /home/vegard/git/gcc/gcc/cp/decl.c:5002 0xfa391c cp_parser_init_declarator /home/vegard/git/gcc/gcc/cp/parser.c:19591 0xfa9757 cp_parser_simple_declaration /home/vegard/git/gcc/gcc/cp/parser.c:13063 0xfaf948 cp_parser_block_declaration /home/vegard/git/gcc/gcc/cp/parser.c:12881 0x1002c05 cp_parser_declaration /home/vegard/git/gcc/gcc/cp/parser.c:12778 0xff9bdb cp_parser_declaration_seq_opt /home/vegard/git/gcc/gcc/cp/parser.c:12654 0xffb203 cp_parser_translation_unit /home/vegard/git/gcc/gcc/cp/parser.c:4561 0xffb203 c_parse_file() /home/vegard/git/gcc/gcc/cp/parser.c:38986 0x15a6ba5 c_common_parse_file() /home/vegard/git/gcc/gcc/c-family/c-opts.c:1132 $ xgcc --version xgcc (GCC) 8.0.1 20180301 (experimental) Built from git c435a9e730c6e8f10da09d58b4fc9aaeb401b0d5 (r258097). It seems to have been introduced between 5.5.0 and 6.1.0. Test case was minimised by C-Reduce.
[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 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 43535 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43535&action=edit gcc8-pr84614.patch Untested fix.
[Bug fortran/81827] Large compile time with derived-type rrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81827 --- Comment #16 from Paul Thomas --- (In reply to Richard Biener from comment #15) > Bisected to pauls r254427, the fix for PR81447 and PR82783. > > Test adjustments suggest that we'll create even more malloc/free calls. Hi Richard, I am sorry to take so long to get back to this. The vtable copy and finalise procedures get expanded for the allocatable components to the the ultimate allocatable components. This is only an issue, of course, if the vtable is generated. This also exhibits the problem: program main implicit none type level1 real, allocatable :: var_r1(:), var_r2(:), var_r3(:), var_r4(:), var_r5(:) integer, allocatable :: var_i1(:), var_i2(:), var_i3(:), var_i4(:), var_i5(:) complex, allocatable :: var_c1(:), var_c2(:), var_c3(:), var_c4(:), var_c5(:) logical, allocatable :: and_this_makes_sixteen(:) end type level1 type level2 type(level1), allocatable :: var1(:), var2(:), var3(:), var4(:), var5(:) end type level2 type level3 type(level2), allocatable :: var1(:), var2(:), var3(:), var4(:), var5(:) end type level3 type level4 type(level3), allocatable :: var1(:), var2(:), var3(:), var4(:), var5(:) end type level4 class (level4), allocatable :: foo(:) ! TYPE (level4) does not exibit the long compile time. allocate(foo(1)) end program There are two ways to fix this: (i) Generate incomplete vtables, with the pointers to copy and finalise set to null, for module derived types. This has the disadvantage that class objects, such as the above, will still cause the compilation cascade; or (ii) Call the functions associated with each derived type vtable at each level. My preference would be for the latter and I will set to seeing how it can be done. Cheers Paul
[Bug c++/84639] gcc/c-family/c-attribs.c:1822:27: runtime error: shift exponent -1 is negative
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84639 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org
[Bug debug/84645] -flto -g0 at compile-time vs. -flto -g at link time ICEs in add_dwarf_attr, at dwarf2out.c:4353
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84645 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed.
[Bug target/82005] [8 regression] early lto debug creates invalid assembly on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82005 Bug 82005 depends on bug 84645, which changed state. Bug 84645 Summary: -flto -g0 at compile-time vs. -flto -g at link time ICEs in add_dwarf_attr, at dwarf2out.c:4353 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84645 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug debug/84645] -flto -g0 at compile-time vs. -flto -g at link time ICEs in add_dwarf_attr, at dwarf2out.c:4353
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84645 --- Comment #2 from Richard Biener --- Author: rguenth Date: Thu Mar 1 13:39:56 2018 New Revision: 258100 URL: https://gcc.gnu.org/viewcvs?rev=258100&root=gcc&view=rev Log: 2018-03-01 Richard Biener PR debug/84645 * dwarf2out.c (gen_variable_die): Properly handle late VLA type annotation with LTO when debug was disabled at compile-time. * gfortran.dg/lto/pr84645_0.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/lto/pr84645_0.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c trunk/gcc/testsuite/ChangeLog
[Bug target/82005] [8 regression] early lto debug creates invalid assembly on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82005 --- Comment #34 from Richard Biener --- (In reply to Richard Biener from comment #31) > (In reply to Dominique d'Humieres from comment #30) > > > However I have restore my testing of the gfortran test suite with -g -flto > > > and I see the following new failures: > > > > > > FAIL: gfortran.dg/namelist_14.f90 -g -flto (internal compiler error) > > > FAIL: gfortran.dg/namelist_14.f90 -g -flto (test for excess errors) > > > FAIL: gfortran.dg/namelist_69.f90 -g -flto (internal compiler error) > > > FAIL: gfortran.dg/namelist_69.f90 -g -flto (test for excess errors) > > > FAIL: gfortran.dg/namelist_70.f90 -g -flto (internal compiler error) > > > FAIL: gfortran.dg/namelist_70.f90 -g -flto (test for excess errors) > > > > This is caused by revision r251448 and "fixed" by restoring the gcc_assert > > in r251447. > > > > I also see > > > > FAIL: libgomp.fortran/taskloop3.f90 -g -flto (internal compiler error) > > > > which appeared between r251187 and r251447. > > Ok, I can reproduce those when compiling with -flto -g0 and linking with > -flto -g which is what the patch in comment 26 ends up forcing (-g0 at > compile-time). Let's split this out to a separate bug. PR84645. Fixed that. If you see similar symptoms elsewhere in the testsuite please report those. > > IMO the patch in comment 26 should be committed. > > Patch posted, waiting for approval.
[Bug c++/66159] bogus warning for alias-declaration using elaborated-type-specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66159
--- Comment #3 from Jonathan Wakely ---
Patch for stage 1:
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index 4fa546a086c..4dc4e751b28 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -17818,9 +17818,11 @@ cp_parser_elaborated_type_specifier (cp_parser*
parser,
caught elsewhere in parsing. Those that are pointless arrive
here. */
- if (cp_lexer_next_token_is (parser->lexer, CPP_SEMICOLON)
+ if (warn_redundant_decls
+ && cp_lexer_next_token_is (parser->lexer, CPP_SEMICOLON)
&& !is_friend && !processing_explicit_instantiation)
-warning (0, "declaration %qD does not declare anything", decl);
+warning (OPT_Wredundant_decls,
+"declaration %qD does not declare anything", decl);
type = TREE_TYPE (decl);
}
diff --git a/gcc/testsuite/g++.dg/warn/forward-inner.C
b/gcc/testsuite/g++.dg/warn/forward-inner.C
index 5336d4ed946..f720a6cdae3 100644
--- a/gcc/testsuite/g++.dg/warn/forward-inner.C
+++ b/gcc/testsuite/g++.dg/warn/forward-inner.C
@@ -1,5 +1,6 @@
// Check that the compiler warns about inner-style forward declarations in
// contexts where they're not actually illegal, but merely useless.
+// { dg-options "-Wredundant-decls" }
// Verify warnings for and within classes, and by extension, struct and union.
class C1;
@@ -70,7 +71,7 @@ template class TC6::TC7; // Valid explicit
instantiation, no warning
// Verify that friend declarations, also easy to confuse with forward
-// declrations, are similarly not warned about.
+// declarations, are similarly not warned about.
class C8 {
public:
class C9 { };
@@ -79,3 +80,10 @@ class C10 {
public:
friend class C8::C9; // Valid friend declaration, no warning
};
+
+#if __cplusplus >= 201103L
+// Verify that alias-declarations using an elaborated-type-specifier and
+// nested-name-specifier are not warned about (PR c++/66159).
+struct C11;
+using A1 = struct ::C11;
+#endif
diff --git a/gcc/testsuite/g++.dg/warn/pr36999.C
b/gcc/testsuite/g++.dg/warn/pr36999.C
index ce2286efcf4..6f69e192d02 100644
--- a/gcc/testsuite/g++.dg/warn/pr36999.C
+++ b/gcc/testsuite/g++.dg/warn/pr36999.C
@@ -1,5 +1,6 @@
/* PR36999: Erroneous "does not declare anything" warnings. */
/* { dg-do compile } */
+/* { dg-options "-Wredundant-decls" } */
class C1 {
public: class C2 { };
[Bug lto/84592] [openacc,openmp] lto1: ICE in input_varpool_node, at lto-cgraph.c:1424: for CSWTCH symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84592 --- Comment #6 from Tom de Vries --- Looks like a duplicate of PR71536
[Bug testsuite/80546] [7/8 Regression] FAIL: gcc.target/powerpc/bool3-p[78].c scan-assembler-not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80546
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
With somewhat older revisions when -mno-lra still existed xxlnor wouldn't
appear with that option.
Anyway, isn't the problem already in IRA?
We have:
(insn 9 16 10 2 (parallel [
(set (reg:TI 125 [ a ])
(asm_operands:TI ("# gpr reg %0") ("=r") 0 [
(reg:TI 125 [ a ])
]
[
(asm_input:TI ("0") bool3.h:74)
]
[] bool3.h:74))
(clobber (reg:SI 76 ca))
]) "bool3.h":74 -1
(expr_list:REG_UNUSED (reg:SI 76 ca)
(nil)))
(insn 10 9 17 2 (set (reg/v:TI 122 [ b ])
(not:TI (reg:TI 125 [ a ]))) "bool3.h":75 493 {*one_cmplti3_internal}
(expr_list:REG_DEAD (reg:TI 125 [ a ])
(nil)))
(insn 17 10 12 2 (set (reg:TI 126 [ b ])
(reg/v:TI 122 [ b ])) "bool3.h":76 1197 {*vsx_movti_64bit}
(expr_list:REG_DEAD (reg/v:TI 122 [ b ])
(nil)))
(insn 12 17 13 2 (parallel [
(set (reg:TI 126 [ b ])
(asm_operands:TI ("# gpr reg %0") ("=r") 0 [
(reg:TI 126 [ b ])
]
[
(asm_input:TI ("0") bool3.h:76)
]
[] bool3.h:76))
(clobber (reg:SI 76 ca))
]) "bool3.h":76 -1
(expr_list:REG_UNUSED (reg:SI 76 ca)
(nil)))
and
r126: preferred GENERAL_REGS, alternative NO_REGS, allocno GENERAL_REGS
r125: preferred GENERAL_REGS, alternative NO_REGS, allocno GENERAL_REGS
r124: preferred BASE_REGS, alternative GENERAL_REGS, allocno GENERAL_REGS
r123: preferred BASE_REGS, alternative GENERAL_REGS, allocno GENERAL_REGS
r122: preferred VSX_REGS, alternative NO_REGS, allocno VSX_REGS
r121: preferred VSX_REGS, alternative NO_REGS, allocno VSX_REGS
a0(r123,l0) costs: BASE_REGS:0,0 GENERAL_REGS:4000,4000
FLOAT_REGS:24000,24000 ALTIVEC_REGS:24000,24000 VSX_REGS:24000,24000
NON_SPECIAL_REGS:24000,24000 LINK_REGS:18000,18000 CTR_REGS:18000,18000
LINK_OR_CTR_REGS:18000,18000 SPEC_OR_GEN_REGS:18000,18000 ALL_REGS:62000,62000
MEM:12000,12000
a1(r126,l0) costs: GENERAL_REGS:8000,8000 FLOAT_REGS:48000,48000
ALTIVEC_REGS:48000,48000 VSX_REGS:48000,48000 NON_SPECIAL_REGS:54000,54000
ALL_REGS:148000,148000 MEM:35000,35000
a2(r122,l0) costs: BASE_REGS:26000,26000 GENERAL_REGS:26000,26000
FLOAT_REGS:2,2 ALTIVEC_REGS:2,2 VSX_REGS:2,2
NON_SPECIAL_REGS:38000,38000 ALL_REGS:74000,74000 MEM:23000,23000
a3(r125,l0) costs: GENERAL_REGS:18000,18000 FLOAT_REGS:48000,48000
ALTIVEC_REGS:48000,48000 VSX_REGS:48000,48000 NON_SPECIAL_REGS:64000,64000
ALL_REGS:172000,172000 MEM:41000,41000
a4(r121,l0) costs: BASE_REGS:26000,26000 GENERAL_REGS:26000,26000
FLOAT_REGS:8000,8000 ALTIVEC_REGS:8000,8000 VSX_REGS:8000,8000
NON_SPECIAL_REGS:26000,26000 ALL_REGS:46000,46000 MEM:11000,11000
a5(r124,l0) costs: BASE_REGS:0,0 GENERAL_REGS:2000,2000
FLOAT_REGS:16000,16000 ALTIVEC_REGS:16000,16000 VSX_REGS:16000,16000
NON_SPECIAL_REGS:16000,16000 LINK_REGS:12000,12000 CTR_REGS:12000,12000
LINK_OR_CTR_REGS:12000,12000 SPEC_OR_GEN_REGS:12000,12000 ALL_REGS:48000,48000
MEM:8000,8000
I wonder how it could come up with so huge costs of BASE_REGS/GENERAL_REGS for
r122.
It is used just in:
(define_insn ("*one_cmplti3_internal")
[
(set (match_operand:TI 0 ("vlogical_operand") ("=&r,r,r,wt,v"))
(not:TI (match_operand:TI 1 ("vlogical_operand") ("r,0,0,wt,v"
] ("") ("*{
if (TARGET_VSX && vsx_register_operand (operands[0], TImode))
return "xxlnor %x0,%x1,%x1";
if (TARGET_ALTIVEC && altivec_register_operand (operands[0], TImode))
return "vnor %0,%1,%1";
return "#";
}")
and
(define_insn ("*vsx_movti_64bit")
[
(set (match_operand:TI 0 ("nonimmediate_operand") ("=ZwO, wt,
wt, r, we,?wQ,
?&r, ??r, ??Y, ??r, wo,v,
?wt,*r,v, ??r, wZ,v"))
(match_operand:TI 1 ("input_operand") ("wt, ZwO, wt,
we,r, r,
wQ,Y, r, r, wE,jwM,
?jwM, jwM, W, W, v, wZ")))
] ("TARGET_POWERPC64 && VECTOR_MEM_VSX_P (TImode)
&& (register_operand (operands[0], TImode)
|| register_operand (operands[1], TImode))") ("*{
return rs6000_output_move_128bit (operands);
}")
Is that because of the ??r/??r in the *vsx_movti_64bit instruction?
[Bug testsuite/80546] [7/8 Regression] FAIL: gcc.target/powerpc/bool3-p[78].c scan-assembler-not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80546 --- Comment #4 from Jakub Jelinek --- Created attachment 43536 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=43536&action=edit gcc8-pr80546.patch The following completely untested patch fixes this. Probably other mov patterns need inspection too. Or shall IRA handle the noop moves itself?
[Bug c++/82565] [7/8 Regression] Concept and lambda return type deduction cause compilation to crash with "mmap: Cannot allocate memory"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82565 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Started to ICE with r249323, before it was accepted.
[Bug c++/84647] [6/7/8 Regression] ICE: segfault with NULL "from" in standard_conversion()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84647 David Malcolm changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-03-01 CC||dmalcolm at gcc dot gnu.org Target Milestone|--- |6.5 Summary|internal compiler error:|[6/7/8 Regression] ICE: |Segmentation fault |segfault with NULL "from" |(standard_conversion()) |in standard_conversion() Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Confirmed. Affects trunk, 6 and 7. Started with r214396. Segfault reading through NULL "from" here: #0 0x00801c7b in standard_conversion (to=, from=, expr=, c_cast_p=false, flags=5, complain=2) at ../../src/gcc/cp/call.c:1107 1107 if (TREE_CODE (from) == REFERENCE_TYPE)
[Bug tree-optimization/84648] New: Missed optimization : loop not removed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84648
Bug ID: 84648
Summary: Missed optimization : loop not removed.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: cassio.neri at gmail dot com
Target Milestone: ---
The loop below is not eliminated:
int main() {
for (unsigned i = 0; i < (1u << 31); ++i) {
}
return 0;
}
Compiled with -O3:
main:
xor eax, eax
.L2:
add eax, 1
jns .L2
xor eax, eax
ret
The loop is removed for other bounds, e.g. (1u << 31) + 1 or (1u << 31) - 1, or
when < is replaced with <=.
Allow me to make a guess of the underlying problem: The optimization that uses
jns to detect when i reaches (10...0)_2 ends up by blocking the other
optimization that eliminates the loop altoghether.
Same issue when using unsigned long long and (1ull << 63).
FWIW: clang has the same issue (in C but not in C++).
[Bug c++/84642] [6/7/8 Regression] ICE: segfault reading through NULL current_template_parms in synthesize_implicit_template_parm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84642 David Malcolm changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2018-03-01 CC||dmalcolm at gcc dot gnu.org Target Milestone|--- |6.5 Summary|internal compiler error:|[6/7/8 Regression] ICE: |Segmentation fault |segfault reading through |(tree_check()/synthesize_im |NULL current_template_parms |plicit_template_parm()) |in ||synthesize_implicit_templat ||e_parm Ever confirmed|0 |1 --- Comment #1 from David Malcolm --- Confirmed on trunk, 7, and 6 (and 5, with -std=c++14). Started with r208426. Segfault reading through NULL for "current_template_parms": #1 0x00a19850 in synthesize_implicit_template_parm (parser=0x77ffbbd0, constr=) at ../../src/gcc/cp/parser.c:39078 39078 tree& new_parms = INNERMOST_TEMPLATE_PARMS (current_template_parms); (gdb) p scope_chain->template_parms $8 =
[Bug c++/84642] [6/7/8 Regression] ICE: segfault reading through NULL current_template_parms in synthesize_implicit_template_parm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84642 --- Comment #2 from David Malcolm --- (In reply to Vegard Nossum from comment #0) > Seems potentially related to bug #84610? Similar backtraces - and they both started with same commit - though this one is a read-through-NULL, whereas bug #84610 is an assertion failure.
[Bug sanitizer/82484] [8 Regression] ICE in verify_gimple failed w/ -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82484 --- Comment #5 from Martin Liška --- Author: marxin Date: Thu Mar 1 14:54:10 2018 New Revision: 258101 URL: https://gcc.gnu.org/viewcvs?rev=258101&root=gcc&view=rev Log: Do not handled volatile arguments (PR sanitizer/82484). 2018-03-01 Martin Liska PR sanitizer/82484 * sanopt.c (sanitize_rewrite_addressable_params): Do not handle volatile arguments. 2018-03-01 Martin Liska PR sanitizer/82484 * gcc.dg/asan/pr82484.c: New test. Added: trunk/gcc/testsuite/gcc.dg/asan/pr82484.c Modified: trunk/gcc/ChangeLog trunk/gcc/sanopt.c trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/82484] [8 Regression] ICE in verify_gimple failed w/ -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82484 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Martin Liška --- Fixed.
[Bug testsuite/80546] [7/8 Regression] FAIL: gcc.target/powerpc/bool3-p[78].c scan-assembler-not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80546 Jakub Jelinek changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Unfortunately it breaks bootstrap on powerpc64le-linux: ../../../libgcc/libgcc2.c: In function ‘__mulvti3’: ../../../libgcc/libgcc2.c:396:1: internal compiler error: Max. number of generated reload insns per insn is achieved (90) Vlad, any thoughts on this? Does IRA have any code which would estimate if two pseudos where one dies in a simple move insn and another one defined in there can be sharing the same register? Should IRA itself estimate in those cases that a noop move would be for free (0 cost)? Or would ^^r instead of ??r work here? Or something else?
[Bug c++/84630] [6/7/8 Regression] ICE: TYPE_NAME() used on error_mark_node in tsubst_lambda_expr, at cp/pt.c:17141
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84630
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2018-03-01
CC||dmalcolm at gcc dot gnu.org
Target Milestone|--- |6.5
Summary|internal compiler error:|[6/7/8 Regression] ICE:
|tree check: expected class |TYPE_NAME() used on
|'type', have 'exceptional' |error_mark_node in
|(error_mark) in |tsubst_lambda_expr, at
|tsubst_lambda_expr, at |cp/pt.c:17141
|cp/pt.c:17141 |
Ever confirmed|0 |1
--- Comment #2 from David Malcolm ---
Confirmed with trunk, 7, 6 (and 5). Doesn't crash with 4.8.3.
ICE began on this code (with -std=c++11) between r198776 (no ICE) and r198781,
with:
"unexpected expression ‘’ of kind template_parm_index")
The ICE message changed to
"tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in
tsubst_lambda_expr, at cp/pt.c:16972"
sometime between r257193 and r257199 (probably in r257199).
Fails on trunk here:
#3 tsubst_lambda_expr (t=, args=, complain=1,
in_decl=) at
../../src/gcc/cp/pt.c:17141
17141 determine_visibility (TYPE_NAME (type));
where "type" is "error_mark_node" and thus not a type.
On unchecked builds (e.g. 7), this becomes:
#1 0x007b8eea in cxx_eval_constant_expression(constexpr_ctx const*,
tree_node*, bool, bool*, bool*, tree_node**) ()
at ../../src/gcc/cp/constexpr.c:4654
4654internal_error ("unexpected expression %qE of kind %s", t,
4655get_tree_code_name (TREE_CODE (t)));
[Bug c/84649] New: -Wstringop-truncation shouldn't warn on strncat() when 2nd argument is a char array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84649
Bug ID: 84649
Summary: -Wstringop-truncation shouldn't warn on strncat() when
2nd argument is a char array
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sirl at gcc dot gnu.org
Target Milestone: ---
With gcc-8 trunk@258093 for this example
char *append_leading_digits(char *cp, int i)
{
char buf[16];
__builtin_sprintf(buf, "%2i ", i);
__builtin_strncat(cp, buf, 4);
return cp;
}
gcc warns like that:
gcc-trunk -O2 -c test-strncat.c -Wstringop-truncation
test-strncat.c: In function 'append_leading_digits':
test-strncat.c:8:2: warning: '__builtin_strncat' output may be truncated
copying 3 bytes from a string of length 15 [-Wstringop-truncation]
__builtin_strncat(cp, buf, 4);
^
I believe this warning is unjustified as buf[] may contain strings of varying
lengths and the whole purpose of strncat() is to truncate the source string
after all.
Actually maybe the warning should only trigger for strncat() when BOTH the 2nd
and 3rd argument are constant (like in the example in the manual)?
[Bug tree-optimization/84650] New: [8 Regression] [graphite] ICE: Segmentation fault (in create_new_iv)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84650
Bug ID: 84650
Summary: [8 Regression] [graphite] ICE: Segmentation fault (in
create_new_iv)
Product: gcc
Version: 8.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-8.0.0-alpha20180225 snapshot (r257975) ICEs when compiling the following
snippet w/ -O2 (-O3, -Ofast, -Os) -fgraphite-identity -fno-tree-copy-prop
--param lim-expensive=3:
unsigned int dj;
void
np (void)
{
const unsigned int uw = 2;
unsigned int eu;
for (eu = 0; eu < uw; ++eu)
{
for (dj = 0; dj < uw; ++dj)
{
}
eu -= !!(dj - uw - 1);
}
}
% gcc-8.0.0-alpha20180225 -O2 -fgraphite-identity -fno-tree-copy-prop --param
lim-expensive=3 -c bl9jevma.c
during GIMPLE pass: ivopts
bl9jevma.c: In function 'np':
bl9jevma.c:4:1: internal compiler error: Segmentation fault
np (void)
^~
0xca1fcf crash_signal
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180225/work/gcc-8-20180225/gcc/toplev.c:325
0xdf7f25 create_new_iv
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180225/work/gcc-8-20180225/gcc/tree-ssa-loop-ivopts.c:6793
0xdf7f25 create_new_ivs
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180225/work/gcc-8-20180225/gcc/tree-ssa-loop-ivopts.c:6819
0xdf7f25 tree_ssa_iv_optimize_loop
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180225/work/gcc-8-20180225/gcc/tree-ssa-loop-ivopts.c:7582
0xdf7f25 tree_ssa_iv_optimize()
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180225/work/gcc-8-20180225/gcc/tree-ssa-loop-ivopts.c:7618
0xe153b0 execute
/var/tmp/portage/sys-devel/gcc-8.0.0_alpha20180225/work/gcc-8-20180225/gcc/tree-ssa-loop.c:500
[Bug testsuite/80546] [7/8 Regression] FAIL: gcc.target/powerpc/bool3-p[78].c scan-assembler-not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80546 --- Comment #6 from Jakub Jelinek --- (In reply to Jakub Jelinek from comment #5) > Unfortunately it breaks bootstrap on powerpc64le-linux: > ../../../libgcc/libgcc2.c: In function ‘__mulvti3’: > ../../../libgcc/libgcc2.c:396:1: internal compiler error: Max. number of > generated reload insns per insn is achieved (90) > > Vlad, any thoughts on this? > Does IRA have any code which would estimate if two pseudos where one dies in > a simple move insn and another one defined in there can be sharing the same > register? Should IRA itself estimate in those cases that a noop move would > be for free (0 cost)? > Or would ^^r instead of ??r work here? Or something else? Perhaps ??r <- r and #r <- 0 alternatives? Though I guess it would work only if IRA actually can handle 0 in simple moves reasonably, by trying to guess if it is likely the two pseudos can be allocated into the same register (and then using corresponding alternative cost), and if it is unlikely using some other alternative instead.
[Bug tree-optimization/84005] [8 regression] gcc.dg/vect/bb-slp-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84005 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #5 from Eric Botcazou --- So either we bump the alignment of the arrays or we selectively XFAIL?
[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 Richard Biener changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* Priority|P3 |P2
[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 Richard Biener changed: What|Removed |Added Target Milestone|--- |8.0
[Bug c++/84630] [6/7/8 Regression] ICE: TYPE_NAME() used on error_mark_node in tsubst_lambda_expr, at cp/pt.c:17141
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84630 Richard Biener changed: What|Removed |Added Priority|P3 |P4
[Bug c++/71569] [6/7/8 regression] Crash: External definition of template member from template struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71569
--- Comment #6 from Oliver Tale-Yazdi ---
It seems to be only dependent on the template specialization of the member.
–––
template
struct A {
template
static U u;
};
template
template
U A::u = nullptr;
–––
template
struct A {
template
static U u;
};
template
template
U A::u = nullptr;
–––
The first one is accepted, the second one ICE's. Both is valid C++14.
I also need to point out that >= 5.1 accepts weird (invalid?) Code, eg:
––
#include
template
struct A {
template
static U u;
};
template
template
U A::u = nullptr;
int main()
{
std::cerr << "'" << typeid(decltype(A::u)).name() << "'" << std::endl;
}
––
This dosent print _Anything_.
I dont even have to include , which is needed, if I specialize u with
A::u in the second last line.
typeid seems to not be called.
[Bug c++/84642] [6/7/8 Regression] ICE: segfault reading through NULL current_template_parms in synthesize_implicit_template_parm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84642 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug c++/84647] [6/7/8 Regression] ICE: segfault with NULL "from" in standard_conversion()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84647 Richard Biener changed: What|Removed |Added Priority|P3 |P2
[Bug tree-optimization/84646] Missed optimisation for hoisting conditions outside nested loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84646 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2018-03-01 CC||law at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Component|c |tree-optimization Version|unknown |8.0.1 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- I think this boils down to jump threading -- FSM threading should be able to notice that after setting running to false we should can exit the loop nest. Likely that doesn't work for the nest but just for the inner loop for some reason.
[Bug sanitizer/70875] ICE in get_ubsan_type_info_for_type with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70875 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #7 from Eric Botcazou --- The exit code of the testcase looks random to me, doesn't it?
[Bug tree-optimization/84648] Missed optimization : loop not removed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84648
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2018-03-01
Version|unknown |8.0.1
Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot
gnu.org
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Confirmed. The issue seems to be that we prematurely optimize the compare to
(signed int) i < 0 and number of iteration analysis fails to handle
that.
The FE emits:
unsigned int i = 0;
goto ;
:;
++i;
:;
if ((signed int) i >= 0) goto ; else goto ;
:;
(set_scalar_evolution
instantiated_below = 2
(scalar = i.0_1)
(scalar_evolution = (signed int) {0, +, 1}_1))
)
(analyze_scalar_evolution
(loop_nb = 1)
(scalar = 0)
(get_scalar_evolution
(scalar = 0)
(scalar_evolution = 0))
)
(set_nb_iterations_in_loop = scev_not_known))
we need to teach niter analysis this kind of trick.
Let me have a closer look.
[Bug sanitizer/70875] ICE in get_ubsan_type_info_for_type with -fsanitize=undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70875 --- Comment #8 from Jakub Jelinek --- No, why do you think so? Something miscompiled on some target? If so, which?
