[Bug inline-asm/97667] [11 Regression] a bug in asm_operand_ok() recog.c:1801
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97667 Jakub Jelinek changed: What|Removed |Added CC||crazylht at gmail dot com, ||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- I think we have a dup of this already.
[Bug middle-end/97656] Specify that there is no address arithmetic on a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97656 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- (In reply to Richard Biener from comment #1) > Maybe use > > ". WT" > > for this? And the discussed 'a'...'z' for the "upper case" '1'...'9', both > to denote the range is exact? Note we discussed that we can this way > specify a must-def but here it's a may-def but with known offset. Guess > must vs. may would rather be another first letter like 'D'? (and only > 'direct' supported there obviously) And the upper case size specification > means > at zero offset? Well, at least in the above case it is not just 0 offset, but any access from the offset 0 (inclusive) to size of the type pointed by the argument (exclusive). E.g. if it is a structure, SRA must be surely be able to split it off and use MEM_REFs even with non-zero offsets.
[Bug c++/97639] [c++20,-fconcepts-ts] ICE: gcc_assert in tsubst, cp/pt.c:15464
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97639 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-11-02 CC||jason at gcc dot gnu.org, ||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Confirmed, it's there since the beginning r10-3735-gcb57504a55015891.
[Bug middle-end/97656] Specify that there is no address arithmetic on a pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97656 --- Comment #3 from rguenther at suse dot de --- On Mon, 2 Nov 2020, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97656 > > Jakub Jelinek changed: > >What|Removed |Added > > CC||jakub at gcc dot gnu.org > > --- Comment #2 from Jakub Jelinek --- > (In reply to Richard Biener from comment #1) > > Maybe use > > > > ". WT" > > > > for this? And the discussed 'a'...'z' for the "upper case" '1'...'9', both > > to denote the range is exact? Note we discussed that we can this way > > specify a must-def but here it's a may-def but with known offset. Guess > > must vs. may would rather be another first letter like 'D'? (and only > > 'direct' supported there obviously) And the upper case size specification > > means > > at zero offset? > > Well, at least in the above case it is not just 0 offset, but any access from > the offset 0 (inclusive) to size of the type pointed by the argument > (exclusive). > E.g. if it is a structure, SRA must be surely be able to split it off and use > MEM_REFs even with non-zero offsets. Yes, we can only model the effect in the caller not constraints to the actual IL in the callee.
[Bug tree-optimization/97650] ICE: tree check: expected ssa_name, have addr_expr in vect_get_and_check_slp_defs, at tree-vect-slp.c:533 with "-Os -ftree-slp-vectorize -fallow-store-data-races"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97650 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #2 from Martin Liška --- Just for the record, started with r11-4428-g4a369d199bf2f34e.
[Bug fortran/97655] gcc/fortran/openmp.c:4133: possible cut'n'paste error ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97655 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Oh, missed that totally, seems atomics changed a lot in 5.1 So I think it is ok to handle them separately, but I'd strongly prefer to ensure that we reject the forms invalid in 5.0 even if they will be valid in 5.1, at least until we get most of the 5.0 support done (perhaps sans OMPD/OMPT).
[Bug fortran/97655] gcc/fortran/openmp.c:4133: possible cut'n'paste error ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97655 Martin Liška changed: What|Removed |Added Last reconfirmed||2020-11-02 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug sanitizer/97657] libsanitizer/sanitizer_common/sanitizer_posix.cpp:162: no code to deal with bad mode ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97657 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-11-02 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Martin Liška --- I can take a look.
[Bug analyzer/97668] [11 Regression] ICE in cmp_cst, at analyzer/svalue.cc:283
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97668 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-11-02 CC||marxin at gcc dot gnu.org --- Comment #1 from Martin Liška --- Confirmed, started with r11-4435-gbf1b5dae440de888.
[Bug inline-asm/97667] [11 Regression] a bug in asm_operand_ok() recog.c:1801
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97667 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-11-02 --- Comment #2 from Martin Liška --- Likely dup of PR97540.
[Bug inline-asm/97667] [11 Regression] a bug in asm_operand_ok() recog.c:1801
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97667 --- Comment #3 from Hongtao.liu --- (In reply to Martin Liška from comment #2) > Likely dup of PR97540. Yes, it should be.
[Bug fortran/96886] [10 Regression] valgrind error with optional character argument of unknown length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96886 Martin Liška changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Martin Liška --- Closing then.
[Bug inline-asm/97667] [11 Regression] a bug in asm_operand_ok() recog.c:1801
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97667 Martin Liška changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #4 from Martin Liška --- Dup. *** This bug has been marked as a duplicate of bug 97540 ***
[Bug rtl-optimization/97540] [11 Regression] ICE in lra_set_insn_recog_data, at lra.c:1004 since r11-4202-g4de7b010038933dd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97540 Martin Liška changed: What|Removed |Added CC||huntazhang at tencent dot com --- Comment #6 from Martin Liška --- *** Bug 97667 has been marked as a duplicate of this bug. ***
[Bug inline-asm/97667] [11 Regression] a bug in asm_operand_ok() recog.c:1801
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97667 --- Comment #5 from huntazhang --- YES DUP.
[Bug debug/97669] New: Section .debug_info.dwo contains standard_opcode_lenghts array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97669 Bug ID: 97669 Summary: Section .debug_info.dwo contains standard_opcode_lenghts array Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: vries at gcc dot gnu.org Target Milestone: --- In the dwarf v5 standard we read: ... .debug_line.dwo - Contains specialized line number tables for the type units in the .debug_info.dwo section. These tables contain only the directory and filename lists needed to interpret DW_AT_decl_file attributes in the debugging information entries. Actual line number tables remain in the .debug_line section, and remain in the relocatable object (.o) files. ... Now consider: ... $ gcc-11 \ -g -gsplit-dwarf \ ~/hello.c \ -v -save-temps \ -dA ... In file hello.s, in section .debug_line.dwo, we have the standard_opcode_lenghts array: ... .byte 0xd # Special Opcode Base .byte 0 # opcode: 0x1 has 0 args .byte 0x1 # opcode: 0x2 has 1 args .byte 0x1 # opcode: 0x3 has 1 args .byte 0x1 # opcode: 0x4 has 1 args .byte 0x1 # opcode: 0x5 has 1 args .byte 0 # opcode: 0x6 has 0 args .byte 0 # opcode: 0x7 has 0 args .byte 0 # opcode: 0x8 has 0 args .byte 0x1 # opcode: 0x9 has 1 args .byte 0 # opcode: 0xa has 0 args .byte 0 # opcode: 0xb has 0 args .byte 0x1 # opcode: 0xc has 1 args ... But given that this is a "specialized line number table", there's no line number program, and because of that, the standard_opcode_lengths array is unnecessary. [ And then there's the fact that actually the whole .debug_line.dwo is unnecessary, given that there are no type units in .debug_info.dwo. ]
[Bug debug/97669] Section .debug_info.dwo contains standard_opcode_lenghts array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97669 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-11-02 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Confirmed.
[Bug d/97644] FAIL: gdc.dg/gdc204.d due to ICE in finish_thunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97644 --- Comment #7 from Iain Buclaw --- Created attachment 49485 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49485&action=edit workaround pr97644 Current workaround I'm using locally for the time being is to call thunk_info::process_early_thunks if the particular branch where this ICE happens is hit.
[Bug tree-optimization/97650] ICE: tree check: expected ssa_name, have addr_expr in vect_get_and_check_slp_defs, at tree-vect-slp.c:533 with "-Os -ftree-slp-vectorize -fallow-store-data-races"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97650 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Richard Biener --- Fixed.
[Bug tree-optimization/97650] ICE: tree check: expected ssa_name, have addr_expr in vect_get_and_check_slp_defs, at tree-vect-slp.c:533 with "-Os -ftree-slp-vectorize -fallow-store-data-races"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97650 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:a159081ad4259c42456bd3dc2b637747c373c5a5 commit r11-4602-ga159081ad4259c42456bd3dc2b637747c373c5a5 Author: Richard Biener Date: Mon Nov 2 08:59:02 2020 +0100 tree-optimization/97650 - fix ICE in vect_get_and_check_slp_defs I was mistaken to treat vect_external_def as only applying to SSA_NAME defs, so check for that. 2020-11-02 Richard Biener PR tree-optimization/97650 * tree-vect-slp.c (vect_get_and_check_slp_defs): Check for SSA_NAME before checking SSA_NAME_IS_DEFAULT_DEF. * gcc.dg/vect/bb-slp-pr97650.c: New testcase.
[Bug tree-optimization/97558] [11 Regression] ICE in vect_slp_analyze_node_operations, at tree-vect-slp.c:3342 since r11-4227-g655f7f0fb7c9aa2f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97558 --- Comment #6 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:5b41d673ad96dd2f9a7dec3877d0381320ccadb1 commit r11-4603-g5b41d673ad96dd2f9a7dec3877d0381320ccadb1 Author: Richard Biener Date: Mon Nov 2 09:38:09 2020 +0100 tree-optimization/97558 - avoid SLP analyzing irrelevant stmts This avoids analyzing reductions that are not relevant (thus dead) which eventually will lead into crashes because the participating stmts meta is not analyzed. For this to work the patch also properly removes reduction groups that are not uniformly recognized as patterns. 2020-11-02 Richard Biener PR tree-optimization/97558 * tree-vect-loop.c (vect_fixup_scalar_cycles_with_patterns): Check for any mismatch in pattern vs. non-pattern and dissolve the group if there is one. * tree-vect-slp.c (vect_analyze_slp_instance): Avoid analyzing not relevant reductions. (vect_analyze_slp): Avoid analyzing not relevant reduction groups. * gcc.dg/vect/pr97558.c: New testcase.
[Bug tree-optimization/97558] [11 Regression] ICE in vect_slp_analyze_node_operations, at tree-vect-slp.c:3342 since r11-4227-g655f7f0fb7c9aa2f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97558 --- Comment #7 from Richard Biener --- The ICE in comment#5 remains.
[Bug tree-optimization/97505] [11 Regression] ICE in extract_range_basic, at vr-values.c:1439 since r11-4130-g16e4f1ad44e3c00b8b73c9e4ade3d236ea7044a8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97505 --- Comment #7 from CVS Commits --- The master branch has been updated by Aldy Hernandez : https://gcc.gnu.org/g:f3a3327fe3d4e20a8fe863c2a3ad949864191f5d commit r11-4604-gf3a3327fe3d4e20a8fe863c2a3ad949864191f5d Author: Aldy Hernandez Date: Mon Nov 2 11:34:47 2020 +0100 Add test for PR97505. gcc/testsuite/ChangeLog: PR tree-optimization/97505 * gcc.dg/pr97505.c: New test.
[Bug bootstrap/57076] @ in the src directory name causes failure while building of gcc.info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57076 --- Comment #7 from Francois-Xavier Coudert --- Updated patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557728.html
[Bug c++/97663] [c++17] Function with return type 'unsigned' in nested namespace misinterpreted as deduction guide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97663 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Started with r7-6608-ga56c0ac08242269bbcc4bd1f480eda2378336776
[Bug c++/97670] New: [11 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'mem_ref' in finistree check: expected tree that contains 'decl minimal' structure, hav
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97670
Bug ID: 97670
Summary: [11 Regression] ICE: tree check: expected tree that
contains 'decl minimal' structure, have 'mem_ref' in
finistree check: expected tree that contains 'decl
minimal' structure, have 'mem_ref' in
finish_omp_clauses, at ch_omp_clauses, at
cp/semantics.c:8251
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, openmp
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
g++-11.0.0-alpha20201101 snapshot (g:590febb5f6624f78b36402a7c9a9c318978f1efa)
ICEs when compiling the following testcase, reduced from
test/OpenMP/for_reduction_codegen_UDR.cpp from the clang 10.0.1 test suite, w/
-fopenmp:
enum omp_allocator_handle_t {
omp_cgroup_mem_alloc = 6,
};
struct pd {
};
void
d9 ()
{
int t7;
pd gy[1] = { pd(), };
#pragma omp for reduction (& : gy) allocate (omp_cgroup_mem_alloc: gy)
for (t7 = 0; t7 < 1; ++t7)
{
}
}
% g++-11.0.0 -fopenmp -c xbxpjk57.cpp
xbxpjk57.cpp: In function 'void d9()':
xbxpjk57.cpp:14:32: error: user defined reduction not found for 'gy'
14 | #pragma omp for reduction (& : gy) allocate (omp_cgroup_mem_alloc: gy)
|^~
xbxpjk57.cpp:14:71: internal compiler error: tree check: expected tree that
contains 'decl minimal' structure, have 'mem_ref' in finish_omp_clauses, at
cp/semantics.c:8251
14 | #pragma omp for reduction (& : gy) allocate (omp_cgroup_mem_alloc: gy)
| ^
0x7df75e tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/tree.c:9905
0x6a8d5c contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/tree.h:3427
0x6a8d5c finish_omp_clauses(tree_node*, c_omp_region_type)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cp/semantics.c:8251
0x9dcb4c cp_parser_omp_all_clauses
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cp/parser.c:37749
0x9f8028 cp_parser_omp_for
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cp/parser.c:39744
0x9cc29c cp_parser_omp_construct
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cp/parser.c:43421
0x9cd9ad cp_parser_pragma
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cp/parser.c:44079
0x9d5ba4 cp_parser_statement
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cp/parser.c:11548
0x9d688d cp_parser_statement_seq_opt
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cp/parser.c:11940
0x9d6968 cp_parser_compound_statement
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cp/parser.c:11890
0x9ef944 cp_parser_function_body
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cp/parser.c:23262
0x9ef944 cp_parser_ctor_initializer_opt_and_function_body
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cp/parser.c:23313
0x9f3179 cp_parser_function_definition_after_declarator
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cp/parser.c:29205
0x9f41a9 cp_parser_function_definition_from_specifiers_and_declarator
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cp/parser.c:29121
0x9f41a9 cp_parser_init_declarator
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cp/parser.c:20848
0x9d2b2e cp_parser_simple_declaration
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cp/parser.c:13888
0x9ff526 cp_parser_declaration
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cp/parser.c:13587
0x9ffb90 cp_parser_translation_unit
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cp/parser.c:4793
0x9ffb90 c_parse_file()
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cp/parser.c:44251
0xb22e0d c_common_parse_file()
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/c-family/c-opts.c:1198
[Bug rtl-optimization/97540] [11 Regression] ICE in lra_set_insn_recog_data, at lra.c:1004 since r11-4202-g4de7b010038933dd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97540 --- Comment #7 from Hongtao.liu --- (In reply to Hongtao.liu from comment #5) > The patch is posted at > https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557143.html With upper patch and https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557142.html in pr97532, successfully build and boot linux-kernel 5.9.2.
[Bug c++/97671] New: ICE: tree check: expected var_decl or function_decl or field_decl or type_decl or concept_decl or template_decl, have parm_decl in push_template_decl, at cp/pt.c:6102
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97671
Bug ID: 97671
Summary: ICE: tree check: expected var_decl or function_decl or
field_decl or type_decl or concept_decl or
template_decl, have parm_decl in push_template_decl,
at cp/pt.c:6102
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
g++-11.0.0-alpha20201101 snapshot (g:590febb5f6624f78b36402a7c9a9c318978f1efa)
ICEs when compiling the following testcase, reduced from
test/SemaTemplate/dependent-expr.cpp from the clang 10.0.1 test suite:
void
k7 (auto fe)
{
[] (auto fe, int = ({decltype (fe) k7; k7 * 2;})) {} (fe);
}
% g++-11.0.0 -fconcepts-ts -c gtrqdjtk.cpp
gtrqdjtk.cpp: In function 'void k7(auto:1)':
gtrqdjtk.cpp:4:38: internal compiler error: tree check: expected var_decl or
function_decl or field_decl or type_decl or concept_decl or template_decl, have
parm_decl in push_template_decl, at cp/pt.c:6102
4 | [] (auto fe, int = ({decltype (fe) k7; k7 * 2;})) {} (fe);
| ^~
0x7dedcc tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/tree.c:9731
0x66c54c template_info_decl_check(tree_node const*, char const*, int, char
const*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cp/cp-tree.h:633
0x691e00 template_info_decl_check(tree_node const*, char const*, int, char
const*)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/tree.h:3427
0x691e00 push_template_decl(tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cp/pt.c:6102
0x940831 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cp/decl.c:5403
0x9f36d1 cp_parser_init_declarator
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cp/parser.c:20944
0x9d2b2e cp_parser_simple_declaration
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cp/parser.c:13888
0x9d4adc cp_parser_declaration_statement
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cp/parser.c:13328
0x9d57af cp_parser_statement
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cp/parser.c:11574
0x9d688d cp_parser_statement_seq_opt
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cp/parser.c:11940
0x9d6968 cp_parser_compound_statement
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cp/parser.c:11890
0x9d9593 cp_parser_statement_expr
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cp/parser.c:4993
0x9d9593 cp_parser_primary_expression
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cp/parser.c:5400
0x9e2f52 cp_parser_postfix_expression
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cp/parser.c:7332
0x9c4292 cp_parser_binary_expression
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cp/parser.c:9652
0x9c60bc cp_parser_assignment_expression
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cp/parser.c:9957
0x9c4bcd cp_parser_constant_expression
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cp/parser.c:10251
0x9c5411 cp_parser_initializer_clause
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cp/parser.c:23418
0x9ca07c cp_parser_initializer
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cp/parser.c:23356
0x9f0b11 cp_parser_default_argument
/var/tmp/portage/sys-devel/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cp/parser.c:23237
[Bug d/97644] FAIL: gdc.dg/gdc204.d due to ICE in finish_thunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97644 --- Comment #8 from Jan Hubicka --- > Current workaround I'm using locally for the time being is to call > thunk_info::process_early_thunks if the particular branch where this ICE > happens is hit. Why D frontend needs to expand the thunk early and does not rely on backend to handle it same way as C++ does? It would be most practical if both was finalizing same way. If there is good reason for not doing so and there is no PCH in D frontend we could just add argument to expand_thunk to avoid the game o putting things into a vector. Honza
[Bug middle-end/97672] New: [11 Regression] gfortran.dg/pdt_14.f03 – runtime: timeout with -O2 (and higher)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97672 Bug ID: 97672 Summary: [11 Regression] gfortran.dg/pdt_14.f03 – runtime: timeout with -O2 (and higher) Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- The program testsuite/gfortran.dg/pdt_14.f03 runs in 0.001s with -O0 and -O2 but now it times out with -O2/-O3/-Os Timeout with r11-4590-g29e418485848c4a6943d8561cd8fb0b1abf14015, r11-4603. According to gcc-testresults, working with r11-4557-g228156e84966963a318c2c09dc15aed887e8eb0f
[Bug ipa/97673] New: [11 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1922
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97673 Bug ID: 97673 Summary: [11 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1922 Product: gcc Version: 11.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com CC: marxin at gcc dot gnu.org Target Milestone: --- gfortran-11.0.0-alpha20201101 snapshot (g:590febb5f6624f78b36402a7c9a9c318978f1efa) ICEs when compiling the following testcase, extracted from gcc/testsuite/gfortran.dg/bind_c_usage_14.f03, w/ -O3 -fno-early-inlining --param large-stack-frame=400: subroutine sub3noiso(a, b) use iso_c_binding implicit none character(len=1,kind=c_char) :: a(*), b character(len=1,kind=c_char):: x,z integer(c_int) :: y value :: b print *, a(1:2), b entry sub3noisoEntry(x,y,z) x = 'd' end subroutine sub3noiso % powerpc-e300c3-linux-gnu-gfortran-11.0.0 -O3 -fno-early-inlining --param large-stack-frame=400 -c lvybva48.f03 during IPA pass: inline lvybva48.f03:9:0: 9 | entry sub3noisoEntry(x,y,z) | internal compiler error: in remap_gimple_stmt, at tree-inline.c:1922 0xedd483 remap_gimple_stmt /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/tree-inline.c:1922 0xee1393 copy_bb /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/tree-inline.c:2023 0xee2862 copy_cfg_body /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/tree-inline.c:3046 0xee2862 copy_body /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/tree-inline.c:3294 0xee5d7b expand_call_inline /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/tree-inline.c:5084 0xee7aac gimple_expand_calls_inline /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/tree-inline.c:5274 0xee7aac optimize_inline_calls(tree_node*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/tree-inline.c:5447 0xc30eee inline_transform(cgraph_node*) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/ipa-inline-transform.c:763 0xd80fdf execute_one_ipa_transform_pass /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/passes.c:2240 0xd80fdf execute_all_ipa_transforms(bool) /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/passes.c:2287 0x9fb6e2 cgraph_node::expand() /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cgraphunit.c:1822 0x9fcdae expand_all_functions /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cgraphunit.c:1997 0x9fcdae symbol_table::compile() /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cgraphunit.c:2361 0x9fcdae symbol_table::compile() /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cgraphunit.c:2272 0x9ffa56 symbol_table::finalize_compilation_unit() /var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-11.0.0_alpha20201101/work/gcc-11-20201101/gcc/cgraphunit.c:2542 (While my target here is powerpc, the ICE should not be target-specific.)
[Bug middle-end/97672] [11 Regression] gfortran.dg/pdt_14.f03 – runtime: timeout with -O2 (and higher)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97672 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jan Hubicka --- Duplicate. I added some analysis to the other PR. It is apprently a TBAA issue in the frontend. *** This bug has been marked as a duplicate of bug 97652 ***
[Bug fortran/97652] New pdt14 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97652 Jan Hubicka changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Jan Hubicka --- *** Bug 97672 has been marked as a duplicate of this bug. ***
[Bug ipa/97673] [11 Regression] ICE in remap_gimple_stmt, at tree-inline.c:1922 since r11-4267-g0e590b68fa374365
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97673 Martin Liška changed: What|Removed |Added Ever confirmed|0 |1 Known to fail||11.0 Target Milestone|--- |11.0 Summary|[11 Regression] ICE in |[11 Regression] ICE in |remap_gimple_stmt, at |remap_gimple_stmt, at |tree-inline.c:1922 |tree-inline.c:1922 since ||r11-4267-g0e590b68fa374365 Last reconfirmed||2020-11-02 Status|UNCONFIRMED |NEW Known to work||10.2.0 CC||hubicka at gcc dot gnu.org Priority|P3 |P1 --- Comment #1 from Martin Liška --- One can reproduce that on x86_64 with: --param large-stack-frame=4000: started with r11-4267-g0e590b68fa374365.
[Bug tree-optimization/97558] [11 Regression] ICE in vect_slp_analyze_node_operations, at tree-vect-slp.c:3342 since r11-4227-g655f7f0fb7c9aa2f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97558 --- Comment #8 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:4c198ddff83744f8b7bf24306ed1e6b889c44044 commit r11-4605-g4c198ddff83744f8b7bf24306ed1e6b889c44044 Author: Richard Biener Date: Mon Nov 2 11:09:56 2020 +0100 tree-optimization/97558 - compute vectype for SLP nested cycles This makes sure to compute the vector type for invariant SLP children of nested cycles. 2020-11-02 Richard Biener PR tree-optimization/97558 * tree-vect-loop.c (vectorizable_reduction): For nested SLP cycles compute invariant operands vector type. * gcc.dg/vect/pr97558-2.c: New testcase.
[Bug tree-optimization/97558] [11 Regression] ICE in vect_slp_analyze_node_operations, at tree-vect-slp.c:3342 since r11-4227-g655f7f0fb7c9aa2f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97558 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from Richard Biener --- Fixed.
[Bug c++/97663] [c++17] Function with return type 'unsigned' in nested namespace misinterpreted as deduction guide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97663 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 49486 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49486&action=edit gcc11-pr97663.patch Only lightly tested fix (so far), passes check-c++-all without regressions.
[Bug c++/97665] constexpr union array member incorrectly rejected as non-constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97665
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
You can do Foo foo = Foo(); and it compiles. clang++ rejects it too:
error: constexpr union constructor that does not initialize any member is a
C++20 extension [-Werror,-Wc++20-extensions]
though only with -pedantic-errors.
But g++ rejects it even in -std=c++20 mode:
pr97665.C:15:13: error: ‘V{U [1]{U()}}’ is not a constant expression
15 | constexpr V v;
| ^
pr97665.C:15:13: error: ‘V()’ is not a constant expression because it refers to
an incompletely initialized variable
[Bug fortran/97655] gcc/fortran/openmp.c:4133: possible cut'n'paste error ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97655 --- Comment #5 from CVS Commits --- The master branch has been updated by Tobias Burnus : https://gcc.gnu.org/g:b2a31e2c341d96520c5fb7c1e1f1c590eb182d7f commit r11-4606-gb2a31e2c341d96520c5fb7c1e1f1c590eb182d7f Author: Tobias Burnus Date: Mon Nov 2 13:07:17 2020 +0100 Fortran: OpenMP - fixes for omp atomic [PR97655] gcc/fortran/ChangeLog: PR fortran/97655 * openmp.c (gfc_match_omp_atomic): Fix mem-order handling; reject specifying update + capture together. gcc/testsuite/ChangeLog: PR fortran/97655 * gfortran.dg/gomp/atomic.f90: Update tree-dump counts; move invalid OMP 5.0 code to ... * gfortran.dg/gomp/atomic-2.f90: ... here; update dg-error. * gfortran.dg/gomp/requires-9.f90: Update tree dump scan.
[Bug fortran/97655] gcc/fortran/openmp.c:4133: possible cut'n'paste error ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97655 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Tobias Burnus --- (In reply to David Binderman from comment #0) > gcc/fortran/openmp.c:4133:12: style: Expression is always false because > 'else if' condition matches previous condition at line 4131. [multiCondition] Thanks for the report – this issue has been FIXED as well as the other issues discussed here.
[Bug d/97644] FAIL: gdc.dg/gdc204.d due to ICE in finish_thunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97644
--- Comment #9 from Iain Buclaw ---
(In reply to Jan Hubicka from comment #8)
> > Current workaround I'm using locally for the time being is to call
> > thunk_info::process_early_thunks if the particular branch where this ICE
> > happens is hit.
>
> Why D frontend needs to expand the thunk early and does not rely on
> backend to handle it same way as C++ does? It would be most practical
> if both was finalizing same way.
>
> If there is good reason for not doing so and there is no PCH in D
> frontend we could just add argument to expand_thunk to avoid the game o
> putting things into a vector.
>
Not discounting that I may be doing it wrong. The call to expand_thunk is
there so that thunks for externally defined methods are generated.
As the backend usually doesn't emit such thunks, a gimple generated thunk is
forced by the frontend.
I have seen linker errors in the past when this was not done, however there
could be some alignment with what C++ does to handle this though.
A simplistic example would be:
interface I { void foo(); }
class C : I { void foo(); }
Where a TU local thunk is generated for C.foo.
A more complex example would be when interfacing with C++, where different
methods are implemented half in C++, half in D.
// C++
class Base
{
public:
virtual void base() { };
};
class Interface
{
public:
virtual int MethodCPP() = 0;
virtual int MethodD() = 0;
};
class Derived : public Base, public Interface
{
public:
int MethodCPP(); // thunk _ZThn8_N7Derived9MethodCPPEv
int MethodD();// thunk _ZThn8_N7Derived7MethodDEv
};
int Derived::MethodCPP() { return 30; }
// D
extern (C++)
{
class Base
{
void based();
}
interface Interface
{
int MethodCPP();
int MethodD();
}
class Derived : Base, Interface
{
int MethodCPP(); // thunk _DT8_ZN7Derived9MethodCPPEv
int MethodD() // thunk _DT8_ZN7Derived7MethodDEv
{
return 3;
}
}
}
In the above, g++ and gdc give different global symbol names for the thunks, so
linker errors would occur if they are not emitted.
[Bug c++/97665] constexpr union array member incorrectly rejected as non-constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97665 Jakub Jelinek changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- P1331R2 support is there since r10-5194-g7906797ebec6881d7d90165340f51efcf447d716 (so without [1] it is accepted for -std=c++2a since that revision).
[Bug d/97644] FAIL: gdc.dg/gdc204.d due to ICE in finish_thunk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97644 --- Comment #10 from Jan Hubicka --- > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97644 > > --- Comment #9 from Iain Buclaw --- > (In reply to Jan Hubicka from comment #8) > > > Current workaround I'm using locally for the time being is to call > > > thunk_info::process_early_thunks if the particular branch where this ICE > > > happens is hit. > > > > Why D frontend needs to expand the thunk early and does not rely on > > backend to handle it same way as C++ does? It would be most practical > > if both was finalizing same way. > > > > If there is good reason for not doing so and there is no PCH in D > > frontend we could just add argument to expand_thunk to avoid the game o > > putting things into a vector. > > > > Not discounting that I may be doing it wrong. The call to expand_thunk is > there so that thunks for externally defined methods are generated. > > As the backend usually doesn't emit such thunks, a gimple generated thunk is > forced by the frontend. > > I have seen linker errors in the past when this was not done, however there > could be some alignment with what C++ does to handle this though. Aha, thanks for explanation. In C++ thunks was always connected to the actual function so for external symbols we indeed do not produce the thunk. How does the symbols look like? So you have external symbol and a thunk associated to it with different visibility? What it is? I see that if you expand it to gimple you turn it to normal function and it will be output then. We could do that at the finalization time avoiding the need for additional hacks in the frontend/middleend interface. Honza
[Bug testsuite/80219] relative line numbers only working if gcc_{error,warning}_prefix defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80219 --- Comment #1 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:528507fa0314c75d1105890e4781a475c8badd7c commit r11-4607-g528507fa0314c75d1105890e4781a475c8badd7c Author: Thomas Schwinge Date: Thu Oct 29 10:29:19 2020 +0100 libgomp testsuite: tell warning from error diagnostics, etc. [PR80219, PR85303] This changes makes 'dg-warning', 'dg-error', 'dg-bogus', 'dg-message' behave as expected, and also enables use of relative line numbers as well as 'dg-line'. libgomp/ PR testsuite/80219 PR testsuite/85303 * testsuite/lib/libgomp.exp (libgomp_init): Set 'gcc_warning_prefix', 'gcc_error_prefix'.
[Bug testsuite/85303] [testsuite, libgomp] dg-message not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85303 --- Comment #1 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:528507fa0314c75d1105890e4781a475c8badd7c commit r11-4607-g528507fa0314c75d1105890e4781a475c8badd7c Author: Thomas Schwinge Date: Thu Oct 29 10:29:19 2020 +0100 libgomp testsuite: tell warning from error diagnostics, etc. [PR80219, PR85303] This changes makes 'dg-warning', 'dg-error', 'dg-bogus', 'dg-message' behave as expected, and also enables use of relative line numbers as well as 'dg-line'. libgomp/ PR testsuite/80219 PR testsuite/85303 * testsuite/lib/libgomp.exp (libgomp_init): Set 'gcc_warning_prefix', 'gcc_error_prefix'.
[Bug target/85486] [og7, nvptx] ref-1.C fails with vector length 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85486 --- Comment #4 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:79680c1d5cd3d89c2e7423e20dc8a6e1d6dc8151 commit r11-4609-g79680c1d5cd3d89c2e7423e20dc8a6e1d6dc8151 Author: Thomas Schwinge Date: Wed Oct 28 10:56:20 2020 +0100 Simplify and enhance 'libgomp.oacc-c-c++-common/pr85486*.c' [PR85486] Avoid code duplication, and better test what we expect to happen. libgomp/ PR target/85486 * testsuite/libgomp.oacc-c-c++-common/pr85486-2.c: Simplify and enhance. * testsuite/libgomp.oacc-c-c++-common/pr85486-3.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/pr85486.c: Likewise.
[Bug fortran/92793] Fortran Location Data for Diagnostic lacks the column number – when passing on to ME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92793 --- Comment #7 from CVS Commits --- The master branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:5677444f7e7ca15557030902c3d09dab4852fa90 commit r11-4608-g5677444f7e7ca15557030902c3d09dab4852fa90 Author: Thomas Schwinge Date: Fri Oct 30 13:13:51 2020 +0100 Further improve Fortran column location information [PR92793] Building on top of commit 9c81750c5bedd7883182ee2684a012c6210ebe1d "Fortran] PR 92793 - fix column used for error diagnostic", there is another place where we have to use 'gfc_get_location' returning column-corrected locations. For example, this improves column location information for OMP constructs. gcc/fortran/ PR fortran/92793 * trans.c (gfc_set_backend_locus): Use 'gfc_get_location'. (gfc_restore_backend_locus): Adjust. gcc/testsuite/ PR fortran/92793 * gfortran.dg/goacc/pr92793-1.f90: Adjust.
[Bug testsuite/80219] relative line numbers only working if gcc_{error,warning}_prefix defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80219 --- Comment #2 from CVS Commits --- The releases/gcc-10 branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:591e878fc6dd08502429a8e480d8e7d966836ca9 commit r10-8959-g591e878fc6dd08502429a8e480d8e7d966836ca9 Author: Thomas Schwinge Date: Thu Oct 29 10:29:19 2020 +0100 libgomp testsuite: tell warning from error diagnostics, etc. [PR80219, PR85303] This changes makes 'dg-warning', 'dg-error', 'dg-bogus', 'dg-message' behave as expected, and also enables use of relative line numbers as well as 'dg-line'. libgomp/ PR testsuite/80219 PR testsuite/85303 * testsuite/lib/libgomp.exp (libgomp_init): Set 'gcc_warning_prefix', 'gcc_error_prefix'. (cherry picked from commit 528507fa0314c75d1105890e4781a475c8badd7c)
[Bug testsuite/85303] [testsuite, libgomp] dg-message not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85303 --- Comment #2 from CVS Commits --- The releases/gcc-10 branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:591e878fc6dd08502429a8e480d8e7d966836ca9 commit r10-8959-g591e878fc6dd08502429a8e480d8e7d966836ca9 Author: Thomas Schwinge Date: Thu Oct 29 10:29:19 2020 +0100 libgomp testsuite: tell warning from error diagnostics, etc. [PR80219, PR85303] This changes makes 'dg-warning', 'dg-error', 'dg-bogus', 'dg-message' behave as expected, and also enables use of relative line numbers as well as 'dg-line'. libgomp/ PR testsuite/80219 PR testsuite/85303 * testsuite/lib/libgomp.exp (libgomp_init): Set 'gcc_warning_prefix', 'gcc_error_prefix'. (cherry picked from commit 528507fa0314c75d1105890e4781a475c8badd7c)
[Bug target/85486] [og7, nvptx] ref-1.C fails with vector length 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85486 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:28aaad48d5aafde3e5f269864ba934c602011328 commit r10-8961-g28aaad48d5aafde3e5f269864ba934c602011328 Author: Thomas Schwinge Date: Wed Oct 28 10:56:20 2020 +0100 Simplify and enhance 'libgomp.oacc-c-c++-common/pr85486*.c' [PR85486] Avoid code duplication, and better test what we expect to happen. libgomp/ PR target/85486 * testsuite/libgomp.oacc-c-c++-common/pr85486-2.c: Simplify and enhance. * testsuite/libgomp.oacc-c-c++-common/pr85486-3.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/pr85486.c: Likewise. (cherry picked from commit 79680c1d5cd3d89c2e7423e20dc8a6e1d6dc8151)
[Bug fortran/92793] Fortran Location Data for Diagnostic lacks the column number – when passing on to ME
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92793 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:a5c5f9e181c1f7548930f1cab91002b9d460cc92 commit r10-8960-ga5c5f9e181c1f7548930f1cab91002b9d460cc92 Author: Thomas Schwinge Date: Fri Oct 30 13:13:51 2020 +0100 Further improve Fortran column location information [PR92793] Building on top of commit 9c81750c5bedd7883182ee2684a012c6210ebe1d "Fortran] PR 92793 - fix column used for error diagnostic", there is another place where we have to use 'gfc_get_location' returning column-corrected locations. For example, this improves column location information for OMP constructs. gcc/fortran/ PR fortran/92793 * trans.c (gfc_set_backend_locus): Use 'gfc_get_location'. (gfc_restore_backend_locus): Adjust. gcc/testsuite/ PR fortran/92793 * gfortran.dg/goacc/pr92793-1.f90: Adjust. (cherry picked from commit 5677444f7e7ca15557030902c3d09dab4852fa90)
[Bug target/85486] [og7, nvptx] ref-1.C fails with vector length 128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85486 --- Comment #6 from CVS Commits --- The releases/gcc-9 branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:8860822a91e2e90a5eae726a478cd5ffc0d1fbfa commit r9-9018-g8860822a91e2e90a5eae726a478cd5ffc0d1fbfa Author: Thomas Schwinge Date: Wed Oct 28 10:56:20 2020 +0100 Simplify and enhance 'libgomp.oacc-c-c++-common/pr85486*.c' [PR85486] Avoid code duplication, and better test what we expect to happen. libgomp/ PR target/85486 * testsuite/libgomp.oacc-c-c++-common/pr85486-2.c: Simplify and enhance. * testsuite/libgomp.oacc-c-c++-common/pr85486-3.c: Likewise. * testsuite/libgomp.oacc-c-c++-common/pr85486.c: Likewise. (cherry picked from commit 79680c1d5cd3d89c2e7423e20dc8a6e1d6dc8151)
[Bug testsuite/85303] [testsuite, libgomp] dg-message not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85303 --- Comment #4 from CVS Commits --- The releases/gcc-8 branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:3940a3ff2be0b445a5b24a222e83669e570f32a9 commit r8-10603-g3940a3ff2be0b445a5b24a222e83669e570f32a9 Author: Thomas Schwinge Date: Thu Oct 29 10:29:19 2020 +0100 libgomp testsuite: tell warning from error diagnostics, etc. [PR80219, PR85303] This changes makes 'dg-warning', 'dg-error', 'dg-bogus', 'dg-message' behave as expected, and also enables use of relative line numbers as well as 'dg-line'. libgomp/ PR testsuite/80219 PR testsuite/85303 * testsuite/lib/libgomp.exp (libgomp_init): Set 'gcc_warning_prefix', 'gcc_error_prefix'. (cherry picked from commit 528507fa0314c75d1105890e4781a475c8badd7c)
[Bug testsuite/80219] relative line numbers only working if gcc_{error,warning}_prefix defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80219 --- Comment #3 from CVS Commits --- The releases/gcc-9 branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:d824c5df1714403067f2a7170dd884887ce04712 commit r9-9017-gd824c5df1714403067f2a7170dd884887ce04712 Author: Thomas Schwinge Date: Thu Oct 29 10:29:19 2020 +0100 libgomp testsuite: tell warning from error diagnostics, etc. [PR80219, PR85303] This changes makes 'dg-warning', 'dg-error', 'dg-bogus', 'dg-message' behave as expected, and also enables use of relative line numbers as well as 'dg-line'. libgomp/ PR testsuite/80219 PR testsuite/85303 * testsuite/lib/libgomp.exp (libgomp_init): Set 'gcc_warning_prefix', 'gcc_error_prefix'. (cherry picked from commit 528507fa0314c75d1105890e4781a475c8badd7c)
[Bug testsuite/85303] [testsuite, libgomp] dg-message not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85303 --- Comment #3 from CVS Commits --- The releases/gcc-9 branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:d824c5df1714403067f2a7170dd884887ce04712 commit r9-9017-gd824c5df1714403067f2a7170dd884887ce04712 Author: Thomas Schwinge Date: Thu Oct 29 10:29:19 2020 +0100 libgomp testsuite: tell warning from error diagnostics, etc. [PR80219, PR85303] This changes makes 'dg-warning', 'dg-error', 'dg-bogus', 'dg-message' behave as expected, and also enables use of relative line numbers as well as 'dg-line'. libgomp/ PR testsuite/80219 PR testsuite/85303 * testsuite/lib/libgomp.exp (libgomp_init): Set 'gcc_warning_prefix', 'gcc_error_prefix'. (cherry picked from commit 528507fa0314c75d1105890e4781a475c8badd7c)
[Bug testsuite/80219] relative line numbers only working if gcc_{error,warning}_prefix defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80219 --- Comment #4 from CVS Commits --- The releases/gcc-8 branch has been updated by Thomas Schwinge : https://gcc.gnu.org/g:3940a3ff2be0b445a5b24a222e83669e570f32a9 commit r8-10603-g3940a3ff2be0b445a5b24a222e83669e570f32a9 Author: Thomas Schwinge Date: Thu Oct 29 10:29:19 2020 +0100 libgomp testsuite: tell warning from error diagnostics, etc. [PR80219, PR85303] This changes makes 'dg-warning', 'dg-error', 'dg-bogus', 'dg-message' behave as expected, and also enables use of relative line numbers as well as 'dg-line'. libgomp/ PR testsuite/80219 PR testsuite/85303 * testsuite/lib/libgomp.exp (libgomp_init): Set 'gcc_warning_prefix', 'gcc_error_prefix'. (cherry picked from commit 528507fa0314c75d1105890e4781a475c8badd7c)
[Bug testsuite/80219] relative line numbers only working if gcc_{error,warning}_prefix defined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80219 Thomas Schwinge changed: What|Removed |Added Ever confirmed|0 |1 CC||tschwinge at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2020-11-02 --- Comment #5 from Thomas Schwinge --- Fixed (only) for libgomp.
[Bug testsuite/85303] [testsuite, libgomp] dg-message not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85303 Thomas Schwinge changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |tschwinge at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||tschwinge at gcc dot gnu.org --- Comment #5 from Thomas Schwinge --- Fixed.
[Bug fortran/97652] [11 Regression] New gfortran.dg/pdt_14.f03 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97652 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0 Summary|New gfortran.dg/pdt_14.f03 |[11 Regression] New |failure after |gfortran.dg/pdt_14.f03 |g:617695cdc2b3d950f1e4deb5e |failure after |a85d5cc302943f4 |g:617695cdc2b3d950f1e4deb5e ||a85d5cc302943f4
[Bug c++/97670] [11 Regression] ICE: tree check: expected tree that contains 'decl minimal' structure, have 'mem_ref' in finish_omp_clauses, at cp/semantics.c:8251
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97670 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0
[Bug fortran/97674] New: [11 Regression] gfortran.dg/pdt_14.f03 is compiled into an infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97674 Bug ID: 97674 Summary: [11 Regression] gfortran.dg/pdt_14.f03 is compiled into an infinite loop Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com Target Milestone: --- On Linux/x86-64, r11-4588 compiles gfortran.dg/pdt_14.f03 into an infinite loop. r11-4584 is OK.
[Bug fortran/97652] [11 Regression] New gfortran.dg/pdt_14.f03 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97652 Richard Biener changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #3 from Richard Biener --- *** Bug 97674 has been marked as a duplicate of this bug. ***
[Bug fortran/97674] [11 Regression] gfortran.dg/pdt_14.f03 is compiled into an infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97674 Richard Biener changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Richard Biener --- dup *** This bug has been marked as a duplicate of bug 97652 ***
[Bug fortran/97652] [11 Regression] New gfortran.dg/pdt_14.f03 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97652 --- Comment #4 from Richard Biener --- I can only see one __vtype_link_module_Pdtlink_8 and one Pdtlink_8 type (breaking at record_component_aliases).
[Bug fortran/97652] [11 Regression] New gfortran.dg/pdt_14.f03 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97652 --- Comment #5 from Richard Biener --- Oh, btw: > /home/rguenther/obj-gcc2-g/gcc/testsuite/gfortran/../../gfortran > -B/home/rguenther/obj-gcc2-g/gcc/testsuite/gfortran/../../ > -B/home/rguenther/obj-gcc2-g/x86_64-pc-linux-gnu/./libgfortran/ > /home/rguenther/src/gcc2/gcc/testsuite/gfortran.dg/pdt_14.f03 > -fdiagnostics-plain-output -fdiagnostics-plain-output -O2 -pedantic-errors > -B/home/rguenther/obj-gcc2-g/x86_64-pc-linux-gnu/./libgfortran/.libs > -L/home/rguenther/obj-gcc2-g/x86_64-pc-linux-gnu/./libgfortran/.libs > -L/home/rguenther/obj-gcc2-g/x86_64-pc-linux-gnu/./libgfortran/.libs > -L/home/rguenther/obj-gcc2-g/x86_64-pc-linux-gnu/./libatomic/.libs > -B/home/rguenther/obj-gcc2-g/x86_64-pc-linux-gnu/./libquadmath/.libs > -L/home/rguenther/obj-gcc2-g/x86_64-pc-linux-gnu/./libquadmath/.libs > -L/home/rguenther/obj-gcc2-g/x86_64-pc-linux-gnu/./libquadmath/.libs -lm -o > ./pdt_14.exe -fno-ipa-cp -fno-ipa-vrp -fno-ipa-icf -fdump-ipa-all during IPA pass: inline dump file: ./pdt_14.f03.081i.inline /home/rguenther/src/gcc2/gcc/testsuite/gfortran.dg/pdt_14.f03:85:0: internal compiler error: Segmentation fault 0x14896d3 crash_signal /home/rguenther/src/gcc2/gcc/toplev.c:330 0xd26c14 cgraph_edge::redirect_call_stmt_to_callee(cgraph_edge*) /home/rguenther/src/gcc2/gcc/cgraph.c:1513 0x156e11a redirect_all_calls(copy_body_data*, basic_block_def*) /home/rguenther/src/gcc2/gcc/tree-inline.c:2963 0x156e906 copy_cfg_body /home/rguenther/src/gcc2/gcc/tree-inline.c:3118 0x156f0e5 copy_body /home/rguenther/src/gcc2/gcc/tree-inline.c:3294 0x1574028 expand_call_inline /home/rguenther/src/gcc2/gcc/tree-inline.c:5084 0x1574dca gimple_expand_calls_inline
[Bug fortran/97652] [11 Regression] New gfortran.dg/pdt_14.f03 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97652 Richard Biener changed: What|Removed |Added Last reconfirmed||2020-11-02 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #6 from Richard Biener --- And it looks like something (inlining) inserts __builtin_unreachable () calls that eventually make us optimize this to an endless loop. pdt_14.f03.081i.inline:Introduced new external node (__builtin_unreachable/19). pdt_14.f03.081i.inline:unreachable : 4 calls, 0.00 freq, 0 count pdt_14.f03.081i.inline:__builtin_unreachable/19 unreachable ...
[Bug fortran/97652] [11 Regression] New gfortran.dg/pdt_14.f03 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97652 --- Comment #7 from Jan Hubicka --- > And it looks like something (inlining) inserts __builtin_unreachable () calls > that eventually make us optimize this to an endless loop. > > pdt_14.f03.081i.inline:Introduced new external node > (__builtin_unreachable/19). > pdt_14.f03.081i.inline:unreachable : > > 4 calls, 0.00 freq, 0 count > pdt_14.f03.081i.inline:__builtin_unreachable/19 unreachable > ... Aha, that will be the wrong jump function from ipa-cp I mentioned in earlier comment. We should not believe that root is not written to as we derive now from TBAA in push_8.
[Bug ipa/97652] [11 Regression] New gfortran.dg/pdt_14.f03 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97652 Richard Biener changed: What|Removed |Added Component|fortran |ipa --- Comment #8 from Richard Biener --- Ok, the unreachable () appears in place of indirect calls: _8 = __vtab_link_module_Pdtlink_8._deallocate; _8 (&cdesc.1); but -fno-devirtualize doesn't help.
[Bug ipa/97652] [11 Regression] New gfortran.dg/pdt_14.f03 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97652 --- Comment #9 from Richard Biener --- (In reply to Jan Hubicka from comment #7) > > And it looks like something (inlining) inserts __builtin_unreachable () > > calls > > that eventually make us optimize this to an endless loop. > > > > pdt_14.f03.081i.inline:Introduced new external node > > (__builtin_unreachable/19). > > pdt_14.f03.081i.inline:unreachable : > > > > 4 calls, 0.00 freq, 0 count > > pdt_14.f03.081i.inline:__builtin_unreachable/19 unreachable > > ... > Aha, that will be the wrong jump function from ipa-cp I mentioned in > earlier comment. We should not believe that root is not written to as > we derive now from TBAA in push_8. But -fno-ipa-cp doesn't help.
[Bug ipa/97652] [11 Regression] New gfortran.dg/pdt_14.f03 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97652 --- Comment #10 from Jan Hubicka --- > > Aha, that will be the wrong jump function from ipa-cp I mentioned in > > earlier comment. We should not believe that root is not written to as > > we derive now from TBAA in push_8. > > But -fno-ipa-cp doesn't help. It is because jump functions are used both by inlining and ipa-cp. If inline predicates says that the path is impossible (which it will derriving from jump function) we redirect to unreachable. Honza
[Bug fortran/97652] [11 Regression] New gfortran.dg/pdt_14.f03 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97652
Richard Biener changed:
What|Removed |Added
Component|ipa |fortran
--- Comment #11 from Richard Biener ---
push_8 argument type is
arguments
unsigned DI size unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x769ec000>
readonly used unsigned DI passed-by-reference
/home/rguenther/src/gcc2/gcc/testsuite/gfortran.dg/pdt_14.f03:47:0 size
unit-size
align:64 warn_if_not_align:0 context arg-type >
(gdb) p debug_tree (0x769e3000)
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x769dcf18
and in ch2701 the root variable is
var_decl 0x769f6900 root type
addressable used unsigned DI
/home/rguenther/src/gcc2/gcc/testsuite/gfortran.dg/pdt_14.f03:78:48 size
unit-size
align:64 warn_if_not_align:0 context >
(gdb) p debug_tree (0x769fb0a8)
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x769fb2a0
which is a different type. The latter is created here:
#0 0x00c1d6f2 in gfc_get_derived_type (derived=0x39ebb70, codimen=0)
at /home/rguenther/src/gcc2/gcc/fortran/trans-types.c:2647
#1 0x00c18c21 in gfc_typenode_for_spec (spec=0x39eb090, codim=0)
at /home/rguenther/src/gcc2/gcc/fortran/trans-types.c:1167
#2 0x00c1c54b in gfc_sym_type (sym=0x39eb070)
at /home/rguenther/src/gcc2/gcc/fortran/trans-types.c:2252
#3 0x00b701d9 in gfc_get_symbol_decl (sym=0x39eb070)
at /home/rguenther/src/gcc2/gcc/fortran/trans-decl.c:1790
#4 0x00b7fe7f in generate_local_decl (sym=0x39eb070)
at /home/rguenther/src/gcc2/gcc/fortran/trans-decl.c:5948
#5 0x00b1843d in do_traverse_symtree (st=0x39ec880, st_func=0x0,
sym_func=0xb7fdbb )
at /home/rguenther/src/gcc2/gcc/fortran/symbol.c:4170
#6 0x00b184f8 in gfc_traverse_ns (ns=0x3a2f6d0,
sym_func=0xb7fdbb )
at /home/rguenther/src/gcc2/gcc/fortran/symbol.c:4195
#7 0x00b80677 in generate_local_vars (ns=0x3a2f6d0)
at /home/rguenther/src/gcc2/gcc/fortran/trans-decl.c:6154
#8 0x00b825af in gfc_generate_function_code (ns=0x3a2f6d0)
at /home/rguenther/src/gcc2/gcc/fortran/trans-decl.c:6812
#9 0x00b3e3fe in gfc_generate_code (ns=0x3a2f6d0)
at /home/rguenther/src/gcc2/gcc/fortran/trans.c:2235
#10 0x00abe7e0 in translate_all_program_units (
gfc_global_ns_list=0x39b18f0)
while the former here:
#0 0x00c1d6f2 in gfc_get_derived_type (derived=0x39c6480, codimen=0)
at /home/rguenther/src/gcc2/gcc/fortran/trans-types.c:2647
#1 0x00c18c21 in gfc_typenode_for_spec (spec=0x39ce5a0, codim=0)
at /home/rguenther/src/gcc2/gcc/fortran/trans-types.c:1167
#2 0x00c1c54b in gfc_sym_type (sym=0x39ce580)
at /home/rguenther/src/gcc2/gcc/fortran/trans-types.c:2252
#3 0x00b701d9 in gfc_get_symbol_decl (sym=0x39ce580)
at /home/rguenther/src/gcc2/gcc/fortran/trans-decl.c:1790
#4 0x00b7dd72 in gfc_create_module_variable (sym=0x39ce580)
at /home/rguenther/src/gcc2/gcc/fortran/trans-decl.c:5339
#5 0x00b1843d in do_traverse_symtree (st=0x3951a30, st_func=0x0,
sym_func=0xb7d65d )
at /home/rguenther/src/gcc2/gcc/fortran/symbol.c:4170
#6 0x00b184f8 in gfc_traverse_ns (ns=0x39b2f80,
sym_func=0xb7d65d )
at /home/rguenther/src/gcc2/gcc/fortran/symbol.c:4195
#7 0x00b7fb05 in gfc_generate_module_vars (ns=0x39b2f80)
at /home/rguenther/src/gcc2/gcc/fortran/trans-decl.c:5838
#8 0x00b3e4f4 in gfc_generate_module_code (ns=0x39b2f80)
at /home/rguenther/src/gcc2/gcc/fortran/trans.c:2259
#9 0x00abe712 in translate_all_program_units (
gfc_global_ns_list=0x39b18f0)
there is it seems code to deal with the type already been there but it seems
this handling doesn't work. It does
/* Store up the canonical type to be added to this one. */
if (got_canonical)
{
if (TYPE_CANONICAL (derived->backend_decl))
canonical = TYPE_CANONICAL (derived->backend_decl);
else
canonical = derived->backend_decl;
derived->backend_decl = NULL_TREE;
}
/* derived->backend_decl != 0 means we saw it before, but its
components' backend_decl may have not been built. */
if (derived->backend_decl)
...
else
{
/* We see this derived type first time, so build the type node. */
typenode = make_node (RECORD_TYPE);
TYPE_NAME (typenode) = get_identifier (derived->name);
TYPE_PACKED (typenode) = flag_pack_derived;
derived->backend_decl = typenode;
}
but we enver find a canonical type.
Looks like a latent issue exposed now.
[Bug fortran/97652] [11 Regression] New gfortran.dg/pdt_14.f03 failure after g:617695cdc2b3d950f1e4deb5ea85d5cc302943f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97652 --- Comment #12 from Richard Biener --- Note setting TYPE_TYPELESS_STORAGE on the aggregates doesn't help the testcase since the pointer types are the issue.
[Bug c++/97675] New: GCC does not allow turning off the warning for exceptions being caught by an earlier handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97675 Bug ID: 97675 Summary: GCC does not allow turning off the warning for exceptions being caught by an earlier handler Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Target Milestone: --- In the LLVM libc++abi test suite, we test that an exception of type 'Child' is being caught by an earlier handler of type 'Base'. As a result, GCC (and Clang) produce a warning saying that the later catch clause (of type 'Child') will never be used. This is fine. However, Clang allows turning off that specific warning using -Wno-exceptions (or the appropriate warning pragma). GCC doesn't provide that option, which is problematic because we compile our test suite with -Werror. The options that are left are: - To disable these tests with GCC altogether - To disable -Werror on these tests Instead, it would be nice if GCC allowed controlling that warning (and perhaps other related warnings I'm not aware of) using a compiler flag. Reproducer: cat <: In function 'int main()': :6:5: warning: exception of type 'Child' will be caught :5:5: warning:by earlier handler for 'Base' Expectation: Some warning flag (e.g. -Wno-exceptions) allows turning off that warning.
[Bug target/97638] aarch64: bti c is missing at function entry with branch-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97638 --- Comment #1 from CVS Commits --- The master branch has been updated by Sudakshina Das : https://gcc.gnu.org/g:ce99142c11b8090105cbf2aa853262f6d9abc0d3 commit r11-4615-gce99142c11b8090105cbf2aa853262f6d9abc0d3 Author: Sudakshina Das Date: Mon Nov 2 15:52:22 2020 + [PATCH] aarch64: Fix PR97638 Currently the testcase in the patch was failing to produce a 'bti c' at the beginning of the function. This was because in aarch64_pac_insn_p, we were wrongly returning at the first check! 2020-10-30 Sudakshina Das gcc/ChangeLog: PR target/97638 * config/aarch64/aarch64-bti-insert.c (aarch64_pac_insn_p): Update return value on INSN_P check. gcc/testsuite/ChangeLog: PR target/97638 * gcc.target/aarch64/pr97638.c: New test.a
[Bug fortran/97320] False positive "Array reference out of bounds in loop" in a protecting if block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97320 Jacques Le Bourlot changed: What|Removed |Added CC||Jacques.Lebourlot at obspm dot fr --- Comment #2 from Jacques Le Bourlot --- Same here. This is annoying because *some* warnings ARE relevant, and I need them to clean a huge (and old) code. But they are lost in too many false positives. Here is the test case I can provide (similar to Tomas') - PROGRAM Warn_Bug INTEGER, PARAMETER :: N = 2 INTEGER, DIMENSION(0:N) :: a INTEGER :: i a = [ (i, i = 0, N) ] DO i = 0, N IF (i == 0) THEN PRINT *, " Do nothing" ELSE IF (i >= 1) THEN PRINT *, " OK:", a(i) - a(i-1) ENDIF ENDDO END PROGRAM Warn_Bug - The compiler should see that "IF (i >= 1)" THEN "i-1 >= 0". Quoting the manual is not an adequate answer. An upgrade would be most welcomed. Thank you. Jacques
[Bug c/97578] ice during IPA pass: inline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97578
Martin Jambor changed:
What|Removed |Added
CC||jamborm at gcc dot gnu.org
--- Comment #6 from Martin Jambor ---
(In reply to Jan Hubicka from comment #5)
> Hi,
> this patch fixes the ICE, though I think we do have a design issue here
> while producing debug info across ltrans boundary.
>
> Martin, Jakub: as discussed on IRC it would be nice to add predicate
> when the body is really needed and avoid materializing if it is not.
> Can you add one?
>
> Something like param_adjustemnts->need_callee_parm_decls_p ()
I think that in practice the existence of param_adjustemnts is by far
the biggest part of the test and the patch already checks for that.
A more precise check would probably be the following?
/* Return true if any of the original parameters of the function has been
removed or replaced. */
bool
ipa_param_adjustments::orig_parameter_removed_p ()
{
if (m_always_copy_start == 0)
return false;
unsigned adj_len = vec_safe_length (m_adj_params);
if (adj_len < m_always_copy_start)
return true;
unsigned i;
for (i = 0; i < m_always_copy_start; i++)
{
ipa_adjusted_param *apm = &(*m_adj_params)[i];
if (apm->op != IPA_PARAM_OP_COPY
|| apm->base_index != i)
break;
}
if (i == m_always_copy_start)
return false;
/* In all likelihood, the ith parameter has been removed, verify. */
bool complex_case = false;
for (unsigned j = i; j < adj_len; j++)
{
ipa_adjusted_param *apm = &(*m_adj_params)[j];
if (apm->op == IPA_PARAM_OP_COPY
|| apm->base_index == i)
{
complex_case = true;
break;
}
}
if (!complex_case)
return true;
auto_vec kept;
kept.safe_grow_cleared (m_always_copy_start - i, true);
for (unsigned j = i; j < adj_len; j++)
{
ipa_adjusted_param *apm = &(*m_adj_params)[j];
if (apm->op == IPA_PARAM_OP_COPY)
kept[apm->base_index - i] = true;
}
for (unsigned j = 0; j < m_always_copy_start - i; j++)
if (!kept[j])
return true;
return false;
}
[Bug rtl-optimization/97676] New: "*" should skip a constraint, not just one char of it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97676 Bug ID: 97676 Summary: "*" should skip a constraint, not just one char of it Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: segher at gcc dot gnu.org Target Milestone: --- See https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557759.html and the thread leading up to it.
[Bug fortran/97320] False positive "Array reference out of bounds in loop" in a protecting if block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97320 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #3 from kargl at gcc dot gnu.org --- (In reply to Jacques Le Bourlot from comment #2) > > The compiler should see that "IF (i >= 1)" THEN "i-1 >= 0". Quoting the > manual is not an adequate answer. An upgrade would be most welcomed. > gfortran is mostly maintained by a diminishing number of contributors. Messages telling the few remaining contributors what they ought to do are likely to fall on deaf ears. Patches from new contributors are welcomed; otherwise, sometime in the future, perhaps a decade or so, someone might care enough to try to fix this annoyance. In the meantime, add -Wno-do-subscript to your options.
[Bug fortran/97320] False positive "Array reference out of bounds in loop" in a protecting if block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97320 --- Comment #4 from Jacques Le Bourlot --- (In reply to kargl from comment #3) > (In reply to Jacques Le Bourlot from comment #2) > > > > The compiler should see that "IF (i >= 1)" THEN "i-1 >= 0". Quoting the > > manual is not an adequate answer. An upgrade would be most welcomed. > > > > gfortran is mostly maintained by a diminishing number of contributors. > Messages telling the few remaining contributors what they ought to > do are likely to fall on deaf ears. Patches from new contributors > are welcomed; otherwise, sometime in the future, perhaps a decade > or so, someone might care enough to try to fix this annoyance. In the > meantime, add -Wno-do-subscript to your options. My apologies. I did not mean to be rude or to complain. And I am not skilled enough to contribute. Sorry. But I will keep -Wdo-subscript, because I need the few cases that are *real* positives. Jacques
[Bug c++/97665] constexpr union array member incorrectly rejected as non-constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97665
--- Comment #4 from Luke Dalessandro ---
Hi Jakob,
Thank you for looking at this. I restructured the code sample according to your
suggestions and it is available here https://godbolt.org/z/P1bMEz. I don't
understand a couple of things that you said, and ultimately I'm not sure if you
are agreeing that this could be a bug.
> You can do Foo foo = Foo(); and it compiles.
1. I can't do `Foo foo = Foo();` because the purpose of the union is to
allocate uninitialized storage for the `Foo` during `constexpr` execution when
`Foo` has no default constructor. I realize now I meant to write `constexpr
Foo() = delete;` in the original code. I _can_ use the monostate to have an
active member at initialization, but would prefer not to as it complicates the
union.
> clang++ rejects it too:
> error: constexpr union constructor that does not initialize any member is a
> C++20 extension [-Werror,-Wc++20-extensions] though only with
> -pedantic-errors.
2. I can't get clang to emit the warning you describe even with the provided
flags, perhaps I am doing it wrong or misinterpreting your comment.
> P1331R2 support is there since
> r10-5194-g7906797ebec6881d7d90165340f51efcf447d716
> (so without [1] it is accepted for -std=c++2a since that revision)
3. I think this means that, if the member is not an array, then it is accepted
with `-std=c++2a`. I do observe this, however it's not my use case. Technically
I have an array of some class template parameter `N`.
The updated test case with the deleted constructor is.
```
struct Foo {
constexpr Foo() = delete;
};
union U {
// struct {} monostate = {};
Foo foo;
constexpr U() {}
};
struct V {
U storage[1];
};
constexpr V v;
```
[Bug target/93449] PPC: Missing conversion builtin from vector to _Decimal128 and vice versa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93449 --- Comment #9 from CVS Commits --- The master branch has been updated by Carl Love : https://gcc.gnu.org/g:05161256d3d2a598966ca1cf676fa0e427570f73 commit r11-4623-g05161256d3d2a598966ca1cf676fa0e427570f73 Author: Carl Love Date: Mon Aug 31 16:12:31 2020 -0500 Add bcd builtings listed in appendix B of the ABI 2020-10-29 Carl Love gcc/ PR target/93449 * config/rs6000/altivec.h (__builtin_bcdadd, __builtin_bcdadd_lt, __builtin_bcdadd_eq, __builtin_bcdadd_gt, __builtin_bcdadd_ofl, __builtin_bcdadd_ov, __builtin_bcdsub, __builtin_bcdsub_lt, __builtin_bcdsub_eq, __builtin_bcdsub_gt, __builtin_bcdsub_ofl, __builtin_bcdsub_ov, __builtin_bcdinvalid, __builtin_bcdmul10, __builtin_bcddiv10, __builtin_bcd2dfp, __builtin_bcdcmpeq, __builtin_bcdcmpgt, __builtin_bcdcmplt, __builtin_bcdcmpge, __builtin_bcdcmple): Add defines. * config/rs6000/altivec.md: Add UNSPEC_BCDSHIFT. (BCD_TEST): Add le, ge to code iterator. Add VBCD mode iterator. (bcd_test, *bcd_test2, bcd_, bcd_): Add mode to name. Change iterator from V1TI to VBCD. (*bcdinvalid_, bcdshift_v16qi): New define_insn. (bcdinvalid_, bcdmul10_v16qi, bcddiv10_v16qi): New define. * config/rs6000/dfp.md (dfp_denbcd_v16qi_inst): New define_insn. (dfp_denbcd_v16qi): New define_expand. * config/rs6000/rs6000-builtin.def (BU_P8V_MISC_1): New define. (BCDADD): Replaced with BCDADD_V1TI and BCDADD_V16QI. (BCDADD_LT): Replaced with BCDADD_LT_V1TI and BCDADD_LT_V16QI. (BCDADD_EQ): Replaced with BCDADD_EQ_V1TI and BCDADD_EQ_V16QI. (BCDADD_GT): Replaced with BCDADD_GT_V1TI and BCDADD_GT_V16QI. (BCDADD_OV): Replaced with BCDADD_OV_V1TI and BCDADD_OV_V16QI. (BCDSUB_V1TI, BCDSUB_V16QI, BCDSUB_LT_V1TI, BCDSUB_LT_V16QI, BCDSUB_LE_V1TI, BCDSUB_LE_V16QI, BCDSUB_EQ_V1TI, BCDSUB_EQ_V16QI, BCDSUB_GT_V1TI, BCDSUB_GT_V16QI, BCDSUB_GE_V1TI, BCDSUB_GE_V16QI, BCDSUB_OV_V1TI, BCDSUB_OV_V16QI, BCDINVALID_V1TI, BCDINVALID_V16QI, BCDMUL10_V16QI, BCDDIV10_V16QI, DENBCD_V16QI): New builtin definitions. (BCDADD, BCDADD_LT, BCDADD_EQ, BCDADD_GT, BCDADD_OV, BCDSUB, BCDSUB_LT, BCDSUB_LE, BCDSUB_EQ, BCDSUB_GT, BCDSUB_GE, BCDSUB_OV, BCDINVALID, BCDMUL10, BCDDIV10, DENBCD): New overload definitions. * config/rs6000/rs6000-call.c (P8V_BUILTIN_VEC_BCDADD, P8V_BUILTIN_VEC_BCDADD_LT, P8V_BUILTIN_VEC_BCDADD_EQ, P8V_BUILTIN_VEC_BCDADD_GT, P8V_BUILTIN_VEC_BCDADD_OV, P8V_BUILTIN_VEC_BCDINVALID, P9V_BUILTIN_VEC_BCDMUL10, P8V_BUILTIN_VEC_DENBCD. P8V_BUILTIN_VEC_BCDSUB, P8V_BUILTIN_VEC_BCDSUB_LT, P8V_BUILTIN_VEC_BCDSUB_LE, P8V_BUILTIN_VEC_BCDSUB_EQ, P8V_BUILTIN_VEC_BCDSUB_GT, P8V_BUILTIN_VEC_BCDSUB_GE, P8V_BUILTIN_VEC_BCDSUB_OV): New overloaded specifications. (CODE_FOR_bcdadd): Replaced with CODE_FOR_bcdadd_v16qi and CODE_FOR_bcdadd_v1ti. (CODE_FOR_bcdadd_lt): Replaced with CODE_FOR_bcdadd_lt_v16qi and CODE_FOR_bcdadd_lt_v1ti. (CODE_FOR_bcdadd_eq): Replaced with CODE_FOR_bcdadd_eq_v16qi and CODE_FOR_bcdadd_eq_v1ti. (CODE_FOR_bcdadd_gt): Replaced with CODE_FOR_bcdadd_gt_v16qi and CODE_FOR_bcdadd_gt_v1ti. (CODE_FOR_bcdsub): Replaced with CODE_FOR_bcdsub_v16qi and CODE_FOR_bcdsub_v1ti. (CODE_FOR_bcdsub_lt): Replaced with CODE_FOR_bcdsub_lt_v16qi and CODE_FOR_bcdsub_lt_v1ti. (CODE_FOR_bcdsub_eq): Replaced with CODE_FOR_bcdsub_eq_v16qi and CODE_FOR_bcdsub_eq_v1ti. (CODE_FOR_bcdsub_gt): Replaced with CODE_FOR_bcdsub_gt_v16qi and CODE_FOR_bcdsub_gt_v1ti. (rs6000_expand_ternop_builtin): Add CODE_FOR_dfp_denbcd_v16qi to else if. * doc/extend.texi: Add documentation for new builtins. gcc/testsuite/ * gcc.target/powerpc/bcd-2.c: Add include altivec.h. * gcc.target/powerpc/bcd-3.c: Add include altivec.h. * gcc.target/powerpc/bcd-4.c: New test.
[Bug target/93449] PPC: Missing conversion builtin from vector to _Decimal128 and vice versa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93449 Carl Love changed: What|Removed |Added CC||cel at us dot ibm.com --- Comment #10 from Carl Love --- Patch approved and committed. commit 05161256d3d2a598966ca1cf676fa0e427570f73 (HEAD -> master, origin/master, origin/HEAD) Author: Carl Love Date: Mon Aug 31 16:12:31 2020 -0500 Add bcd builtings listed in appendix B of the ABI 2020-10-29 Carl Love gcc/ PR target/93449 * config/rs6000/altivec.h (__builtin_bcdadd, __builtin_bcdadd_lt, __builtin_bcdadd_eq, __builtin_bcdadd_gt, __builtin_bcdadd_ofl, __builtin_bcdadd_ov, __builtin_bcdsub, __builtin_bcdsub_lt, __builtin_bcdsub_eq, __builtin_bcdsub_gt, __builtin_bcdsub_ofl, __builtin_bcdsub_ov, __builtin_bcdinvalid, __builtin_bcdmul10, __builtin_bcddiv10, __builtin_bcd2dfp, __builtin_bcdcmpeq, __builtin_bcdcmpgt, __builtin_bcdcmplt, __builtin_bcdcmpge, __builtin_bcdcmple): Add defines. * config/rs6000/altivec.md: Add UNSPEC_BCDSHIFT. (BCD_TEST): Add le, ge to code iterator. Add VBCD mode iterator. (bcd_test, *bcd_test2, bcd_, bcd_): Add mode to name. Change iterator from V1TI to VBCD. (*bcdinvalid_, bcdshift_v16qi): New define_insn. (bcdinvalid_, bcdmul10_v16qi, bcddiv10_v16qi): New define. * config/rs6000/dfp.md (dfp_denbcd_v16qi_inst): New define_insn. (dfp_denbcd_v16qi): New define_expand. * config/rs6000/rs6000-builtin.def (BU_P8V_MISC_1): New define. (BCDADD): Replaced with BCDADD_V1TI and BCDADD_V16QI. (BCDADD_LT): Replaced with BCDADD_LT_V1TI and BCDADD_LT_V16QI. (BCDADD_EQ): Replaced with BCDADD_EQ_V1TI and BCDADD_EQ_V16QI. (BCDADD_GT): Replaced with BCDADD_GT_V1TI and BCDADD_GT_V16QI. (BCDADD_OV): Replaced with BCDADD_OV_V1TI and BCDADD_OV_V16QI. (BCDSUB_V1TI, BCDSUB_V16QI, BCDSUB_LT_V1TI, BCDSUB_LT_V16QI, BCDSUB_LE_V1TI, BCDSUB_LE_V16QI, BCDSUB_EQ_V1TI, BCDSUB_EQ_V16QI, BCDSUB_GT_V1TI, BCDSUB_GT_V16QI, BCDSUB_GE_V1TI, BCDSUB_GE_V16QI, BCDSUB_OV_V1TI, BCDSUB_OV_V16QI, BCDINVALID_V1TI, BCDINVALID_V16QI, BCDMUL10_V16QI, BCDDIV10_V16QI, DENBCD_V16QI): New builtin definitions. (BCDADD, BCDADD_LT, BCDADD_EQ, BCDADD_GT, BCDADD_OV, BCDSUB, BCDSUB_LT, BCDSUB_LE, BCDSUB_EQ, BCDSUB_GT, BCDSUB_GE, BCDSUB_OV, BCDINVALID, BCDMUL10, BCDDIV10, DENBCD): New overload definitions. * config/rs6000/rs6000-call.c (P8V_BUILTIN_VEC_BCDADD, P8V_BUILTIN_VEC_BCDADD_LT, P8V_BUILTIN_VEC_BCDADD_EQ, P8V_BUILTIN_VEC_BCDADD_GT, P8V_BUILTIN_VEC_BCDADD_OV, P8V_BUILTIN_VEC_BCDINVALID, P9V_BUILTIN_VEC_BCDMUL10, P8V_BUILTIN_VEC_DENBCD. P8V_BUILTIN_VEC_BCDSUB, P8V_BUILTIN_VEC_BCDSUB_LT, P8V_BUILTIN_VEC_BCDSUB_LE, P8V_BUILTIN_VEC_BCDSUB_EQ, P8V_BUILTIN_VEC_BCDSUB_GT, P8V_BUILTIN_VEC_BCDSUB_GE, P8V_BUILTIN_VEC_BCDSUB_OV): New overloaded specifications. (CODE_FOR_bcdadd): Replaced with CODE_FOR_bcdadd_v16qi and CODE_FOR_bcdadd_v1ti. (CODE_FOR_bcdadd_lt): Replaced with CODE_FOR_bcdadd_lt_v16qi and CODE_FOR_bcdadd_lt_v1ti. (CODE_FOR_bcdadd_eq): Replaced with CODE_FOR_bcdadd_eq_v16qi and CODE_FOR_bcdadd_eq_v1ti. (CODE_FOR_bcdadd_gt): Replaced with CODE_FOR_bcdadd_gt_v16qi and CODE_FOR_bcdadd_gt_v1ti. (CODE_FOR_bcdsub): Replaced with CODE_FOR_bcdsub_v16qi and CODE_FOR_bcdsub_v1ti. (CODE_FOR_bcdsub_lt): Replaced with CODE_FOR_bcdsub_lt_v16qi and CODE_FOR_bcdsub_lt_v1ti. (CODE_FOR_bcdsub_eq): Replaced with CODE_FOR_bcdsub_eq_v16qi and CODE_FOR_bcdsub_eq_v1ti. (CODE_FOR_bcdsub_gt): Replaced with CODE_FOR_bcdsub_gt_v16qi and CODE_FOR_bcdsub_gt_v1ti. (rs6000_expand_ternop_builtin): Add CODE_FOR_dfp_denbcd_v16qi to else if. * doc/extend.texi: Add documentation for new builtins. gcc/testsuite/ * gcc.target/powerpc/bcd-2.c: Add include altivec.h. * gcc.target/powerpc/bcd-3.c: Add include altivec.h. * gcc.target/powerpc/bcd-4.c: New test.
[Bug target/93449] PPC: Missing conversion builtin from vector to _Decimal128 and vice versa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93449 Carl Love changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Carl Love --- Patch committed to fix issue
[Bug c++/97665] constexpr union array member incorrectly rejected as non-constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97665 --- Comment #5 from Luke Dalessandro --- Ugh... replying to myself. > You can do Foo foo = Foo(); and it compiles. >> 1. I can't do `Foo foo = Foo();` because the purpose of the union is to >> allocate uninitialized storage for the `Foo` during `constexpr` execution >> when `Foo` has no default constructor. I realize now I meant to write >> `constexpr Foo() = delete;`. This means to say "trivial default constructor," not just "default constructor". The empty default constructor was an adequate test case for this, but is misleading. The `= delete` should be more effective as an example. The context for the use is to create an array that provides uninitialized vector storage during `constexpr` evaluation in the same way a `std::byte[T*sizeof(T)]` array combined with `reinterptret_cast` might be used during normal execution.
[Bug c++/97677] New: std::array and std::initializer_list gives wrong results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97677 Bug ID: 97677 Summary: std::array and std::initializer_list gives wrong results Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: peter_foelsche at mentor dot com Target Milestone: --- Created attachment 49487 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49487&action=edit ConsoleApplication2.cpp g++ 5.3.0 gives wrong results: orw-ams-ms7 /scratch/pfoelsch : g++ ConsoleApplication2.cpp -std=c++11 orw-ams-ms7 /scratch/pfoelsch : g++ --version g++ (GCC) 5.3.0 Copyright (C) 2015 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. orw-ams-ms7 /scratch/pfoelsch : ./a.out t2[0]=0.761594 t2[1]=4.19974 t3[0]=-0.661594 t3[1]=-4.19974 t3[2]=1 t4[0]=0 t4[1]=0 t4[2]=1 orw-ams-ms7 /scratch/pfoelsch : g++ (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 gives correct results: pfoelsch@txa-pfoelsch-lt:/mnt/c/MGC_NOSCAN/ConsoleApplication2$ g++ ConsoleApplication2.cpp -std=c++11 pfoelsch@txa-pfoelsch-lt:/mnt/c/MGC_NOSCAN/ConsoleApplication2$ g++ --version g++ (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0 Copyright (C) 2017 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. pfoelsch@txa-pfoelsch-lt:/mnt/c/MGC_NOSCAN/ConsoleApplication2$ ./a.out t2[0]=0.761594 t2[1]=4.19974 t3[0]=-0.661594 t3[1]=-4.19974 t3[2]=1 t4[0]=-0.661594 t4[1]=-4.19974 t4[2]=1
[Bug c++/97675] GCC does not allow turning off the warning for exceptions being caught by an earlier handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97675 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2020-11-02 Keywords||diagnostic Status|UNCONFIRMED |NEW
[Bug c++/97665] constexpr union array member incorrectly rejected as non-constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97665 --- Comment #6 from Jakub Jelinek --- All I'm saying is that I believe your code is not valid C++17, but is valid C++20 and that for C++20 we have a compiler bug we need to fix.
[Bug c++/97665] constexpr union array member incorrectly rejected as non-constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97665 --- Comment #7 from Luke Dalessandro --- Thank you, sorry for the confusion.
[Bug tree-optimization/97678] New: [11 regression] execution fail for gcc.target/powerpc/p9-vec-length-epil-run-5.c after r11-4614
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97678 Bug ID: 97678 Summary: [11 regression] execution fail for gcc.target/powerpc/p9-vec-length-epil-run-5.c after r11-4614 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- e881774d0dda6d5127eb8f0642f6edc16dc0b1e7, r11-4614 spawn -ignore SIGHUP /home3/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home3/seurer/gcc/git/build/gcc-test/gcc/ exceptions_enabled78561.cc -fdiagnostics-plain-output -S -o exceptions_enabled78561.s PASS: gcc.target/powerpc/p9-vec-length-epil-run-5.c (test for excess errors) Setting LD_LIBRARY_PATH to :/home3/seurer/gcc/git/build/gcc-test/gcc::/home3/seurer/gcc/git/build/gcc-test/gcc:/home3/seurer/gcc/git/build/gcc-test/./gmp/.libs:/home3/seurer/gcc/git/build/gcc-test/./prev-gmp/.libs:/home3/seurer/gcc/git/build/gcc-test/./mpfr/src/.libs:/home3/seurer/gcc/git/build/gcc-test/./prev-mpfr/src/.libs:/home3/seurer/gcc/git/build/gcc-test/./mpc/src/.libs:/home3/seurer/gcc/git/build/gcc-test/./prev-mpc/src/.libs:/home3/seurer/gcc/git/build/gcc-test/./isl/.libs:/home3/seurer/gcc/git/build/gcc-test/./prev-isl/.libs Execution timeout is: 300 spawn [open ...] FAIL: gcc.target/powerpc/p9-vec-length-epil-run-5.c execution test Executing on host: /home3/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home3/seurer/gcc/git/build/gcc-test/gcc/ vmx_hw_available78561.c -fdiagnostics-plain-output -mno-vsx -lm -o vmx_hw_available78561.exe (timeout = 300) spawn -ignore SIGHUP /home3/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home3/seurer/gcc/git/build/gcc-test/gcc/ vmx_hw_available78561.c -fdiagnostics-plain-output -mno-vsx -lm -o vmx_hw_available78561.exe Setting LD_LIBRARY_PATH to :/home3/seurer/gcc/git/build/gcc-test/gcc::/home3/seurer/gcc/git/build/gcc-test/gcc:/home3/seurer/gcc/git/build/gcc-test/./gmp/.libs:/home3/seurer/gcc/git/build/gcc-test/./prev-gmp/.libs:/home3/seurer/gcc/git/build/gcc-test/./mpfr/src/.libs:/home3/seurer/gcc/git/build/gcc-test/./prev-mpfr/src/.libs:/home3/seurer/gcc/git/build/gcc-test/./mpc/src/.libs:/home3/seurer/gcc/git/build/gcc-test/./prev-mpc/src/.libs:/home3/seurer/gcc/git/build/gcc-test/./isl/.libs:/home3/seurer/gcc/git/build/gcc-test/./prev-isl/.libs Execution timeout is: 300 spawn [open ...] testcase /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/powerpc.exp completed in 3 seconds === gcc Summary === # of expected passes1 # of unexpected failures1 (gdb) run Starting program: /home3/seurer/gcc/git/build/gcc-test/p9-vec-length-epil-run-5.exe Program received signal SIGABRT, Aborted. 0x77c2e98c in __libc_signal_restore_set (set=0x7fffa4f8) at ../sysdeps/unix/sysv/linux/nptl-signals.h:80 80 ../sysdeps/unix/sysv/linux/nptl-signals.h: No such file or directory. (gdb) where #0 0x77c2e98c in __libc_signal_restore_set (set=0x7fffa4f8) at ../sysdeps/unix/sysv/linux/nptl-signals.h:80 #1 __GI_raise (sig=) at ../sysdeps/unix/sysv/linux/raise.c:48 #2 0x77c30be0 in __GI_abort () at abort.c:79 #3 0x10001830 in main () at /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/p9-vec-length-run-5.h:43 if (a[i * 2] != exp_a1 || a[i * 2 + 1] != exp_a2 || b[i * 2] != exp_b1 \ || b[i * 2 + 1] != exp_b2) \ __builtin_abort (); // line 43 commit e881774d0dda6d5127eb8f0642f6edc16dc0b1e7 (HEAD, refs/bisect/bad) Author: Richard Biener Date: Mon Nov 2 12:38:04 2020 +0100
[Bug c++/97679] New: ICE with CTAD on a nested class template with constrained constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97679
Bug ID: 97679
Summary: ICE with CTAD on a nested class template with
constrained constructor
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
$ cat testcase.C
template struct A {
template struct B { B(T) requires V; };
};
A::B x(0);
$ g++ -std=c++20 testcase.C
testcase.C: In substitution of ‘template B(T)-> A::B requires
T [with T = int]’:
testcase.C:5:15: required from here
testcase.C:5:15: internal compiler error: Segmentation fault
5 | A::B x(0);
| ^
[Bug testsuite/97680] New: new test case c-c++-common/zero-scratch-regs-10.c in r11-4578 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97680 Bug ID: 97680 Summary: new test case c-c++-common/zero-scratch-regs-10.c in r11-4578 has excess errors Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- g:d10f3e900b0377b4760a090b0f90371bcef01686, r11-4578 make -k check-gcc RUNTESTFLAGS="dg.exp=c-c++-common/zero-scratch-regs-10.c" FAIL: c-c++-common/zero-scratch-regs-10.c -Wc++-compat (test for excess errors) FAIL: c-c++-common/zero-scratch-regs-10.c -std=gnu++98 (test for excess errors) FAIL: c-c++-common/zero-scratch-regs-10.c -std=gnu++14 (test for excess errors) FAIL: c-c++-common/zero-scratch-regs-10.c -std=gnu++17 (test for excess errors) FAIL: c-c++-common/zero-scratch-regs-10.c -std=gnu++2a (test for excess errors) # of unexpected failures1 # of unexpected failures4 # of unresolved testcases 1 # of unresolved testcases 4 commit d10f3e900b0377b4760a090b0f90371bcef01686 Author: qing zhao Date: Fri Oct 30 20:41:38 2020 +0100 If looks like the errors are all like this: FAIL: c-c++-common/zero-scratch-regs-10.c -std=gnu++98 (test for excess errors) Excess errors: /home/seurer/gcc/git/gcc-test/gcc/testsuite/c-c++-common/zero-scratch-regs-10.c:77:1: sorry, unimplemented: '-fzero-call-used_regs' not supported on this target
[Bug fortran/97320] False positive "Array reference out of bounds in loop" in a protecting if block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97320 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |DUPLICATE Status|WAITING |RESOLVED --- Comment #5 from anlauf at gcc dot gnu.org --- See PR 94978. *** This bug has been marked as a duplicate of bug 94978 ***
[Bug fortran/94978] [8/9/10/11 Regression] Bogus warning "Array reference at (1) out of bounds in loop beginning at (2)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94978 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||trnka at scm dot com --- Comment #4 from anlauf at gcc dot gnu.org --- *** Bug 97320 has been marked as a duplicate of this bug. ***
[Bug testsuite/97680] new test case c-c++-common/zero-scratch-regs-10.c in r11-4578 has excess errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97680 --- Comment #1 from qinzhao at gcc dot gnu.org --- (In reply to seurer from comment #0) > commit d10f3e900b0377b4760a090b0f90371bcef01686 > Author: qing zhao > Date: Fri Oct 30 20:41:38 2020 +0100 > > If looks like the errors are all like this: > > FAIL: c-c++-common/zero-scratch-regs-10.c -std=gnu++98 (test for excess > errors) > Excess errors: > /home/seurer/gcc/git/gcc-test/gcc/testsuite/c-c++-common/zero-scratch-regs- > 10.c:77:1: sorry, unimplemented: '-fzero-call-used_regs' not supported on > this target Hi, this is an expected error on this platform since the middle-end implementation of -fzero-call-used-regs doesn't work for it. Please mark these testing case as expected failure on this platform, or finish the implementation on powerpc backend
[Bug target/70210] -march=native and -mcpu=native do not detect ARM cortex-a53 in 32 bit mode on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70210 Viktor Engelmann changed: What|Removed |Added CC||Viktor.Engelmann@googlemail ||.com --- Comment #3 from Viktor Engelmann --- I see a (probably related) problem in gcc 9.3 on docker image alpine:latest on raspberry pi 3. There, Makefiles generated by autoconf pass -mcpu=armv7l. And you can't just force it to use a different cpu by passing --host= to ./configure in your Dockerfile, because that would break the Dockerfiles' cross-platform compatibility. This breaks all autoconf projects in docker on raspberry pi 3. This shouldn't be that hard IMHO, because -mcpu=armv7l only needs to be reinterpreted as -mcpu=cortex-a53.
[Bug c++/97681] New: noinline attribute ignored on constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97681
Bug ID: 97681
Summary: noinline attribute ignored on constexpr function
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ldalessandro at gmail dot com
Target Milestone: ---
GCC inlines function marked noinline when the function is marked as
`constexpr`, even if it is not used in `constexpr` context.
https://godbolt.org/z/b94Kje
```
[[gnu::noinline]] constexpr auto a() { return 1; }
[[gnu::noinline]] auto b() { return 2; }
int main() {
int i = a();
int j = b();
return i + j;
}
```
```
b():
mov eax, 2
ret
main:
callb()
add eax, 1
ret
```
[Bug c++/97681] noinline attribute ignored on constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97681 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- That is not inlining, but just constant expression evaluation. Attempting to constant evaluate initializers etc. even outside of constant expression is very important optimization, and noinline attribute has nothing to do with that.
[Bug c++/97681] noinline attribute ignored on constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97681 --- Comment #2 from Luke Dalessandro --- Okay, how would one constrain such inlining in order to retain a symbol and stack frame for debugging purposes?
[Bug c++/97681] noinline attribute ignored on constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97681 --- Comment #3 from Jakub Jelinek --- Don't mark it constexpr. Or, if it has any arguments, don't call it with constant arguments, but call it with non-constant ones.
[Bug c++/97681] noinline attribute ignored on constexpr function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97681 --- Comment #4 from Luke Dalessandro --- There are other occurrences of `a` that _are_ in `constexpr` context, it is used in both contexts within the application thus the keyword is necessary. This report came from a testcase reduction, so I'll have to look into what's going on in the real calling context (presumably it's *already* not `constexpr` there so it might not be an issue in practice in that context). I'd still suggest that a user that explicitly asks for `noinline`, even for a `constexpr` function, would expect `noinline` to take precedence over constant expression propagation, as the clang results provide. Perhaps some diagnostic warning can be manifested if constant expression evaluation is overriding the attribute? Thanks for the explanation.
