[Bug fortran/79886] New: [5/6/7 Regression] ICE in pp_format, at pretty-print.c:681
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79886 Bug ID: 79886 Summary: [5/6/7 Regression] ICE in pp_format, at pretty-print.c:681 Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: manu at gcc dot gnu.org Target Milestone: --- Starting from r217383 we ICE: $ gfortran /home/marxin/Programming/gcc/gcc/testsuite/gfortran.fortran-torture/compile/pr26806.f90 -Wpadded f951: Warning: padding struct size to alignment boundary [-Wpadded] f951: Warning: padding struct size to alignment boundary [-Wpadded] ‘ in pp_format, at pretty-print.c:681 0x1478169 pp_format(pretty_printer*, text_info*) ../../gcc/pretty-print.c:681 0x146a9f8 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) ../../gcc/diagnostic.c:961 0x146ad53 diagnostic_impl ../../gcc/diagnostic.c:1084 0x146b0cc warning(int, char const*, ...) ../../gcc/diagnostic.c:1172 0xc5a315 place_field(record_layout_info_s*, tree_node*) ../../gcc/stor-layout.c:1215 0xc5bafa layout_type(tree_node*) ../../gcc/stor-layout.c:2375 0x7d4a66 gfc_finish_type(tree_node*) ../../gcc/fortran/trans-types.c:2251 0x7acb43 gfc_build_st_parameter ../../gcc/fortran/trans-io.c:222 0x7acb43 gfc_build_io_library_fndecls() ../../gcc/fortran/trans-io.c:318 0x765c17 gfc_build_builtin_function_decls() ../../gcc/fortran/trans-decl.c:3771 0x73b71a gfc_create_decls ../../gcc/fortran/f95-lang.c:189 0x73b71a gfc_be_parse_file ../../gcc/fortran/f95-lang.c:203
[Bug fortran/79886] [5/6/7 Regression] ICE in pp_format, at pretty-print.c:681
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79886 --- Comment #1 from Manuel López-Ibáñez --- This is probably a warning from the middle end with a printf %-code not supported by the Fortran FE's pretty printer. The solution is to either add support for it in the FE or switch to the middle end pp when entering the middle end. There are several bugs like this one. Another solution is to either not call into the middle end at arbitrary points during parsing only during gimplification (not sure if this is the case here) or move the warning to the FE (middle end warnings should be avoided if possible). On 6 Mar 2017 8:04 a.m., "marxin at gcc dot gnu.org" < gcc-bugzi...@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79886 > > Bug ID: 79886 >Summary: [5/6/7 Regression] ICE in pp_format, at > pretty-print.c:681 >Product: gcc >Version: 7.0 > Status: UNCONFIRMED > Keywords: ice-on-valid-code > Severity: normal > Priority: P3 > Component: fortran > Assignee: unassigned at gcc dot gnu.org > Reporter: marxin at gcc dot gnu.org > CC: manu at gcc dot gnu.org > Target Milestone: --- > > Starting from r217383 we ICE: > > $ gfortran > /home/marxin/Programming/gcc/gcc/testsuite/gfortran. > fortran-torture/compile/pr26806.f90 > -Wpadded > f951: Warning: padding struct size to alignment boundary [-Wpadded] > f951: Warning: padding struct size to alignment boundary [-Wpadded] > ‘ > in pp_format, at pretty-print.c:681 > 0x1478169 pp_format(pretty_printer*, text_info*) > ../../gcc/pretty-print.c:681 > 0x146a9f8 diagnostic_report_diagnostic(diagnostic_context*, > diagnostic_info*) > ../../gcc/diagnostic.c:961 > 0x146ad53 diagnostic_impl > ../../gcc/diagnostic.c:1084 > 0x146b0cc warning(int, char const*, ...) > ../../gcc/diagnostic.c:1172 > 0xc5a315 place_field(record_layout_info_s*, tree_node*) > ../../gcc/stor-layout.c:1215 > 0xc5bafa layout_type(tree_node*) > ../../gcc/stor-layout.c:2375 > 0x7d4a66 gfc_finish_type(tree_node*) > ../../gcc/fortran/trans-types.c:2251 > 0x7acb43 gfc_build_st_parameter > ../../gcc/fortran/trans-io.c:222 > 0x7acb43 gfc_build_io_library_fndecls() > ../../gcc/fortran/trans-io.c:318 > 0x765c17 gfc_build_builtin_function_decls() > ../../gcc/fortran/trans-decl.c:3771 > 0x73b71a gfc_create_decls > ../../gcc/fortran/f95-lang.c:189 > 0x73b71a gfc_be_parse_file > ../../gcc/fortran/f95-lang.c:203 > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug inline-asm/79880] Gcc refuses to encode vpgatherdd instruction (x86-64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79880 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Resolution|MOVED |INVALID --- Comment #2 from Jakub Jelinek --- Note this isn't valid Intel syntax, for memory you need in this particular case DWORD PTR [r13 + xmm3].
[Bug inline-asm/79880] Gcc refuses to encode vpgatherdd instruction (x86-64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79880 --- Comment #3 from Jakub Jelinek --- Perhaps something to report to llvm that they accept invalid, that is a bug. Also, why do you use Intel syntax when you don't know how should it be used? In AT&T syntax you wouldn't need to specify this extra stuff, just vpgatherdd %xmm4, (%r13 + %xmm3), %xmm4. Also note that for inline asm you don't specify clobbers etc. (but that might be just from simplification of the testcase).
[Bug tree-optimization/79887] New: [7 Regression] ICE in set_uid_loop_bbs, at tree-vectorizer.c:482
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79887 Bug ID: 79887 Summary: [7 Regression] ICE in set_uid_loop_bbs, at tree-vectorizer.c:482 Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Created attachment 40886 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40886&action=edit test-case Starting from r242759 we ICE on of LLVM's test-case: $ g++ copy.pass.cpp --param vect-epilogues-nomask=1 -I/home/marxin/BIG/Programming/llvm-project/libcxx/test/support/ -O3 -mavx512f copy.pass.cpp: In function ‘C make(int, int) [with C = std::deque >]’: copy.pass.cpp:26:1: internal compiler error: in set_uid_loop_bbs, at tree-vectorizer.c:482 make(int size, int start = 0 ) ^~~~ 0x1071196 set_uid_loop_bbs ../../gcc/tree-vectorizer.c:481 0x1071196 vectorize_loops() ../../gcc/tree-vectorizer.c:681 with -mtune=generic -march=x86-64.
[Bug tree-optimization/71437] [7 regression] Performance regression after r235817
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71437 --- Comment #16 from rguenther at suse dot de --- On Fri, 3 Mar 2017, law at redhat dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71437 > > Jeffrey A. Law changed: > >What|Removed |Added > > Status|NEW |ASSIGNED >Assignee|unassigned at gcc dot gnu.org |law at redhat dot com > > --- Comment #15 from Jeffrey A. Law --- > So what looks real promising here. > > 1. Pull the "handle_dominating_asserts" bits out of tree-ssa-threadedge and > into tree-vrp.c. They really should have been there all along. > > 2. Improve DOM's handling of BIT_AND_EXPR/BIT_IOR_EXPR to avoid a couple minor > regressions due to #1. > > 3. Push some common code from tree-vrp.c/tree-ssa-dom.c into > tree-ssa-threadedge.c. > > 4. Change the random walk order for threading in tree-vrp.c to a domwalk I've experimented (not very thoroughly though) with doing the threading during substitute_and_fold via the vrp_fold_stmt callback which is now invoked from a domwalk. > 5. Record data from ASSERT_EXPRs during threading domwalk > > 6. Query the expression hash table in simplify_stmt_for_jump_threading That said, eventually organizing the non-backward threading as a domwalk that uses callbacks to record data / simplify stmts so that it can be used from VRP but also maybe from FRE or other passes that have a useful lattice would be nice. Not sure if all this is appropriate for GCC 7 though.
[Bug fortran/79888] New: ICE in gfc_warning with -Warray-temporaries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79888 Bug ID: 79888 Summary: ICE in gfc_warning with -Warray-temporaries Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 40887 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40887&action=edit test-case All releases I have (4.5.0+) ICE here: $ gfortran where_operator_assign_1.f90 -c -Warray-temporaries where_operator_assign_1.f90:102:15: ans%vect=(/index,-index/) 1 Warning: Creating array temporary at (1) [-Warray-temporaries] where_operator_assign_1.f90:81:0: WHERE(la((/1_I4,2_I4/),i)) Segmentation fault 0xc66dcf crash_signal ../../gcc/toplev.c:337 0x69e6f5 gfc_format_decoder ../../gcc/fortran/error.c:935 0x1477eff pp_format(pretty_printer*, text_info*) ../../gcc/pretty-print.c:679 0x146b2d8 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) ../../gcc/diagnostic.c:961 0x69e4af gfc_warning ../../gcc/fortran/error.c:792 0x69f136 gfc_warning(int, char const*, ...) ../../gcc/fortran/error.c:823 0x746d2f gfc_trans_create_temp_array(stmtblock_t*, stmtblock_t*, gfc_ss*, tree_node*, tree_node*, bool, bool, bool, locus*) ../../gcc/fortran/trans-array.c:1044 0x75784d trans_array_constructor ../../gcc/fortran/trans-array.c:2382 0x75784d gfc_add_loop_ss_code ../../gcc/fortran/trans-array.c:2664 0x758135 gfc_conv_loop_setup(gfc_loopinfo*, locus*) ../../gcc/fortran/trans-array.c:4915 0x7c5709 gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool) ../../gcc/fortran/trans-stmt.c:455 0x7c6410 gfc_trans_where_assign ../../gcc/fortran/trans-stmt.c:4785 0x7c6410 gfc_trans_where_2 ../../gcc/fortran/trans-stmt.c:5175 0x7cc5b5 gfc_trans_where(gfc_code*) ../../gcc/fortran/trans-stmt.c:5427 0x73ea57 trans_code ../../gcc/fortran/trans.c:1961 0x7cb692 gfc_trans_simple_do ../../gcc/fortran/trans-stmt.c:1924 0x7cb692 gfc_trans_do(gfc_code*, tree_node*) ../../gcc/fortran/trans-stmt.c:2057 0x73eaba trans_code ../../gcc/fortran/trans.c:1917 0x76fce8 gfc_generate_function_code(gfc_namespace*) ../../gcc/fortran/trans-decl.c:6306 0x6f7890 translate_all_program_units ../../gcc/fortran/parse.c:6070
[Bug tree-optimization/79887] [7 Regression] ICE in set_uid_loop_bbs, at tree-vectorizer.c:482
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79887 --- Comment #1 from Martin Liška --- A simpler test-case from our test-suite: $ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/vect/no-trapping-math-1.c -O3 --param vect-epilogues-nomask=1 -mavx512ifma /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/vect/no-trapping-math-1.c: In function ‘foo’: /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/vect/no-trapping-math-1.c:5:1: internal compiler error: in set_uid_loop_bbs, at tree-vectorizer.c:482 foo (float a[32], float b[2][32]) ^~~ 0xe83956 set_uid_loop_bbs ../../gcc/tree-vectorizer.c:481 0xe83956 vectorize_loops() ../../gcc/tree-vectorizer.c:681
[Bug rtl-optimization/79728] [7 Regression] ICE in setup_pressure_classes, at ira.c:912
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79728 Xi Ruoyao changed: What|Removed |Added CC||ryxi at stu dot xidian.edu.cn --- Comment #3 from Xi Ruoyao --- I think this patch will fix it. https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00233.html
[Bug rtl-optimization/79571] [5/6/7 Regression] ICE in Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79571
--- Comment #10 from Jakub Jelinek ---
(In reply to Bernd Schmidt from comment #9)
> Maybe we just need to declare this address to be invalid for TImode. The
> following seems to cure the testcase; untested otherwise.
>
> Index: i386.c
> ===
> --- i386.c(revision 245685)
> +++ i386.c(working copy)
> @@ -15877,7 +15877,7 @@ ix86_validate_address_register (rtx op)
> be recognized. */
>
> static bool
> -ix86_legitimate_address_p (machine_mode, rtx addr, bool strict)
> +ix86_legitimate_address_p (machine_mode mem_mode, rtx addr, bool strict)
> {
>struct ix86_address parts;
>rtx base, index, disp;
> @@ -15899,7 +15899,8 @@ ix86_legitimate_address_p (machine_mode,
> {
>rtx reg = ix86_validate_address_register (base);
>
> - if (reg == NULL_RTX)
> + if (reg == NULL_RTX
> + || (GET_MODE (reg) != Pmode && mem_mode == TImode))
> return false;
>
>if ((strict && ! REG_OK_FOR_BASE_STRICT_P (reg))
Wouldn't it penalize other code? E.g. if you have a TImode MEM and store from
something in XMM register, then it doesn't have to be offsetable and can use
even zero_extend in the address.
[Bug target/79889] New: ICE in aarch64_process_target_attr, at config/aarch64/aarch64.c:9537
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79889
Bug ID: 79889
Summary: ICE in aarch64_process_target_attr, at
config/aarch64/aarch64.c:9537
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Following causes ICE:
$ aarch64-linux-gnu-g++
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/mv8.C
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/mv8.C:5:15: internal
compiler error: in aarch64_process_target_attr, at
config/aarch64/aarch64.c:9537
void foo (void) // { dg-error "not a string" }
^
0xd70c26 aarch64_process_target_attr(tree_node*, char const*)
.././../gcc/config/aarch64/aarch64.c:9537
0xd70ba0 aarch64_process_target_attr(tree_node*, char const*)
.././../gcc/config/aarch64/aarch64.c:9528
0xd70cad aarch64_option_valid_attribute_p
.././../gcc/config/aarch64/aarch64.c:9632
0x77925e handle_target_attribute
.././../gcc/c-family/c-attribs.c:3028
0x725ca4 decl_attributes(tree_node**, tree_node*, int)
.././../gcc/attribs.c:548
0x652fec cplus_decl_attributes(tree_node**, tree_node*, int)
.././../gcc/cp/decl2.c:1436
0x5b824e grokfndecl
.././../gcc/cp/decl.c:8859
0x6068ee grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
.././../gcc/cp/decl.c:12225
0x608a26 start_function(cp_decl_specifier_seq*, cp_declarator const*,
tree_node*)
.././../gcc/cp/decl.c:15137
0x68ceb4 cp_parser_function_definition_from_specifiers_and_declarator
.././../gcc/cp/parser.c:26129
0x68ceb4 cp_parser_init_declarator
.././../gcc/cp/parser.c:19141
0x68da4f cp_parser_simple_declaration
.././../gcc/cp/parser.c:12773
0x68e66a cp_parser_block_declaration
.././../gcc/cp/parser.c:12599
0x692c1e cp_parser_declaration
.././../gcc/cp/parser.c:12496
0x693006 cp_parser_declaration_seq_opt
.././../gcc/cp/parser.c:12372
0x693310 cp_parser_translation_unit
.././../gcc/cp/parser.c:4366
0x693310 c_parse_file()
.././../gcc/cp/parser.c:38427
0x762c32 c_common_parse_file()
.././../gcc/c-family/c-opts.c:1107
It's invalid test-case and we should produce error message similar to what's
done in i386. I'll prepare patch for that.
[Bug middle-end/79835] load to a variable outside the scope of a function is optimized out
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79835 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Richard Biener --- As Andrew says.
[Bug target/79890] New: ICE in s390_initial_elimination_offset, at config/s390/s390.c:10430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79890 Bug ID: 79890 Summary: ICE in s390_initial_elimination_offset, at config/s390/s390.c:10430 Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Target: s390x-linux-gnu Following causes an ICE: $ s390x-linux-gnu-gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/mips/call-saved-7.c -march=zEC12 /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/mips/call-saved-7.c: In function ‘foo’: /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/mips/call-saved-7.c:11:1: internal compiler error: in s390_initial_elimination_offset, at config/s390/s390.c:10430 } ^ 0xe9ceb4 s390_initial_elimination_offset(int, int) .././../gcc/config/s390/s390.c:10430 0xad8cdd set_initial_elim_offsets .././../gcc/reload1.c:3841 0xae4ba9 calculate_elim_costs_all_insns() .././../gcc/reload1.c:1562 0x9a7f5d ira_costs() .././../gcc/ira-costs.c:2258 0x9a19b8 ira_build() .././../gcc/ira-build.c:3420 0x9985de ira .././../gcc/ira.c:5287 0x9985de execute .././../gcc/ira.c:5592
[Bug gcov-profile/79891] New: Wrong count of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79891
Bug ID: 79891
Summary: Wrong count of
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: manfred.melzig at web dot de
Target Milestone: ---
Following situation has been extracted form real code:
#include /* for exit() */
unsigned int UuT(void)
{
unsigned int true_var = 1;
unsigned int false_var = 0;
unsigned int ReturnStatus_t = 0;
if (false_var) {
ReturnStatus_t = 1;
}
else{
if (true_var) {
if (true_var) {
ReturnStatus_t = 0;
}
else {
if (true_var) {
ReturnStatus_t = 0;
}
else {
**/* Following line falsely marked as covered
when parameter "--rc lcov_branch_coverage=1" is set */**
ReturnStatus_t = 0;
}
}
}
else {
ReturnStatus_t = 0;
}
}
return (ReturnStatus_t);
}
int main(int argc, char** argv) {
UuT();
return 0;
}
Invoking gcov -a Test.c produce a wrong count of line coverage:
[...]
-: 28:else {
-: 29:/* Following line
falsely marked as covered when parameter "--rc lcov_branch_coverage=1" is set
*/
1: 30:ReturnStatus_t = 0;
$: 30-block 0
1: 30-block 1
-: 31:}
-: 32:}
[...]
without parameter -a it looks fine:
[...]
-: 28:else {
-: 29:/* Following line
falsely marked as covered when parameter "--rc lcov_branch_coverage=1" is set
*/
#: 30:ReturnStatus_t = 0;
-: 31:}
-: 32:}
[...]
Used version (in cygwin):
gcc 6.3.0
gcov 6.3.0
The invoked script:
#!/bin/bash
[ "$COMSPEC" ] && set -o igncr; # Ignore CR if on Windows system
gcc -O0 -g3 -ftest-coverage -fprofile-arcs -Wall -c -fmessage-length=0 -MMD -MP
-MF"Test.d" -MT"Test.o" -o "Test.o" "Test.c"
gcc -ftest-coverage -fprofile-arcs -Wall -Wextra -o "Test.exe" ./Test.o
./Test.exe
gcov -a Test.c
For me it looks like a bug and I hope the effect is reproducible.
Best regards
MMelzig
[Bug target/79892] New: ICE in processing of target attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79892 Bug ID: 79892 Summary: ICE in processing of target attribute Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Target: s390x-linux-gnu That's probably very similar to PR79889: $ s390x-linux-gnu-gcc -c -I/home/marxin/BIG/Programming/llvm-project/libcxx/test/support/ -Wno-overflow -O3 /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/mvc9.c -fno-inline-functions-called-once --param max-rtl-if-conversion-insns=0 -Wformat-security -Wclobbered -ffloat-store --param max-inline-insns-recursive=1236020584 -Wno-line-truncation -fno-split-wide-types -Wno-override-init-side-effects -fsingle-precision-constant --param tracer-dynamic-coverage=41 --param l1-cache-size=0 -fno-asynchronous-unwind-tables -fno-inline-atomics -Wunused-but-set-parameter -Wc++11-compat -o/dev/null
[Bug target/79893] New: ICE in s390_adjust_builtin_arglist in gcc/config/s390/s390-c.c:679
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79893 Bug ID: 79893 Summary: ICE in s390_adjust_builtin_arglist in gcc/config/s390/s390-c.c:679 Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Created attachment 40888 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40888&action=edit test-case Following test-case from LLVM ICEs: $ s390x-linux-gnu-gcc builtins-systemz-zvector-error.c ... /home/marxin/BIG/Programming/llvm-project/clang/test/CodeGen/builtins-systemz-zvector-error.c:235:3: internal compiler error: in tree_to_uhwi, at tree.c:7344 0xe07242 tree_to_uhwi(tree_node const*) .././../gcc/tree.c:7344 0x6d009e s390_adjust_builtin_arglist .././../gcc/config/s390/s390-c.c:679 0x6d009e s390_resolve_overloaded_builtin(unsigned int, tree_node*, void*) .././../gcc/config/s390/s390-c.c:987 0x6003c5 c_build_function_call_vec(unsigned int, vec, tree_node*, vec*, vec*) .././../gcc/c/c-typeck.c:3175 0x628029 c_parser_postfix_expression_after_primary .././../gcc/c/c-parser.c:8425 0x615f90 c_parser_postfix_expression .././../gcc/c/c-parser.c:8238 0x6218aa c_parser_unary_expression .././../gcc/c/c-parser.c:7053 0x6226b7 c_parser_cast_expression .././../gcc/c/c-parser.c:6882 0x6228d2 c_parser_binary_expression .././../gcc/c/c-parser.c:6691 0x6235b5 c_parser_conditional_expression .././../gcc/c/c-parser.c:6459 0x623d10 c_parser_expr_no_commas .././../gcc/c/c-parser.c:6376 0x623d8a c_parser_expr_no_commas .././../gcc/c/c-parser.c:6418 0x623f92 c_parser_expression .././../gcc/c/c-parser.c:8576 0x626819 c_parser_expression_conv .././../gcc/c/c-parser.c:8609 0x63a259 c_parser_statement_after_labels .././../gcc/c/c-parser.c:5394 0x63c027 c_parser_compound_statement_nostart .././../gcc/c/c-parser.c:4908 0x63c77e c_parser_compound_statement .././../gcc/c/c-parser.c:4741 0x637bbc c_parser_declaration_or_fndef .././../gcc/c/c-parser.c:2113 0x63fb8b c_parser_external_declaration .././../gcc/c/c-parser.c:1469 0x6405e9 c_parser_translation_unit .././../gcc/c/c-parser.c:1349
[Bug tree-optimization/79894] New: [5/6/7 Regression] ICE in gfc_add_modify_loc, at fortran/trans.c:159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79894
Bug ID: 79894
Summary: [5/6/7 Regression] ICE in gfc_add_modify_loc, at
fortran/trans.c:159
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
Starting from r217421, we ICE on:
$ gcc
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/complex_intrinsic_6.f90
-c
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/complex_intrinsic_6.f90:35:0:
z4 = asin(z4) ! { dg-error "Fortran 2008: COMPLEX argument" }
internal compiler error: in gfc_add_modify_loc, at fortran/trans.c:159
0x73e520 gfc_add_modify_loc(unsigned int, stmtblock_t*, tree_node*, tree_node*)
../../gcc/fortran/trans.c:158
0x7783b1 gfc_trans_scalar_assign(gfc_se*, gfc_se*, gfc_typespec, bool, bool,
bool)
../../gcc/fortran/trans-expr.c:8793
0x7899ea gfc_trans_assignment_1
../../gcc/fortran/trans-expr.c:10064
0x73ec87 trans_code
../../gcc/fortran/trans.c:1817
0x76fce8 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6306
0x6f7890 translate_all_program_units
../../gcc/fortran/parse.c:6070
0x6f7890 gfc_parse_file()
../../gcc/fortran/parse.c:6270
0x73b80f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:204
[Bug target/79895] New: ICE in extract_constrain_insn, at recog.c:2213
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79895
Bug ID: 79895
Summary: ICE in extract_constrain_insn, at recog.c:2213
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Target: s390x-linux-gnu
We ICE on:
$ s390x-linux-gnu-gcc
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-7.c
-O3 -mno-lra
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-7.c:
In function ‘main’:
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-7.c:196:1:
error: insn does not satisfy its constraints:
}
^
(insn 6003 944 945 131 (set (reg:TI 4 %r4)
(const_wide_int 0x0))
"/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-7.c":160
1093 {movti}
(nil))
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-7.c:196:1:
internal compiler error: in extract_constrain_insn, at recog.c:2213
0xae9088 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
.././../gcc/rtl-error.c:108
0xae90af _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
.././../gcc/rtl-error.c:119
0xabd2dd extract_constrain_insn(rtx_insn*)
.././../gcc/recog.c:2213
0xa8ee96 reload_cse_simplify_operands
.././../gcc/postreload.c:391
0xa8ffa4 reload_cse_simplify
.././../gcc/postreload.c:179
0xa8ffa4 reload_cse_regs_1
.././../gcc/postreload.c:218
0xa918bb reload_cse_regs
.././../gcc/postreload.c:64
0xa918bb execute
.././../gcc/postreload.c:2342
[Bug lto/79851] diagnostics: replace '%s' with %qs in all diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79851
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2017-03-06
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
A complication is that we use two different diagnostic machineries, where I
believe only one handles %qs and the other simply uses fprintf
(diagnostic*.[ch]
vs. errors.[ch]). Some files are build both for generator programs (which use
errors.[ch]) and for GCC. For example errors.c simply has
/* Similar, but say we got an internal error. */
void
internal_error (const char *format, ...)
{
va_list ap;
va_start (ap, format);
fprintf (stderr, "%s: Internal error: ", progname);
vfprintf (stderr, format, ap);
va_end (ap);
fputc ('\n', stderr);
exit (FATAL_EXIT_CODE);
}
(so those are also not marked for translation).
[Bug rtl-optimization/79856] rtl_verify_edges: use internal_error instead of error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79856 --- Comment #2 from Richard Biener --- Note that internal_error will terminate GCC immediately while error () allows for further errors to be diagnosed. Which is what we want here, internal_error is done as the final step in "CFG verification failed" or so.
[Bug rtl-optimization/79856] rtl_verify_edges: use internal_error instead of error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79856 --- Comment #3 from Richard Biener --- So maybe we instead want a internal_error_cont () which will not end compilation.
[Bug c++/79857] cgraph_node::verify_node should call internal_error instead of error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79857 --- Comment #2 from Richard Biener --- No, see other bug.
[Bug rtl-optimization/79858] Explain to translators what %smode means
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79858 --- Comment #1 from Richard Biener --- It's a few uppercase letters, like forming QImode, not to be translated.
[Bug target/79896] New: ICE in gimplify_expr, at gimplify.c:11950 on ARM target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79896 Bug ID: 79896 Summary: ICE in gimplify_expr, at gimplify.c:11950 on ARM target Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Target: arm-linux-gnueabi Running an invalid test-case for the target ICEs: $ arm-linux-gnueabi-g++ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/int128-3.C /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/int128-3.C:7:3: error: overflow in enumeration values at ‘e2’ e2, e3 ^~ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/int128-3.C:12:27: error: expected primary-expression before ‘__int128’ SA(1, sizeof(E) == sizeof(__int128)); ^ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/int128-3.C:10:27: note: in definition of macro ‘SA’ #define SA(I,X) int a##I[(X)? 1 : -1] ^ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/int128-3.C:12:27: error: expected ‘)’ before ‘__int128’ SA(1, sizeof(E) == sizeof(__int128)); ^ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/int128-3.C:10:27: note: in definition of macro ‘SA’ #define SA(I,X) int a##I[(X)? 1 : -1] ^ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/int128-3.C:12:37: error: expected ‘)’ before ‘;’ token SA(1, sizeof(E) == sizeof(__int128)); ^ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/int128-3.C:12:37: error: expected ‘]’ before ‘;’ token /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/int128-3.C: In function ‘void __static_initialization_and_destruction_0(int, int)’: /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/int128-3.C:8:3: internal compiler error: in gimplify_expr, at gimplify.c:11950 } e = e3; ^ 0xaf0dca gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) .././../gcc/gimplify.c:11950 0xb016bf gimplify_modify_expr .././../gcc/gimplify.c:5457 0xaef54d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) .././../gcc/gimplify.c:11192 0xaf2cf6 gimplify_stmt(tree_node**, gimple**) .././../gcc/gimplify.c:6478 0xaef7f1 gimplify_cleanup_point_expr .././../gcc/gimplify.c:6230 0xaef7f1 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) .././../gcc/gimplify.c:11567 0xaf2cf6 gimplify_stmt(tree_node**, gimple**) .././../gcc/gimplify.c:6478 0xaee0b3 gimplify_statement_list .././../gcc/gimplify.c:1716 0xaee0b3 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) .././../gcc/gimplify.c:11619 0xaf2cf6 gimplify_stmt(tree_node**, gimple**) .././../gcc/gimplify.c:6478 0xaf7f49 gimplify_cond_expr .././../gcc/gimplify.c:3971 0xaef584 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) .././../gcc/gimplify.c:11148 0xaf2cf6 gimplify_stmt(tree_node**, gimple**) .././../gcc/gimplify.c:6478 0xaf7f49 gimplify_cond_expr .././../gcc/gimplify.c:3971 0xaef584 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) .././../gcc/gimplify.c:11148 0xaf2cf6 gimplify_stmt(tree_node**, gimple**) .././../gcc/gimplify.c:6478 0xaf4cd9 gimplify_body(tree_node*, bool) .././../gcc/gimplify.c:12388 0xaf5374 gimplify_function_tree(tree_node*) .././../gcc/gimplify.c:12546 0x96ae67 cgraph_node::analyze() .././../gcc/cgraphunit.c:657 0x96e5d3 analyze_functions .././../gcc/cgraphunit.c:1118
[Bug libstdc++/79862] Compilation error while building libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79862 Richard Biener changed: What|Removed |Added Keywords||build Target||powerpc-wrs-vxworks Component|c++ |libstdc++ Host||i686-pc-linux-gnu Build||i686-pc-linux-gnu --- Comment #1 from Richard Biener --- Note GCC 4.8.1 is no longer maintained.
[Bug sanitizer/79897] New: ICE in gimplify_modify_expr, at gimplify.c:5627 on ARM target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79897 Bug ID: 79897 Summary: ICE in gimplify_modify_expr, at gimplify.c:5627 on ARM target Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org 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, mpolacek at gcc dot gnu.org Target Milestone: --- Target: arm-linux-gnueabi Running on ARM target (with cross-compiler): $ arm-linux-gnueabi-g++ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/init/enum2.C -fsanitize=undefined In function ‘int main()’: cc1plus: internal compiler error: in gimplify_modify_expr, at gimplify.c:5627 0xb01b51 gimplify_modify_expr .././../gcc/gimplify.c:5626 0xaef54d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) .././../gcc/gimplify.c:11192 0xaf2cf6 gimplify_stmt(tree_node**, gimple**) .././../gcc/gimplify.c:6478 0xaf39a1 gimplify_compound_expr .././../gcc/gimplify.c:5715 0xaef4fd gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) .././../gcc/gimplify.c:11181 0xb10435 force_gimple_operand_1(tree_node*, gimple**, bool (*)(tree_node*), tree_node*) .././../gcc/gimplify-me.c:78 0xb1056f force_gimple_operand_gsi_1(gimple_stmt_iterator*, tree_node*, bool (*)(tree_node*), tree_node*, bool, gsi_iterator_update) .././../gcc/gimplify-me.c:115 0xd9016c instrument_bool_enum_load .././../gcc/ubsan.c:1462 0xd9016c execute .././../gcc/ubsan.c:2003
[Bug other/79874] symtab_node::verify_base: replace error with internal_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79874 --- Comment #2 from Richard Biener --- Yep, see some other similar bugs.
[Bug tree-optimization/79898] New: ICE in const_binop, at fold-const.c:1554 on ARM target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79898 Bug ID: 79898 Summary: ICE in const_binop, at fold-const.c:1554 on ARM target Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Target: arm-linux-gnueabi Following ICEs on ARM target (with cross-compiler): $ arm-linux-gnueabi-gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/fixed-point/loop-index.c -Ofast /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/fixed-point/loop-index.c: In function ‘main’: /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/fixed-point/loop-index.c:55:1: internal compiler error: in const_binop, at fold-const.c:1554 main () ^~~~ 0x8907da const_binop(tree_code, tree_node*, tree_node*, tree_node*) .././../gcc/fold-const.c:1553 0xee5cb8 gimple_resimplify2(gimple**, code_helper*, tree_node*, tree_node**, tree_node* (*)(tree_node*)) .././../gcc/gimple-match-head.c:132 0xd440dd vn_nary_build_or_lookup_1 .././../gcc/tree-ssa-sccvn.c:1676 0xd44345 vn_nary_simplify(vn_nary_op_s*) .././../gcc/tree-ssa-sccvn.c:1771 0xd1db90 fully_constant_expression .././../gcc/tree-ssa-pre.c:1216 0xd22f25 phi_translate_1 .././../gcc/tree-ssa-pre.c:1462 0xd20d23 phi_translate .././../gcc/tree-ssa-pre.c:1742 0xd20ea5 phi_translate_set .././../gcc/tree-ssa-pre.c:1780 0xd21d7d compute_antic_aux .././../gcc/tree-ssa-pre.c:2116 0xd21d7d compute_antic .././../gcc/tree-ssa-pre.c:2403 0xd250c0 execute .././../gcc/tree-ssa-pre.c:5094
[Bug c++/79821] [7 regression] SEGV in cc1plus compiling 64-bit stdc++.h.gch/O2g.gch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79821 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- If you up from the ICE case up to gt_pch_nx_die_struct frame, it would be interesting if you can figure out what x is would be print_die (x, stderr) E.g. in void gt_pch_nx (struct dw_attr_struct& x_r ATTRIBUTE_UNUSED) there are several cases that work with _S: case dw_val_class_vec: gt_pch_n_S ((*x).dw_attr_val.v.val_vec.array); break; ... case dw_val_class_lbl_id: gt_pch_n_S ((*x).dw_attr_val.v.val_lbl_id); break; ... case dw_val_class_vms_delta: gt_pch_n_S ((*x).dw_attr_val.v.val_vms_delta.lbl1); gt_pch_n_S ((*x).dw_attr_val.v.val_vms_delta.lbl2); break; I hope vms_delta is not something you see, it would be interesting to know what kind of attribute it is. For val_lbl_id we strangely use xstrdup rather than say ggc_strdup, but it would be really weird if the labels appeared during PCH streaming.
[Bug libstdc++/79862] Compilation error while building libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79862 --- Comment #2 from Sumit --- (In reply to Richard Biener from comment #1) > Note GCC 4.8.1 is no longer maintained. Hi Richard, I understand that 4.8.1 is no longer supported. Actually, our project in current state can't move to any version beyond 4.8.1 for some maintainability reasons. At least can you share some pointers by which I can try to debug this issue myself. That would be appreciated. Thanks. Sumit
[Bug c/79881] -Wc++-compat should warn about sizeof character literals
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79881 Richard Biener changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2017-03-06 Ever confirmed|0 |1
[Bug c++/79899] New: ICE in ctor_omit_inherited_parms at gcc/cp/method.c:576 on ARM target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79899
Bug ID: 79899
Summary: ICE in ctor_omit_inherited_parms at
gcc/cp/method.c:576 on ARM target
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Target: arm-linux-gnueabi
Following test-case ICEs on ARM target (with cross-compiler):
$ arm-linux-gnueabi-g++
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/other/friend5.C -Os
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/other/friend5.C:8:16: error:
member functions are implicitly friends of their class [-fpermissive]
friend A::~A() {} /* { dg-error "implicitly friends of their class" } */
^
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/other/friend5.C:8:19:
internal compiler error: Segmentation fault
friend A::~A() {} /* { dg-error "implicitly friends of their class" } */
^
0xd67a0f crash_signal
.././../gcc/toplev.c:337
0x79c79b ctor_omit_inherited_parms(tree_node*)
.././../gcc/cp/method.c:576
0x7efc58 maybe_thunk_body
.././../gcc/cp/optimize.c:265
0x7f11c8 maybe_clone_body(tree_node*)
.././../gcc/cp/optimize.c:509
0x7b4727 expand_or_defer_fn_1(tree_node*)
.././../gcc/cp/semantics.c:4236
0x7b49f8 expand_or_defer_fn(tree_node*)
.././../gcc/cp/semantics.c:4258
0x7445ab cp_parser_function_definition_after_declarator
.././../gcc/cp/parser.c:26270
0x744954 cp_parser_late_parsing_for_member
.././../gcc/cp/parser.c:27144
0x725d41 cp_parser_class_specifier_1
.././../gcc/cp/parser.c:22328
0x726831 cp_parser_class_specifier
.././../gcc/cp/parser.c:22354
0x726831 cp_parser_type_specifier
.././../gcc/cp/parser.c:16421
0x73bb69 cp_parser_decl_specifier_seq
.././../gcc/cp/parser.c:13332
0x745881 cp_parser_simple_declaration
.././../gcc/cp/parser.c:12654
0x7467ca cp_parser_block_declaration
.././../gcc/cp/parser.c:12599
0x74e73e cp_parser_declaration
.././../gcc/cp/parser.c:12496
0x74eb96 cp_parser_declaration_seq_opt
.././../gcc/cp/parser.c:12372
0x74eec8 cp_parser_translation_unit
.././../gcc/cp/parser.c:4366
0x74eec8 c_parse_file()
.././../gcc/cp/parser.c:38427
0x8b2b82 c_common_parse_file()
.././../gcc/c-family/c-opts.c:1107
[Bug fortran/79886] [5/6/7 Regression] ICE in pp_format, at pretty-print.c:681
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79886 Richard Biener changed: What|Removed |Added Keywords||diagnostic Target Milestone|--- |5.5
[Bug tree-optimization/79887] [7 Regression] ICE in set_uid_loop_bbs, at tree-vectorizer.c:482
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79887 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-03-06 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |7.0 Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Mine.
[Bug libstdc++/79862] Compilation error while building libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79862 --- Comment #3 from Andrew Pinski --- --disable-hosted-libstdcxx \ That is more likely the cause. non-hosted libstdc++ is not well tested.
[Bug gcov-profile/79891] Wrong count of line coverage in case of gcov -a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79891 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2017-03-06 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug tree-optimization/79894] [5/6/7 Regression] ICE in gfc_add_modify_loc, at fortran/trans.c:159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79894 Richard Biener changed: What|Removed |Added Target Milestone|--- |5.5
[Bug c++/79900] New: [5/6/7 Regression] ICE in strip_typedefs, at cp/tree.c:1554
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79900 Bug ID: 79900 Summary: [5/6/7 Regression] ICE in strip_typedefs, at cp/tree.c:1554 Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Starting from 4.7.0, we started to ICE on: $ g++ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/eh/unwind2.C -Wpadded /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/eh/unwind2.C: In instantiation of ‘class std::basic_filebuf >’: /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/eh/unwind2.C:93:18: required from here /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/eh/unwind2.C:70:16: warning: padding struct to align ‘std::basic_filebuf >::_M_pback_cur_save’ [-Wpadded] char_type *_M_pback_cur_save; ^ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/eh/unwind2.C:61:55: warning: padding struct size to alignment boundary [-Wpadded] template struct basic_filebuf : public basic_streambuf <_CharT, _Traits> ^ ‘ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/eh/unwind2.C: In instantiation of ‘struct std::fpos’: /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/eh/unwind2.C:83:3: in strip_typedefs, at cp/tree.c:1554 template struct fpos ^~~~ 0x86b7d9 strip_typedefs(tree_node*, bool*) ../../gcc/cp/tree.c:1554 0x783b81 dump_template_bindings ../../gcc/cp/error.c:357 0x783b81 dump_substitution ../../gcc/cp/error.c:1494 0x7847ab dump_substitution ../../gcc/cp/error.c:1528 0x7847ab dump_function_decl ../../gcc/cp/error.c:1649 0x790c02 decl_to_string ../../gcc/cp/error.c:3028 0x790c02 cp_printer ../../gcc/cp/error.c:3605 0x15fd79f pp_format(pretty_printer*, text_info*) ../../gcc/pretty-print.c:679 0x15fe780 pp_format_verbatim(pretty_printer*, text_info*) ../../gcc/pretty-print.c:738 0x15fe854 pp_verbatim(pretty_printer*, char const*, ...) ../../gcc/pretty-print.c:939 0x78256d print_instantiation_partial_context_line ../../gcc/cp/error.c:3405 0x78256d print_instantiation_partial_context ../../gcc/cp/error.c:3515 0x78256d print_instantiation_full_context ../../gcc/cp/error.c:3394 0x78256d maybe_print_instantiation_context ../../gcc/cp/error.c:3531 0x78c4af cp_diagnostic_starter ../../gcc/cp/error.c:3224 0x15f0b84 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) ../../gcc/diagnostic.c:962 0x15f0ed3 diagnostic_impl ../../gcc/diagnostic.c:1084 0x15f124c warning(int, char const*, ...) ../../gcc/diagnostic.c:1172 0xde474d finalize_record_size ../../gcc/stor-layout.c:1583 0xde474d finish_record_layout(record_layout_info_s*, int) ../../gcc/stor-layout.c:2023
[Bug libstdc++/79862] Compilation error while building libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79862 --- Comment #4 from Sumit --- (In reply to Andrew Pinski from comment #3) > --disable-hosted-libstdcxx \ > > That is more likely the cause. non-hosted libstdc++ is not well tested. Hi Andrew, Thanks for the comments. Actually, when we say "--disable-hosted-libstdcxx", we mean that we only want a limited set of headers (same as the one in "freestanding" mode). But as per the info below, "freestanding" mode supports typeinfo and exception headers. In "freestanding" mode only the following headers can be safely used: •cstdarg •cstddef •cstdlib •exception •limits •new •exception •typeinfo
[Bug c/79855] params.def: missing period in PARAM_MAX_STORES_TO_MERGE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79855 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-03-06 CC||ktkachov at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot gnu.org Target Milestone|--- |7.0 Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- PARAM_STORE_MERGING_ALLOW_UNALIGNED also needs a full stop
[Bug rtl-optimization/79901] New: ICE in prepare_cmp_insn, at optabs.c:3904
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79901 Bug ID: 79901 Summary: ICE in prepare_cmp_insn, at optabs.c:3904 Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Target: x86_64-llinux-gnu Starting from GCC 5 (where -fssa-phiopt was added), we ICE on: $ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/aarch64/pr63424.c -mavx512cd -O3 -fno-ssa-phiopt /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/aarch64/pr63424.c: In function ‘test’: /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/aarch64/pr63424.c:35:12: internal compiler error: in prepare_cmp_insn, at optabs.c:3904 a[i] = mul (a[i], s); ~^~~ 0xb032bb prepare_cmp_insn ../../gcc/optabs.c:3904 0xb03355 emit_cmp_and_jump_insns(rtx_def*, rtx_def*, rtx_code, rtx_def*, machine_mode, int, rtx_def*, int) ../../gcc/optabs.c:4051 0x83ad7c do_compare_rtx_and_jump(rtx_def*, rtx_def*, rtx_code, int, machine_mode, rtx_def*, rtx_code_label*, rtx_code_label*, int) ../../gcc/dojump.c:1145 0x8e2e21 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) ../../gcc/expr.c:9024 0x8cfc2f expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/expr.c:9758 0x8d944e expand_expr ../../gcc/expr.h:276 0x8d944e expand_operands(tree_node*, tree_node*, rtx_def*, rtx_def**, rtx_def**, expand_modifier) ../../gcc/expr.c:7672 0x8e130c expand_expr_real_2(separate_ops*, rtx_def*, machine_mode, expand_modifier) ../../gcc/expr.c:9549 0x8cfc2f expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool) ../../gcc/expr.c:9758 0x8da516 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool, tree_node*) ../../gcc/expr.c:5552 0x8dc100 expand_assignment(tree_node*, tree_node*, bool) ../../gcc/expr.c:5321 0x7c0066 expand_gimple_stmt_1 ../../gcc/cfgexpand.c:3641 0x7c0066 expand_gimple_stmt ../../gcc/cfgexpand.c:3737 0x7c235e expand_gimple_basic_block ../../gcc/cfgexpand.c:5744 0x7c8426 execute ../../gcc/cfgexpand.c:6357
[Bug ipa/79902] New: ICE in rebuild_frequencies, at predict.c:3689
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79902
Bug ID: 79902
Summary: ICE in rebuild_frequencies, at predict.c:3689
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: ipa
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: hubicka at ucw dot cz
Target Milestone: ---
We ICE on:
$ gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr78419.c -O3
-fbranch-probabilities
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr78419.c:15:1:
error: attribute(target("foo")) is unknown
bar (double *__restrict a, double *__restrict b, int n) /* { dg-error
"attribute\[^\n\r]*foo\[^\n\r]* is unknown" } */
^~~
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr78419.c: In
function ‘bar._GLOBAL___foo.resolver.part.4’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.target/i386/pr78419.c:24:1:
internal compiler error: in rebuild_frequencies, at predict.c:3689
}
^
0xb3de98 rebuild_frequencies()
../../gcc/predict.c:3689
0xc8a374 tree_function_versioning(tree_node*, tree_node*, vec*, bool, bitmap_head*, bool, bitmap_head*, basic_block_def*)
../../gcc/tree-inline.c:6007
0x8027e0 cgraph_node::create_version_clone_with_body(vec, vec*, bitmap_head*, bool,
bitmap_head*, basic_block_def*, char const*)
../../gcc/cgraphclones.c:1003
0x1346ded split_function
../../gcc/ipa-split.c:1359
0x1346ded execute_split_functions
../../gcc/ipa-split.c:1865
0x1348258 execute_feedback_split_functions
../../gcc/ipa-split.c:1928
0x1348258 execute
../../gcc/ipa-split.c:1960
I'll fix that.
[Bug ada/79903] New: When building RTEMS for SPARC with Ada support, the build fails because of missing #ifdef
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79903 Bug ID: 79903 Summary: When building RTEMS for SPARC with Ada support, the build fails because of missing #ifdef Product: gcc Version: 6.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: ttsiodras at gmail dot com Target Milestone: --- I have just successfully built the latest GCC cross-compiling toolchain for RTEMS/SPARC with Ada support - but to do so, I had to patch the GCC 6.3 source in one place: diff --git a/gcc-6.3.0/gcc/ada/socket.c b/gcc-6.3.0/gcc/ada/socket.c index f5fb663..5cdd656 100644 --- a/gcc-6.3.0/gcc/ada/socket.c +++ b/gcc-6.3.0/gcc/ada/socket.c @@ -202,7 +202,7 @@ __gnat_gethostbyaddr (const char *addr, int len, int type, struct hostent *rh; int ri; -#if defined(__linux__) || defined(__GLIBC__) +#if defined(__linux__) || defined(__GLIBC__) || defined(__rtems__) (void) gethostbyaddr_r (addr, len, type, ret, buf, buflen, &rh, h_errnop); #else rh = gethostbyaddr_r (addr, len, type, ret, buf, buflen, h_errnop); Without that patch, the RTEMS RSB build fails - at least for the following version of the RSB: $ # RTEMS Source Builder: commit 4c5eb8969451c4ea0997b3caa98bfe80fe15da69 $ ../source-builder/sb-set-builder --log=sparc2.log --prefix=/opt/rtems-4.12 --without-rtems --with-ada 4.12/rtems-sparc Hope this helps. Kind regards, Thanassis. -- Thanassis Tsiodras Real-time Embedded Software Engineer European Space Agency System, Software and Technology Department
[Bug target/79904] New: ICE in annotate_constant_pool_refs, at config/s390/s390.c:7909
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79904 Bug ID: 79904 Summary: ICE in annotate_constant_pool_refs, at config/s390/s390.c:7909 Product: gcc Version: 7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: mpolacek at gcc dot gnu.org Target Milestone: --- Target: s390x-linux-gnu We ICE on following target (with cross-compiler): $ s390x-linux-gnu-gcc /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr59261.c -fsanitize=undefined /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr59261.c: In function ‘foo’: /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr59261.c:11:1: internal compiler error: in annotate_constant_pool_refs, at config/s390/s390.c:7909 } ^ 0xe74d05 annotate_constant_pool_refs .././../gcc/config/s390/s390.c:7908 0xe74cdb annotate_constant_pool_refs .././../gcc/config/s390/s390.c:7992 0xe74cdb annotate_constant_pool_refs .././../gcc/config/s390/s390.c:7992 0xe74cdb annotate_constant_pool_refs .././../gcc/config/s390/s390.c:7992 0xe8ab19 execute .././../gcc/config/s390/s390.c:10819
[Bug target/79905] New: ICE in canonical types differ for identical types __vector(4) int and V4i {aka __vector(4) int}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79905
Bug ID: 79905
Summary: ICE in canonical types differ for identical types
__vector(4) int and V4i {aka __vector(4) int}
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Host: ppc64le-linux-gnu
Created attachment 40889
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40889&action=edit
test-case
Following ICEs on ppc64le-linux-gnu (with cross-compiler):
$ ppc64le-linux-gnu-g++ altivec.cpp
altivec.cpp: In function ‘void test_vec_step(__vector(8) short int)’:
altivec.cpp:20:12: error: ‘vec_step’ was not declared in this scope
int res1[vec_step(arg1) == 8 ? 1 : -1];
^~~~
altivec.cpp:20:12: note: suggested alternative: ‘vector’
int res1[vec_step(arg1) == 8 ? 1 : -1];
^~~~
vector
altivec.cpp: In function ‘void test1()’:
altivec.cpp:44:13: internal compiler error: canonical types differ for
identical types __vector(4) int and V4i {aka __vector(4) int}
f(vAltiVec);
^
0x75287f comptypes(tree_node*, tree_node*, int)
.././../gcc/cp/typeck.c:1434
0x5ed46c standard_conversion
.././../gcc/cp/call.c:1187
0x5f8748 implicit_conversion
.././../gcc/cp/call.c:1839
0x5facc1 add_function_candidate
.././../gcc/cp/call.c:2197
0x5fca7f add_candidates
.././../gcc/cp/call.c:5504
0x5ff341 perform_overload_resolution
.././../gcc/cp/call.c:4148
0x6018ce build_new_function_call(tree_node*, vec**, bool, int)
.././../gcc/cp/call.c:4233
0x7a4bac finish_call_expr(tree_node*, vec**, bool,
bool, int)
.././../gcc/cp/semantics.c:2441
0x71c67b cp_parser_postfix_expression
.././../gcc/cp/parser.c:6994
0x71aa94 cp_parser_unary_expression
.././../gcc/cp/parser.c:8102
0x724fd7 cp_parser_cast_expression
.././../gcc/cp/parser.c:8780
0x72556d cp_parser_binary_expression
.././../gcc/cp/parser.c:8881
0x725e30 cp_parser_assignment_expression
.././../gcc/cp/parser.c:9168
0x7289ea cp_parser_expression
.././../gcc/cp/parser.c:9337
0x728fa9 cp_parser_expression_statement
.././../gcc/cp/parser.c:10885
0x73a70c cp_parser_statement
.././../gcc/cp/parser.c:10701
0x73ba14 cp_parser_statement_seq_opt
.././../gcc/cp/parser.c:11027
0x73bb1f cp_parser_compound_statement
.././../gcc/cp/parser.c:10981
0x73652d cp_parser_function_body
.././../gcc/cp/parser.c:21438
0x73652d cp_parser_ctor_initializer_opt_and_function_body
.././../gcc/cp/parser.c:21474
[Bug c++/79821] [7 regression] SEGV in cc1plus compiling 64-bit stdc++.h.gch/O2g.gch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79821 --- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #5 from Jakub Jelinek --- > If you up from the ICE case up to gt_pch_nx_die_struct frame, it would be > interesting if you can figure out what x is would be print_die (x, stderr) I get DIE0: DW_TAG_member (f821cdb0) abbrev id: 0 offset: 0 mark: 0 DW_AT_name: "is_specialized" DW_AT_decl_file: "/var/gcc/reghunt/pch-segv/36684/sparc-sun-solaris2.12/sparcv9/libstdc++-v3/include/limits" (0) DW_AT_decl_line: 385 DW_AT_type: die -> 0 (fb6a4c60) DW_AT_external: 1 DW_AT_declaration: 1 DW_AT_const_value: floating-point or vector constant DW_AT_const_expr: 1 for the innermost call to gt_pch_nx_die_struct. Rainer
[Bug target/79906] New: ICE in rs6000_inner_target_options, at config/rs6000/rs6000.c:39199
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79906
Bug ID: 79906
Summary: ICE in rs6000_inner_target_options, at
config/rs6000/rs6000.c:39199
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Target: ppc64le-linux-gnu
Target attribute with invalid value should produce error message instead of
ICE:
$ ppc64le-linux-gnu-g++
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/mv8.C
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/ext/mv8.C:5:15: internal
compiler error: in rs6000_inner_target_options, at config/rs6000/rs6000.c:39199
void foo (void) // { dg-error "not a string" }
^
0x108715c rs6000_inner_target_options
.././../gcc/config/rs6000/rs6000.c:39199
0x1086e1c rs6000_inner_target_options
.././../gcc/config/rs6000/rs6000.c:39189
0x109d3a7 rs6000_valid_attribute_p
.././../gcc/config/rs6000/rs6000.c:39297
0x8cabf1 handle_target_attribute
.././../gcc/c-family/c-attribs.c:3028
0x854a53 decl_attributes(tree_node**, tree_node*, int)
.././../gcc/attribs.c:548
0x6e5a2e cplus_decl_attributes(tree_node**, tree_node*, int)
.././../gcc/cp/decl2.c:1436
0x5b3e36 grokfndecl
.././../gcc/cp/decl.c:8859
0x634462 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
.././../gcc/cp/decl.c:12225
0x636d56 start_function(cp_decl_specifier_seq*, cp_declarator const*,
tree_node*)
.././../gcc/cp/decl.c:15137
0x737622 cp_parser_function_definition_from_specifiers_and_declarator
.././../gcc/cp/parser.c:26129
0x737622 cp_parser_init_declarator
.././../gcc/cp/parser.c:19141
0x73830f cp_parser_simple_declaration
.././../gcc/cp/parser.c:12773
0x73906a cp_parser_block_declaration
.././../gcc/cp/parser.c:12599
0x740fde cp_parser_declaration
.././../gcc/cp/parser.c:12496
0x741436 cp_parser_declaration_seq_opt
.././../gcc/cp/parser.c:12372
0x741768 cp_parser_translation_unit
.././../gcc/cp/parser.c:4366
0x741768 c_parse_file()
.././../gcc/cp/parser.c:38427
0x8a4f72 c_common_parse_file()
.././../gcc/c-family/c-opts.c:1107
[Bug target/79907] New: ICE in extract_constrain_insn, at recog.c:2213 on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79907
Bug ID: 79907
Summary: ICE in extract_constrain_insn, at recog.c:2213 on
ppc64le
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Target: ppc64le-linux-gnu
We ICE on:
$ ppc64le-linux-gnu-gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/fold-convmaxconv-1.c -Ofast
-mno-upper-regs-df
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/fold-convmaxconv-1.c: In
function ‘foo’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/fold-convmaxconv-1.c:13:1:
error: insn does not satisfy its constraints:
}
^
(insn 479 478 140 20 (set (reg:DI 9 9)
(reg:DI 77 0)) 583 {*movdi_internal64}
(expr_list:REG_DEAD (reg:DI 77 0)
(nil)))
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/fold-convmaxconv-1.c:13:1:
internal compiler error: in extract_constrain_insn, at recog.c:2213
0xb085a8 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
.././../gcc/rtl-error.c:108
0xb085cf _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
.././../gcc/rtl-error.c:119
0xadaf77 extract_constrain_insn(rtx_insn*)
.././../gcc/recog.c:2213
0xade6c3 copyprop_hardreg_forward_1
.././../gcc/regcprop.c:794
0xadf50f execute
.././../gcc/regcprop.c:1301
[Bug target/79908] New: ICE in gimplify_expr (gimplify.c:12155) gimplification failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79908 Bug ID: 79908 Summary: ICE in gimplify_expr (gimplify.c:12155) gimplification failed Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org Target Milestone: --- Target: ppc64le-linux-gnu Created attachment 40890 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40890&action=edit test-case Following test-case taken from LLVM ICEs: ppc64le-linux-gnu-gcc ppc64-varargs-complex.c -O1 gimplification failed: COMPLEX_EXPR unit size align 32 symtab 0 alias set -1 canonical type 0x7f64a71bd738 precision 32 min max pointer_to_this > sizes-gimplified CSI size unit size align 32 symtab 0 alias set -1 canonical type 0x7f64a71d2f18 pointer_to_this > arg 0 used ignored SI file ppc64-varargs-complex.c line 10 col 16 size unit size align 32 context chain used unsigned ignored DI file ppc64-varargs-complex.c line 10 col 16 size unit size align 64 context chain >> arg 1 used ignored SI file ppc64-varargs-complex.c line 10 col 16 size unit size align 32 context chain used unsigned ignored DI file ppc64-varargs-complex.c line 10 col 16 size unit size align 64 context chain >>> ppc64-varargs-complex.c: In function ‘testva’: ppc64-varargs-complex.c:10:16: internal compiler error: gimplification failed _Complex int i = va_arg(ap, _Complex int); ^ 0x8fe8e9 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*), int) .././../gcc/gimplify.c:12155 0xd99b9b expand_ifn_va_arg_1 .././../gcc/tree-stdarg.c:1061 0xd99b9b expand_ifn_va_arg .././../gcc/tree-stdarg.c:1101 0xd9ba6b execute .././../gcc/tree-stdarg.c:1154 Please submit a full bug report,
[Bug rtl-optimization/79571] [5/6/7 Regression] ICE in Max. number of generated reload insns per insn is achieved (90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79571 --- Comment #11 from Martin Liška --- I see a similar test-case on ppc64le-linux-gnu (w/ cross-compiler): $ ppc64le-linux-gnu-g++ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/compat/decimal/return-6_x.C -mno-popcntd -Og In file included from /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/compat/decimal/return-6_x.C:7:0: /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/compat/decimal/return_x.h: In function ‘void testitd32()’: /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/compat/decimal/return_x.h:84:1: internal compiler error: Max. number of generated reload insns per insn is achieved (90) } ^ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/compat/decimal/return_x.h:86:1: note: in expansion of macro ‘T’ T(d32, dec32, (dec32)1.5DF); ^ 0xbffedb lra_constraints(bool) .././../gcc/lra-constraints.c:4678 0xbe8cfc lra(_IO_FILE*) .././../gcc/lra.c:2392 0xb9d681 do_reload .././../gcc/ira.c:5451 0xb9d681 execute .././../gcc/ira.c:5635 Should I create a separate issue, or is it the same as this one?
[Bug target/79909] New: ICE error: invalid rtl sharing found in the insn on ppc64le
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79909
Bug ID: 79909
Summary: ICE error: invalid rtl sharing found in the insn on
ppc64le
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
Target Milestone: ---
Target: ppc64le-linux-gnu
We ICE on:
$ ppc64le-linux-gnu-g++
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/compat/decimal/pass-5_x.C
-mxl-compat -O
In file included from
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/compat/decimal/pass-5_x.C:5:0:
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/compat/decimal/pass_x.h: In
function ‘void test2_d128(dec128, dec128, dec128, dec128, dec128, dec128,
dec128, dec128)’:
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/compat/decimal/pass_x.h:33:1:
error: invalid rtl sharing found in the insn
}\
^
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/compat/decimal/pass_x.h:149:1:
note: in expansion of macro ‘T’
T(d128, dec128, (dec128)3.5DL)
^
(call_insn 74 72 0 2 (parallel [
(call (mem:SI (symbol_ref:DI
("_Z8testd128DeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDe") [flags 0x41] ) [0 testd128 S4 A8])
(const_int 256 [0x100]))
(clobber (reg:DI 65 lr))
])
"/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/compat/decimal/pass_x.h":149
667 {*call_nonlocal_aixdi}
(expr_list:REG_CALL_DECL (symbol_ref:DI
("_Z8testd128DeDeDeDeDeDeDeDeDeDeDeDeDeDeDeDe") [flags 0x41] )
(expr_list:REG_DEAD (reg:TD 34 2)
(expr_list:REG_DEAD (reg:TD 36 4)
(expr_list:REG_DEAD (reg:TD 38 6)
(expr_list:REG_DEAD (reg:TD 40 8)
(expr_list:REG_DEAD (reg:TD 42 10)
(expr_list:REG_DEAD (reg:TD 44 12)
(nil
(expr_list (use (reg:DI 2 2))
(expr_list:TD (use (reg:TD 34 2))
(expr_list:TD (use (reg:TD 36 4))
(expr_list:TD (use (reg:TD 38 6))
(expr_list:TD (use (reg:TD 40 8))
(expr_list (use (reg:TD 42 10))
(expr_list (use (reg:TD 44 12))
(expr_list:TD (use (mem:TD (plus:DI (plus:DI
(reg/f:DI 1 1)
(const_int 32 [0x20]))
(const_int 64 [0x40])) [0 S16
A64]))
(expr_list:TD (use (mem:TD (plus:DI
(plus:DI (reg/f:DI 1 1)
(const_int 32 [0x20]))
(const_int 80 [0x50])) [0
S16 A64]))
(expr_list:TD (use (mem:TD (plus:DI
(plus:DI (reg/f:DI 1 1)
(const_int 32
[0x20]))
(const_int 96 [0x60]))
[0 S16 A64]))
(expr_list:TD (use (mem:TD (plus:DI
(plus:DI (reg/f:DI 1 1)
(const_int 32
[0x20]))
(const_int 112
[0x70])) [0 S16 A64]))
(expr_list:TD (use (mem:TD
(plus:DI (plus:DI (reg/f:DI 1 1)
(const_int
32 [0x20]))
(const_int 128
[0x80])) [0 S16 A64]))
(expr_list:TD (use (mem:TD
(plus:DI (plus:DI (reg/f:DI 1 1)
(const_int 32 [0x20]))
(const_int
144 [0x90])) [0 S16 A64]))
(expr_list:TD (use
(mem:TD (plus:DI (plus:DI (reg/f:DI 1 1)
(const_int 32 [0x20]))
(const_int 160 [0xa0])) [0 S16 A64]))
(expr_list:TD (use
(mem:TD (plus:DI (plus:DI (reg/f:DI 1 1)
(const_int 32 [0x20]))
(const_int 176 [0xb0])) [0 S16 A64]))
(expr_list:TD
(use (mem:TD (plus:DI (plus:DI (reg/f:DI 1 1)
(const_int 32 [0x20]))
[Bug fortran/79876] [7 Regression] FAIL: libgomp.fortran/strassen.f90 -O execution test on x86_64-apple-darwin16
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79876 Thomas Koenig changed: What|Removed |Added Status|NEW |WAITING
[Bug sanitizer/79783] [7 Regression] ICE on valid C++ with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79783 --- Comment #2 from Martin Liška --- Author: marxin Date: Mon Mar 6 10:20:33 2017 New Revision: 245912 URL: https://gcc.gnu.org/viewcvs?rev=245912&root=gcc&view=rev Log: Fix ICE in use-after-scope w/ -fno-tree-dce (PR sanitize/79783). 2017-03-06 Martin Liska PR sanitize/79783 * asan.c (asan_expand_poison_ifn): Do not expand ASAN_POISON when having a SSA NAME w/o VAR_DECL assigned to it. 2017-03-06 Martin Liska PR sanitize/79783 * g++.dg/asan/pr79783.C: New test. Added: trunk/gcc/testsuite/g++.dg/asan/pr79783.C Modified: trunk/gcc/ChangeLog trunk/gcc/asan.c trunk/gcc/testsuite/ChangeLog
[Bug sanitizer/79783] [7 Regression] ICE on valid C++ with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79783 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Martin Liška --- Fixed.
[Bug gcov-profile/79891] Wrong count of line coverage in case of gcov -a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79891 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- I'll take a look.
[Bug tree-optimization/79894] [5/6/7 Regression] ICE in gfc_add_modify_loc, at fortran/trans.c:159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79894
--- Comment #1 from rguenther at suse dot de ---
On Mon, 6 Mar 2017, marxin at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79894
>
> Bug ID: 79894
>Summary: [5/6/7 Regression] ICE in gfc_add_modify_loc, at
> fortran/trans.c:159
>Product: gcc
>Version: 7.0
> Status: UNCONFIRMED
> Keywords: ice-on-valid-code
> Severity: normal
> Priority: P3
> Component: tree-optimization
> Assignee: unassigned at gcc dot gnu.org
> Reporter: marxin at gcc dot gnu.org
> CC: rguenth at gcc dot gnu.org
> Target Milestone: ---
>
> Starting from r217421, we ICE on:
>
> $ gcc
> /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/complex_intrinsic_6.f90
>
> -c
> /home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/complex_intrinsic_6.f90:35:0:
>
>z4 = asin(z4) ! { dg-error "Fortran 2008: COMPLEX argument" }
>
> internal compiler error: in gfc_add_modify_loc, at fortran/trans.c:159
> 0x73e520 gfc_add_modify_loc(unsigned int, stmtblock_t*, tree_node*,
> tree_node*)
> ../../gcc/fortran/trans.c:158
> 0x7783b1 gfc_trans_scalar_assign(gfc_se*, gfc_se*, gfc_typespec, bool, bool,
> bool)
> ../../gcc/fortran/trans-expr.c:8793
> 0x7899ea gfc_trans_assignment_1
> ../../gcc/fortran/trans-expr.c:10064
> 0x73ec87 trans_code
> ../../gcc/fortran/trans.c:1817
> 0x76fce8 gfc_generate_function_code(gfc_namespace*)
> ../../gcc/fortran/trans-decl.c:6306
> 0x6f7890 translate_all_program_units
> ../../gcc/fortran/parse.c:6070
> 0x6f7890 gfc_parse_file()
> ../../gcc/fortran/parse.c:6270
> 0x73b80f gfc_be_parse_file
> ../../gcc/fortran/f95-lang.c:204
So the FE builds (and simplifies)
COMPLEX_EXPR
(REALPART_EXPR (save_expr 0x76a697e0 (..),
IMAGPART_EXPR (save_expr 0x76a697e0
type
[Bug tree-optimization/79824] [7 Regression] Failure to peel for gaps leads to read beyond mapped memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79824
--- Comment #2 from Richard Biener ---
Ok, so in the SLP case this is actually safe because we only ever load vectors
that end up having at least a single element used (we do not load from unused
gaps). In the non-SLP case I botched up the patch, plain interleaving with
a single-element is rejected with gaps bigger than vector size (whoo!) and
with multi-element I failed to properly use 'first_stmt' for the alignment
test and thus we always get peeling for gaps.
Index: gcc/tree-vect-stmts.c
===
--- gcc/tree-vect-stmts.c (revision 245908)
+++ gcc/tree-vect-stmts.c (working copy)
@@ -1796,7 +1796,8 @@ get_group_load_store_type (gimple *stmt,
bool would_overrun_p = (gap != 0);
/* If the access is aligned an overrun is fine. */
if (would_overrun_p
- && aligned_access_p (STMT_VINFO_DATA_REF (stmt_info)))
+ && aligned_access_p
+ (STMT_VINFO_DATA_REF (vinfo_for_stmt (first_stmt
would_overrun_p = false;
if (!STMT_VINFO_STRIDED_P (stmt_info)
&& (can_overrun_p || !would_overrun_p)
makes
void __attribute__((noinline))
foo (TYPE *__restrict a, TYPE *__restrict b)
{
int n;
b = __builtin_assume_aligned (b, sizeof (TYPE) * 2);
a = __builtin_assume_aligned (a, sizeof (TYPE) * 2);
for (n = 0; n < COUNT; n++)
{
a[n] = b[n * 4] + b[n * 4 + 1];
}
}
fail on x86_64. So I am testing
Index: gcc/tree-vect-stmts.c
===
--- gcc/tree-vect-stmts.c (revision 245908)
+++ gcc/tree-vect-stmts.c (working copy)
@@ -1731,7 +1731,7 @@ get_group_load_store_type (gimple *stmt,
bool single_element_p = (stmt == first_stmt
&& !GROUP_NEXT_ELEMENT (stmt_info));
unsigned HOST_WIDE_INT gap = GROUP_GAP (vinfo_for_stmt (first_stmt));
- int nunits = TYPE_VECTOR_SUBPARTS (vectype);
+ unsigned nunits = TYPE_VECTOR_SUBPARTS (vectype);
/* True if the vectorized statements would access beyond the last
statement in the group. */
@@ -1794,9 +1794,13 @@ get_group_load_store_type (gimple *stmt,
/* If there is a gap at the end of the group then these optimizations
would access excess elements in the last iteration. */
bool would_overrun_p = (gap != 0);
- /* If the access is aligned an overrun is fine. */
+ /* If the access is aligned an overrun is fine, but only if the
+ overrun is not inside an unused vector (if the gap is as large
+or larger than a vector). */
if (would_overrun_p
- && aligned_access_p (STMT_VINFO_DATA_REF (stmt_info)))
+ && gap < nunits
+ && aligned_access_p
+ (STMT_VINFO_DATA_REF (vinfo_for_stmt (first_stmt
would_overrun_p = false;
if (!STMT_VINFO_STRIDED_P (stmt_info)
&& (can_overrun_p || !would_overrun_p)
[Bug tree-optimization/79894] [5/6/7 Regression] ICE in gfc_add_modify_loc, at fortran/trans.c:159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79894 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-03-06 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener --- Mine.
[Bug tree-optimization/79894] [5/6/7 Regression] ICE in gfc_add_modify_loc, at fortran/trans.c:159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79894
--- Comment #3 from Richard Biener ---
Note while we've tried to enforce this strict rules I don't think any checking
code ever come to fruit actually verifying that calling fold_* (.., type, ...)
produces a tree of TREE_TYPE () == type.
So it would be probably better for the Fortran FE to relax this assert
to test for equal TYPE_MAIN_VARIANT.
Checking code like the following (here only applying to match.pd foldings):
Index: gcc/fold-const.c
===
--- gcc/fold-const.c(revision 245908)
+++ gcc/fold-const.c(working copy)
@@ -7617,7 +7617,10 @@ fold_unary_loc (location_t loc, enum tre
tem = generic_simplify (loc, code, type, op0);
if (tem)
-return tem;
+{
+ gcc_checking_assert (TREE_TYPE (tem) == type);
+ return tem;
+}
if (TREE_CODE_CLASS (code) == tcc_unary)
{
@@ -9156,7 +9159,10 @@ fold_binary_loc (location_t loc,
tem = generic_simplify (loc, code, type, op0, op1);
if (tem)
-return tem;
+{
+ gcc_checking_assert (TREE_TYPE (tem) == type);
+ return tem;
+}
/* ARG0 is the first operand of EXPR, and ARG1 is the second operand.
@@ -11260,7 +11266,10 @@ fold_ternary_loc (location_t loc, enum t
tem = generic_simplify (loc, code, type, op0, op1, op2);
if (tem)
-return tem;
+{
+ gcc_checking_assert (TREE_TYPE (tem) == type);
+ return tem;
+}
/* Strip any conversions that don't change the mode. This is safe
for every expression, except for a comparison expression because
[Bug middle-end/79788] ICE in expand_expr_real_2, at expr.c:9557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79788 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Btw. can MPX be used for 32-bit binaries? Is it supported by ICC?
[Bug target/79890] ICE in s390_initial_elimination_offset, at config/s390/s390.c:10430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79890 --- Comment #1 from Dominik Vogt --- The ICE needs to be fixed, of course, by what is the idea behind executing the mips testsuite on s390?
[Bug middle-end/79788] ICE in expand_expr_real_2, at expr.c:9557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79788 --- Comment #3 from Uroš Bizjak --- (In reply to Martin Liška from comment #2) > Btw. can MPX be used for 32-bit binaries? Is it supported by ICC? MPX is supported on 32-bit i686, but not on x32.
[Bug c++/79821] [7 regression] SEGV in cc1plus compiling 64-bit stdc++.h.gch/O2g.gch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79821
--- Comment #7 from Jakub Jelinek ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #6)
> > --- Comment #5 from Jakub Jelinek ---
> > If you up from the ICE case up to gt_pch_nx_die_struct frame, it would be
> > interesting if you can figure out what x is would be print_die (x, stderr)
>
> I get
>
> DIE0: DW_TAG_member (f821cdb0)
> abbrev id: 0 offset: 0 mark: 0
> DW_AT_name: "is_specialized"
> DW_AT_decl_file:
> "/var/gcc/reghunt/pch-segv/36684/sparc-sun-solaris2.12/sparcv9/libstdc++-v3/
> include/limits" (0)
> DW_AT_decl_line: 385
> DW_AT_type: die -> 0 (fb6a4c60)
> DW_AT_external: 1
> DW_AT_declaration: 1
> DW_AT_const_value: floating-point or vector constant
> DW_AT_const_expr: 1
>
> for the innermost call to gt_pch_nx_die_struct.
Ah, so it will be most likely that
DW_AT_const_value: floating-point or vector constant
We have:
dw_vec_const GTY ((tag ("dw_val_class_vec"))) val_vec;
and
struct GTY(()) dw_vec_const {
unsigned char * GTY((atomic)) array;
unsigned length;
unsigned elt_size;
};
If we are calling strlen on that array, that is obviously incorrect, because
the array contains random bytes.
We need some way to tell GC that the array has length * elt_size size.
[Bug target/79890] ICE in s390_initial_elimination_offset, at config/s390/s390.c:10430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79890 --- Comment #2 from Martin Liška --- I do some basic fuzzing. This test-case just uses builtins, thus I consider it generic enough to report it.
[Bug target/79890] ICE in s390_initial_elimination_offset, at config/s390/s390.c:10430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79890 --- Comment #3 from Dominik Vogt --- Not reproduceable here with r245913. Is it gone with a recent Gcc? Gcc configured with --with-arch=zEC12 and compiled without explicit options: $ ~/src/gcc/install-master/bin/gcc ~/src/gcc/gcc/testsuite/gcc.target/mips/call-saved-7.c -march=zEC12 -S (Complains about missing main function without "-S")
[Bug target/79890] ICE in s390_initial_elimination_offset, at config/s390/s390.c:10430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79890 --- Comment #4 from Martin Liška --- I see the ICE with cross-compiler (on x86_64-linux-gnu), compiled with --target=s390x-linux-gnu. $ s390x-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=s390x-linux-gnu-gcc COLLECT_LTO_WRAPPER=/home/marxin/BIG/buildbot/slave/install/gcc-6fe883d64cf228785f3d0a4e24f9138c8958c93b/bin/../lib/gcc/s390x-linux-gnu/7.0.1/lto-wrapper Target: s390x-linux-gnu Configured with: ./../configure --enable-linker-build-id --prefix=/home/marxin/BIG/buildbot/slave/gcc-master-build-s390x/../install/gcc-6fe883d64cf228785f3d0a4e24f9138c8958c93b --target=s390x-linux-gnu --with-as=/usr/bin/s390x-suse-linux-as --disable-bootstrap Thread model: posix gcc version 7.0.1 20170305 (experimental) (GCC)
[Bug libstdc++/79862] Compilation error while building libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79862 --- Comment #5 from Sumit --- (In reply to Sumit from comment #4) > (In reply to Andrew Pinski from comment #3) > > --disable-hosted-libstdcxx \ > > > > That is more likely the cause. non-hosted libstdc++ is not well tested. > Hi Andrew, I have tried without --disable-hosted-libstdcxx and still the same error. In file included from ../../../../gcc-4.8/libstdc++-v3/libsupc++/array_type_info.cc:24:0: ../../../../gcc-4.8/libstdc++-v3/libsupc++/tinfo.h:25:20: fatal error: typeinfo: No such file or directory #include "typeinfo"
[Bug inline-asm/79880] Gcc refuses to encode vpgatherdd instruction (x86-64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79880
--- Comment #4 from Petr ---
In this case, DWORD PTR is redundant, nasm and yasm is fine with the syntax I
posted as well.
It's a simplified test just to show that it won't pass.
Try:
__asm(".intel_syntax\n"
"vpgatherdd xmm4, dword ptr [r13 + xmm3], xmm4\n"
".att_syntax\n");
I will end up reporting the same error.
[Bug c++/79821] [7 regression] SEGV in cc1plus compiling 64-bit stdc++.h.gch/O2g.gch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79821 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-03-06 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #8 from Jakub Jelinek --- Created attachment 40891 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40891&action=edit gcc7-pr79821.patch Untested fix. This way GC will not consider array to be a string, but array of objects that don't contain pointers.
[Bug target/79812] [7 Regression] ICE in simplify_binary_operation_1, at simplify-rtx.c:3586
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79812 --- Comment #4 from Jakub Jelinek --- Author: jakub Date: Mon Mar 6 11:35:58 2017 New Revision: 245915 URL: https://gcc.gnu.org/viewcvs?rev=245915&root=gcc&view=rev Log: PR target/79812 * config/i386/sse.md (VI8F_256_512): Remove mode iterator. (_perm): Rename to ... (avx2_perm): ... this. Use VI8F_256 iterator instead of VI8F_256_512. (_perm_mask): Rename to ... (avx512vl_perm_mask): ... this. Use VI8F_256 iterator instead of VI8F_256_512. (_perm_1): Rename to ... (avx2_perm_1): New define_expand. (avx512f_perm_mask): Likewise. (avx512f_perm_1): New define_insn. (_vec_dup_1): Fix up vec_select mode. * gcc.target/i386/avx512f-vpermq-imm-3.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/avx512f-vpermq-imm-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog
[Bug inline-asm/79880] Gcc refuses to encode vpgatherdd instruction (x86-64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79880 --- Comment #5 from Jakub Jelinek --- Ah, if you want to avoid the %xmm4, %r13, %xmm3, etc., you need .intel_syntax noprefix. And, the insn is invalid anyway, because you can't have the same mask and destination. In any case, this has nothing to do with gcc, that just passes the text through to gas.
[Bug target/79812] [7 Regression] ICE in simplify_binary_operation_1, at simplify-rtx.c:3586
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79812 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug c++/64574] ICE (stack overflow SEGV) with bad template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64574 --- Comment #1 from Paolo Carlini --- This is already fixed in trunk. I'm adding a testcase and closing the bug.
[Bug c++/79821] [7 regression] SEGV in cc1plus compiling 64-bit stdc++.h.gch/O2g.gch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79821
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #7 from Jakub Jelinek ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #6)
[...]
> Ah, so it will be most likely that
> DW_AT_const_value: floating-point or vector constant
>
> We have:
> dw_vec_const GTY ((tag ("dw_val_class_vec"))) val_vec;
> and
> struct GTY(()) dw_vec_const {
> unsigned char * GTY((atomic)) array;
> unsigned length;
> unsigned elt_size;
> };
>
> If we are calling strlen on that array, that is obviously incorrect, because
> the array contains random bytes.
> We need some way to tell GC that the array has length * elt_size size.
I'd already wondered about this:
(gdb) display/i $pc
1: x/i $pc
=> 0xfed6c634 : ld [ %o2 ], %o1
(gdb) p/x $o2
$1 = 0xf940
#1 0x009e0208 in gt_pch_note_object (obj=0xf938,
note_ptr_cookie=0xf938,
note_ptr_fn=0xcfe544 ) at /var/gcc/reghunt/trunk/gcc/ggc-common.c:285
285 (*slot)->size = strlen ((const char *)obj) + 1;
(gdb) p obj
$2 = (void *) 0xf938
(gdb) p (char *)obj
$4 = 0xf938 "\001\257\257\257\257\257\257\257"
where obj doesn't look like a string ;-)
[Bug c++/79821] [7 regression] SEGV in cc1plus compiling 64-bit stdc++.h.gch/O2g.gch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79821 --- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #8 from Jakub Jelinek --- > Created attachment 40891 > --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40891&action=edit > gcc7-pr79821.patch > > Untested fix. This way GC will not consider array to be a string, but array > of > objects that don't contain pointers. I'd just applied your patch on top of the failing rev: stage1 now completes successfully. I can also run a full bootstrap if that's helpful. Thanks. Rainer
[Bug c++/64574] ICE (stack overflow SEGV) with bad template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64574 --- Comment #2 from paolo at gcc dot gnu.org --- Author: paolo Date: Mon Mar 6 11:54:37 2017 New Revision: 245916 URL: https://gcc.gnu.org/viewcvs?rev=245916&root=gcc&view=rev Log: 2017-03-06 Paolo Carlini PR c++/64574 * g++.dg/template/crash125.C: New. Added: trunk/gcc/testsuite/g++.dg/template/crash125.C Modified: trunk/gcc/testsuite/ChangeLog
[Bug c++/64574] ICE (stack overflow SEGV) with bad template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64574 Paolo Carlini changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #3 from Paolo Carlini --- Done.
[Bug inline-asm/79880] Gcc refuses to encode vpgatherdd instruction (x86-64)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79880 --- Comment #6 from Petr --- Ok, that's fair enough. I didn't know GCC needs an additional option to switch to fully compatible Intel syntax. The code that I posted works fine in clang, so sorry about that. And yes, the instruction will #UD, but that was the point, initially :)
[Bug c++/79821] [7 regression] SEGV in cc1plus compiling 64-bit stdc++.h.gch/O2g.gch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79821 --- Comment #11 from Jakub Jelinek --- (In reply to r...@cebitec.uni-bielefeld.de from comment #10) > I'd just applied your patch on top of the failing rev: stage1 now > completes successfully. Glad to hear that. > I can also run a full bootstrap if that's helpful. If you can, it is useful. I'll do a x86_64/i686-linux bootstrap as well later today.
[Bug tree-optimization/79894] [5/6/7 Regression] ICE in gfc_add_modify_loc, at fortran/trans.c:159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79894 --- Comment #4 from Richard Biener --- OTOH this is really GIGO - the frontend feeds us with incompatible types (there's only one complex type per scalar type). So I am testing Index: gcc/fortran/trans.c === --- gcc/fortran/trans.c (revision 245913) +++ gcc/fortran/trans.c (working copy) @@ -151,11 +151,11 @@ gfc_add_modify_loc (location_t loc, stmt tree t1, t2; t1 = TREE_TYPE (rhs); t2 = TREE_TYPE (lhs); - /* Make sure that the types of the rhs and the lhs are the same + /* Make sure that the types of the rhs and the lhs are compatible for scalar assignments. We should probably have something similar for aggregates, but right now removing that check just breaks everything. */ - gcc_checking_assert (t1 == t2 + gcc_checking_assert (TYPE_MAIN_VARIANT (t1) == TYPE_MAIN_VARIANT (t2) || AGGREGATE_TYPE_P (TREE_TYPE (lhs))); tmp = fold_build2_loc (loc, MODIFY_EXPR, void_type_node, lhs, instead.
[Bug rtl-optimization/79910] New: [7 Regression] wrong code with -O -fweb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79910
Bug ID: 79910
Summary: [7 Regression] wrong code with -O -fweb
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Target Milestone: ---
Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu
Created attachment 40892
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40892&action=edit
reduced testcase
Output:
$ x86_64-pc-linux-gnu-gcc -O -fweb testcase.c
$ ./a.out
Aborted
$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-245841-checking-yes-rtl-df-extra-nographite-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/7.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--without-cloog --without-ppl --without-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-245841-checking-yes-rtl-df-extra-nographite-amd64
Thread model: posix
gcc version 7.0.1 20170302 (experimental) (GCC)
There seems to be a problem in the combine pass.
Before .combine, there is:
...
(insn 16 14 17 2 (parallel [
(set (reg/v:DI 100 [ bD.1802 ])
(lshiftrt:DI (reg:DI 107)
(reg:QI 110)))
(clobber (reg:CC 17 flags))
]) "testcase.c":11 544 {*lshrdi3_1}
(expr_list:REG_DEAD (reg:QI 110)
(expr_list:REG_DEAD (reg:DI 107)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)
...
(insn 28 27 30 2 (parallel [
(set (reg:DI 128 [ _6 ])
(minus:DI (reg:DI 111 [ p1D.1798 ])
(reg:DI 119)))
(clobber (reg:CC 17 flags))
]) "testcase.c":12 272 {*subdi_1}
(expr_list:REG_DEAD (reg:DI 119)
(expr_list:REG_DEAD (reg:DI 111 [ p1D.1798 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)
(insn 30 28 31 2 (parallel [
(set (reg:SI 120)
(and:SI (subreg:SI (reg/v:DI 100 [ bD.1802 ]) 0)
(const_int 31 [0x1f])))
(clobber (reg:CC 17 flags))
]) "testcase.c":13 389 {*andsi_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn 31 30 32 2 (set (reg:SI 121)
(const_int 4 [0x4])) "testcase.c":13 82 {*movsi_internal}
(nil))
(insn 32 31 33 2 (parallel [
(set (reg/v:SI 106 [ p2D.1799 ])
(lshiftrt:SI (reg:SI 121)
(subreg:QI (reg:SI 120) 0)))
(clobber (reg:CC 17 flags))
]) "testcase.c":13 542 {*lshrsi3_1}
(expr_list:REG_DEAD (reg:SI 121)
(expr_list:REG_DEAD (reg:SI 120)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUAL (lshiftrt:SI (const_int 4 [0x4])
(subreg:QI (reg:SI 120) 0))
(nil))
...
But .combine shows:
...
Trying 27, 28 -> 33:
...
Successfully matched this instruction:
(set (reg:QI 128 [ _6 ])
(plus:QI (subreg:QI (reg:DI 111 [ p1D.1798 ]) 0)
(subreg:QI (reg/v:DI 100 [ bD.1802 ]) 0)))
Successfully matched this instruction:
(set (reg:QI 123 [ p1D.1798 ])
(plus:QI (reg:QI 128 [ _6 ])
(subreg:QI (reg:DI 92 [ _6 ]) 0)))
allowing combination of insns 27, 28 and 33
...
Trying 16, 32 -> 35:
...
Successfully matched this instruction:
(set (reg/v:DI 100 [ bD.1802 ])
(lshiftrt:DI (reg:DI 107)
(reg:QI 110)))
Successfully matched this instruction:
(set (reg:SI 125 [ p2D.1799 ])
(const_int 0 [0]))
allowing combination of insns 16, 32 and 35
...
So after .combine, there is:
...
(insn 28 27 30 2 (parallel [
(set (reg:QI 128 [ _6 ])
(plus:QI (subreg:QI (reg:DI 111 [ p1D.1798 ]) 0)
(subreg:QI (reg/v:DI 100 [ bD.1802 ]) 0)))
(clobber (reg:CC 17 flags))
]) "testcase.c":12 219 {*addqi_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_DEAD (reg:DI 111 [ p1D.1798 ])
(nil
(note 30 28 31 2 NOTE_INSN_DELETED)
(note 31 30 32 2 NOTE_INSN_DELETED)
(insn 32 31 33 2 (parallel [
(set (reg/v:DI 100 [ bD.1802 ])
(lshiftrt:DI (reg:DI 107)
(reg:QI 110)))
(clobber (reg:CC 17 flags))
]) "testcase.c":13 544 {*lshrdi3_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_DEAD (reg:DI 107)
(expr_list:REG_DEAD (reg:QI 110)
[Bug rtl-optimization/79910] [7 Regression] wrong code with -O -fweb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79910 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2017-03-06 Known to work||6.3.1 Target Milestone|--- |7.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed (probably latent).
[Bug target/79911] New: VEC_SELECT bugs in arm neon patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79911 Bug ID: 79911 Summary: VEC_SELECT bugs in arm neon patterns Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- I've recently posted http://gcc.gnu.org/ml/gcc-patches/2017-03/msg00183.html with some extra verification of sanity of md patterns (based on assertions simplify-rtx.c does for VEC_SELECT as well as documentation requiring it). With this patch make s-recog fails on arm-linux: ../../gcc/config/arm/neon.md:1338:1: element mode mismatch between vec_select HImode and its operand QImode ../../gcc/config/arm/neon.md:1338:1: element mode mismatch between vec_select SImode and its operand QImode ../../gcc/config/arm/neon.md:1338:1: element mode mismatch between vec_select QImode and its operand HImode ../../gcc/config/arm/neon.md:1338:1: element mode mismatch between vec_select SImode and its operand HImode ../../gcc/config/arm/neon.md:1338:1: element mode mismatch between vec_select QImode and its operand SImode ../../gcc/config/arm/neon.md:1338:1: element mode mismatch between vec_select HImode and its operand SImode ../../gcc/config/arm/neon.md:1353:1: element mode mismatch between vec_select HImode and its operand QImode ../../gcc/config/arm/neon.md:1353:1: element mode mismatch between vec_select SImode and its operand QImode ../../gcc/config/arm/neon.md:1353:1: element mode mismatch between vec_select QImode and its operand HImode ../../gcc/config/arm/neon.md:1353:1: element mode mismatch between vec_select SImode and its operand HImode ../../gcc/config/arm/neon.md:1353:1: element mode mismatch between vec_select QImode and its operand SImode ../../gcc/config/arm/neon.md:1353:1: element mode mismatch between vec_select HImode and its operand SImode ../../gcc/config/arm/neon.md:1407:1: element mode mismatch between vec_select HImode and its operand QImode ../../gcc/config/arm/neon.md:1407:1: element mode mismatch between vec_select SImode and its operand QImode ../../gcc/config/arm/neon.md:1407:1: element mode mismatch between vec_select QImode and its operand HImode ../../gcc/config/arm/neon.md:1407:1: element mode mismatch between vec_select SImode and its operand HImode ../../gcc/config/arm/neon.md:1407:1: element mode mismatch between vec_select QImode and its operand SImode ../../gcc/config/arm/neon.md:1407:1: element mode mismatch between vec_select HImode and its operand SImode ../../gcc/config/arm/neon.md:1422:1: element mode mismatch between vec_select HImode and its operand QImode ../../gcc/config/arm/neon.md:1422:1: element mode mismatch between vec_select SImode and its operand QImode ../../gcc/config/arm/neon.md:1422:1: element mode mismatch between vec_select QImode and its operand HImode ../../gcc/config/arm/neon.md:1422:1: element mode mismatch between vec_select SImode and its operand HImode ../../gcc/config/arm/neon.md:1422:1: element mode mismatch between vec_select QImode and its operand SImode ../../gcc/config/arm/neon.md:1422:1: element mode mismatch between vec_select HImode and its operand SImode
[Bug target/79912] New: [7 regression] LRA unable to generate reloads after r245655
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79912
Bug ID: 79912
Summary: [7 regression] LRA unable to generate reloads after
r245655
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: npickito at gmail dot com
CC: matthew.fortune at imgtec dot com, vmakarov at redhat dot
com
Target Milestone: ---
Target: riscv32-unknown-linux-gnu
Created attachment 40893
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40893&action=edit
vfscanf.i
It's ICE after r245655, and work if revert it.
Configure: --target=riscv32-unknown-linux-gnu --with-abi=ilp32d
--with-arch=rv32imafd
riscv32-elf-gcc vfscanf.i -O2
vfscanf.c: In function ‘_IO_vfscanf_internal’:
vfscanf.c:3050:1: error: unable to generate reloads for:
(insn 11026 11523 5651 1080 (set (reg:QI 3515)
(mem/c:QI (plus:SI (reg/f:SI 65 frame)
(const_int -1568 [0xf9e0])) [65 %sfp+-1504 S1
A32])) "vfscanf.c":266 138 {*movqi_internal}
(expr_list:REG_DEAD (reg:QI 3956)
(nil)))
vfscanf.c:3050:1: internal compiler error: in curr_insn_transform, at
lra-constraints.c:3785
0xa9f028 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../../src/gcc/trunk/gcc/rtl-error.c:108
0x9a1d91 curr_insn_transform
../../../src/gcc/trunk/gcc/lra-constraints.c:3785
0x9a3016 lra_constraints(bool)
../../../src/gcc/trunk/gcc/lra-constraints.c:4754
0x98cd0c lra(_IO_FILE*)
../../../src/gcc/trunk/gcc/lra.c:2392
0x942b6b do_reload
../../../src/gcc/trunk/gcc/ira.c:5451
0x942b6b execute
../../../src/gcc/trunk/gcc/ira.c:5635
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79912 --- Comment #1 from Kito Cheng --- Update for command to reproduce: riscv32-unknown-linux-gnu-gcc vfscanf.E.i -O2
[Bug target/79911] VEC_SELECT bugs in arm neon patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79911 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-03-06 Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot gnu.org Target Milestone|--- |7.0 Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- I'll take a look
[Bug target/79913] New: VEC_SELECT bugs in aarch64 patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79913 Bug ID: 79913 Summary: VEC_SELECT bugs in aarch64 patterns Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- I've recently posted http://gcc.gnu.org/ml/gcc-patches/2017-03/msg00183.html with some extra verification of sanity of md patterns (based on assertions simplify-rtx.c does for VEC_SELECT as well as documentation requiring it). With this patch make s-recog fails on aarch64-linux: ../../gcc/config/aarch64/aarch64-simd.md:79:1: DImode of first vec_select operand is not a vector mode ../../gcc/config/aarch64/aarch64-simd.md:79:1: DFmode of first vec_select operand is not a vector mode ../../gcc/config/aarch64/aarch64-simd.md:588:1: DImode of first vec_select operand is not a vector mode ../../gcc/config/aarch64/aarch64-simd.md:588:1: DFmode of first vec_select operand is not a vector mode ../../gcc/config/aarch64/aarch64-simd.md:3192:1: DFmode of first vec_select operand is not a vector mode
[Bug target/79913] VEC_SELECT bugs in aarch64 patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79913 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-03-06 Assignee|unassigned at gcc dot gnu.org |ktkachov at gcc dot gnu.org Target Milestone|--- |7.0 Ever confirmed|0 |1 --- Comment #1 from ktkachov at gcc dot gnu.org --- I'll have a look
[Bug target/79914] New: VEC_SELECT bugs in mips patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79914 Bug ID: 79914 Summary: VEC_SELECT bugs in mips patterns Product: gcc Version: 7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: jakub at gcc dot gnu.org Target Milestone: --- I've recently posted http://gcc.gnu.org/ml/gcc-patches/2017-03/msg00183.html with some extra verification of sanity of md patterns (based on assertions simplify-rtx.c does for VEC_SELECT as well as documentation requiring it). With this patch make s-recog fails on mips-linux: ../../gcc/config/mips/mips-msa.md:1219:1: vec_select parallel with 2 elements, expected 4 ../../gcc/config/mips/mips-msa.md:1219:1: vec_select parallel with 2 elements, expected 4 ../../gcc/config/mips/mips-msa.md:1219:1: vec_select parallel with 2 elements, expected 4 ../../gcc/config/mips/mips-msa.md:1219:1: vec_select parallel with 2 elements, expected 4 ../../gcc/config/mips/mips-msa.md:1307:1: vec_select parallel with 2 elements, expected 4 ../../gcc/config/mips/mips-msa.md:1307:1: vec_select parallel with 2 elements, expected 4 ../../gcc/config/mips/mips-msa.md:1307:1: vec_select parallel with 2 elements, expected 4 ../../gcc/config/mips/mips-msa.md:1307:1: vec_select parallel with 2 elements, expected 4 ../../gcc/config/mips/mips-msa.md:1401:1: vec_select parallel with 2 elements, expected 4 ../../gcc/config/mips/mips-msa.md:1401:1: vec_select parallel with 2 elements, expected 4 ../../gcc/config/mips/mips-msa.md:1401:1: vec_select parallel with 2 elements, expected 4 ../../gcc/config/mips/mips-msa.md:1401:1: vec_select parallel with 2 elements, expected 4
[Bug target/79914] VEC_SELECT bugs in mips patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79914 mpf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-03-06 Assignee|unassigned at gcc dot gnu.org |prachigodbole at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from mpf at gcc dot gnu.org --- Prachi, could you confirm your patch in... https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00229.html is the fix for these. The patch to fix them happens to have crossed over with being reported.
[Bug target/79914] VEC_SELECT bugs in mips patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79914 prachee.godbole at gmail dot com changed: What|Removed |Added CC||prachee.godbole at gmail dot com --- Comment #2 from prachee.godbole at gmail dot com --- Yes, the patch in https://gcc.gnu.org/ml/gcc-patches/2017-03/msg00229.html fixes this bug.
[Bug target/79912] [7 regression] LRA unable to generate reloads after r245655
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79912 mpf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2017-03-06 CC||mpf at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpf at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from mpf at gcc dot gnu.org --- I'll take a look shortly. It may be a day to get initial feedback so I can build tools and check dumps and RISCV description in GCC.
[Bug fortran/79894] [5/6/7 Regression] ICE in gfc_add_modify_loc, at fortran/trans.c:159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79894 --- Comment #5 from Richard Biener --- Author: rguenth Date: Mon Mar 6 12:48:54 2017 New Revision: 245919 URL: https://gcc.gnu.org/viewcvs?rev=245919&root=gcc&view=rev Log: 2017-03-06 Richard Biener PR fortran/79894 * trans.c (gfc_add_modify_loc): Weaken assert. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans.c
[Bug target/79890] ICE in s390_initial_elimination_offset, at config/s390/s390.c:10430
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79890 --- Comment #5 from Dominik Vogt --- Reproduceable on a zEC12 with $ ./configure --enable-languages=c --disable-bootstrap --disable-multilib --enable-checking --with-system-zlib --enable-threads=posix --enable-__cxa_atexit --enable-gnu-indirect-function
[Bug target/79893] ICE in s390_adjust_builtin_arglist in gcc/config/s390/s390-c.c:679
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79893 --- Comment #1 from Dominik Vogt --- Confirmed.
[Bug target/79895] ICE in extract_constrain_insn, at recog.c:2213
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79895 --- Comment #1 from Dominik Vogt --- Confirmed.
[Bug target/79904] ICE in annotate_constant_pool_refs, at config/s390/s390.c:7909
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79904 --- Comment #1 from Dominik Vogt --- Confirmed.
[Bug rtl-optimization/79910] [7 Regression] wrong code with -O -fweb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79910 Martin Liška changed: What|Removed |Added CC||bernds at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Started with r244817: PR rtl-optimization/71724 * combine.c (if_then_else_cond): Look for situations where it is beneficial to undo the work of one of the recursive calls.
[Bug target/79893] ICE in s390_adjust_builtin_arglist in gcc/config/s390/s390-c.c:679
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79893
--- Comment #2 from Dominik Vogt ---
A small test program that reproduces the crash:
--
#include
void foo(signed char *p, int i) {
vec_load_bndry(p, i);
}
--
$ gcc -mzvector -mvx -march=z13 -S
[Bug rtl-optimization/79910] [7 Regression] wrong code with -O -fweb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79910 Bernd Schmidt changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |bernds at gcc dot gnu.org --- Comment #3 from Bernd Schmidt --- Investigating.
