[Bug testsuite/102658] [12 regression] Many test case failures after r12-4240
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102658 --- Comment #11 from Kewen Lin --- > > For the failure: > > FAIL: libgomp.graphite/force-parallel-8.c scan-tree-dump-times graphite "5 > > loops carried no dependency" 1 > > > > It's not a target specific failure, Hongtao already posted one patch [2] for > > it. > > > > [2] https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581260.html > > Should be fixed by r12-4338 Nice, thanks!
[Bug testsuite/102658] [12 regression] Many test case failures after r12-4240
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102658 --- Comment #10 from Hongtao.liu --- (In reply to Kewen Lin from comment #9) > There are some discussions [1] to improve the fixing way for the test cases > in g++.dg and c-c++-common. So I hold the changes adding powerpc*-*-* onto > them, just updated the testcases under gcc.target/powerpc/. Will revisit > them once one better solution comes out. > > For the failure: > FAIL: libgomp.graphite/force-parallel-8.c scan-tree-dump-times graphite "5 > loops carried no dependency" 1 > > It's not a target specific failure, Hongtao already posted one patch [2] for > it. > > [1] https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581371.html > [2] https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581260.html Should be fixed by r12-4338
[Bug testsuite/102658] [12 regression] Many test case failures after r12-4240
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102658 --- Comment #9 from Kewen Lin --- There are some discussions [1] to improve the fixing way for the test cases in g++.dg and c-c++-common. So I hold the changes adding powerpc*-*-* onto them, just updated the testcases under gcc.target/powerpc/. Will revisit them once one better solution comes out. For the failure: FAIL: libgomp.graphite/force-parallel-8.c scan-tree-dump-times graphite "5 loops carried no dependency" 1 It's not a target specific failure, Hongtao already posted one patch [2] for it. [1] https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581371.html [2] https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581260.html
[Bug testsuite/102658] [12 regression] Many test case failures after r12-4240
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102658 --- Comment #8 from CVS Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:a124c1b0a2595f285c0d8ed863b37b83e14a6566 commit r12-4364-ga124c1b0a2595f285c0d8ed863b37b83e14a6566 Author: Kewen Lin Date: Wed Oct 13 00:20:45 2021 -0500 rs6000/test: Adjust test cases due to O2 vect [PR102658] Commit r12-4240 enables vectorization at O2, this patch is to adjust some test cases for rs6000 port accordingly. It simply adds -fno-tree-vectorize to retain original test points. gcc/testsuite/ChangeLog: PR testsuite/102658 * gcc.target/powerpc/dform-1.c: Adjust as vectorization enabled at O2. * gcc.target/powerpc/dform-2.c: Likewise. * gcc.target/powerpc/pr80510-2.c: Likewise.
[Bug tree-optimization/100464] [11 Regression] emitted binary code changes when -g is enabled at -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100464 --- Comment #13 from Chengnian Sun --- (In reply to Jakub Jelinek from comment #8) > gcc has the -fcompare-debug option, which compiles twice, once with -g and > once with -g -gtoggle and compares result, anything that fails with that > option with an error about debug vs. non-debug differences or potential > differences is a bug. Hi Jakub, Is the following flag is correct usage of -fcompare-debug? $ gcc -fcompare-debug -O3 t.c Also, what is the output or the exit code if gcc finds an inconsistency in debug info? Is there an internal compiler error? Thanks.
[Bug c++/95686] undefined reference to static local variable within inline function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95686 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code, lto --- Comment #6 from Andrew Pinski --- Note this code ICEs with LTO turned on also.
[Bug c++/95686] undefined reference to static local variable within inline function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95686 Andrew Pinski changed: What|Removed |Added CC||asolokha at gmx dot com --- Comment #5 from Andrew Pinski --- *** Bug 102723 has been marked as a duplicate of this bug. ***
[Bug c++/102723] ICE in get_partitioning_class, at symtab.c:2092
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102723 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Andrew Pinski --- This is a dup of bug 95686. Note the problem is seen even without LTO if you add a main function. There is an undefined symbol. The ICE and undefined symbols are the symptom of the same problem. *** This bug has been marked as a duplicate of bug 95686 ***
[Bug c++/102723] ICE in get_partitioning_class, at symtab.c:2092
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102723 Andrew Pinski changed: What|Removed |Added Component|ipa |c++ --- Comment #1 from Andrew Pinski --- template_type_parm should not leak to the middle-end from the front-end.
[Bug middle-end/101836] __builtin_object_size(P->M, 1) where M is an array and the last member of a struct fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 Siddhesh Poyarekar changed: What|Removed |Added CC||siddhesh at gotplt dot org --- Comment #5 from Siddhesh Poyarekar --- Vim explicitly disables _FORTIFY_SOURCE to keep its use of 1-sized trailing arrays: https://github.com/vim/vim/issues/5581 so either they haven't tested with more recent gcc or they're hitting a corner case where __builtin_object_size does return the subscript value for the trailing member. I inherited the __builtin_object_size behaviour in __builtin_dynamic_object_size to remain consistent with current behaviour: ok: sizeof(*working) == 24 ok: sizeof(working->c) == 16 ok: __builtin_object_size(working, 1) == -1 ok: __builtin_object_size(working->c, 1) == 16 ok: __builtin_dynamic_object_size(working, 1) == -1 ok: __builtin_dynamic_object_size(working->c, 1) == 16 ok: sizeof(*broken) == 24 ok: sizeof(broken->c) == 16 ok: __builtin_object_size(broken, 1) == -1 WAT: __builtin_object_size(broken->c, 1) == -1 (expected 16) ok: __builtin_dynamic_object_size(broken, 1) == -1 WAT: __builtin_dynamic_object_size(broken->c, 1) == -1 (expected 16) However in theory if the pass can see the allocation, it should be able to build the right expression for object size. I'm updating the patchset to meld the two passes into one and I could add -fstrict-flex-arrays as one of the patches to make this stricter.
[Bug ipa/102723] New: ICE in get_partitioning_class, at symtab.c:2092
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102723
Bug ID: 102723
Summary: ICE in get_partitioning_class, at symtab.c:2092
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, lto
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: ---
g++-12.0.0-alpha20211010 snapshot (g:74ccca380cde5e79e082d39214b306a90ded0344)
ICEs when compiling the following testcase, reduced from
test/SemaTemplate/instantiate-static-local.cpp from the clang 12.0.0 test
suite, w/ -flto:
template
struct A {
static constexpr int = R;
};
template
auto
S ()
{
static int s;
return A{};
}
auto s = decltype (S ())::value;
% g++-12.0.0 -flto -c bxra81wv.cpp
during IPA pass: modref
bxra81wv.cpp:14:32: internal compiler error: in get_partitioning_class, at
symtab.c:2092
14 | auto s = decltype (S ())::value;
|^
0x75e687 symtab_node::get_partitioning_class()
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211010/work/gcc-12-20211010/gcc/symtab.c:2092
0xfe627b lto_output_varpool_node
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211010/work/gcc-12-20211010/gcc/lto-cgraph.c:620
0xfe627b output_symtab()
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211010/work/gcc-12-20211010/gcc/lto-cgraph.c:987
0xffc874 lto_output()
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211010/work/gcc-12-20211010/gcc/lto-streamer-out.c:2813
0x1089881 write_lto
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211010/work/gcc-12-20211010/gcc/passes.c:2680
0x1089881 ipa_write_summaries_1
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211010/work/gcc-12-20211010/gcc/passes.c:2744
0x1089881 ipa_write_summaries()
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211010/work/gcc-12-20211010/gcc/passes.c:2800
0xcd95c2 ipa_passes
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211010/work/gcc-12-20211010/gcc/cgraphunit.c:2202
0xcd95c2 symbol_table::compile()
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211010/work/gcc-12-20211010/gcc/cgraphunit.c:2289
0xcdc137 symbol_table::compile()
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211010/work/gcc-12-20211010/gcc/cgraphunit.c:2269
0xcdc137 symbol_table::finalize_compilation_unit()
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211010/work/gcc-12-20211010/gcc/cgraphunit.c:2537
And g++ 11 ICEs differently:
during IPA pass: modref
bxra81wv.cpp:14:32: internal compiler error: tree code 'template_type_parm' is
not supported in LTO streams
14 | auto s = decltype (S ())::value;
|^
0x164fe9c internal_error(char const*, ...)
0xba7403 DFS::DFS(output_block*, tree_node*, bool, bool, bool)
0xbd0da8 lto_output_tree(output_block*, tree_node*, bool, bool)
0xbb0c41 produce_asm_for_decls()
0x904b26 symbol_table::finalize_compilation_unit()
[Bug middle-end/102722] New: [Disgnostic]Xpass for gcc.dg/Wstringop-overflow-68.c after O2 vectorization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102722
Bug ID: 102722
Summary: [Disgnostic]Xpass for gcc.dg/Wstringop-overflow-68.c
after O2 vectorization.
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: diagnostic
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
Target Milestone: ---
Host: x86_64-pc-linux-gnu
void warn_comp_lit (void)
{
*(AC2*)a1 = Ac2; // { dg-warning "writing 2 bytes into a region of size
1" "pr101475" { xfail *-*-* } }
// and warning should be expected, refer to PR102697.
*(AC4*)a2 = Ac4; // { dg-warning "writing 4 bytes into a region of size
2" "pr101475" { xfail { ! { i?86-*-* x86_64-*-* } } } }
*(AC4*)a3 = Ac4; // { dg-warning "writing 4 bytes into a region of size
3" "pr101475" { xfail { ! { i?86-*-* x86_64-*-* } } } }
*(AC8*)a4 = Ac8; // { dg-warning "writing 8 bytes into a region of size
4" "pr101475" { xfail { ! { i?86-*-* x86_64-*-* } } } }
*(AC8*)a7 = Ac8; // { dg-warning "writing 8 bytes into a region of size
7" "pr101475" { xfail { ! { i?86-*-* x86_64-*-* } } } }
*(AC16*)a15 = Ac16; // { dg-warning "writing 16 bytes into a region of size
15" "pr101475" { xfail { ! { i?86-*-* x86_64-*-* } } } }
}
The xpass here looks exact what we want，After vectorization, it's optimized to
// MEM [(char *)] = { 0, 1, 2, 3 };
// MEM [(char *)] = { 0, 1, 2, 3 };
// MEM [(char *)] = { 0, 1, 2, 3, 4, 5, 6, 7 };
// MEM [(char *)] = { 0, 1, 2, 3, 4, 5, 6, 7 };
// MEM [(char *)] = { 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10,
11, 12, 13, 14, 15 };
and Wstring-overflow catchs these.
[Bug tree-optimization/102462] vectorization breaks diagnostic for array out of bound detect.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102462
--- Comment #9 from Hongtao.liu ---
case 1: All accesses are out of bound, and after vectorization, there are
some warnings missing.(Because there only 1 access after vectorization, 2
accesses w/o vectorization, and diagnostic is based on access).
from c-c++-common/Wstringop-overflow-2.c
struct A1 a1__ = { 0 };
void ga1__ (void)
{
a1__.a[0] = 0;
a1__.a[1] = 1; // { dg-warning "\\\[-Wstringop-overflow" }
a1__.a[2] = 2; // { dg-warning "\\\[-Wstringop-overflow" }
struct A1 a = { 1 };
a.a[0] = 0;
// After vectorization, below codes are optimized to
// vector(2) char = { 1, 2}, there's only 1 access remained, so add xfail
// to a.a[2] = 2, refer to pr102462.
a.a[1] = 1;// { dg-warning "\\\[-Wstringop-overflow" }
a.a[2] = 2;// { dg-warning "\\\[-Wstringop-overflow" "" {
xfail { i?86-*-* x86_64-*-* } } }
sink ();
}
struct A1 a1_0 = { 0, { } };
void ga1_0_ (void)
{
a1_0.a[0] = 0;
a1_0.a[1] = 1;// { dg-warning "\\\[-Wstringop-overflow" }
a1_0.a[2] = 2;// { dg-warning "\\\[-Wstringop-overflow" }
struct A1 a = { 1, { } };
a.a[0] = 0;
a.a[1] = 1; // { dg-warning "\\\[-Wstringop-overflow" }
a.a[2] = 2; // { dg-warning "\\\[-Wstringop-overflow" "" {
xfail { i?86-*-* x86_64-*-* } } }
sink ();
}
struct A1i a1i__ = { 0 };
void ga1i__ (void)
{
a1i__.a[0] = 0;
a1i__.a[1] = 1;// { dg-warning "\\\[-Wstringop-overflow" }
a1i__.a[2] = 2;// { dg-warning "\\\[-Wstringop-overflow" }
struct A1i a = { 0 };
a.a[0] = 0;
a.a[1] = 1;// { dg-warning "\\\[-Wstringop-overflow" }
a.a[2] = 2;// { dg-warning "\\\[-Wstringop-overflow" "" {
xfail { i?86-*-* x86_64-*-* } } }
sink ();
}
struct A1 a1i_0 = { 0, { } };
void ga1i_0_ (void)
{
a1i_0.a[0] = 0;
a1i_0.a[1] = 1; // { dg-warning "\\\[-Wstringop-overflow" }
a1i_0.a[2] = 2; // { dg-warning "\\\[-Wstringop-overflow" }
struct A1 a = { 0, { } };
a.a[0] = 0;
a.a[1] = 1; // { dg-warning "\\\[-Wstringop-overflow" }
a.a[2] = 2; // { dg-warning "\\\[-Wstringop-overflow" "" {
xfail { i?86-*-* x86_64-*-* } } }
sink ();
}
[Bug tree-optimization/102706] [12 regression] -O2 vectorization causes regression in Warray-bounds-48.c on many targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102706
--- Comment #3 from Hongtao.liu ---
>From gcc.dg/Warray-bounds-51.c
void test_struct_char_vla_location (void)
{
unsigned nelts = 7;
struct {
char cvla[nelts]; // { dg-message "declared here|while referencing" }
} s;
s.cvla[0] = __LINE__;
s.cvla[nelts - 1] = 0; // { dg-warning "\\\[-Wstringop-overflow" "" { target
{ i?86-*-* x86_64-*-* } } }
s.cvla[nelts] = 0; // { dg-warning "\\\[-Warray-bounds" }
sink ();
}
>From gcc.dg/Warray-parameter-3.c
__attribute__ ((noipa)) void
gcas3 (char a[static 3])
{
a[0] = 0; a[1] = 1; a[2] = 2; // { dg-warning "\\\[-Wstringop-overflow" "" {
target { i?86-*-* x86_64-*-* } } }
a[3] = 3; // { dg-warning "\\\[-Warray-bounds" }
}
>From gcc.dg/Wstringop-overflow-14.c
void test_int16 (void)
{
char *p = a4 + 1;
*(int16_t*)p = 0;// { dg-warning "writing 4 bytes into a region of size
3" "" { target { i?86-*-* x86_64-*-* } } }
*(int16_t*)(p + 2) = 0; // { dg-warning "writing 2 bytes into a region of
size 1" "" { xfail { i?86-*-* x86_64-*-* } } }
}
>From gcc.dg/Wstringop-overflow-21.c
void test_store_zero_length (int i)
{
char a[3];
struct S0 *p = (struct S0*)a;
p->a = 0; // { dg-warning "\\\[-Wstringop-overflow"
"" { target { i?86-*-* x86_64-*-* } } }
p->b[0] = 0;
p->b[1] = 1; // { dg-bogus "\\\[-Wstringop-overflow" }
p->b[2] = 2; // { dg-warning "\\\[-Wstringop-overflow"
"" { xfail { i?86-*-* x86_64-*-* } } }
p->b[i] = 2;
sink (p);
}
void test_store_flexarray (int i)
{
char a[3];
struct Sx *p = (struct Sx*)a;
p->a = 0; // { dg-warning "\\\[-Wstringop-overflow"
"" { target { i?86-*-* x86_64-*-* } } }
p->b[0] = 0;
p->b[1] = 1; // { dg-bogus "\\\[-Wstringop-overflow" }
p->b[2] = 1; // { dg-warning "\\\[-Wstringop-overflow"
"" { xfail { i?86-*-* x86_64-*-* } } }
p->b[i] = 2;
sink (p);
}
>From gcc.dg/Wstringop-overflow-76.c:
extern char a3[3];
extern char a5[5]; // { dg-message "at offset \[^a-zA-Z\n\r\]*5\[^a-zA-Z0-9\]*
into destination object 'a5' of size 5" "note" }
void max_a3_a5 (int i)
{
char *p = a3 + i;
char *q = a5 + i;
/* The relational expression below is invalid and should be diagnosed
by its own warning independently of -Wstringop-overflow. */
char *d = MAX (p, q);
d[2] = 0; // { dg-warning "writing 4 bytes into a region of size 3"
"" { target { i?86-*-* x86_64-*-* } } }
d[3] = 0;
d[4] = 0;
d[5] = 0; // { dg-warning "writing 1 byte into a region of size 0" ""
{ xfail { i?86-*-* x86_64-*-* } } }
}
// Same as above but with the larger array as the first MAX_EXPR operand.
extern char b4[4];
extern char b6[6]; // { dg-message "at offset \[^a-zA-Z\n\r\]*6\[^a-zA-Z0-9\]*
into destination object 'b6' of size 6" "note" }
void max_b6_b4 (int i)
{
char *p = b6 + i;
char *q = b4 + i;
char *d = MAX (p, q);
d[3] = 0; // { dg-warning "writing 4 bytes into a region of size 3"
"" { target { i?86-*-* x86_64-*-* } } }
d[4] = 0;
d[5] = 0;
d[6] = 0; // { dg-warning "writing 1 byte into a region of size 0" ""
{ xfail { i?86-*-* x86_64-*-* } } }
}
[Bug testsuite/102658] [12 regression] Many test case failures after r12-4240
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102658 --- Comment #7 from Kewen Lin --- r12-4273 caused some new expected failures: FAIL: c-c++-common/Wstringop-overflow-2.c -Wc++-compat (test for excess errors) FAIL: c-c++-common/Wstringop-overflow-2.c -std=gnu++14 (test for excess errors) FAIL: c-c++-common/Wstringop-overflow-2.c -std=gnu++17 (test for excess errors) FAIL: c-c++-common/Wstringop-overflow-2.c -std=gnu++2a (test for excess errors) FAIL: c-c++-common/Wstringop-overflow-2.c -std=gnu++98 (test for excess errors) FAIL: gcc.dg/Warray-parameter-3.c (test for excess errors) FAIL: gcc.dg/Wstringop-overflow-21.c (test for excess errors) FAIL: gcc.dg/Wstringop-overflow-76.c (test for excess errors) which have been considered in the associated patch already.
[Bug tree-optimization/102706] [12 regression] -O2 vectorization causes regression in Warray-bounds-48.c on many targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102706
--- Comment #2 from Hongtao.liu ---
case (2): Part of accesses are inbound, part of accesses are out of bound,
and after vectorization, the warning goes from out of bound line to
inbound line.
>From Wstringop-overflow-2.c:
struct A1 a1_1 = { 0, { 1 } };
void ga1_1 (void)
{
a1_1.a[0] = 0;
a1_1.a[1] = 1;// { dg-warning "\\\[-Wstringop-overflow" }
a1_1.a[2] = 2;// { dg-warning "\\\[-Wstringop-overflow" }
struct A1 a = { 0, { 1 } }; // { dg-warning "\\\[-Wstringop-overflow" "" {
target { i?86-*-* x86_64-*-* } } }
a.a[0] = 0;
a.a[1] = 1; // { dg-warning "\\\[-Wstringop-overflow" "" {
xfail { i?86-*-* x86_64-*-* } } }
a.a[2] = 2; // { dg-warning "\\\[-Wstringop-overflow" "" {
xfail { i?86-*-* x86_64-*-* } } }
sink ();
}
struct A1 a1i_1 = { 0, { 1 } };
void ga1i_1 (void)
{
a1i_1.a[0] = 0;
a1i_1.a[1] = 1; // { dg-warning "\\\[-Wstringop-overflow" }
a1i_1.a[2] = 2; // { dg-warning "\\\[-Wstringop-overflow" }
// Refer to PR102462
struct A1 a = { 0, { 1 } }; // { dg-warning "\\\[-Wstringop-overflow" "" {
target { i?86-*-* x86_64-*-* } } }
a.a[0] = 1;
a.a[1] = 2; // { dg-warning "\\\[-Wstringop-overflow" "" {
xfail { i?86-*-* x86_64-*-* } } }
a.a[2] = 3; // { dg-warning "\\\[-Wstringop-overflow" "" {
xfail { i?86-*-* x86_64-*-* } } }
sink ();
}
[Bug testsuite/102658] [12 regression] Many test case failures after r12-4240
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102658 --- Comment #6 from Kewen Lin --- *** Bug 102713 has been marked as a duplicate of this bug. ***
[Bug other/102713] [12 regression] Several failures after r12-3273
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102713 Kewen Lin changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED Assignee|unassigned at gcc dot gnu.org |linkw at gcc dot gnu.org --- Comment #1 from Kewen Lin --- These new failures are expected since the typos for target selector which are fixed by this commit made these cases pass unexpectedly before (that is running on powerpc without any selector). I would mark this as duplicated of PR102658. The posted patch for PR102658 can fix these failures. *** This bug has been marked as a duplicate of bug 102658 ***
[Bug testsuite/102720] [12 regression] gcc.dg/tree-ssa/ldist-strlen-1.c and ldist-strlen-2.c fail after r12-4234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102720 Martin Sebor changed: What|Removed |Added Last reconfirmed||2021-10-13 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||msebor at gcc dot gnu.org --- Comment #1 from Martin Sebor --- Confirmed, also reported on x86_64 and i686: https://gcc.gnu.org/pipermail/gcc-testresults/2021-October/727873.html https://gcc.gnu.org/pipermail/gcc-testresults/2021-October/727870.html
[Bug middle-end/101836] __builtin_object_size(P->M, 1) where M is an array and the last member of a struct fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 Martin Sebor changed: What|Removed |Added Severity|normal |enhancement Component|c |middle-end
[Bug tree-optimization/102714] A volatile-related problem cased by ipa inline pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102714 --- Comment #1 from Jeffle Xu --- Some more detailed information about the effect to the application: Linux kernel relies 'volatile' to do synchronization. Let's say, there are two processes accessing one memory, one of them will write the memory, while the other will read the memory (through 'volatile') in a loop. That is, these two processes will synchronize with each other with this shared memory. With this bug, the process reading the memory may always read the old value (cached in the register) rather than get the new value (from memory), and thus will get stuck in the infinite loop and finally causes soft lockup.
[Bug c/101836] __builtin_object_size(P->M, 1) where M is an array and the last member of a struct fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 Martin Sebor changed: What|Removed |Added Last reconfirmed||2021-10-13 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||msebor at gcc dot gnu.org, ||siddhesh at redhat dot com --- Comment #4 from Martin Sebor --- I'm not sure how feasible it is to change __builtin_object_size or to add an option to control this behavior but I agree that treating all trailing arrays as flexible array members is overly permissive and unhelpful (GCC warnings like -Warray-bounds are stricter and treat only zero and one-element arrays that way). Let me confirm this request and CC Siddhesh who just submitted a patch for __builtin_dynamic_object_size. Maybe that's a way toward something stricter.
[Bug target/102543] -march=cascadelake performs odd alignment peeling
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102543 --- Comment #9 from Hongtao.liu --- I'm curious why we need peeling for unaligned access, because unaligned access instructions should also be available for aligned addresses, can't we just mark mem_ref as unaligned (although this is fake, just to generate unaligned instructions for the back end only)
[Bug tree-optimization/95384] Poor codegen cause by using base class instead of member for Optional construction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95384
--- Comment #4 from Barry Revzin ---
Here's another example of the same kind of issue
(https://godbolt.org/z/KWr9rMssj):
template
struct tagged_union {
tagged_union(T t) : index(0), a(t) { }
tagged_union(U u) : index(1), b(u) { }
union {
T a;
U b;
};
char index;
};
struct X { int i; };
struct Y { int j; };
tagged_union as_tagged_union(X x) {
return x;
}
template
struct tagged_union_wrapped : tagged_union {
using tagged_union::tagged_union;
};
auto as_tagged_union2(X x) {
return tagged_union_wrapped(x);
}
this on -O3 emits:
as_tagged_union(X):
mov eax, edi
ret
as_tagged_union2(X):
mov DWORD PTR [rsp-8], edi
mov BYTE PTR [rsp-4], 0
mov rax, QWORD PTR [rsp-8]
ret
If you change the index member from 'char' to 'int', causing the tail padding
to disappear, as_tagged_union2 improves to the same code gen as
as_tagged_union.
This is relevant for std::variant performance. std::variant behaves like
tagged_union_wrapped, whereas if you drop down to the implementation
details and directly use _Variant_storage_alias, that behaves like
tagged_union for these purposes.
[Bug c++/54367] [meta-bug] lambda expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 Bug 54367 depends on bug 102367, which changed state. Bug 102367 Summary: types can be defined in lambdas in unevaluated expression (decltype/sizeof) in C++20 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102367 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/101911] Type cannot be defined inside of the lambda in unevaluated context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101911 Andrew Pinski changed: What|Removed |Added CC||fchelnokov at gmail dot com --- Comment #2 from Andrew Pinski --- *** Bug 102367 has been marked as a duplicate of this bug. ***
[Bug c++/102367] types can be defined in lambdas in unevaluated expression (decltype/sizeof) in C++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102367 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > I thought there was a dup of this bug somewhere. > Anyways confirmed. I did, PR 101911. *** This bug has been marked as a duplicate of bug 101911 ***
[Bug c++/102721] out-of-line member function definition fails to allow lambda in unevaluated-context of new feature in c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102721 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=92707 --- Comment #3 from Andrew Pinski --- Maybe related to PR 92707.
[Bug c++/102721] out-of-line member function definition fails to allow lambda in unevaluated-context of new feature in c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102721
--- Comment #2 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #1)
> Confirmed,
> Here is a better example of what is going wrong:
> template
> struct A
> {
> void foo(const T){}
> };
>
> using t = decltype(+[]{})[3];
> using t1 = const decltype(+[]{})[3];
>
> template<>
> void A::foo(t1)
> {}
>
> template<>
> void A::foo(const decltype(+[]{})[4])
> {}
>
> The first template specialization is accepted but the second one is not.
Note it is not array related either:
template<>
void A::foo(const decltype(+[]{}))
{}
[Bug c++/102721] out-of-line member function definition fails to allow lambda in unevaluated-context of new feature in c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102721
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-10-12
Ever confirmed|0 |1
--- Comment #1 from Andrew Pinski ---
Confirmed,
Here is a better example of what is going wrong:
template
struct A
{
void foo(const T){}
};
using t = decltype(+[]{})[3];
using t1 = const decltype(+[]{})[3];
template<>
void A::foo(t1)
{}
template<>
void A::foo(const decltype(+[]{})[4])
{}
The first template specialization is accepted but the second one is not.
[Bug c++/102721] New: out-of-line member function definition fails to allow lambda in unevaluated-context of new feature in c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102721
Bug ID: 102721
Summary: out-of-line member function definition fails to allow
lambda in unevaluated-context of new feature in c++20
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
The following snippet code exposes that GCC parser doesn't comply with c++20
standard to allow lambda in unevaluated context. It seems this out-of-line
definition creates a new lambda type where lambda as operand of "decltype"
should be treated as in unevaluated context. So, it shouldn't create a new
lambda type in out-of-line definition.
Both clang and MSVC++ (https://www.godbolt.org/z/EMbb44fd8) parse this
correctly.
(with "-std=c++20")
template
struct A
{
void foo(const T){}
};
template<>
void A::foo(const decltype(+[]{})[3])
{}
:9:6: error: ambiguating new declaration of 'void A::foo(void (* const*)())'
9 | void A::foo(const decltype(+[]{})[3])
| ^
:5:10: note: old declaration 'void A::foo(T) [with T = void (*
[3])()]'
5 | void foo(const T){}
| ^~~
[Bug testsuite/102719] [12 regression] several failures after r12-4337
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102719 --- Comment #1 from seurer at gcc dot gnu.org --- FAIL: gcc.target/powerpc/sse4_2-pcmpgtq.c (test for excess errors) Also fails on power 8 & 9.
[Bug modula2/102325] gm2 testsuite drivers should be unique
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102325 --- Comment #2 from Gaius Mulley --- Many thanks for reporting this bug/issue. I've now git pushed changes which have renamed all the gm2.exp driver scripts as distinct names.
[Bug libstdc++/100070] Standard library container iterator-pair constructors should check C++20 iterator concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100070 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=102181 --- Comment #10 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #4) > Barry suggested out-of-band that we could change std::__iterator_category to > determine the result based on the C++20 iterator concepts. That looks > promising. > > std::distance dispatches on the result of std::__iterator_category, and > doesn't care whether some meets all the Cpp17RandomAccessIterator > requirements, it only cares whether (last - first) is valid and efficient. I have a patch to do this for PR 102181 however the suggested direction for lwg 3197 is to require Cpp17InputIterator for std distance, and not Do The Right Thing for C++20 iterators. We could of course so it anyway as a valid interpretation of a precondition violation.
[Bug target/101985] vec_cpsgn parameter order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101985 --- Comment #6 from Bill Schmidt --- Currently fixed on trunk. The parts of the fix that don't involve the new builtin infrastructure should be backported to all releases after some burn-in time.
[Bug target/101985] vec_cpsgn parameter order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101985 --- Comment #5 from CVS Commits --- The master branch has been updated by William Schmidt : https://gcc.gnu.org/g:76ba473b99c30ddec6171840a76292d6d4b67e7c commit r12-4361-g76ba473b99c30ddec6171840a76292d6d4b67e7c Author: Bill Schmidt Date: Tue Oct 12 17:37:16 2021 -0500 rs6000: Fix vec_cpsgn parameter order (PR101985) The vec_cpsgn built-in function API differs in argument order from the copysign3 convention. Currently that pattern is incorrctly used to implement vec_cpsgn. Fix that by reversing the operand order of the builtin while leaving the existing pattern in place to implement copysignf for vector modes. Part of the fix when using the new built-in support requires an adjustment to a pending patch that replaces much of altivec.h with an automatically generated file. Also fix a bug in the new built-in overload infrastructure where we were using the VSX form of the VEC_COPYSIGN built-in when we should default to the VMX form. 2021-10-12 Bill Schmidt gcc/ PR target/101985 * config/rs6000/altivec.h (vec_cpsgn): Swap operand order. * config/rs6000/rs6000-overload.def (VEC_COPYSIGN): Use SKIP to avoid generating an automatic #define of vec_cpsgn. Use the correct built-in for V4SFmode that doesn't depend on VSX. gcc/testsuite/ PR target/101985 * gcc.target/powerpc/pr101985-1.c: New. * gcc.target/powerpc/pr101985-2.c: New.
[Bug libstdc++/100070] Standard library container iterator-pair constructors should check C++20 iterator concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100070 Patrick Palka changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=100795 --- Comment #9 from Patrick Palka --- This seems to be related to the correctness bug PR100795: some of our ranges::algos (e.g. ranges::inplace_merge) are implemented as simple wrappers over the corresponding std::algo, but that breaks in cases where the std::algo has a minimum requirement on the range's iterator_category..
[Bug testsuite/102720] New: [12 regression] gcc.dg/tree-ssa/ldist-strlen-1.c and ldist-strlen-2.c fail after r12-4234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102720 Bug ID: 102720 Summary: [12 regression] gcc.dg/tree-ssa/ldist-strlen-1.c and ldist-strlen-2.c fail after r12-4234 Product: gcc Version: 12.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:008e7397dad971c03c08fc1b0a4a98fddccaaed8, r12-4324 FAIL: gcc.dg/tree-ssa/ldist-strlen-1.c execution test FAIL: gcc.dg/tree-ssa/ldist-strlen-2.c execution test Executing on host: /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ exceptions_enabled3377861.cc -fdiagnostics-plain-output -S -o exceptions_enabled3377861.s(timeout = 300) spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ exceptions_enabled3377861.cc -fdiagnostics-plain-output -S -o exceptions_enabled3377861.s PASS: gcc.dg/tree-ssa/ldist-strlen-1.c (test for excess errors) Setting LD_LIBRARY_PATH to :/home/seurer/gcc/git/build/gcc-test/gcc::/home/seurer/gcc/git/build/gcc-test/gcc:/home/seurer/gcc/git/build/gcc-test/./gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./isl/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-isl/.libs Execution timeout is: 300 spawn [open ...] ldist-strlen-1.exe: /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/tree-ssa/ldist-strlen-1.c:52: main: Assertion `test_uint8_tsize_t (p) == 1' failed. FAIL: gcc.dg/tree-ssa/ldist-strlen-1.c execution test spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/tree-ssa/ldist-strlen-2.c -fdiagnostics-plain-output -O2 -ftree-loop-distribution -fdump-tree-ldist-details -lm -o ./ldist-strlen-2.exe PASS: gcc.dg/tree-ssa/ldist-strlen-2.c (test for excess errors) Setting LD_LIBRARY_PATH to :/home/seurer/gcc/git/build/gcc-test/gcc::/home/seurer/gcc/git/build/gcc-test/gcc:/home/seurer/gcc/git/build/gcc-test/./gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-gmp/.libs:/home/seurer/gcc/git/build/gcc-test/./mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test/./mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test/./isl/.libs:/home/seurer/gcc/git/build/gcc-test/./prev-isl/.libs Execution timeout is: 300 spawn [open ...] ldist-strlen-2.exe: /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/tree-ssa/ldist-strlen-2.c:43: main: Assertion `test_pos (s) == 42+13' failed. FAIL: gcc.dg/tree-ssa/ldist-strlen-2.c execution test commit 008e7397dad971c03c08fc1b0a4a98fddccaaed8 (HEAD, refs/bisect/bad) Author: Jan Hubicka Date: Mon Oct 11 18:43:26 2021 +0200 Commonize ipa-pta constraint generation for calls
[Bug testsuite/102719] New: [12 regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102719 Bug ID: 102719 Summary: [12 regression] Product: gcc Version: 12.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:82bc9355eebd6f92fecdee464ea36f6f75994780, r12-4337 These fail on power 7 both 32 and 64 bits. FAIL: gcc.target/powerpc/pr78102.c (test for excess errors) FAIL: gcc.target/powerpc/pr78102.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-packusdw.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-packusdw.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pmaxsb.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pmaxsb.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pmaxsd.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pmaxsd.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pmaxud.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pmaxud.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pmaxuw.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pmaxuw.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pminsb.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pminsb.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pminsd.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pminsd.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pminud.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pminud.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pminuw.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pminuw.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pmovsxbd.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pmovsxbd.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pmovsxbw.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pmovsxbw.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pmovsxwd.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pmovsxwd.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pmovzxbd.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pmovzxbd.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pmovzxbq.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pmovzxbq.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pmovzxbw.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pmovzxbw.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pmovzxdq.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pmovzxdq.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pmovzxwd.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pmovzxwd.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pmovzxwq.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pmovzxwq.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pmulld.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_1-pmulld.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_2-pcmpgtq.c (test for excess errors) FAIL: gcc.target/powerpc/sse4_2-pcmpgtq.c (test for excess errors) spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/sse4_1-packusdw.c -fdiagnostics-plain-output -O2 -mvsx -lm -o ./sse4_1-packusdw.exe In file included from /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/m128-check.h:9, from /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/sse4_1-check.h:8, from /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/sse4_1-packusdw.c:13: /home/seurer/gcc/git/build/gcc-test/gcc/include/emmintrin.h: In function '_mm_cmpord_pd': /home/seurer/gcc/git/build/gcc-test/gcc/include/emmintrin.h:444:3: note: builtin '__builtin_vec_cmpgt' requires builtin '__builtin_altivec_vcmpgtud' /home/seurer/gcc/git/build/gcc-test/gcc/include/emmintrin.h:445:3: note: builtin '__builtin_vec_cmpgt' requires builtin '__builtin_altivec_vcmpgtud' /home/seurer/gcc/git/build/gcc-test/gcc/include/emmintrin.h: In function '_mm_mul_epu32': /home/seurer/gcc/git/build/gcc-test/gcc/include/emmintrin.h:1498:3: note: builtin '__builtin_vec_mule' requires builtin '__builtin_altivec_vmuleuw' In file included from /home/seurer/gcc/git/build/gcc-test/gcc/include/tmmintrin.h:44, from /home/seurer/gcc/git/build/gcc-test/gcc/include/smmintrin.h:43, from /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.target/powerpc/sse4_1-packusdw.c:15: /home/seurer/gcc/git/build/gcc-test/gcc/include/pmmintrin.h: In function '_mm_movehdup_ps': /home/seurer/gcc/git/build/gcc-test/gcc/include/pmmintrin.h:129:3: note: builtin '__builtin_vec_vmrgow' requires builtin
[Bug fortran/102717] ICE in gfc_simplify_reshape, at fortran/simplify.c:6843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102717
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Ever confirmed|0 |1
Last reconfirmed||2021-10-12
CC||anlauf at gcc dot gnu.org
Status|UNCONFIRMED |NEW
--- Comment #1 from anlauf at gcc dot gnu.org ---
Tentative fix (not regtested):
diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c
index f40e4930b58..5d29ab23dff 100644
--- a/gcc/fortran/simplify.c
+++ b/gcc/fortran/simplify.c
@@ -6840,7 +6840,13 @@ gfc_simplify_reshape (gfc_expr *source, gfc_expr
*shape_exp,
gfc_extract_int (e, [rank]);
gcc_assert (rank >= 0 && rank < GFC_MAX_DIMENSIONS);
- gcc_assert (shape[rank] >= 0);
+ if (shape[rank] < 0)
+ {
+ gfc_error ("The SHAPE array for the RESHAPE intrinsic has a "
+"negative value %d for dimension %d",
+shape[rank], rank+1);
+ return _bad_expr;
+ }
rank++;
}
[Bug fortran/102716] ICE in gfc_validate_kind(): Got bad kind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102716 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-10-12 Ever confirmed|0 |1 CC||anlauf at gcc dot gnu.org --- Comment #1 from anlauf at gcc dot gnu.org --- Moving the check on the KIND argument seems to fix this (not regtested): diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c index 677209ee95e..cfaf9d26bbc 100644 --- a/gcc/fortran/check.c +++ b/gcc/fortran/check.c @@ -5086,6 +5086,13 @@ gfc_check_shape (gfc_expr *source, gfc_expr *kind) if (gfc_invalid_null_arg (source)) return false; + if (!kind_check (kind, 1, BT_INTEGER)) +return false; + if (kind && !gfc_notify_std (GFC_STD_F2003, "%qs intrinsic " + "with KIND argument at %L", + gfc_current_intrinsic, >where)) +return false; + if (source->rank == 0 || source->expr_type != EXPR_VARIABLE) return true; @@ -5098,13 +5105,6 @@ gfc_check_shape (gfc_expr *source, gfc_expr *kind) return false; } - if (!kind_check (kind, 1, BT_INTEGER)) -return false; - if (kind && !gfc_notify_std (GFC_STD_F2003, "%qs intrinsic " - "with KIND argument at %L", - gfc_current_intrinsic, >where)) -return false; - return true; }
[Bug libstdc++/93884] ranges::copy doesn't like output iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93884 Patrick Palka changed: What|Removed |Added Target Milestone|--- |10.0 Status|NEW |RESOLVED CC||ppalka at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Patrick Palka --- Fixed (for GCC 10+)
[Bug other/102718] New: gtype-desc.c function redefinition error for gt_ggc_xxx (int_hash&)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102718 Bug ID: 102718 Summary: gtype-desc.c function redefinition error for gt_ggc_xxx (int_hash&) Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: msebor at gcc dot gnu.org Target Milestone: --- This is to make a record of a bug in GCC's garbage collection machinery. With the following patch I get the errors below. gtype-desc.c is a generated file and the errors are due to the gengtype tool generating two definitions of the gt_ggc_xxx functions, one for each specialization of the hash_map. It seems that it's not possible to have two hash_maps with keys of distinct types but the same element type. diff --git a/gcc/diagnostic-spec.c b/gcc/diagnostic-spec.c index 85ffb725c02..dc98696132a 100644 --- a/gcc/diagnostic-spec.c +++ b/gcc/diagnostic-spec.c @@ -108,6 +108,7 @@ nowarn_spec_t::nowarn_spec_t (opt_code opt) /* A mapping from a 'location_t' to the warning spec set for it. */ GTY(()) xint_hash_map_t *nowarn_map; +extern GTY(()) int_hash_map_t *nowarn_map_2; /* Return the no-warning disposition for location LOC and option OPT or for all/any otions by default. */ diff --git a/gcc/diagnostic-spec.h b/gcc/diagnostic-spec.h index 9b33ce6..b1fb304c2f3 100644 --- a/gcc/diagnostic-spec.h +++ b/gcc/diagnostic-spec.h @@ -136,4 +136,8 @@ typedef hash_map xint_hash_map_t; /* A mapping from a 'location_t' to the warning spec set for it. */ extern GTY(()) xint_hash_map_t *nowarn_map; +typedef int_hash int_hash_t; +typedef hash_map int_hash_map_t; +extern GTY(()) int_hash_map_t *nowarn_map_2; + #endif // DIAGNOSTIC_SPEC_H_INCLUDED synchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I/src/gcc/master/gcc -I/src/gcc/master/gcc/. -I/src/gcc/master/gcc/../include -I/src/gcc/master/gcc/../libcpp/include -I/src/gcc/master/gcc/../libcody -I/src/gcc/master/gcc/../libdecnumber -I/src/gcc/master/gcc/../libdecnumber/bid -I../libdecnumber -I/src/gcc/master/gcc/../libbacktrace -o gtype-desc.o -MT gtype-desc.o -MMD -MP -MF ./.deps/gtype-desc.TPo gtype-desc.c gtype-desc.c:3037:1: error: redefinition of ‘void gt_ggc_mx(nowarn_spec_t&)’ gt_ggc_mx (struct nowarn_spec_t& x_r ATTRIBUTE_UNUSED) ^ gtype-desc.c:3014:1: note: ‘void gt_ggc_mx(nowarn_spec_t&)’ previously defined here gt_ggc_mx (struct nowarn_spec_t& x_r ATTRIBUTE_UNUSED) ^ gtype-desc.c:3043:1: error: redefinition of ‘void gt_ggc_mx(int_hash&)’ gt_ggc_mx (int_hash& x_r ATTRIBUTE_UNUSED) ^ gtype-desc.c:3020:1: note: ‘void gt_ggc_mx(int_hash&)’ previously defined here gt_ggc_mx (int_hash& x_r ATTRIBUTE_UNUSED) ^ gtype-desc.c:6999:1: error: redefinition of ‘void gt_pch_nx(nowarn_spec_t&)’ gt_pch_nx (struct nowarn_spec_t& x_r ATTRIBUTE_UNUSED) ^ gtype-desc.c:6976:1: note: ‘void gt_pch_nx(nowarn_spec_t&)’ previously defined here gt_pch_nx (struct nowarn_spec_t& x_r ATTRIBUTE_UNUSED) ^ gtype-desc.c:7005:1: error: redefinition of ‘void gt_pch_nx(int_hash&)’ gt_pch_nx (int_hash& x_r ATTRIBUTE_UNUSED) ^ gtype-desc.c:6982:1: note: ‘void gt_pch_nx(int_hash&)’ previously defined here gt_pch_nx (int_hash& x_r ATTRIBUTE_UNUSED) ^ gtype-desc.c:11395:1: error: redefinition of ‘void gt_pch_nx(nowarn_spec_t*, gt_pointer_operator, void*)’ gt_pch_nx (struct nowarn_spec_t* x ATTRIBUTE_UNUSED, ^ gtype-desc.c:11369:1: note: ‘void gt_pch_nx(nowarn_spec_t*, gt_pointer_operator, void*)’ previously defined here gt_pch_nx (struct nowarn_spec_t* x ATTRIBUTE_UNUSED, ^ gtype-desc.c:11402:1: error: redefinition of ‘void gt_pch_nx(int_hash*, gt_pointer_operator, void*)’ gt_pch_nx (int_hash* x ATTRIBUTE_UNUSED, ^ gtype-desc.c:11376:1: note: ‘void gt_pch_nx(int_hash*, gt_pointer_operator, void*)’ previously defined here gt_pch_nx (int_hash* x ATTRIBUTE_UNUSED, ^
[Bug middle-end/102700] [12 Regression] wrong location in -Wuninitialized after -O2 vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102700 Martin Sebor changed: What|Removed |Added Last reconfirmed||2021-10-12 CC||msebor at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Summary|[Diagnostics] uninitialized |[12 Regression] wrong |warning missing after O2|location in -Wuninitialized |vectorization. |after -O2 vectorization Blocks|88443 |24639 --- Comment #3 from Martin Sebor --- It looks like it's just the the location of the warning that's off, the warning itself is still issued but it's swallowed by the dg-prune-output directive. Since the test was added to verify the fix for an ICE without vectorization I think disabling vectorization should be fine. Ideally, we would understand why the location is wrong so let's keep this bug open and add a comment to the test referencing this bug. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 [Bug 24639] [meta-bug] bug to track all Wuninitialized issues https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 [Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
[Bug other/102657] libcody makefile is missing a mostlyclean target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102657 --- Comment #3 from Eric Gallager --- it's missing a TAGS target, too, but I can handle that as part of this: https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581485.html
[Bug libstdc++/100285] experimental/net/socket/socket_base.cc fails on arm-eabi (r12-137)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100285 --- Comment #12 from Jonathan Wakely --- This is failing for aarch64-none-elf: FAIL: experimental/net/headers.cc (test for excess errors) Could you let me know what the error is please?
[Bug libstdc++/98677] std::regex constructor triggers valgrind under clang++ with undefined sanitizer; possible use-after-move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98677 --- Comment #6 from Jonathan Wakely --- I can reproduce it in a container using: FROM ubuntu:20.04 RUN apt-get update RUN echo 'tzdata tzdata/Areas select Europe' | debconf-set-selections RUN echo 'tzdata tzdata/Zones/Europe select London' | debconf-set-selections RUN DEBIAN_FRONTEND="noninteractive" apt-get -y install tzdata RUN apt-get -y install build-essential clang-10 valgrind COPY test.cc /tmp/ RUN clang++-10 -fsanitize=undefined -O1 -g /tmp/test.cc -o /tmp/a.out && valgrind /tmp/a.out But it's not caused by the move (it still happens if I copy the state object instead of moving it). Initializing the _State_base::_M_match_storage buffer doesn't help. Nothing I changed in the code helped. I think it's a ubsan bug in clang 10 and clang 11.
[Bug middle-end/102700] [Diagnostics] uninitialized warning missing after O2 vectorization.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102700 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #2 from Eric Gallager --- Why is this put as blocking the Wstringop-overflow meta-bug instead of the Wuninitialized one?
[Bug libstdc++/100285] experimental/net/socket/socket_base.cc fails on arm-eabi (r12-137)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100285 --- Comment #11 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:b7e73951fd15f07946ff0c56f4e31b0006c621f9 commit r11-9141-gb7e73951fd15f07946ff0c56f4e31b0006c621f9 Author: Jonathan Wakely Date: Thu Aug 26 12:06:55 2021 +0100 libstdc++: Make Networking TS headers more portable [PR100285] Add more preprocessor conditions to check for constants being defined before using them, so that the Networking TS headers can be compiled on a wider range of platforms. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/100285 * configure.ac: Check for O_NONBLOCK. * configure: Regenerate. * include/experimental/internet: Include for Windows. Use preprocessor conditions around more constants. * include/experimental/socket: Use preprocessor conditions around more constants. * testsuite/experimental/net/internet/resolver/base.cc: Only use constants when the corresponding C macro is defined. * testsuite/experimental/net/socket/basic_socket.cc: Likewise. * testsuite/experimental/net/socket/socket_base.cc: Likewise. Make preprocessor checks more fine-grained.
[Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863 --- Comment #10 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:10c0df1048fdb6404328d4966a3737d4f784c48f commit r11-9140-g10c0df1048fdb6404328d4966a3737d4f784c48f Author: Jonathan Wakely Date: Tue Jul 20 15:20:41 2021 +0100 libstdc++: fix is_default_constructible for hash containers [PR 100863] The recent change to _Hashtable_ebo_helper for this PR broke the is_default_constructible trait for a hash container with a non-default constructible allocator. That happens because the constructor needs to be user-provided in order to initialize the member, and so is not defined as deleted when the type is not default constructible. By making _Hashtable derive from _Enable_special_members we can ensure that the default constructor for the std::unordered_xxx containers is deleted when it would be ill-formed. This makes the trait give the correct answer. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/100863 * include/bits/hashtable.h (_Hashtable): Conditionally delete default constructor by deriving from _Enable_special_members. * testsuite/23_containers/unordered_map/cons/default.cc: New test. * testsuite/23_containers/unordered_set/cons/default.cc: New test. (cherry picked from commit 89ec3b67dbe856a447d068b053bc19559f136f43)
[Bug c++/65816] Constructor delegation does not perform zero-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65816 --- Comment #11 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:573c2ffd3cacde5c54605eb0d8b312d22594f7fa commit r11-9139-g573c2ffd3cacde5c54605eb0d8b312d22594f7fa Author: Jonathan Wakely Date: Wed Jun 2 12:34:48 2021 +0100 libstdc++: Value-initialize objects held by EBO helpers [PR 100863] The allocator, hash function and equality function should all be value-initialized by the default constructor of an unordered container. Do it in the EBO helper, so we don't have to get it right in multiple places. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/100863 PR libstdc++/65816 * include/bits/hashtable_policy.h (_Hashtable_ebo_helper): Value-initialize subobject. * testsuite/23_containers/unordered_map/allocator/default_init.cc: Remove XFAIL. * testsuite/23_containers/unordered_set/allocator/default_init.cc: Remove XFAIL. (cherry picked from commit f8f0193b5b83f6e85d65015e79c803295baf5166)
[Bug libstdc++/100863] 23_containers/unordered_{map,set}/allocator/default_init.cc still fail at runtime even after r12-1153
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100863 --- Comment #9 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:573c2ffd3cacde5c54605eb0d8b312d22594f7fa commit r11-9139-g573c2ffd3cacde5c54605eb0d8b312d22594f7fa Author: Jonathan Wakely Date: Wed Jun 2 12:34:48 2021 +0100 libstdc++: Value-initialize objects held by EBO helpers [PR 100863] The allocator, hash function and equality function should all be value-initialized by the default constructor of an unordered container. Do it in the EBO helper, so we don't have to get it right in multiple places. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/100863 PR libstdc++/65816 * include/bits/hashtable_policy.h (_Hashtable_ebo_helper): Value-initialize subobject. * testsuite/23_containers/unordered_map/allocator/default_init.cc: Remove XFAIL. * testsuite/23_containers/unordered_set/allocator/default_init.cc: Remove XFAIL. (cherry picked from commit f8f0193b5b83f6e85d65015e79c803295baf5166)
[Bug libstdc++/102048] __gnu_cxx::rope.erase(size_t __p) implementation seems to be wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102048 --- Comment #9 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a1dc688940ffade63452c8f9d80fd4b3204e5f40 commit r11-9134-ga1dc688940ffade63452c8f9d80fd4b3204e5f40 Author: Jonathan Wakely Date: Wed Aug 25 16:42:49 2021 +0100 libstdc++: Remove __gnu_cxx::rope::erase(size_type) [PR102048] This function claims to remove a single character at index p, but it actually removes p+1 characters beginning at p. So r.erase(0) removes the first character, but r.erase(1) removes the second and third, and r.erase(2) removes the second, third and fourth. This is not a useful API. The overload is present in the SGI STL header that we imported, but it isn't documented in the API reference. The erase overloads that are documented are: erase(const iterator& p) erase(const iterator& f, const iterator& l) erase(size_type i, size_type n); Having an erase(size_type p) overload that erases a single character (as the comment says it does) might be useful, but would be inconsistent with std::basic_string::erase(size_type p = 0, size_type n = npos), which erases from p to the end of the string when called with a single argument. Since the function isn't part of the documented API, doesn't do what it claims to do (or anything useful) and "fixing" it would leave it inconsistent with basic_string, I'm just removing that overload. libstdc++-v3/ChangeLog: PR libstdc++/102048 * include/ext/rope (rope::erase(size_type)): Remove broken function. (cherry picked from commit 2cd229dec8d6716938de5052479d059d306969da)
[Bug libstdc++/90787] filesystem tests fail if file permissions are not supported
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90787 --- Comment #7 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:cec047eaeb3ca40be65500d140a3a3f16db742e1 commit r11-9133-gcec047eaeb3ca40be65500d140a3a3f16db742e1 Author: Jonathan Wakely Date: Fri Aug 20 14:51:06 2021 +0100 libstdc++: Skip filesystem tests that depend on permissions [PR90787] Tests that depend on filesystem permissions FAIL if run on Windows or as root. Add a helper function to detect those cases, so the tests can skip those checks gracefully. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/90787 * testsuite/27_io/filesystem/iterators/directory_iterator.cc: Use new __gnu_test::permissions_are_testable() function. * testsuite/27_io/filesystem/iterators/recursive_directory_iterator.cc: Likewise. * testsuite/27_io/filesystem/operations/exists.cc: Likewise. * testsuite/27_io/filesystem/operations/is_empty.cc: Likewise. * testsuite/27_io/filesystem/operations/remove.cc: Likewise. * testsuite/27_io/filesystem/operations/remove_all.cc: Likewise. * testsuite/27_io/filesystem/operations/status.cc: Likewise. * testsuite/27_io/filesystem/operations/symlink_status.cc: Likewise. * testsuite/27_io/filesystem/operations/temp_directory_path.cc: Likewise. * testsuite/experimental/filesystem/iterators/directory_iterator.cc: Likewise. * testsuite/experimental/filesystem/iterators/recursive_directory_iterator.cc: Likewise. * testsuite/experimental/filesystem/operations/exists.cc: Likewise. * testsuite/experimental/filesystem/operations/is_empty.cc: Likewise. * testsuite/experimental/filesystem/operations/remove.cc: Likewise. * testsuite/experimental/filesystem/operations/remove_all.cc: Likewise. * testsuite/experimental/filesystem/operations/temp_directory_path.cc: Likewise. * testsuite/util/testsuite_fs.h (__gnu_test::permissions_are_testable): New function to guess whether testing permissions will work. (cherry picked from commit 29b2fd371f18169141e20b90effa7205db68fb11)
[Bug middle-end/102697] [12 Regression] overflow warning missing after -O2 vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102697 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0
[Bug other/102713] [12 regression] Several failures after r12-3273
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102713 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Keywords||diagnostic
[Bug tree-optimization/102706] [12 regression] -O2 vectorization causes regression in Warray-bounds-48.c on many targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102706 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |12.0 Version|11.0|12.0
[Bug libstdc++/100621] ranges::reverse_view fails to meet its complexity requirements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100621 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |12.0 Status|ASSIGNED|RESOLVED --- Comment #4 from Patrick Palka --- Fixed for GCC 12. This probably isn't suitable for backporting to 11/10 as it changes the layout of some specializations of reverse_view.
[Bug libstdc++/100479] range adaptors handle cached iterators incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100479 Patrick Palka changed: What|Removed |Added Target Milestone|--- |11.2 Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Patrick Palka --- Fixed for 11.2/12
[Bug libstdc++/100387] ranges::minmax compares moved-out value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100387 --- Comment #8 from Patrick Palka --- (In reply to Patrick Palka from comment #7) > Fixed for GCC 10.4/11.3/12 For the record this fix is also present in 11.2
[Bug libstdc++/100475] semiregular-box's constructor uses wrong list-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100475 Patrick Palka changed: What|Removed |Added Target Milestone|11.3|11.2 --- Comment #11 from Patrick Palka --- Er, this was actually already fixed for 11.2
[Bug libstdc++/100475] semiregular-box's constructor uses wrong list-initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100475 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |11.3 --- Comment #10 from Patrick Palka --- Fixed for GCC 11.3 and 12. (10.4 doesn't implement this partial specialization of __box)
[Bug libstdc++/100387] ranges::minmax compares moved-out value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100387 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |10.4 --- Comment #7 from Patrick Palka --- Fixed for GCC 10.4/11.3/12
[Bug libstdc++/100606] Please complete LWG3490: ranges::drop_while_view::begin() is missing a precondition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100606 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |10.4 Resolution|--- |FIXED --- Comment #4 from Patrick Palka --- Fixed for GCC 10.4/11.3/12
[Bug libstdc++/101599] ranges::copy_or_move missing std::move for input_iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101599 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Patrick Palka --- Fixed for GCC 10.4/11.3/12
[Bug libstdc++/101589] Incorrect implementation of LWG 3533 for elements_view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101589 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Patrick Palka --- Fixed for GCC 10.4/11.3/12
[Bug libstdc++/101483] join_view::iterator's constructor missing std::move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101483 Patrick Palka changed: What|Removed |Added Target Milestone|--- |10.4 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||ppalka at gcc dot gnu.org --- Comment #4 from Patrick Palka --- Fixed for GCC 10.4/11.3/12
[Bug libstdc++/101599] ranges::copy_or_move missing std::move for input_iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101599 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:55e6dca3090eb34ad9e48bdd7fc50e8ab376244e commit r10-10203-g55e6dca3090eb34ad9e48bdd7fc50e8ab376244e Author: Patrick Palka Date: Mon Aug 2 15:30:15 2021 -0400 libstdc++: Add missing std::move to ranges::copy/move/reverse_copy [PR101599] In passing, this also renames the template parameter _O2 to _Out2 in ranges::partition_copy and uglifies two of its function parameters, out_true and out_false. PR libstdc++/101599 libstdc++-v3/ChangeLog: * include/bits/ranges_algo.h (__reverse_copy_fn::operator()): Add missing std::move in return statement. (__partition_copy_fn::operator()): Rename templtae parameter _O2 to _Out2. Uglify function parameters out_true and out_false. * include/bits/ranges_algobase.h (__copy_or_move): Add missing std::move to recursive call that unwraps a __normal_iterator output iterator. * testsuite/25_algorithms/copy/constrained.cc (test06): New test. * testsuite/25_algorithms/move/constrained.cc (test05): New test. (cherry picked from commit 14d8a5ae472ca5743016f37da2dd4770d83dea21)
[Bug libstdc++/101589] Incorrect implementation of LWG 3533 for elements_view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101589 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:ac987e1e9b7679c550e6a02a3a47737609cf1462 commit r10-10202-gac987e1e9b7679c550e6a02a3a47737609cf1462 Author: Patrick Palka Date: Mon Aug 2 15:30:13 2021 -0400 libstdc++: Fix up implementation of LWG 3533 [PR101589] In r12-569 I accidentally applied the LWG 3533 change to elements_view::iterator::base instead to elements_view::base. This patch corrects this, and also applies the corresponding LWG 3533 change to lazy_split_view::inner-iter::base now that we implement P2210. PR libstdc++/101589 libstdc++-v3/ChangeLog: * include/std/ranges (lazy_split_view::_InnerIter::base): Make the const& overload unconstrained and return a const reference as per LWG 3533. Make unconditionally noexcept. (elements_view::base): Revert accidental r12-569 change. (elements_view::_Iterator::base): Make the const& overload unconstrained and return a const reference as per LWG 3533. Make unconditionally noexcept. (cherry picked from commit 4414057186b227edf5b5efa527732bfcdf39d575)
[Bug libstdc++/101483] join_view::iterator's constructor missing std::move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101483 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:3e40f630f247d576c1534e5e8b40951d0b6ff517 commit r10-10201-g3e40f630f247d576c1534e5e8b40951d0b6ff517 Author: Patrick Palka Date: Mon Aug 2 15:30:10 2021 -0400 libstdc++: Add missing std::move to join_view::iterator ctor [PR101483] PR libstdc++/101483 libstdc++-v3/ChangeLog: * include/std/ranges (join_view::_Iterator::_Iterator): Add missing std::move. (cherry picked from commit 0e1bb3c88c7bd624bc34d6cebe3df9532f1858f0)
[Bug libstdc++/100387] ranges::minmax compares moved-out value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100387 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:1335d35a530f31f60874cea1d5c98de81deed335 commit r10-10196-g1335d35a530f31f60874cea1d5c98de81deed335 Author: Patrick Palka Date: Fri Jun 18 19:33:39 2021 -0400 libstdc++: Reduce ranges::minmax/minmax_element comparison complexity This rewrites ranges::minmax and ranges::minmax_element so that it performs at most 3*N/2 many comparisons, as required by the standard. In passing, this also fixes PR100387 by avoiding a premature std::move in ranges::minmax and in std::shift_right. PR libstdc++/100387 libstdc++-v3/ChangeLog: * include/bits/ranges_algo.h (__minmax_fn::operator()): Rewrite to limit comparison complexity to 3*N/2. (__minmax_element_fn::operator()): Likewise. (shift_right): Avoid premature std::move of __result. * testsuite/25_algorithms/minmax/constrained.cc (test04, test05): New tests. * testsuite/25_algorithms/minmax_element/constrained.cc (test02): Likewise. (cherry picked from commit cc9c94d43dcfa98436152af9c00f011e9dab25f6)
[Bug libstdc++/100606] Please complete LWG3490: ranges::drop_while_view::begin() is missing a precondition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100606 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:936194bc072ffd915d83f6a99a586b82cb7da75c commit r10-10194-g936194bc072ffd915d83f6a99a586b82cb7da75c Author: Patrick Palka Date: Fri May 21 00:05:18 2021 -0400 libstdc++: Implement LWG 3490 change to drop_while_view::begin() libstdc++-v3/ChangeLog: PR libstdc++/100606 * include/std/ranges (drop_while_view::begin): Assert the precondition added by LWG 3490. (cherry picked from commit 11784fe27d879a10dc8a79212c37f50d4f7146f3)
[Bug libstdc++/101599] ranges::copy_or_move missing std::move for input_iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101599 --- Comment #4 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:e22db028743ff2f82c2aade4c8003e256ca15a6e commit r11-9132-ge22db028743ff2f82c2aade4c8003e256ca15a6e Author: Patrick Palka Date: Mon Aug 2 15:30:15 2021 -0400 libstdc++: Add missing std::move to ranges::copy/move/reverse_copy [PR101599] In passing, this also renames the template parameter _O2 to _Out2 in ranges::partition_copy and uglifies two of its function parameters, out_true and out_false. PR libstdc++/101599 libstdc++-v3/ChangeLog: * include/bits/ranges_algo.h (__reverse_copy_fn::operator()): Add missing std::move in return statement. (__partition_copy_fn::operator()): Rename templtae parameter _O2 to _Out2. Uglify function parameters out_true and out_false. * include/bits/ranges_algobase.h (__copy_or_move): Add missing std::move to recursive call that unwraps a __normal_iterator output iterator. * testsuite/25_algorithms/copy/constrained.cc (test06): New test. * testsuite/25_algorithms/move/constrained.cc (test05): New test. (cherry picked from commit 14d8a5ae472ca5743016f37da2dd4770d83dea21)
[Bug libstdc++/101589] Incorrect implementation of LWG 3533 for elements_view
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101589 --- Comment #3 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:d187dfbd038a9be68ceb81a6ce4125d50cb453f9 commit r11-9131-gd187dfbd038a9be68ceb81a6ce4125d50cb453f9 Author: Patrick Palka Date: Mon Aug 2 15:30:13 2021 -0400 libstdc++: Fix up implementation of LWG 3533 [PR101589] In r12-569 I accidentally applied the LWG 3533 change to elements_view::iterator::base instead to elements_view::base. This patch corrects this, and also applies the corresponding LWG 3533 change to lazy_split_view::inner-iter::base now that we implement P2210. PR libstdc++/101589 libstdc++-v3/ChangeLog: * include/std/ranges (lazy_split_view::_InnerIter::base): Make the const& overload unconstrained and return a const reference as per LWG 3533. Make unconditionally noexcept. (elements_view::base): Revert accidental r12-569 change. (elements_view::_Iterator::base): Make the const& overload unconstrained and return a const reference as per LWG 3533. Make unconditionally noexcept. (cherry picked from commit 4414057186b227edf5b5efa527732bfcdf39d575)
[Bug libstdc++/101483] join_view::iterator's constructor missing std::move
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101483 --- Comment #2 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:58873a565898550893165427ccbef343f1390b9c commit r11-9130-g58873a565898550893165427ccbef343f1390b9c Author: Patrick Palka Date: Mon Aug 2 15:30:10 2021 -0400 libstdc++: Add missing std::move to join_view::iterator ctor [PR101483] PR libstdc++/101483 libstdc++-v3/ChangeLog: * include/std/ranges (join_view::_Iterator::_Iterator): Add missing std::move. (cherry picked from commit 0e1bb3c88c7bd624bc34d6cebe3df9532f1858f0)
[Bug libstdc++/100606] Please complete LWG3490: ranges::drop_while_view::begin() is missing a precondition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100606 --- Comment #2 from CVS Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:0dd0905e2f59c1e8fc1597355f47afb53630cfc9 commit r11-9123-g0dd0905e2f59c1e8fc1597355f47afb53630cfc9 Author: Patrick Palka Date: Fri May 21 00:05:18 2021 -0400 libstdc++: Implement LWG 3490 change to drop_while_view::begin() libstdc++-v3/ChangeLog: PR libstdc++/100606 * include/std/ranges (drop_while_view::begin): Assert the precondition added by LWG 3490. (cherry picked from commit 11784fe27d879a10dc8a79212c37f50d4f7146f3)
[Bug libstdc++/101960] std::tuple with an array element is rejected as a named return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101960 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |11.3 --- Comment #9 from Jonathan Wakely --- Fixed for 11.3 Given that nobody noticed this before now, I don't think backporting it further is necessary. Thanks for the report.
[Bug c++/102281] -ftrivial-auto-var-init=zero causes ice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281 --- Comment #13 from David Binderman --- Created attachment 51593 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51593=edit C++ source code Third test case.
[Bug fortran/102717] New: ICE in gfc_simplify_reshape, at fortran/simplify.c:6843
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102717 Bug ID: 102717 Summary: ICE in gfc_simplify_reshape, at fortran/simplify.c:6843 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least r5 : $ cat z1.f90 program p integer, parameter :: a(1) = 2 integer, parameter :: b(2,2) = reshape([1,2,3,4], -[a,a]) end $ gfortran-12-20211010 -c z1.f90 f951: internal compiler error: in gfc_simplify_reshape, at fortran/simplify.c:6843 0x82b845 gfc_simplify_reshape(gfc_expr*, gfc_expr*, gfc_expr*, gfc_expr*) ../../gcc/fortran/simplify.c:6843 0x7aa71b do_simplify ../../gcc/fortran/intrinsic.c:4678 0x7b50ba gfc_intrinsic_func_interface(gfc_expr*, int) ../../gcc/fortran/intrinsic.c:5050 0x8078e9 resolve_unknown_f ../../gcc/fortran/resolve.c:2937 0x8078e9 resolve_function ../../gcc/fortran/resolve.c:3281 0x8078e9 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:7115 0x79a244 gfc_reduce_init_expr(gfc_expr*) ../../gcc/fortran/expr.c:3125 0x79d4b0 gfc_match_init_expr(gfc_expr**) ../../gcc/fortran/expr.c:3173 0x787c74 variable_decl ../../gcc/fortran/decl.c:3016 0x787c74 gfc_match_data_decl() ../../gcc/fortran/decl.c:6325 0x7f01d3 match_word ../../gcc/fortran/parse.c:65 0x7f01d3 decode_statement ../../gcc/fortran/parse.c:376 0x7f1c1a next_free ../../gcc/fortran/parse.c:1384 0x7f1c1a next_statement ../../gcc/fortran/parse.c:1616 0x7f333b parse_spec ../../gcc/fortran/parse.c:4151 0x7f610c parse_progunit ../../gcc/fortran/parse.c:6117 0x7f7891 gfc_parse_file() ../../gcc/fortran/parse.c:6658 0x84480f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[Bug fortran/102716] New: ICE in gfc_validate_kind(): Got bad kind
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102716 Bug ID: 102716 Summary: ICE in gfc_validate_kind(): Got bad kind Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Affects versions down to at least r5 : $ cat z1.f90 program p integer, parameter :: a(1) = shape([2], [1]) end $ gfortran-12-20211010 -c z1.f90 f951: internal compiler error: gfc_validate_kind(): Got bad kind 0x794719 gfc_report_diagnostic ../../gcc/fortran/error.c:874 0x796287 gfc_internal_error(char const*, ...) ../../gcc/fortran/error.c:1494 0x8ca3b5 gfc_validate_kind(bt, int, bool) ../../gcc/fortran/trans-types.c:788 0x75e957 gfc_check_integer_range(__mpz_struct*, int) ../../gcc/fortran/arith.c:300 0x8201c0 range_check ../../gcc/fortran/simplify.c:86 0x82c544 range_check ../../gcc/fortran/simplify.c:7465 0x82c544 gfc_simplify_shape(gfc_expr*, gfc_expr*) ../../gcc/fortran/simplify.c:7448 0x7aa693 do_simplify ../../gcc/fortran/intrinsic.c:4664 0x7b50ba gfc_intrinsic_func_interface(gfc_expr*, int) ../../gcc/fortran/intrinsic.c:5050 0x8078e9 resolve_unknown_f ../../gcc/fortran/resolve.c:2937 0x8078e9 resolve_function ../../gcc/fortran/resolve.c:3281 0x8078e9 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:7115 0x79a244 gfc_reduce_init_expr(gfc_expr*) ../../gcc/fortran/expr.c:3125 0x79d4b0 gfc_match_init_expr(gfc_expr**) ../../gcc/fortran/expr.c:3173 0x787c74 variable_decl ../../gcc/fortran/decl.c:3016 0x787c74 gfc_match_data_decl() ../../gcc/fortran/decl.c:6325 0x7f01d3 match_word ../../gcc/fortran/parse.c:65 0x7f01d3 decode_statement ../../gcc/fortran/parse.c:376 0x7f1c1a next_free ../../gcc/fortran/parse.c:1384 0x7f1c1a next_statement ../../gcc/fortran/parse.c:1616
[Bug fortran/102715] New: [12 Regression] ICE in gfc_simplify_transpose, at fortran/simplify.c:8184
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102715 Bug ID: 102715 Summary: [12 Regression] ICE in gfc_simplify_transpose, at fortran/simplify.c:8184 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: gs...@t-online.de Target Milestone: --- Changed between 20211003 and 20211010 : (follow-up of pr102520) $ cat z1.f90 program p type t end type type(t), parameter :: a(4) = t() type(t), parameter :: b(2,2) = reshape(a, [2]) type(t), parameter :: c(2,2) = transpose(b) end $ gfortran-12-20211003 -c z1.f90 z1.f90:5:31: 5 |type(t), parameter :: b(2,2) = reshape(a, [2]) | 1 Error: Incompatible ranks 2 and 1 in assignment at (1) $ gfortran-12-20211010 -c z1.f90 f951: internal compiler error: Segmentation fault 0xd43fcf crash_signal ../../gcc/toplev.c:326 0x82d8f0 gfc_simplify_transpose(gfc_expr*) ../../gcc/fortran/simplify.c:8184 0x7aa66a do_simplify ../../gcc/fortran/intrinsic.c:4657 0x7b50ba gfc_intrinsic_func_interface(gfc_expr*, int) ../../gcc/fortran/intrinsic.c:5050 0x8078e9 resolve_unknown_f ../../gcc/fortran/resolve.c:2937 0x8078e9 resolve_function ../../gcc/fortran/resolve.c:3281 0x8078e9 gfc_resolve_expr(gfc_expr*) ../../gcc/fortran/resolve.c:7115 0x79a244 gfc_reduce_init_expr(gfc_expr*) ../../gcc/fortran/expr.c:3125 0x79d4b0 gfc_match_init_expr(gfc_expr**) ../../gcc/fortran/expr.c:3173 0x787c74 variable_decl ../../gcc/fortran/decl.c:3016 0x787c74 gfc_match_data_decl() ../../gcc/fortran/decl.c:6325 0x7f01d3 match_word ../../gcc/fortran/parse.c:65 0x7f01d3 decode_statement ../../gcc/fortran/parse.c:376 0x7f1c1a next_free ../../gcc/fortran/parse.c:1384 0x7f1c1a next_statement ../../gcc/fortran/parse.c:1616 0x7f333b parse_spec ../../gcc/fortran/parse.c:4151 0x7f610c parse_progunit ../../gcc/fortran/parse.c:6117 0x7f7891 gfc_parse_file() ../../gcc/fortran/parse.c:6658 0x84480f gfc_be_parse_file ../../gcc/fortran/f95-lang.c:216
[Bug tree-optimization/102714] New: A volatile-related problem cased by ipa inline pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102714
Bug ID: 102714
Summary: A volatile-related problem cased by ipa inline pass
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: duan.db at linux dot alibaba.com
Target Milestone: ---
Created attachment 51592
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51592=edit
test.i
Hi, GCC-trunk has a volatile-related problem with -O2 -fno-strict-aliasing.
The complete test case test.i file is attached. Below are the main caller and
callee code snippets:
caller code snippets:
restart:
parent = ((void *)0);
radix_tree_load_root(root, , );
while (radix_tree_is_internal_node(node)) {
parent = entry_to_node(node);
if (node == xa_mk_internal(256))
goto restart;
if (parent->shift == 0)
break;
}
callee code snippets:
static unsigned radix_tree_load_root(const struct xarray *root,
struct xa_node **nodep, unsigned long *maxindex)
{
struct xa_node *node =
({typeof(root->xa_head) p1 = ({(*(const volatile typeof(root->xa_head)
*)&(root->xa_head)); });
((typeof(*root->xa_head) *)(p1));});
*nodep = node;
if (__builtin_expect(!!(radix_tree_is_internal_node(node)), 1)) {
node = entry_to_node(node);
*maxindex = node_maxindex(node);
return node->shift + (0 ? 4 : 6);
}
*maxindex = 0;
return 0;
}
The callee function radix_tree_load_root will assign the volatile attribute to
root->xa_head (struct member of one input parameter), so that xa_head will not
be optimized by subsequent passes, like loop-invariant code motion.
However, during the IPA inline pass, GCC will use function
redirect_call_stmt_to_callee to rewrite the call function statement and the
intput parameter. In this process, the volatile attribute of xa_head will be
lost, which will be optimized and makes the goto jump logic crash.
Wrong Assembly code:
<__radix_tree_lookup>:
0: 4c 8b 47 08 mov0x8(%rdi),%r8
4: 4c 89 c6mov%r8,%rsi
7: 4c 89 c0mov%r8,%rax
a: 83 e6 03and$0x3,%esi
d: 48 83 e0 fd and$0xfffd,%rax
11: 31 c9 xor%ecx,%ecx
13: 48 83 fe 02 cmp$0x2,%rsi
17: 75 18 jne31 <__radix_tree_lookup+0x31>
19: 0f 1f 80 00 00 00 00nopl 0x0(%rax)
20: 48 89 c1mov%rax,%rcx
23: 49 81 f8 02 04 00 00cmp$0x402,%r8
2a: 74 e5 je 11 <__radix_tree_lookup+0x11> //The
difference between correct assembly and incorrect assembly is the goto jump.
The correct assembly here should be (je 0 <__radix_tree_lookup>), which means
each cycle needs to re-fetch xa_head from the memory.
2c: 80 38 00cmpb $0x0,(%rax)
2f: 75 ef jne20 <__radix_tree_lookup+0x20>
31: 48 85 d2test %rdx,%rdx
34: 74 03 je 39 <__radix_tree_lookup+0x39>
36: 48 89 0amov%rcx,(%rdx)
39: 4c 89 c0mov%r8,%rax
3c: c3 retq
Like I see, when IPA uses the class ipa_param_adjustments to analyze and store
the input parameters information of the call statement, it does not consider
related volatile information, which leads to the loss of information.
And early inline pass does not have this problem, which only exists in IPA
inline pass. If lower the limit of early inline pass, the problem can be
circumvented.
But I am not particularly familiar with this part of GCC code. For how to fix
this bug, I look forward to getting some suggestions. Thanks a lot.
[Bug other/102713] New: [12 regression] Several failures after r12-3273
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102713 Bug ID: 102713 Summary: [12 regression] Several failures after r12-3273 Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- previous run: g:b4e81f6dd48732ace73eebf1d2f46ca1d2533b79, r12-4272: 109 failures this run: g:2b3014326fb883a96601a4dde295858d715289a7, r12-4273: 115 failures FAIL: c-c++-common/Wstringop-overflow-2.c -Wc++-compat (test for excess errors) FAIL: c-c++-common/Wstringop-overflow-2.c -std=gnu++14 (test for excess errors) FAIL: c-c++-common/Wstringop-overflow-2.c -std=gnu++17 (test for excess errors) FAIL: c-c++-common/Wstringop-overflow-2.c -std=gnu++2a (test for excess errors) FAIL: c-c++-common/Wstringop-overflow-2.c -std=gnu++98 (test for excess errors) FAIL: gcc.dg/Warray-parameter-3.c (test for excess errors) FAIL: gcc.dg/Wstringop-overflow-21.c (test for excess errors) FAIL: gcc.dg/Wstringop-overflow-76.c (test for excess errors) spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Warray-parameter-3.c -fdiagnostics-plain-output -Wall -Warray-parameter=1 -S -o Warray-parameter-3.s^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Warray-parameter-3.c:57:12: warning: argument 1 of type 'int[static 2]' with mismatched bound [-Warray-parameter=]^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Warray-parameter-3.c:56:12: note: previously declared as 'int[static 1]'^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Warray-parameter-3.c: In function 'gcas3':^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Warray-parameter-3.c:81:4: warning: array subscript 3 is outside array bounds of 'char[3]' [-Warray-bounds]^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Warray-parameter-3.c:78:13: note: at offset 3 into object 'a' of size [0, 3]^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Warray-parameter-3.c:80:8: warning: writing 4 bytes into a region of size between 0 and 3 [-Wstringop-overflow=]^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Warray-parameter-3.c:78:13: note: destination object 'a' of size [0, 3]^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Warray-parameter-3.c: In function 'gias3':^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Warray-parameter-3.c:88:4: warning: array subscript 3 is outside array bounds of 'int[3]' [-Warray-bounds]^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Warray-parameter-3.c:85:12: note: at offset 12 into object 'a' of size [0, 12]^M PASS: gcc.dg/Warray-parameter-3.c (test for warnings, line 56) PASS: gcc.dg/Warray-parameter-3.c (test for warnings, line 57) PASS: gcc.dg/Warray-parameter-3.c (test for warnings, line 81) PASS: gcc.dg/Warray-parameter-3.c (test for warnings, line 88) FAIL: gcc.dg/Warray-parameter-3.c (test for excess errors) Excess errors: /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Warray-parameter-3.c:80:8: warning: writing 4 bytes into a region of size between 0 and 3 [-Wstringop-overflow=] spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test/gcc/xgcc -B/home/seurer/gcc/git/build/gcc-test/gcc/ /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-21.c -fdiagnostics-plain-output -O2 -Wall -Wno-array-bounds -S -o Wstringop-overflow-21.s^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-21.c: In function 'test_memset_zero_length':^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-21.c:18:3: warning: '__builtin_memset' writing 3 bytes into a region of size 2 overflows the destination [-Wstringop-overflow=]^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-21.c:12:8: note: at offset 1 into destination object 'a' of size 3^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-21.c: In function 'test_store_zero_length':^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-21.c:26:8: warning: writing 4 bytes into a region of size 3 [-Wstringop-overflow=]^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-21.c:24:8: note: destination object 'a' of size 3^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-21.c: In function 'test_memset_flexarray':^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-21.c:45:3: warning: '__builtin_memset' writing 3 bytes into a region of size 2 overflows the destination [-Wstringop-overflow=]^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-21.c:39:8: note: at offset 1 into destination object 'a' of size 3^M /home/seurer/gcc/git/gcc-test/gcc/testsuite/gcc.dg/Wstringop-overflow-21.c: In function 'test_store_flexarray':^M
[Bug tree-optimization/102706] [12 regression] -O2 vectorization causes regression in Warray-bounds-48.c on many targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102706
Martin Sebor changed:
What|Removed |Added
CC||crazylht at gmail dot com
Keywords||diagnostic
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Blocks||56456
Last reconfirmed||2021-10-12
--- Comment #1 from Martin Sebor ---
Confirmed. The root cause is similar as in the test case in pr102462 comment
4. Here, in addition to the expected -Warray-bounds (from the vrp1 pass) for
the invalid subscripts (before vectorization) the code also triggers
-Wstringop-overflow (from the strlen pass) for the two valid stores to p->ax at
indices 0 and 1 vectorized with the subsequent two stores. See the dumps
below.
Hongtao and I have been discussing the fallout of the autovectorization change
in the context of the following review:
https://gcc.gnu.org/pipermail/gcc-patches/2021-October/581371.html
Hongtao, we could use this bug to track case (2) that you described in your
reply this morning in the thread above.
$ cat pr102706.c && /build/iq2000-elf/gcc-master/gcc/xgcc -B
/build/iq200f/gcc-master/gcc -O2 -S -Wall -fdump-tree-vrp1=/dev/stdout
-fdump-tree-strlen=/dev/stdout pr102706.c
typedef __INT16_TYPE__ int16_t;
typedef __INT32_TYPE__ int32_t;
void sink (void*);
/* Exercise a true flexible member. */
struct AX
{
int32_t n;
int16_t ax[]; // { dg-message "while referencing 'ax'" "member" }
};
static void warn_ax_local_buf (struct AX *p)
{
p->ax[0] = 4; p->ax[1] = 5;
p->ax[2] = 6; // { dg-warning "\\\[-Warray-bounds" }
p->ax[3] = 7; // { dg-warning "\\\[-Warray-bounds" }
p->ax[4] = 8; // { dg-warning "\\\[-Warray-bounds" }
}
void g (void)
{
/* Verify out-of-bounds access to the local BUF is diagnosed. */
char ax_buf_p2[sizeof (struct AX) + 2 * sizeof (int16_t)];
warn_ax_local_buf ((struct AX*) ax_buf_p2);
sink (ax_buf_p2);
}
;; Function g (g, funcdef_no=1, decl_uid=1438, cgraph_uid=2, symbol_order=1)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2
;; 2 succs { 1 }
Value ranges after VRP:
In function 'warn_ax_local_buf',
inlined from 'g' at pr102706.c:28:3:
pr102706.c:18:8: warning: array subscript 2 is above array bounds of
'int16_t[]' {aka 'short int[]'} [-Warray-bounds]
18 | p->ax[2] = 6; // { dg-warning "\\\[-Warray-bounds" }
| ~^~~
pr102706.c: In function 'g':
pr102706.c:11:11: note: while referencing 'ax'
11 | int16_t ax[]; // { dg-message "while referencing 'ax'" "member" }
| ^~
In function 'warn_ax_local_buf',
inlined from 'g' at pr102706.c:28:3:
pr102706.c:19:8: warning: array subscript 3 is above array bounds of
'int16_t[]' {aka 'short int[]'} [-Warray-bounds]
19 | p->ax[3] = 7; // { dg-warning "\\\[-Warray-bounds" }
| ~^~~
pr102706.c: In function 'g':
pr102706.c:11:11: note: while referencing 'ax'
11 | int16_t ax[]; // { dg-message "while referencing 'ax'" "member" }
| ^~
In function 'warn_ax_local_buf',
inlined from 'g' at pr102706.c:28:3:
pr102706.c:20:8: warning: array subscript 4 is above array bounds of
'int16_t[]' {aka 'short int[]'} [-Warray-bounds]
20 | p->ax[4] = 8; // { dg-warning "\\\[-Warray-bounds" }
| ~^~~
pr102706.c: In function 'g':
pr102706.c:11:11: note: while referencing 'ax'
11 | int16_t ax[]; // { dg-message "while referencing 'ax'" "member" }
| ^~
void g ()
{
char ax_buf_p2[8];
[local count: 1073741824]:
MEM[(struct AX *)_buf_p2].ax[0] = 4;
MEM[(struct AX *)_buf_p2].ax[1] = 5;
MEM[(struct AX *)_buf_p2].ax[2] = 6;
MEM[(struct AX *)_buf_p2].ax[3] = 7;
MEM[(struct AX *)_buf_p2].ax[4] = 8;
sink (_buf_p2);
ax_buf_p2 ={v} {CLOBBER};
return;
}
;; Function g (g, funcdef_no=1, decl_uid=1438, cgraph_uid=2, symbol_order=1)
;; 1 loops found
;;
;; Loop 0
;; header 0, latch 1
;; depth 0, outer -1
;; nodes: 0 1 2
;; 2 succs { 1 }
In function 'warn_ax_local_buf',
inlined from 'g' at pr102706.c:28:3:
pr102706.c:16:12: warning: writing 4 bytes into a region of size 0
[-Wstringop-overflow=]
16 | p->ax[0] = 4; p->ax[1] = 5;
| ~^~~
pr102706.c: In function 'g':
pr102706.c:27:8: note: at offset 8 into destination object 'ax_buf_p2' of size
8
27 | char ax_buf_p2[sizeof (struct AX) + 2 * sizeof (int16_t)];
|^
void g ()
{
int16_t * vectp.5;
vector(2) short int * vectp_ax_buf_p2.4;
char ax_buf_p2[8];
[local count: 1073741824]:
MEM [(short int *)_buf_p2 + 4B] = { 4, 5 };
MEM [(short int *)_buf_p2 + 8B] = { 6, 7 };
MEM[(struct AX *)_buf_p2].ax[4] = 8;
sink (_buf_p2);
ax_buf_p2 ={v} {CLOBBER};
[Bug libstdc++/102425] std::error_code() does not compare equal to std::error_condition()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102425 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |9.5 --- Comment #6 from Jonathan Wakely --- Fixed for 10.4 and 11.3 so far.
[Bug libstdc++/99876] std::filesystem::absolute is inefficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99876 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Jonathan Wakely --- Fixed for 10.4 and 11.3 now.
[Bug libstdc++/102280] span's range deduction guide is missing ranges::contiguous_range constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102280 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jonathan Wakely --- Fixed for 10.4 and 11.3
[Bug libstdc++/102425] std::error_code() does not compare equal to std::error_condition()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102425 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:49f0936bdcdbad9903c3a1e9342205fd27cb8596 commit r10-10188-g49f0936bdcdbad9903c3a1e9342205fd27cb8596 Author: Jonathan Wakely Date: Wed Sep 22 11:58:20 2021 +0100 libstdc++: std::system_category should know meaning of zero [PR102425] Although 0 is not an errno value, it should still be recognized as corresponding to a value belonging to the generic_category(). Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/102425 * src/c++11/system_error.cc (system_error_category::default_error_condition): Add 0 to switch. * testsuite/19_diagnostics/error_category/102425.cc: New test. (cherry picked from commit ce01e2e64c340dadb55a8a24c545a13e654804d4)
[Bug libstdc++/99876] std::filesystem::absolute is inefficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99876 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:154316697dbea9ba96bc14680b642b3ae35dadbd commit r10-10186-g154316697dbea9ba96bc14680b642b3ae35dadbd Author: Jonathan Wakely Date: Fri Aug 27 10:59:54 2021 +0100 libstdc++: Fix inefficiency in filesystem::absolute [PR99876] When the path is already absolute, the call to current_path() is wasteful, because operator/ will ignore the left operand anyway. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/99876 * src/c++17/fs_ops.cc (fs::absolute): Call non-throwing form, to avoid unnecessary current_path() call. (cherry picked from commit 07b990ee23e0c7a92d362dbb25fd5d57d95eb8be)
[Bug libstdc++/102280] span's range deduction guide is missing ranges::contiguous_range constraint
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102280 --- Comment #8 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:1a27df25a71bb0d6a5dfb0162d1867d308f8f33f commit r10-10184-g1a27df25a71bb0d6a5dfb0162d1867d308f8f33f Author: Jonathan Wakely Date: Wed Sep 15 21:49:29 2021 +0100 libstdc++: Add missing constraint to std::span deduction guide [PR102280] Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/102280 * include/std/span (span(Range&&)): Add constraint to deduction guide. (cherry picked from commit e67917f5df9d84f5aed3513b3931a82870d25135)
[Bug libstdc++/102667] Inconsistent result of std::regex_match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102667 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:be3fbe792444bc750a8a1b37481bac9a84528949 commit r10-10181-gbe3fbe792444bc750a8a1b37481bac9a84528949 Author: Jonathan Wakely Date: Mon Oct 11 09:07:15 2021 +0100 libstdc++: Fix std::match_results::end() for failed matches [PR102667] The end() function needs to consider whether the underlying vector is empty, not whether the match_results object is empty. That's because the underlying vector will always contain at least three elements for a match_results object that is "ready". It contains three extra elements which are stored in the vector but are not considered part of sequence, and so should not be part of the [begin(),end()) range. libstdc++-v3/ChangeLog: PR libstdc++/102667 * include/bits/regex.h (match_result::empty()): Optimize by calling the base function directly. (match_results::end()): Check _Base_type::empty() not empty(). * testsuite/28_regex/match_results/102667.C: New test. (cherry picked from commit 84088dc4bb6a546c896a068dc201463493babf43)
[Bug libstdc++/101960] std::tuple with an array element is rejected as a named return type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101960 --- Comment #8 from CVS Commits --- The releases/gcc-11 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:e748216c237cff2915390e9653de2db63b2161ac commit r11-9121-ge748216c237cff2915390e9653de2db63b2161ac Author: Jonathan Wakely Date: Tue Oct 12 15:09:50 2021 +0100 libstdc++: Fix move construction of std::tuple with array elements [PR101960] The r12-3022 commit only fixed the case where an array is the last element of the tuple. This fixes the other cases too. We can just define the move constructor as defaulted, which does the right thing. Changing the move constructor to be trivial would be an ABI break, but since the last base class still has a non-trivial move constructor, defining the derived ones as defaulted doesn't change anything. libstdc++-v3/ChangeLog: PR libstdc++/101960 * include/std/tuple (_Tuple_impl(_Tuple_impl&&)): Define as defauled. * testsuite/20_util/tuple/cons/101960.cc: Check tuples with array elements before the last element. (cherry picked from commit 7481021364e75ba583972e15ed421a53988368ea)
[Bug target/85730] complex code for modifying lowest byte in a 4-byte vector
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85730 --- Comment #10 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:b37351e3279d192d5d4682f002abe5b2e133bba6 commit r12-4359-gb37351e3279d192d5d4682f002abe5b2e133bba6 Author: Uros Bizjak Date: Tue Oct 12 18:20:38 2021 +0200 i386: Improve workaround for PR82524 LRA limitation [PR85730] As explained in PR82524, LRA is not able to reload strict_low_part inout operand with matched input operand. The patch introduces a workaround, where we allow LRA to generate an instruction with non-matched input operand which is split post reload to an instruction that inserts non-matched input operand to an inout operand and the instruction that uses matched operand. The generated code improves from: movsbl %dil, %edx movl%edi, %eax sall$3, %edx movb%dl, %al to: movl%edi, %eax movb%dil, %al salb$3, %al which is still not optimal, but the code is one instruction shorter and does not use a temporary register. 2021-10-12 Uroš Bizjak gcc/ PR target/85730 PR target/82524 * config/i386/i386.md (*add_1_slp): Rewrite as define_insn_and_split pattern. Add alternative 1 and split it post reload to insert operand 1 into the low part of operand 0. (*sub_1_slp): Ditto. (*and_1_slp): Ditto. (*_1_slp): Ditto. (*ashl3_1_slp): Ditto. (*3_1_slp): Ditto. (*3_1_slp): Ditto. (*neg_1_slp): New insn_and_split pattern. (*one_cmpl_1_slp): Ditto. gcc/testsuite/ PR target/85730 PR target/82524 * gcc.target/i386/pr85730.c: New test.
[Bug target/82524] [7/8 Regression] expensive-optimizations produces wrong results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82524 --- Comment #21 from CVS Commits --- The master branch has been updated by Uros Bizjak : https://gcc.gnu.org/g:b37351e3279d192d5d4682f002abe5b2e133bba6 commit r12-4359-gb37351e3279d192d5d4682f002abe5b2e133bba6 Author: Uros Bizjak Date: Tue Oct 12 18:20:38 2021 +0200 i386: Improve workaround for PR82524 LRA limitation [PR85730] As explained in PR82524, LRA is not able to reload strict_low_part inout operand with matched input operand. The patch introduces a workaround, where we allow LRA to generate an instruction with non-matched input operand which is split post reload to an instruction that inserts non-matched input operand to an inout operand and the instruction that uses matched operand. The generated code improves from: movsbl %dil, %edx movl%edi, %eax sall$3, %edx movb%dl, %al to: movl%edi, %eax movb%dil, %al salb$3, %al which is still not optimal, but the code is one instruction shorter and does not use a temporary register. 2021-10-12 Uroš Bizjak gcc/ PR target/85730 PR target/82524 * config/i386/i386.md (*add_1_slp): Rewrite as define_insn_and_split pattern. Add alternative 1 and split it post reload to insert operand 1 into the low part of operand 0. (*sub_1_slp): Ditto. (*and_1_slp): Ditto. (*_1_slp): Ditto. (*ashl3_1_slp): Ditto. (*3_1_slp): Ditto. (*3_1_slp): Ditto. (*neg_1_slp): New insn_and_split pattern. (*one_cmpl_1_slp): Ditto. gcc/testsuite/ PR target/85730 PR target/82524 * gcc.target/i386/pr85730.c: New test.
[Bug target/99723] [11/12 Regression] arm: ICE in build_function_type during selftests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99723 Andrew Pinski changed: What|Removed |Added Summary|arm: ICE in |[11/12 Regression] arm: ICE |build_function_type during |in build_function_type |selftests |during selftests Target Milestone|--- |11.3
[Bug c++/102709] [11/12 Regression] ICE: in build_function_type, at tree.c:7304
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102709 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Known to work||10.3.0 Severity|normal |trivial Summary|ICE: in |[11/12 Regression] ICE: in |build_function_type, at |build_function_type, at |tree.c:7304 |tree.c:7304 Keywords||error-recovery, ||ice-on-invalid-code Known to fail||11.1.0 Status|UNCONFIRMED |NEW Target Milestone|--- |11.3 Last reconfirmed||2021-10-12 --- Comment #2 from Andrew Pinski --- >12 Regression: Not really: :6: confused by earlier errors, bailing out Well it is a regression from GCC 10 though.
[Bug libstdc++/102181] [DR 3197] std::advance and std::views::iota don't work
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102181 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|SUSPENDED Summary|std::advance and|[DR 3197] std::advance and |std::views::iota don't work |_t> don't work --- Comment #8 from Jonathan Wakely --- Suspending until https://wg21.link/lwg3197 is resolved.
[Bug libstdc++/102712] std::optional::operator* should assert on unset value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102712 --- Comment #3 from Giuseppe Ottaviano --- Oh well this is embarrassing, I was looking at _Optional_payload_base::_M_get() instead of _Optional_base_impl::_M_get() . Sorry for the noise and thanks for fixing this 4 years ago!
[Bug tree-optimization/102711] [9/10/11 Regression] CDDCE removes condition that might lead to an infinite loop causing an unconditional infinite loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102711
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-10-12
Ever confirmed|0 |1
--- Comment #2 from Andrew Pinski ---
Just for refence this is the testcase that can be done at runtime:
void exit(int);
__attribute__((noipa))
int bar(void)
{
static int t = 0;
t++;
if (t == 2) exit(0);
return 1;
}
__attribute__((noipa))
void foo(void)
{
if (!bar())
for (;;);
for (;;) {
static int flag = 0;
int ret = 0;
bar();
if (flag) {
ret = bar();
if (!ret)
ret = bar();
}
flag = !bar();
if (!ret)
bar();
}
}
int main(void)
{
foo();
}
[Bug libstdc++/102712] std::optional::operator* should assert on unset value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102712 --- Comment #2 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #1) > Just compile with -D_GLIBCXX_ASSERTIONS Or the more heavyweight -D_GLIBCXX_DEBUG which implies _GLIBCXX_ASSERTIONS too.
