[Bug target/99881] New: Regression compare -O2 -ftree-vectorize with -O2 on SKX/CLX
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99881
Bug ID: 99881
Summary: Regression compare -O2 -ftree-vectorize with -O2 on
SKX/CLX
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
Target Milestone: ---
testcase is extracted from 557.xz_r
void
foo (int* __restrict a, int n, int c)
{
a[0] = n;
a[1] = c;
}
gcc -O2 -ftree-vectorize -fvect-cost-model=very-cheap
foo(int*, int, int):
movdxmm0, esi
movdxmm1, edx
punpckldq xmm0, xmm1
movqQWORD PTR [rdi], xmm0
ret
without vectorization
foo(int*, int, int):
mov DWORD PTR [rdi], esi
mov DWORD PTR [rdi+4], edx
ret
cost model:
scalar: 2 times scalar_store costs 24,
vector: 1 times unaligned_store costs 12, vec_contruct 8
I know that the current strategy of the cost model is to enable vectorization
as much as possible, but for the case above, it hurts performance. Because the
throughput of punpckldq is 1 on SKX/CLX, which becomes a bottleneck (znver2 is
ok). with -march=SKX, the second vmovd and unpck will be replaced by vpinsr,
and it regression more since vpinsr has throught 2 on CLX/SKX.
So i'm thinking to add extra cost for 2-element vec_construct to prevent the
above vectorization, at the same time, try not to affect other vectorization
situations.
[Bug c/99880] New: ICE in maybe_set_vectorized_backedge_value, at tree-vect-loop.c:9161
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99880
Bug ID: 99880
Summary: ICE in maybe_set_vectorized_backedge_value, at
tree-vect-loop.c:9161
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi all.
This valid program makes GCC crash at -O3. GCC-10 also incurs an ICE with a
Segmentation fault, while GCC-10 downwards versions handle this case well.
$cat small.c
int a, b, c, d, e;
void f() {
b = 5;
for (; b <= 51; b++)
;
int g = -8;
while (g) {
g += 5;
int h = 10;
do {
h -= a = 1;
for (; a; a++)
;
c *= c >= d >= b;
} while (h);
c -= e;
}
}
$gcc -w -O3 small.c
during GIMPLE pass: vect
small.c: In function ‘f’:
small.c:2:6: internal compiler error: in maybe_set_vectorized_backedge_value,
at tree-vect-loop.c:9161
2 | void f() {
| ^
0x66093f maybe_set_vectorized_backedge_value
../../gcc/tree-vect-loop.c:9161
0xdc466a vect_transform_loop(_loop_vec_info*, gimple*)
../../gcc/tree-vect-loop.c:9650
0xdebbcc try_vectorize_loop_1
../../gcc/tree-vectorizer.c:1104
0xdec7b1 vectorize_loops()
../../gcc/tree-vectorizer.c:1243
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/99879] New: [modules] ICE in open
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99879 Bug ID: 99879 Summary: [modules] ICE in open Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: alexander.lelyakin at googlemail dot com Target Milestone: --- /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header memory /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header climits /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cmath /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header source_location /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header shared_mutex /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header set /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header bit /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header functional /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header queue /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header iomanip /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header syncstream /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header unordered_set /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header forward_list /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header semaphore /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header condition_variable /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cstring /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header istream /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header iostream /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header future /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header thread /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header typeinfo /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header latch /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header ratio /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header cerrno /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header ios /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header csignal /usr/local/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header regex In module imported at /usr/local/include/c++/11.0.1/regex:53: /usr/local/include/c++/11.0.1/cstring: note: unable to represent further imported source locations /usr/local/include/c++/11.0.1/regex:53: internal compiler error: in open, at cp/module.cc:13625 53 | #include | 0x6de0f9 loc_spans::open(unsigned int) ../../gcc/gcc/cp/module.cc:13625 0xa61915 preprocess_module(module_state*, unsigned int, bool, bool, bool, cpp_reader*) ../../gcc/gcc/cp/module.cc:19417 0xa2b82f module_token_filter::resume(int, int, tree_node*, unsigned int) ../../gcc/gcc/cp/lex.c:520 0xa2b82f module_token_lang(int, int, tree_node*, unsigned int, unsigned long) ../../gcc/gcc/cp/lex.c:557 0xadf873 cp_lexer_new_main ../../gcc/gcc/cp/parser.c:660 0xadf873 c_parse_file() ../../gcc/gcc/cp/parser.c:45253 0xc0480d c_common_parse_file() ../../gcc/gcc/c-family/c-opts.c:1218 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. g++ (GCC) 11.0.1 20210401 (experimental) Copyright (C) 2021 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug ipa/95859] [10/11 regression] Statically true asserts not recognized as such with -O2, but with -O1, -Og, -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95859 --- Comment #12 from Tobias Schlüter --- Because I posted 32bit code before, here is what the trunk does with -m32 func34(m34): fld DWORD PTR [esp+8] mov eax, DWORD PTR [esp+4] fstpQWORD PTR [eax] fld DWORD PTR [esp+24] fstpQWORD PTR [eax+8] fld DWORD PTR [esp+40] fstpQWORD PTR [eax+16] fld DWORD PTR [esp+12] fstpQWORD PTR [eax+24] fld DWORD PTR [esp+28] fstpQWORD PTR [eax+32] fld DWORD PTR [esp+44] fstpQWORD PTR [eax+40] fld DWORD PTR [esp+16] fstpQWORD PTR [eax+48] fld DWORD PTR [esp+32] fstpQWORD PTR [eax+56] fld DWORD PTR [esp+48] fstpQWORD PTR [eax+64] fld DWORD PTR [esp+20] fstpQWORD PTR [eax+72] fld DWORD PTR [esp+36] fstpQWORD PTR [eax+80] fld DWORD PTR [esp+52] fstpQWORD PTR [eax+88] ret 4 This is the same as the assembly from 9.3 in Comment 4.
[Bug ipa/95859] [10/11 regression] Statically true asserts not recognized as such with -O2, but with -O1, -Og, -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95859 --- Comment #11 from Tobias Schlüter --- Works on trunk now but not 10.2. Compiler explorer link: https://godbolt.org/z/1zbh4YM4W On the trunk we get the following. I'm guessing that one could enhance the read pattern by using more registers, but without benchmarking I don't believe that this can be beat: func34(m34): pxorxmm0, xmm0 mov rax, rdi cvtss2sdxmm0, DWORD PTR [rsp+8] movsd QWORD PTR [rdi], xmm0 pxorxmm0, xmm0 cvtss2sdxmm0, DWORD PTR [rsp+24] movsd QWORD PTR [rdi+8], xmm0 pxorxmm0, xmm0 cvtss2sdxmm0, DWORD PTR [rsp+40] movsd QWORD PTR [rdi+16], xmm0 pxorxmm0, xmm0 cvtss2sdxmm0, DWORD PTR [rsp+12] movsd QWORD PTR [rdi+24], xmm0 pxorxmm0, xmm0 cvtss2sdxmm0, DWORD PTR [rsp+28] movsd QWORD PTR [rdi+32], xmm0 pxorxmm0, xmm0 cvtss2sdxmm0, DWORD PTR [rsp+44] movsd QWORD PTR [rdi+40], xmm0 pxorxmm0, xmm0 cvtss2sdxmm0, DWORD PTR [rsp+16] movsd QWORD PTR [rdi+48], xmm0 pxorxmm0, xmm0 cvtss2sdxmm0, DWORD PTR [rsp+32] movsd QWORD PTR [rdi+56], xmm0 pxorxmm0, xmm0 cvtss2sdxmm0, DWORD PTR [rsp+48] movsd QWORD PTR [rdi+64], xmm0 pxorxmm0, xmm0 cvtss2sdxmm0, DWORD PTR [rsp+20] movsd QWORD PTR [rdi+72], xmm0 pxorxmm0, xmm0 cvtss2sdxmm0, DWORD PTR [rsp+36] movsd QWORD PTR [rdi+80], xmm0 pxorxmm0, xmm0 cvtss2sdxmm0, DWORD PTR [rsp+52] movsd QWORD PTR [rdi+88], xmm0 ret Thanks to whoever did that. I see that a release candidate for 10.2.1 has been cut. I would assume that it's not fixed in 10.2.1 because there would be a bugfix mentioned here. My experience is clearly not representative and I can appreciate that there was no deluge of performance regression PRs, but I would think that Eigen is an important enough library that one should consider whether breaking it like this is really something that should survive several (sub-)releases.
[Bug ipa/99862] [meta-issue] various missed optimizations for dead code elimination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99862 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org Keywords||missed-optimization --- Comment #3 from Eric Gallager --- generally meta-bugs are created to collect other issues under their "Depends On" field; do you have any other bug numbers to add here?
[Bug c/99878] New: -use-ld=gold says "could not find ld" instead of "could not find gold"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99878 Bug ID: 99878 Summary: -use-ld=gold says "could not find ld" instead of "could not find gold" Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jynelson at email dot sc.edu Target Milestone: --- $ gcc-10 -fuse-ld=gold example.c collect2: fatal error: cannot find ‘ld’ compilation terminated. I would expect this to say "collect2: fatal error: cannot find ‘gold’" or 'ld.gold' instead. Upstream bug: https://github.com/rust-lang/rust/issues/82172 In case it matters, I do have gold installed but I removed the executable permissions for testing.
[Bug middle-end/80824] Missing -Wuninitialized at -O0 due to conservative aliasing assumptions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80824
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC||msebor at gcc dot gnu.org
Summary|Missing |Missing -Wuninitialized at
|'variable-is-used-uninitial |-O0 due to conservative
|ized' warning |aliasing assumptions
Ever confirmed|0 |1
Known to fail||10.2.0, 11.0, 7.3.0, 8.3.0,
||9.2.0
Last reconfirmed||2021-04-02
--- Comment #3 from Martin Sebor ---
Confirmed with GCC 11 and the slightly smaller test case below. With -O0, the
warning is issued in the first case because GCC sees the initialization
modifies just the two array elements and not s.b. It's not issued in the
second case because the warning relies on the optimizer infrastructure to tell
it if s.b might be modified and because the optimizer doesn't run at -O0 the
constant values aren't propagated into the array dereferences and so the
infrastructure (exceedingly conservatively) assumes that the accesses to s.a
might modify other members of s. This is a downside of warnings using the same
conservative assumptions as optimizers must.
To do better, the warning would have to avoid some of these conservative
assumptions. This isn't really a bug but a limitation inherent in most of
these warnings.
$ cat z.c && gcc -S -Wall z.c
void f (void);
int g (void)
{
f ();
struct S { int a[2], b; } s;
enum { i = 0, j = 1 };
s.a[i] = 0;
s.a[j] = 0;
return s.b;// -Wuninitialized
}
int h (void)
{
f ();
struct S { int a[2], b; } s;
int i = 0, j = 1;
s.a[i] = 0;
s.a[j] = 0;
return s.b;// missing warning
}
z.c: In function ‘g’:
z.c:12:11: warning: ‘s.b’ is used uninitialized [-Wuninitialized]
12 | return s.b;// -Wuninitialized
| ~^~
z.c:7:29: note: ‘s’ declared here
7 | struct S { int a[2], b; } s;
| ^
[Bug c++/80681] missing -Wuninitialized for const or reference member of a private base class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80681 Martin Sebor changed: What|Removed |Added Last reconfirmed|2017-08-23 00:00:00 |2021-4-1 Known to fail||10.2.0, 11.0, 7.3.0, 8.3.0, ||9.2.0 --- Comment #4 from Martin Sebor --- No progress in GCC 11.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 80147, which changed state. Bug 80147 Summary: missing maybe-uninitialized warning on variable with no side effects https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80147 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX
[Bug tree-optimization/80147] missing maybe-uninitialized warning on variable with no side effects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80147 Martin Sebor changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED CC||msebor at gcc dot gnu.org --- Comment #7 from Martin Sebor --- Eric explained the reason for the missing warning with -O1 in the test case in comment #0. The code in the test case in comment #3 is folded away very early on so there's nothing for the warning to complain about. My guess is that Clang warns during parsing. GCC much later on, to avoid warning for dead code. It's a deliberate decision. I don't think there's anything to fix here.
[Bug c++/89976] missing uninitialized warning for uninitialized struct member (VOPs)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89976 Bug 89976 depends on bug 79658, which changed state. Bug 79658 Summary: [-Wuninitialized] referencing uninitialized field of POD struct should warn https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79658 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 79658, which changed state. Bug 79658 Summary: [-Wuninitialized] referencing uninitialized field of POD struct should warn https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79658 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/79658] [-Wuninitialized] referencing uninitialized field of POD struct should warn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79658
Martin Sebor changed:
What|Removed |Added
Resolution|--- |FIXED
CC||msebor at gcc dot gnu.org
Status|NEW |RESOLVED
--- Comment #10 from Martin Sebor ---
Many test cases here...
For the test case in comment #0, GCC 11 still diagnoses only the second
function. The first was never diagnosed because the variable is optimized out.
That should be expected. When the variable is used it is diagnosed.
$ gcc -O2 -S -Wall pr79658-c0.C
pr79658-c0.C: In function ‘void bar()’:
pr79658-c0.C:31:15: warning: ‘f’ is used uninitialized [-Wuninitialized]
31 | f = (flag) (f | FLAG1); // warning here
| ^
pr79658-c0.C:29:8: note: ‘f’ was declared here
29 | flag f;
|^
For the test case in comment #4, with -O, GCC 11 diagnoses all but the first
function. The first function isn't diagnosed because the conditionals are
folded away and all the warning sees is an unconditional call to bar().
Without optimization, the member functions aren't inlined and so the warning
doesn't see the uninitialized reads. That's mostly unavoidable. The warning
does have logic to trigger when an uninitialized object is passed to a
const-qualified reference (or pointer) but not if the object is passed to a
non-const argument by reference prior to that.
$ gcc -O2 -S -Wall pr79658-c4.C
pr79658-c4.C: In function ‘void foo_1(int)’:
pr79658-c4.C:40:10: warning: ‘*(unsigned int*)((char*) + offsetof(eflags,
enum_flags::m_enum_value))’ may be used uninitialized
[-Wmaybe-uninitialized]
40 | eflags f1;
| ^~
pr79658-c4.C: In function ‘void foo_2(int)’:
pr79658-c4.C:52:10: warning: ‘*(unsigned int*)((char*) + offsetof(eflags,
enum_flags::m_enum_value))’ may be used uninitialized
[-Wmaybe-uninitialized]
52 | eflags f2;
| ^~
pr79658-c4.C: In function ‘void foo_3(int)’:
pr79658-c4.C:64:10: warning: ‘*(unsigned int*)((char*) + offsetof(eflags,
enum_flags::m_enum_value))’ may be used uninitialized
[-Wmaybe-uninitialized]
64 | eflags f3;
| ^~
Finally, for the test case in comment #7, GCC 11 (and prior, including 9, since
r264078) diagnoses all four functions:
$ gcc -O2 -S -Wall pr79658.c
pr79658.c: In function ‘foo_0’:
pr79658.c:13:21: warning: ‘f0.value’ is used uninitialized [-Wuninitialized]
13 | struct enum_flags f0; // doesn't warn
| ^~
pr79658.c: In function ‘foo_1’:
pr79658.c:3:81: warning: ‘f1.value’ may be used uninitialized
[-Wmaybe-uninitialized]
3 | oid set_flag (struct enum_flags *f, int e) { f->value = f->value | e; }
| ~^~~
pr79658.c:25:21: note: ‘f1.value’ was declared here
25 | struct enum_flags f1; // warns
| ^~
pr79658.c: In function ‘foo_2’:
pr79658.c:3:81: warning: ‘f1.value’ may be used uninitialized
[-Wmaybe-uninitialized]
3 | oid set_flag (struct enum_flags *f, int e) { f->value = f->value | e; }
| ~^~~
pr79658.c:25:21: note: ‘f1.value’ was declared here
25 | struct enum_flags f1; // warns
| ^~
pr79658.c: In function ‘foo_3’:
pr79658.c:3:81: warning: ‘f3.value’ may be used uninitialized
[-Wmaybe-uninitialized]
3 | oid set_flag (struct enum_flags *f, int e) { f->value = f->value | e; }
| ~^~~
pr79658.c:49:21: note: ‘f3.value’ was declared here
49 | struct enum_flags f3; // warns
| ^~
With that, I'm going to resolve this as fixed (for the last test case).
[Bug c++/97938] [9/10/11 Regression] g++ crash when inferring type of auto parameter pack in lambda capture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97938
--- Comment #3 from Jason Merrill ---
Reduced more:
template
int sink(Args&&... args) { return 2; }
template
auto fwd(const T1& t1) {
return
[] (auto&&... ts1) {
return
[...ts1 = ts1] () {
return sink(ts1...);
}();
}();
}
int main() {
return fwd(1);
}
[Bug c++/97938] [9/10/11 Regression] g++ crash when inferring type of auto parameter pack in lambda capture
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97938
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC||jason at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
--- Comment #2 from Jason Merrill ---
Removed library dependency:
template
auto apply(F&& f, Args&&... args) { return f(args...); }
template T&& forward(T&& t);
template
int print_args(Args&&... args) {
return sizeof...(args);
}
template
auto fwd(const T1& t1, const T2& t2) {
return ::apply([] (auto&&... ts1) {
return ::apply([...ts1 = forward(ts1)] (auto&&... ts2) {
return print_args(ts1..., forward(ts2)...);
}, t2);
}, t1);
}
int main() {
auto t1 = 1;
auto t2 = 2;
return fwd(t1, t2);
}
[Bug middle-end/78993] [9/10/11 Regression] False positive from -Wmaybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78993
Martin Sebor changed:
What|Removed |Added
Known to fail|4.1.0, 5.3.0, 6.2.0, 7.0|10.2.0, 11.0, 5.5.0, 6.4.0,
||7.2.0, 8.3.0, 9.1.0
Last reconfirmed|2017-01-05 00:00:00 |2021-4-1
Summary|False positive from |[9/10/11 Regression] False
|-Wmaybe-uninitialized |positive from
||-Wmaybe-uninitialized
--- Comment #7 from Martin Sebor ---
Reconfirmed with GCC 11 as a regression introduced in r219703 (GCC 5.0). The
warning for the smaller test case started with r147852 (GCC 4.5.0).
(In reply to Manuel López-Ibáñez from comment #5)
> (In reply to Andrew Pinski from comment #4)
> > # i_5 = PHI
> > # j_27 = PHI
> > # prephitmp_7 = PHI <0(3), prephitmp_17(4)>
> > _14 = i_5 > 9;
> > _18 = prephitmp_7 | _14;
> > if (_18 != 0)
> > goto ; [44.99%]
> > else
> > goto ; [55.01%]
> >
> >
> > Most likely conditional warning does not understand the above case :).
>
> If the reason is the prephitmp_7 | _14, then this is PR42145
It doesn't understand it because it only deals with predicates of the form
so when it sees (_18 != 0)" and tries to compare
it to another predicate it can only do it if the other one also involves _18
and that's not the case (there's only one _18 in the IL and that's this one).
But I don't think it should matter in this case because it seems clear in the
IL (as clear as anything can be) that j is undefined when (i < 0 && i > j)
holds and used when (i >= 0 && i < j) holds, and those two are mutually
exclusive. Yet when the warning logic tries to see if the predicate guarding
the definition of the variable is a superset of the one guarding its use is
winds up looking at:
def i_3(D) >= 0 && i_3(D) < j_6 (expanded)
AND (NOT (i_3(D) < 0), NOT (i_3(D) >= j_6))
use (prephitmp_7 | i_5 > 9) == 0 (expanded)
NOT (_17 != 0)
Here's GCC 11 IL for the small test case:
int foobar (int i)
{
int j;
int i;
int j;
int _1;
_Bool prephitmp_7;
_Bool _16;
_Bool _17;
_Bool prephitmp_20;
[local count: 1073741824]:
# .MEM_9 = VDEF <.MEM_2(D)>
j_6 = rand ();
if (i_3(D) >= j_6)
goto ; [55.78%]
else
goto ; [44.22%]
[local count: 474808632]:
if (i_3(D) < 0)
goto ; [13.00%]
else
goto ; [87.00%]
[local count: 413074919]:
goto ; [100.00%]
[local count: 61733713]:
[local count: 273804168]:
# j_26 = PHI
# prephitmp_20 = PHI <0(9), 1(13)>
# .MEM_10 = VDEF <.MEM_9>
i_4 = rand ();
[local count: 686879088]:
# i_5 = PHI
# .MEM_8 = PHI <.MEM_9(10), .MEM_10(4)>
# j_27 = PHI
# prephitmp_7 = PHI <0(10), prephitmp_20(4)>
_16 = i_5 > 9;
_17 = prephitmp_7 | _16;
if (_17 != 0)
goto ; [0.00%]
else
goto ; [100.00%]
[local count: 686879088]:
goto ; [100.00%]
[local count: 0]:
[local count: 386862736]:
# .MEM_11 = PHI <.MEM_8(11), .MEM_9(14)>
[local count: 1073741824]:
# _1 = PHI <0(6), j_27(12)>
# .MEM_25 = PHI <.MEM_11(6), .MEM_8(12)>
# VUSE <.MEM_25>
return _1;
[local count: 598933192]:
if (i_3(D) < 0)
goto ; [35.41%]
else
goto ; [64.59%]
[local count: 386862736]:
goto ; [100.00%]
[local count: 212070456]:
goto ; [100.00%]
}
[Bug c++/99599] [11 Regression] Concepts requirement falsely reporting cyclic dependency, breaks tag_invoke pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99599 Jason Merrill changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |SUSPENDED Last reconfirmed||2021-04-01 --- Comment #2 from Jason Merrill --- (In reply to the_gamester28 from comment #0) > It seems that the template requirements of invoke_tag(bar_tag, int) are > considered while evaluating line marked "here". Requirements of irrelevant > overloads should not be considered, as it can potentially lead to falsely > reporting a cyclic dependency. This is as specified by http://wg21.link/cwg2369 I think it would be reasonable to allow a compiler to accept the testcase under a generalization of 13.9.1/9: "If the function selected by overload resolution (12.4) can be determined without instantiating a class template definition, it is unspecified whether that instantiation actually takes place." But that does not require a compiler to accept it. It might make sense to check non-dependent conversions that don't require template instantiation, then constraints, then non-dependent conversions that do require template instantiation. But that's a matter for the committee; G++ is conforming to the current working paper.
[Bug c++/99831] [10 Regression] ICE: in reshape_init, at cp/decl.c:6720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99831 Marek Polacek changed: What|Removed |Added Summary|[10/11 Regression] ICE: in |[10 Regression] ICE: in |reshape_init, at|reshape_init, at |cp/decl.c:6720 |cp/decl.c:6720 --- Comment #11 from Marek Polacek --- Fixed on trunk so far.
[Bug c++/99831] [10/11 Regression] ICE: in reshape_init, at cp/decl.c:6720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99831
--- Comment #10 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:6a60ffc297b9d4903543a25538e62e7fb39420a9
commit r11-7954-g6a60ffc297b9d4903543a25538e62e7fb39420a9
Author: Marek Polacek
Date: Thu Apr 1 10:42:43 2021 -0400
c++: GC collects live data when synthesizing operator== [PR99831]
Here we crash in reshape_init because we're accessing ggc_freed
& poisoned data: since r277865 in defaulted_late_check we call
synthesize_method here:
if (kind == sfk_comparison)
{
/* If the function was declared constexpr, check that the definition
qualifies. Otherwise we can define the function lazily. */
if (DECL_DECLARED_CONSTEXPR_P (fn) && !DECL_INITIAL (fn))
synthesize_method (fn);
return;
}
which in this test triggers when we're processing the string<"a">{} in
the static_assert. First, we create a CONSTRUCTOR for the "{}" in
cp_parser_functional_cast, then we call finish_compound_literal which
calls complete_type and that results in garbage collection, which then
frees the CONSTRUCTOR {} we created when parsing the braced-list in
string<"a">{} -- at this point, it's not referenced by anything.
(That's not the case for 'type' in finish_compound_literal: the symbol
table contains a node for operator==, so ggc_mark_roots goes and marks
the fn decl, its type, its arguments etc., as used, so we don't collect
it.)
We could just bump function_depth around the new call to synthesize_method
to prevent GC.
gcc/cp/ChangeLog:
PR c++/99831
* method.c (defaulted_late_check): ++ and -- function_depth around
the call to synthesize_method.
* pt.c: Remove the saved_trees global.
gcc/testsuite/ChangeLog:
PR c++/99831
* g++.dg/other/gc6.C: New test.
[Bug sanitizer/99877] Crash in GIMPLE pass:sanopt in huge function using OpenMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99877 --- Comment #1 from Carl Nettelblad --- Created attachment 50500 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50500=edit Preprocessed source file Fully preprocessed sources. Compressed only to fit bugzilla limit.
[Bug c++/99874] [11 Regression] ICE Segmentation fault when declared variable template of template lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99874
Marek Polacek changed:
What|Removed |Added
Target Milestone|--- |11.0
Priority|P3 |P1
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-04-01
CC||mpolacek at gcc dot gnu.org,
||ppalka at gcc dot gnu.org
Ever confirmed|0 |1
Summary|ICE Segmentation fault when |[11 Regression] ICE
|declared variable template |Segmentation fault when
|of template lambda |declared variable template
||of template lambda
--- Comment #1 from Marek Polacek ---
Confirmed. G++10:
99874.C:2:45: error: expected ‘(’ before ‘{’ token
2 | auto l = [] requires requires { x; } {};
| ^
| (
ICE started with r11-3261. I suppose it's a P1 then?
[Bug libstdc++/86169] .data() fails to unshare strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86169 --- Comment #5 from Jonathan Wakely --- Oh dear, this should have removed the 'noexcept' from the non-const data(), since it might now fail to allocate.
[Bug c++/99805] [9/10/11 Regression] filesystem::path::parent_path got a wrong path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99805 --- Comment #5 from Jonathan Wakely --- It would have worked if it used std::as_const(_M_pathname).data() or _M_pathname.c_str() instead of _M_pathname.data(). It's only the non-const data() added in C++17 which reallocates (since r261642 anyway).
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 78915, which changed state. Bug 78915 Summary: missing -Wuninitialized accessing allocated memory https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78915 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug middle-end/78915] missing -Wuninitialized accessing allocated memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78915 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |11.0 Known to fail||10.2.0, 7.3.0, 8.3.0, 9.2.0 Status|NEW |RESOLVED --- Comment #4 from Martin Sebor --- Both f1() and f2() have been diagnosed since r11-959 (GCC 11): $ gcc -O1 -S -Wall pr78915.c pr78915.c: In function ‘f0’: pr78915.c:5:3: warning: ‘i’ is used uninitialized [-Wuninitialized] 5 | ++i; | ^~~ pr78915.c:3:7: note: ‘i’ was declared here 3 | int i; | ^ pr78915.c: In function ‘f1’: pr78915.c:14:5: warning: ‘*p’ is used uninitialized [-Wuninitialized] 14 | ++*p; | ^~ pr78915.c: In function ‘f2’: pr78915.c:25:5: warning: ‘*p’ may be used uninitialized [-Wmaybe-uninitialized] 25 | ++*p; | ^~
[Bug sanitizer/99877] New: Crash in GIMPLE pass:sanopt in huge function using OpenMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99877 Bug ID: 99877 Summary: Crash in GIMPLE pass:sanopt in huge function using OpenMP Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: carl.nettelblad at it dot uu.se CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- Created attachment 50499 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50499=edit Command line and output This code has worked (seemingly) just fine until the new function computecandcliques was added, with a heap corruption bug (in my own code). When trying to track this bug down, I tried to compile the thing with address sanitizer, but I kept getting crashes even when successively reducing optimization settings and trying a few other things. I know this is certainly not a minimal test case, but I hope it is reproducible for you with these files. I did confirm crashes with very similar error output on optimization levels 3 to 1 and on various versions of GCC 9.x and 10.x. I don't have ready access to 10.2.1, though.
[Bug c++/99805] [9/10/11 Regression] filesystem::path::parent_path got a wrong path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99805
--- Comment #4 from Jonathan Wakely ---
Wow, this is tricksy.
The bug happens when parsing the string into a path. The path is split into
components and the offset of each component from the beginning of the string is
stored, so that parent_path() can efficiently erase the part of the native()
string that refers to the last component. The offset is calculated like this:
for (auto& c : buf)
{
auto pos = c.str.data() - _M_pathname.data();
::new(output++) _Cmpt(c.str, c.type, pos);
++_M_cmpts._M_impl->_M_size;
}
The bug is that for the COW std::string _M_pathname.data() causes the string to
be reallocated, and so changes the address at which the string is stored. So
the string_view c.str no longer refers to the same data as _M_pathname. We get
a bogus offset for the components, and when we try to remove the last component
to get the parent_path(), we don't remove anything from the string.
[Bug tree-optimization/78394] False positives of maybe-uninitialized with -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78394
Martin Sebor changed:
What|Removed |Added
Last reconfirmed|2017-07-20 00:00:00 |2021-4-1
Known to fail||10.2.0, 11.0, 6.3.0, 7.0.1,
||8.3.0, 9.3.0
CC||msebor at gcc dot gnu.org
--- Comment #16 from Martin Sebor ---
Reconfirming with GCC 11. Both instances of the warning go back as far as
support for -Og so it's not a regression.
With my patched GCC the output for just the first function is:
pr78394.C: In function ‘float foo()’:
pr78394.C:19:17: warning: ‘vy’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
19 | return vx + vy;
| ^~
pr78394.C:13:15: note: used when ‘(a <= i)’
13 | float vx, vy;
| ^~
pr78394.C:13:15: note: ‘vy’ was declared here
pr78394.C:19:17: warning: ‘vx’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
19 | return vx + vy;
| ^~
pr78394.C:13:11: note: used when ‘(a <= i)’
13 | float vx, vy;
| ^~
pr78394.C:13:11: note: ‘vx’ was declared here
The dump the warning sees is below as as noted the root cause is that the IL
satisfies the conditions under which it's designed to trigger. So the only
ways to avoid it would seem to be to either a) extend the warning to figure out
that the condition it uses cannot happen (basically implement some of the
optimizations disabled at -Og) or b) turn off -Wmaybe-uninitialized at -Og
(i.e,. remove it from -Wall). I'm not in favor of (a) but (b) makes sense to
me. I'd like to try to improve it for GCC 12 so unless I fail at that I'm not
for disabling it at other optimization levels.
float foo ()
{
int i;
float vy;
float vx;
int a;
float _6;
float _8;
[local count: 118111600]:
# VUSE <.MEM_4(D)>
a_5 = b;
if (a_5 <= 3)
goto ; [50.00%]
else
goto ; [50.00%]
[local count: 59055800]:
goto ; [100.00%]
[local count: 59055800]:
[local count: 118111600]:
# a_1 = PHI
goto ; [100.00%]
[local count: 955630225]:
_8 = (float) i_2;
i_7 = i_2 + 1;
[local count: 1073741824]:
# i_2 = PHI <1(4), i_7(5)>
# .MEM_3 = PHI <.MEM_4(D)(4), .MEM_3(5)>
# vx_9 = PHI
# vy_10 = PHI
if (a_1 > i_2)
goto ; [89.00%]
else
goto ; [11.00%]
[local count: 118111600]:
_6 = vx_9 + vy_10;
# VUSE <.MEM_3>
return _6;
}
[Bug libstdc++/99876] std::filesystem::absolute is inefficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99876
--- Comment #2 from Jonathan Wakely ---
--- a/libstdc++-v3/src/c++17/fs_ops.cc
+++ b/libstdc++-v3/src/c++17/fs_ops.cc
@@ -65,19 +65,12 @@ namespace posix = std::filesystem::__gnu_posix;
fs::path
fs::absolute(const path& p)
{
-#ifdef _GLIBCXX_FILESYSTEM_IS_WINDOWS
error_code ec;
path ret = absolute(p, ec);
if (ec)
_GLIBCXX_THROW_OR_ABORT(filesystem_error("cannot make absolute path", p,
ec));
return ret;
-#else
- if (p.empty())
-_GLIBCXX_THROW_OR_ABORT(filesystem_error("cannot make absolute path", p,
- make_error_code(std::errc::invalid_argument)));
- return current_path() / p;
-#endif
}
fs::path
[Bug libstdc++/99876] std::filesystem::absolute is inefficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99876
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed||2021-04-01
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
(In reply to M Welinder from comment #0)
> If the given filename is already absolute, it should be simply returned.
> There is no need to call current_path() which leads to a getcwd syscall.
Yes we already do that for the overload with an error_code parameter:
fs::path
fs::absolute(const path& p, error_code& ec)
{
path ret;
if (p.empty())
{
ec = make_error_code(std::errc::invalid_argument);
return ret;
}
ec.clear();
if (p.is_absolute())
{
ret = p;
return ret;
}
[Bug libstdc++/99875] [10 Regression] experimental filesystem fails on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99875 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Jonathan Wakely --- Should be fixed at r10-9653
[Bug libstdc++/99096] Several failures in the libstdc++-v3 test suite for x86_64-apple-darwin20.3.0 after r11-7220
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99096 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:3a2dc91d7574d1b03b4e5a8ce4098afb62145c35 commit r10-9653-g3a2dc91d7574d1b03b4e5a8ce4098afb62145c35 Author: Jonathan Wakely Date: Sun Feb 14 20:38:32 2021 + libstdc++: Restore in testsuite_fs.h header [PR 99096] libstdc++-v3/ChangeLog: PR libstdc++/99096 * testsuite/util/testsuite_fs.h: Always include . (cherry picked from commit 4e3590d06cf8a06fcc460ccda6150483a0311bae)
[Bug c++/99584] [11 Regression] ICE Segmentation fault when expanding lambda noexcept specifier with invalid parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99584 --- Comment #5 from Jason Merrill --- *** Bug 99583 has been marked as a duplicate of this bug. ***
[Bug c++/99583] Parameter packs not expanded in lambda noexcept specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99583 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Jason Merrill --- Same issue. *** This bug has been marked as a duplicate of bug 99584 ***
[Bug c++/99584] [11 Regression] ICE Segmentation fault when expanding lambda noexcept specifier with invalid parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99584 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jason Merrill --- Fixed.
[Bug c++/99583] Parameter packs not expanded in lambda noexcept specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99583 --- Comment #2 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:0cf4813202f19768e31666f6aa82bde4dce4065a commit r11-7953-g0cf4813202f19768e31666f6aa82bde4dce4065a Author: Jason Merrill Date: Thu Apr 1 15:17:40 2021 -0400 c++: variadic lambda noexcept-specifier [PR99583] The tree-walk looking for parameter packs didn't find this one because we weren't stepping into TYPE_RAISES_EXCEPTIONS. gcc/cp/ChangeLog: PR c++/99583 PR c++/99584 * tree.c (cp_walk_subtrees) [FUNCTION_TYPE]: Walk into TYPE_RAISES_EXCEPTIONS. gcc/testsuite/ChangeLog: PR c++/99583 * g++.dg/cpp0x/lambda/lambda-variadic12.C: New test.
[Bug c++/99584] [11 Regression] ICE Segmentation fault when expanding lambda noexcept specifier with invalid parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99584 --- Comment #3 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:0cf4813202f19768e31666f6aa82bde4dce4065a commit r11-7953-g0cf4813202f19768e31666f6aa82bde4dce4065a Author: Jason Merrill Date: Thu Apr 1 15:17:40 2021 -0400 c++: variadic lambda noexcept-specifier [PR99583] The tree-walk looking for parameter packs didn't find this one because we weren't stepping into TYPE_RAISES_EXCEPTIONS. gcc/cp/ChangeLog: PR c++/99583 PR c++/99584 * tree.c (cp_walk_subtrees) [FUNCTION_TYPE]: Walk into TYPE_RAISES_EXCEPTIONS. gcc/testsuite/ChangeLog: PR c++/99583 * g++.dg/cpp0x/lambda/lambda-variadic12.C: New test.
[Bug libstdc++/99875] [10 Regression] experimental filesystem fails on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99875 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|NEW |ASSIGNED Target Milestone|--- |10.3 --- Comment #2 from Jonathan Wakely --- I backported r11-7220 as r10-9589 but I also need to backport r11-7239
[Bug libstdc++/99876] New: std::filesystem::absolute is inefficient
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99876
Bug ID: 99876
Summary: std::filesystem::absolute is inefficient
Product: gcc
Version: 10.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: terra at gnome dot org
Target Milestone: ---
Created attachment 50498
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50498=edit
Preprocesses source code
The documentation for std::filesystem::absolute states:
"For POSIX-based operating systems, std::filesystem::absolute(p) is equivalent
to std::filesystem::current_path() / p except for when p is the empty path. "
g++ implements it is way -- that is correct, but wasteful.
If the given filename is already absolute, it should be simply returned.
There is no need to call current_path() which leads to a getcwd syscall.
# /usr/local/products/gcc/10.1.0/bin/g++ -std=gnu++17 -Wall -O2 ttt.C
# strace ./a.out 2>&1 | tail
getcwd("/work/nova7/23232/src", 4096) = 22
getcwd("/work/nova7/23232/src", 4096) = 22
getcwd("/work/nova7/23232/src", 4096) = 22
getcwd("/work/nova7/23232/src", 4096) = 22
getcwd("/work/nova7/23232/src", 4096) = 22
getcwd("/work/nova7/23232/src", 4096) = 22
getcwd("/work/nova7/23232/src", 4096) = 22
getcwd("/work/nova7/23232/src", 4096) = 22
exit_group(0) = ?
+++ exited with 0 +++
# cat ttt.C
#include
int
main()
{
std::filesystem::path foo ("/home/welinder");
for (int i = 0; i < 1; i++)
(void)std::filesystem::absolute(foo);
}
# uname -a
Linux monsterd03 5.3.18-lp152.66-default #1 SMP Tue Mar 2 13:18:19 UTC 2021
(73933a3) x86_64 x86_64 x86_64 GNU/Linux
# /usr/local/products/gcc/10.1.0/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/usr/local/products/gcc/10.1.0/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/products/gcc/10.1.0/lib/gcc/x86_64-suse-linux/10.1.0/lto-wrapper
Target: x86_64-suse-linux
Configured with: ../../gcc-10.1.0/configure --enable-languages=c,c++,fortran
--enable-targets=x86_64-suse-linux,i686-suse-linux
--prefix=/usr/local/products/gcc/10.1.0 --with-gnu-as
--with-as=/usr/local/products/gcc/binutils-2.32/bin/as --with-gnu-ld
--with-ld=/usr/local/products/gcc/binutils-2.32/bin/ld --enable-threads=posix
--enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=pool
x86_64-suse-linux
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.1.0 (GCC)
[Bug libstdc++/99875] [10 Regression] experimental filesystem fails on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99875 Iain Sandoe changed: What|Removed |Added Target||x86_64-darwin, i686-darwin Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-04-01 --- Comment #1 from Iain Sandoe --- also present for m32 on platform versions supporting this.
[Bug libstdc++/99875] New: [10 Regression] experimental filesystem fails on Darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99875 Bug ID: 99875 Summary: [10 Regression] experimental filesystem fails on Darwin Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: iains at gcc dot gnu.org Target Milestone: --- On the RC1 for 10.3 === libstdc++ Summary === # of unexpected failures51 of the form Excess errors: /src-local/gcc-git-10/libstdc++-v3/testsuite/util/testsuite_fs.h:135: error: '::getpid' has not been declared these were not present at r10-9540.
[Bug tree-optimization/99873] [11 Regression] GCC no longer makes as much use of ST3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99873 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Last reconfirmed||2021-04-01 Ever confirmed|0 |1 --- Comment #1 from rsandifo at gcc dot gnu.org --- Testing a patch.
[Bug c++/99869] [11 Regression] ICE: in do_auto_deduction, at cp/pt.c:29620
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99869 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org CC||ppalka at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Patrick Palka --- I'm on it.
[Bug c++/99874] New: ICE Segmentation fault when declared variable template of template lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99874
Bug ID: 99874
Summary: ICE Segmentation fault when declared variable template
of template lambda
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
https://godbolt.org/z/4fxhP6jf9
template
auto l = [] requires requires { x; } {};
int main() {
l<0>.template operator()<0>();
}
:2:40: internal compiler error: Segmentation fault
2 | auto l = [] requires requires { x; } {};
|^
0x1cfca39 internal_error(char const*, ...)
???:0
0x917a92 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x73f042 tsubst_requires_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0x73f08a constraints_satisfied_p(tree_node*, tree_node*)
???:0
0x954d48 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
???:0
0x6ded59 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
???:0
0x8e126d c_parse_file()
???:0
0xa60292 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug c++/99869] [11 Regression] ICE: in do_auto_deduction, at cp/pt.c:29620
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99869 Marek Polacek changed: What|Removed |Added Keywords||ice-on-valid-code --- Comment #2 from Marek Polacek --- (In reply to Marek Polacek from comment #1) > Confirmed. Also tarted with r11-7540. Patrick, can you please take a look > at this one too? *started
[Bug c++/99869] [11 Regression] ICE: in do_auto_deduction, at cp/pt.c:29620
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99869 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-04-01 Ever confirmed|0 |1 Priority|P3 |P1 Target Milestone|--- |11.0 CC||mpolacek at gcc dot gnu.org Summary|ICE: in do_auto_deduction, |[11 Regression] ICE: in |at cp/pt.c:29620|do_auto_deduction, at ||cp/pt.c:29620 --- Comment #1 from Marek Polacek --- Confirmed. Also tarted with r11-7540. Patrick, can you please take a look at this one too?
[Bug tree-optimization/99873] New: [11 Regression] GCC no longer makes as much use of ST3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99873
Bug ID: 99873
Summary: [11 Regression] GCC no longer makes as much use of ST3
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
For:
void
f (int *restrict x, int *restrict y, int *restrict z, int n)
{
for (int i = 0; i < n; i += 3)
{
x[i] = y[i] + z[i];
x[i + 1] = y[i + 1] - z[i + 1];
x[i + 2] = y[i + 2] | z[i + 2];
}
}
GCC 10 produced a nice loop using LD3 and ST3:
.L4:
ld3 {v4.4s - v6.4s}, [x4], 48
ld3 {v16.4s - v18.4s}, [x6], 48
add v1.4s, v16.4s, v4.4s
sub v2.4s, v5.4s, v17.4s
orr v3.16b, v18.16b, v6.16b
st3 {v1.4s - v3.4s}, [x5], 48
cmp x8, x4
bne .L4
But GCC 11 instead uses lane stores:
.L4:
ld3 {v4.4s - v6.4s}, [x9], 48
mov x8, x4
ld3 {v16.4s - v18.4s}, [x11], 48
add x16, x4, 24
add x15, x4, 36
add x14, x4, 16
add x13, x4, 28
add x12, x4, 40
add v2.4s, v16.4s, v4.4s
add x7, x4, 20
sub v1.4s, v5.4s, v17.4s
add x6, x4, 32
orr v0.16b, v18.16b, v6.16b
add x5, x4, 44
add x4, x4, 48
str s2, [x8], 12
st1 {v2.s}[1], [x8]
st1 {v2.s}[2], [x16]
st1 {v2.s}[3], [x15]
str s1, [x4, -44]
st1 {v1.s}[1], [x14]
st1 {v1.s}[2], [x13]
st1 {v1.s}[3], [x12]
str s0, [x4, -40]
st1 {v0.s}[1], [x7]
st1 {v0.s}[2], [x6]
st1 {v0.s}[3], [x5]
cmp x10, x9
bne .L4
I think this is due to r11-3966 optimistically splitting store groups
in a way that we can't recover from if SLP subsequently fails.
Maybe the easiest thing for GCC 11 would be to block the split if the
target supports IFN_STORE_LANES for the group size and element type.
That restores the above case. Of the two tests affected by r11-3966,
vect-complex-5.c seems better with LD2 & ST4, while the motivating
case (pr97428.c) still uses SLP as intended.
[Bug fortran/91726] [8/9 Regression] ICE in gfc_conv_array_ref, at fortran/trans-array.c:3612
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91726
--- Comment #9 from José Rui Faustino de Sousa ---
Hi Paul!
This seems to fix the ICE generated by using -ftrapv -fcheck=bounds
Fixes "nelems" type and adds an optional assert to make sure it stays fixed.
Best regards,
José Rui
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index be5eb89350f..7954b138605 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -9375,7 +9375,7 @@ structure_alloc_comps (gfc_symbol * der_type, tree decl,
nelems));
}
else
- nelems = build_int_cst (size_type_node, 1);
+ nelems = build_int_cst (gfc_array_index_type, 1);
if (CLASS_DATA (c)->attr.dimension
|| CLASS_DATA (c)->attr.codimension)
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 2fa17b36c03..258e885faaa 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -1446,6 +1452,7 @@ gfc_copy_class_to_class (tree from, tree to, tree nelems,
bool unlimited)
name = (const char *)(DECL_NAME (to)->identifier.id.str);
from_len = gfc_conv_descriptor_size (from_data, 1);
+ gcc_assert (TREE_TYPE (orig_nelems) == gfc_array_index_type);
tmp = fold_build2_loc (input_location, NE_EXPR,
logical_type_node, from_len, orig_nelems);
msg = xasprintf ("Array bound mismatch for dimension %d "
[Bug c++/99831] [10/11 Regression] ICE: in reshape_init, at cp/decl.c:6720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99831 Marek Polacek changed: What|Removed |Added Keywords||patch --- Comment #9 from Marek Polacek --- https://gcc.gnu.org/pipermail/gcc-patches/2021-April/567599.html
[Bug libstdc++/99868] std::string is not copied correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99868
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Jonathan Wakely ---
(In reply to Artur from comment #0)
> void mod (char* data) {
> data[0] = 'c';
> }
>
> int main () {
> const std::string str {"8:0.0"};
> std::string dn {str};
>
> mod (const_cast (dn.data ()));
This is undefined behaviour.
You are using the old std::string implementation, which matches the rules in
the C++03 standard. That standard is very clear about the requirements for
data():
"Requires: The program shall not alter any of the values stored in the
character array."
The character sequence owned by dn is shared with str, so changing one changes
the other. But you can't change it in a correct program, only in a program with
undefined behaviour.
> As I saw, GCC 8.3 does not have the same issue: https://ideone.com/EuNi6U
The oldest supported release is GCC 8.4, nothing older than that is supported
or maintained.
The behaviour is the same in all releases, but you need to use the gcc4
std::string implementation by specifying -D_GLIBCXX_USE_CXX11_ABI=0 (which is
implied when using the GCC from devtoolset).
[Bug c++/99805] [9/10/11 Regression] filesystem::path::parent_path got a wrong path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99805 Jonathan Wakely changed: What|Removed |Added Known to fail||10.2.0, 11.0, 9.3.0 Target Milestone|--- |9.4 Summary|filesystem::path::parent_pa |[9/10/11 Regression] |th got a wrong path |filesystem::path::parent_pa ||th got a wrong path Known to work||8.4.1
[Bug c++/99805] filesystem::path::parent_path got a wrong path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99805 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Last reconfirmed||2021-04-01 Status|UNCONFIRMED |ASSIGNED --- Comment #3 from Jonathan Wakely --- Ah yes, that explains why devtoolset reproduces it. Thanks.
[Bug libstdc++/99871] #includes inside push visibility scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99871 --- Comment #1 from Jonathan Wakely --- I wonder if there's a reason we don't just put the visibility on the namespace the way we do elsewhere: namespace std _GLIBCXX_VISIBILITY(default) I will do that, or just move the pragma after the includes.
[Bug libstdc++/99871] #includes inside push visibility scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99871 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-04-01
[Bug c++/99584] [11 Regression] ICE Segmentation fault when expanding lambda noexcept specifier with invalid parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99584 Jason Merrill changed: What|Removed |Added Keywords|ice-on-invalid-code |ice-on-valid-code --- Comment #2 from Jason Merrill --- Probably the same issue as PR 95583.
[Bug c++/99584] [11 Regression] ICE Segmentation fault when expanding lambda noexcept specifier with invalid parameter pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99584 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED CC||jason at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c/99872] New: [11 Regression] optimizations sometimes lead to missing asm prefixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99872 Bug ID: 99872 Summary: [11 Regression] optimizations sometimes lead to missing asm prefixes Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: jyong at gcc dot gnu.org Target Milestone: --- Host: x86_64-pc-linux-gnu Target: x86_64-w64-mingw32 Build: x86_64-pc-linux-gnu Created attachment 50497 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50497=edit lib32_libmingwex_a-pow.c test case Compiling with the following command line: x86_64-w64-mingw32-gcc -O2 -c lib32_libmingwex_a-pow.c -std=gnu99 -m32 Causes an undefined symbols with the wrong asm prefixes to be emitted: T ___attribute__pow 0010 B ___attribute__pow_d 0008 B ___attribute__pow_x B ___attribute__pow_y b .bss d .data U ___fpclassify U _internal_modf U LC5 U _LC6 r .rdata r .rdata$zzz U ___signbit t .text Adding -fno-leading-underscore makes the symbols resolved, 32bit Windows code is supposed to have a leading underscore.
[Bug libstdc++/99871] New: #includes inside push visibility scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99871 Bug ID: 99871 Summary: #includes inside push visibility scope Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: nathan at gcc dot gnu.org Target Milestone: --- I ran into this working on module bugs (99823). While it is not affecting that debugging, it has code smell. We have the following: #pragma GCC visibility push(default) .. some decls #include ... more decls #pragma GCC visibility pop The case I ran into is # 33 "../x86_64-pc-linux-gnu/libstdc++-v3/include/bits/nested_exception.h" 3 #pragma GCC visibility push(default) ... #include "type_traits" ... #pragma GCC visibility pop That visibility pragma will not affect the visibility of decls in type_traits, when that is translated to an include. Fortunately, you asked for default visibility.
[Bug target/99870] New: uiret generated for -mcmodel=kernel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99870
Bug ID: 99870
Summary: uiret generated for -mcmodel=kernel
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: hjl.tools at gmail dot com
Target Milestone: ---
Target: x86-64
[hjl@gnu-cfl-2 tmp]$ /usr/gcc-11.0.1-x32/bin/gcc -march=sapphirerapids
-mcmodel=kernel -mno-sse -mno-mmx -O2 -S -mno-80387 x.c
[hjl@gnu-cfl-2 tmp]$ cat x.s
.file "x.c"
.text
.p2align 4
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
uiret
.cfi_endproc
.LFE0:
.size foo, .-foo
.ident "GCC: (GNU) 11.0.1 20210330 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-2 tmp]$ cat x.c
__attribute__((interrupt))
void
foo (void *frame)
{
}
[hjl@gnu-cfl-2 tmp]$ /usr/gcc-11.0.1-x32/bin/gcc -march=sapphirerapids
-mcmodel=kernel -mno-sse -mno-mmx -O2 -S -mno-80387 x.c
[hjl@gnu-cfl-2 tmp]$ cat x.s
.file "x.c"
.text
.p2align 4
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
uiret << This should be iret.
.cfi_endproc
.LFE0:
.size foo, .-foo
.ident "GCC: (GNU) 11.0.1 20210330 (experimental)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-cfl-2 tmp]$
[Bug target/97513] [11 regression] aarch64 SVE regressions since r11-3822
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97513 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |ASSIGNED --- Comment #7 from rsandifo at gcc dot gnu.org --- Testing a patch for the slp_perm_*.c regressions, which as Jakub says are real. The remaining SVE testsuite failures looks like testisms, so I'll deal with those separately.
[Bug c++/99869] New: ICE: in do_auto_deduction, at cp/pt.c:29620
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99869
Bug ID: 99869
Summary: ICE: in do_auto_deduction, at cp/pt.c:29620
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
This is a small variant of fixed PR 99815.
https://godbolt.org/z/jezs4qh3E
template concept C = true;
template
auto bar(Ts...) { for (C auto c : ""); }
:4:42: internal compiler error: in do_auto_deduction, at cp/pt.c:29620
4 | auto bar(Ts...) { for (C auto c : ""); }
| ^~
0x1cfca39 internal_error(char const*, ...)
???:0
0x6ba92b fancy_abort(char const*, int, char const*)
???:0
0x90a724 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
???:0
0x8e126d c_parse_file()
???:0
0xa60292 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
[Bug target/99867] [10/11 Regression] ICE in to_constant, at poly-int.h:504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99867
Alex Coplan changed:
What|Removed |Added
Ever confirmed|0 |1
CC||acoplan at gcc dot gnu.org
Known to fail||10.2.1, 11.0
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-04-01
Summary|[11 Regression] ICE in |[10/11 Regression] ICE in
|to_constant, at |to_constant, at
|poly-int.h:504 |poly-int.h:504
Keywords||ice-on-invalid-code
--- Comment #1 from Alex Coplan ---
Confirmed. ICEs with just:
#include
void g(svint8x2_t *p) { svint8x2_t x = *p; }
Notably for the related:
#include
void f(svint8_t *p) { svint8_t x = *p; }
we diagnose it:
diag.c: In function ‘f’:
diag.c:2:32: error: this operation requires the SVE ISA extension
2 | void f(svint8_t *p) { svint8_t x = *p; }
|^
diag.c:2:32: note: you can enable SVE using the command-line option ‘-march’,
or by using the ‘target’ attribute or pragma
[Bug c++/99859] constexpr evaluation with member function is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99859
--- Comment #3 from Jakub Jelinek ---
The instantiation isn't the problem,
template
struct intrusive_ptr
{
T *ptr = nullptr;
constexpr explicit intrusive_ptr(T* p) : ptr(p) {
++ptr->count_;
}
constexpr ~intrusive_ptr() {
if (ptr->dec() == 0)
delete ptr;
}
constexpr intrusive_ptr(intrusive_ptr const& a) : ptr(a.ptr) {
++ptr->count_;
}
};
struct Foo {
int count_ = 0;
constexpr int dec() {
return --count_;
}
};
constexpr bool baz() {
Foo f { 4 };
intrusive_ptr a();
return true;
}
constexpr bool x = baz();
constexpr void bar(intrusive_ptr a)
{
}
constexpr bool foo() {
intrusive_ptr a(new Foo());
bar(a);
return true;
}
static_assert(foo());
fails too, and during the finish_static_assert fold_nondependent_expr
evaluation only one cxx_eval_outermost_expr is called.
[Bug target/99847] Optimization breaks alignment on CPU32
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99847 ⎓ changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #5 from ⎓ --- I can confirm that everything works as it should with m68k-unknown-elf-gcc/g++ build with crosstool-NG. But I would still prefer that m68k-linux-* refuses to work with the older CPUs or something like that. This problem could potentially discourage less experienced people away from experimenting with m68k.
[Bug c++/98481] [10 Regression] std::vector::size_type as return type gets tagged with abi:cxx11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98481 --- Comment #7 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:5f00df5925082c7b66da91270f2ed29bf4818c93 commit r11-7951-g5f00df5925082c7b66da91270f2ed29bf4818c93 Author: Jason Merrill Date: Wed Mar 31 17:48:50 2021 -0400 c++: Add ABI version for PR98481 fix The PR98481 fix corrects an ABI regression in GCC 10, but we don't want to introduce an ABI change in the middle of the GCC 10 cycle. This patch introduces ABI v15 for the fix, which will be available but not default in GCC 10.3; the broken behavior remains in ABI v14. Compatibility aliases will not be generated for this change. gcc/ChangeLog: PR c++/98481 * common.opt: Document v15 and v16. gcc/c-family/ChangeLog: PR c++/98481 * c-opts.c (c_common_post_options): Bump latest_abi_version. gcc/cp/ChangeLog: PR c++/98481 * mangle.c (write_expression): Adjust. * class.c (find_abi_tags_r): Disable PR98481 fix for ABI v14. (mark_abi_tags_r): Likewise. gcc/testsuite/ChangeLog: PR c++/98481 * g++.dg/abi/abi-tag24a.C: New test. * g++.dg/abi/macro0.C: Adjust expected value.
[Bug rtl-optimization/99863] [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #17 from Jakub Jelinek --- Created attachment 50496 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50496=edit gcc11-pr99863.patch Full untested patch I'm going to bootstrap/regtest overnight.
[Bug bootstrap/87858] Building old multilib bootstrap GCC: stage1 32-bit libstdc++ fails to build after building 64-bit libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87858 Libor Bukata changed: What|Removed |Added CC||libor.bukata at oracle dot com --- Comment #4 from Libor Bukata --- We also cannot build older GCC versions with GCC 11 nightly (commit 8a6a62614a8ae) on Solaris Trunk: /builds/gcc_nightly_full_build/components/gcc10/build/amd64/./gcc/xgcc -shared-libgcc -B/builds/gcc_nightly_full_build/components/gcc10/build/amd64/./gcc -nostdinc++ -L/builds/gcc_nightly_full_build/components/gcc10/build/amd64/x86_64-pc-solaris2.11/32/libstdc++-v3/src -L/builds/gcc_nightly_full_build/components/gcc10/build/amd64/x86_64-pc-solaris2.11/32/libstdc++-v3/src/.libs -L/builds/gcc_nightly_full_build/components/gcc10/build/amd64/x86_64-pc-solaris2.11/32/libstdc++-v3/libsupc++/.libs -B/usr/gcc/10/x86_64-pc-solaris2.11/bin/ -B/usr/gcc/10/x86_64-pc-solaris2.11/lib/ -isystem /usr/gcc/10/x86_64-pc-solaris2.11/include -isystem /usr/gcc/10/x86_64-pc-solaris2.11/sys-include -fno-checking -m32 -x c++-header -nostdinc++ -g -O2 -m32 -I/builds/gcc_nightly_full_build/components/gcc10/build/amd64/x86_64-pc-solaris2.11/32/libstdc++-v3/include/x86_64-pc-solaris2.11 -I/builds/gcc_nightly_full_build/components/gcc10/build/amd64/x86_64-pc-solaris2.11/32/libstdc++-v3/include -I/builds/gcc_nightly_full_build/components/gcc10/gcc-10.2.0/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x /builds/gcc_nightly_full_build/components/gcc10/gcc-10.2.0/libstdc++-v3/include/precompiled/stdc++.h \ -o x86_64-pc-solaris2.11/bits/stdc++.h.gch/O2ggnu++0x.gch ld.so.1: cc1plus: fatal: libstdc++.so.6: version 'GLIBCXX_3.4.29' not found (required by file /builds/gcc_nightly_full_build/components/gcc10/build/amd64/gcc/cc1plus) ld.so.1: cc1plus: fatal: /builds/gcc_nightly_full_build/components/gcc10/build/amd64/gcc/cc1plus: mismatched ELF symbol versioning xgcc: fatal error: Killed signal terminated program cc1plus GLIBCXX_3.4.29 is a new addition to libstdc++.so.6 that is not available in older libstdc++.so.6 libraries of GCC 7, 9, and 10.
[Bug libstdc++/99868] New: std::string is not copied correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99868
Bug ID: 99868
Summary: std::string is not copied correctly
Product: gcc
Version: 7.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: apyszczuk at gmail dot com
Target Milestone: ---
Created attachment 50495
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50495=edit
save-temps
This code does not correctly copy the string *str*.
#include
#include
void mod (char* data) {
data[0] = 'c';
}
int main () {
const std::string str {"8:0.0"};
std::string dn {str};
mod (const_cast (dn.data ()));
std::cout << "dn = " << dn << "\n";
std::cout << "str = " << str << "\n";
return 0;
}
*dn* should be "c:0.0" and *str* should be untouched but in fact both have the
same value.
If I change:
std::string dn {str};
to:
std::string dn {str.c_str ()};
then *str* is "8:0.0" as it should be.
VERSION:
--
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/opt/rh/devtoolset-7/root/usr/libexec/gcc/x86_64-redhat-linux/7/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,lto --prefix=/opt/rh/devtoolset-7/root/usr
--mandir=/opt/rh/devtoolset-7/root/usr/share/man
--infodir=/opt/rh/devtoolset-7/root/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --enable-plugin --with-linker-hash-style=gnu
--enable-initfini-array --with-default-libstdcxx-abi=gcc4-compatible
--with-isl=/builddir/build/BUILD/gcc-7.2.1-20170829/obj-x86_64-redhat-linux/isl-install
--enable-libmpx --enable-gnu-indirect-function --with-tune=generic
--with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 7.2.1 20170829 (Red Hat 7.2.1-1) (GCC)
--
COMPILATION:
g++ -std=c++17 main.cpp -o main && ./main
(in 11 and 14 is the same)
As I saw, GCC 8.3 does not have the same issue: https://ideone.com/EuNi6U
[Bug c++/99283] [modules] ICE in assert_definition, at cp/module.cc:4608
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99283
--- Comment #22 from Alexander Lelyakin ---
Clean rebuild do not change things:
/home/sasha/GCC/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header streambuf
/home/sasha/GCC/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header
type_traits
/home/sasha/GCC/bin/g++ -std=c++20 -fmodules-ts -x c++-system-header valarray
In file included from /home/sasha/GCC/include/c++/11.0.1/iterator:66,
from
/home/sasha/GCC/include/c++/11.0.1/bits/ranges_algobase.h:36,
from /home/sasha/GCC/include/c++/11.0.1/bits/ranges_algo.h:35,
from /home/sasha/GCC/include/c++/11.0.1/algorithm:64,
from /home/sasha/GCC/include/c++/11.0.1/valarray:38:
/home/sasha/GCC/include/c++/11.0.1/bits/streambuf_iterator.h:53:5: internal
compiler error: in assert_definition, at cp/module.cc:4492
53 | {
| ^
0x6e31c7 trees_in::assert_definition(tree_node*, bool)
../../gcc/gcc/cp/module.cc:4492
0xa5eed0 trees_in::odr_duplicate(tree_node*, bool)
../../gcc/gcc/cp/module.cc:11323
0xa6e5af trees_in::read_function_def(tree_node*, tree_node*)
../../gcc/gcc/cp/module.cc:11403
0xa70aa1 module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14817
0xa7111d module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18079
0xa711df module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18737
0xa6b460 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9661
0xa7091b module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14714
0xa7111d module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18079
0xa711df module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18737
0xa74337 lazy_load_pendings(tree_node*)
../../gcc/gcc/cp/module.cc:18830
0xb7eed5 complete_type(tree_node*)
../../gcc/gcc/cp/typeck.c:140
0xb3fe22 lookup_member(tree_node*, tree_node*, int, bool, int,
access_failure_info*)
../../gcc/gcc/cp/search.c:1148
0xa79195 get_class_binding
../../gcc/gcc/cp/name-lookup.c:5333
0xa8065f outer_binding(tree_node*, cxx_binding*, bool)
../../gcc/gcc/cp/name-lookup.c:7649
0xa808af innermost_non_namespace_value(tree_node*)
../../gcc/gcc/cp/name-lookup.c:7686
0xae6547 check_template_shadow(tree_node*)
../../gcc/gcc/cp/pt.c:4379
0xa7ced1 push_class_level_binding_1
../../gcc/gcc/cp/name-lookup.c:5418
0xa7d49e push_class_level_binding(tree_node*, tree_node*)
../../gcc/gcc/cp/name-lookup.c:5567
0xa7d49e pushdecl_class_level(tree_node*)
../../gcc/gcc/cp/name-lookup.c:5280
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/99283] [modules] ICE in assert_definition, at cp/module.cc:4608
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99283 --- Comment #21 from Nathan Sidwell --- Pants
[Bug tree-optimization/97009] [9 Regression] Inlining with non-standard selected_int_kind leads to errors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97009 Martin Jambor changed: What|Removed |Added Summary|[9/10/11 Regression]|[9 Regression] Inlining |Inlining with non-standard |with non-standard |selected_int_kind leads to |selected_int_kind leads to |errors |errors --- Comment #11 from Martin Jambor --- Pushed to master and gcc-10 branch, I will backport the patch to gcc-9 next week.
[Bug c++/99586] Use of class template identifier checked for CTAD before instantiation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99586 Patrick Palka changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Status|NEW |ASSIGNED CC||ppalka at gcc dot gnu.org
[Bug rtl-optimization/99863] [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863 --- Comment #16 from Jakub Jelinek --- (In reply to rguent...@suse.de from comment #15) > On Thu, 1 Apr 2021, jakub at gcc dot gnu.org wrote: > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863 > > > > --- Comment #14 from Jakub Jelinek --- > > Though, we don't add the multiple stores case to active_local_stores and all > > the replace_read calls are from the active_local_stores chain. > > So I think the above patch should DTRT. > > I suppose it already fails elsewhere if fixed_regs_live is not > available? No. But the way I wrote the above patch, if fixed_regs_live is not available, it will punt if any hard regs are live in the considered sequence.
[Bug fortran/99818] [10/11 Regression] ICE in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:2186
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99818 Paul Thomas changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #3 from Paul Thomas --- Created attachment 50494 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50494=edit Fix for the PR The fix is trivial - gfortran now gives the correct error. 15 | call y%s |1 Error: Actual argument to ‘x’ at (1) must be a coarray Paul
[Bug rtl-optimization/99863] [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863 --- Comment #15 from rguenther at suse dot de --- On Thu, 1 Apr 2021, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863 > > --- Comment #14 from Jakub Jelinek --- > Though, we don't add the multiple stores case to active_local_stores and all > the replace_read calls are from the active_local_stores chain. > So I think the above patch should DTRT. I suppose it already fails elsewhere if fixed_regs_live is not available?
[Bug rtl-optimization/99863] [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863 --- Comment #14 from Jakub Jelinek --- Though, we don't add the multiple stores case to active_local_stores and all the replace_read calls are from the active_local_stores chain. So I think the above patch should DTRT.
[Bug rtl-optimization/99863] [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863
--- Comment #13 from Jakub Jelinek ---
So, I think we want to do:
--- gcc/dse.c.jj2021-01-28 09:59:11.973750676 +0100
+++ gcc/dse.c 2021-04-01 15:16:22.003913061 +0200
@@ -1970,8 +1970,7 @@ get_stored_val (store_info *store_info,
static bool
replace_read (store_info *store_info, insn_info_t store_insn,
- read_info_t read_info, insn_info_t read_insn, rtx *loc,
- bitmap regs_live)
+ read_info_t read_info, insn_info_t read_insn, rtx *loc)
{
machine_mode store_mode = GET_MODE (store_info->mem);
machine_mode read_mode = GET_MODE (read_info->mem);
@@ -2040,7 +2039,8 @@ replace_read (store_info *store_info, in
note_stores (this_insn, look_for_hardregs, regs_set);
}
- bitmap_and_into (regs_set, regs_live);
+ if (store_insn->fixed_regs_live)
+ bitmap_and_into (regs_set, store_insn->fixed_regs_live);
if (!bitmap_empty_p (regs_set))
{
if (dump_file && (dump_flags & TDF_DETAILS))
@@ -2286,7 +2286,7 @@ check_mem_read_rtx (rtx *loc, bb_info_t
offset - store_info->offset,
width)
&& replace_read (store_info, i_ptr, read_info,
- insn_info, loc, bb_info->regs_live))
+ insn_info, loc))
return;
/* The bases are the same, just see if the offsets
@@ -2352,8 +2352,7 @@ check_mem_read_rtx (rtx *loc, bb_info_t
store_info->width)
&& all_positions_needed_p (store_info,
offset - store_info->offset, width)
- && replace_read (store_info, i_ptr, read_info, insn_info, loc,
- bb_info->regs_live))
+ && replace_read (store_info, i_ptr, read_info, insn_info, loc))
return;
remove = canon_true_dependence (store_info->mem,
to fix this. Perhaps together with filling fixed_regs_live on more stores,
currently we fill it in only for insn with exactly one store or on memset
calls, perhaps we want to fill it on insns with more than one store?
[Bug rtl-optimization/99863] [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863 --- Comment #12 from Jakub Jelinek --- Ah, I see the actual problem. replace_read checks the hard regs in the insn sequence and compares them to the live hard regs at the point of the read_insn, in the testcase insn 134 after the CC setter 6 and CC users 7 and 40. CC is not live on the insn 134. But we emit that sequence elsewhere: 2076 /* Insert this right before the store insn where it will be safe 2077 from later insns that might change it before the read. */ 2078 emit_insn_before (insns, store_insn->insn); and store_insn->insn in this case is insn 19, which is in between insn 7 and 40, and CC is live there. So, I think we need to do this live hard regs testing in record_store instead or in addition to. We already call get_stored_val there just for testing purposes and throw it away afterwards.
[Bug c++/99283] [modules] ICE in assert_definition, at cp/module.cc:4608
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99283
--- Comment #20 from Alexander Lelyakin ---
Just make:
git pull
make
make install
That is: just make in previously configured dir.
Then:
---
g++ -std=c++20 -fmodules-ts -x c++-system-header string
g++ -std=c++20 -fmodules-ts -x c++-system-header type_traits
g++ -std=c++20 -fmodules-ts -x c++-system-header iostream
In file included from /home/sasha/GCC/include/c++/11.0.1/bits/ios_base.h:41,
from /home/sasha/GCC/include/c++/11.0.1/ios:42,
from /home/sasha/GCC/include/c++/11.0.1/ostream:38,
from /home/sasha/GCC/include/c++/11.0.1/iostream:39:
/home/sasha/GCC/include/c++/11.0.1/bits/locale_classes.h:163:23: internal
compiler error: in assert_definition, at cp/module.cc:4492
163 | locale(const std::string& __s) : locale(__s.c_str()) { }
| ^~
0x6e31c7 trees_in::assert_definition(tree_node*, bool)
../../gcc/gcc/cp/module.cc:4492
0xa5eed0 trees_in::odr_duplicate(tree_node*, bool)
../../gcc/gcc/cp/module.cc:11323
0xa6e5af trees_in::read_function_def(tree_node*, tree_node*)
../../gcc/gcc/cp/module.cc:11403
0xa70aa1 module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14817
0xa7111d module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18079
0xa711df module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18737
0xa6b460 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9661
0xa7091b module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14714
0xa7111d module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18079
0xa711df module_state::lazy_load(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18737
0xa6b460 trees_in::tree_node(bool)
../../gcc/gcc/cp/module.cc:9661
0xa7091b module_state::read_cluster(unsigned int)
../../gcc/gcc/cp/module.cc:14714
0xa7111d module_state::load_section(unsigned int, binding_slot*)
../../gcc/gcc/cp/module.cc:18079
0xa712d8 lazy_load_binding(unsigned int, tree_node*, tree_node*, binding_slot*)
../../gcc/gcc/cp/module.cc:18770
0xa8301e name_lookup::search_namespace_only(tree_node*)
../../gcc/gcc/cp/name-lookup.c:928
0xa8321a name_lookup::search_namespace(tree_node*)
../../gcc/gcc/cp/name-lookup.c:1014
0xa8321a name_lookup::search_namespace(tree_node*)
../../gcc/gcc/cp/name-lookup.c:1007
0xa8331c name_lookup::search_qualified(tree_node*, bool)
../../gcc/gcc/cp/name-lookup.c:1075
0xa8785f qualified_namespace_lookup
../../gcc/gcc/cp/name-lookup.c:7161
0xa88878 lookup_qualified_name(tree_node*, tree_node*, LOOK_want, bool)
../../gcc/gcc/cp/name-lookup.c:7122
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug ipa/99447] [11 Regression] ICE (segfault) in lookup_page_table_entry
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99447 Matthias Klose changed: What|Removed |Added Resolution|--- |WORKSFORME Status|WAITING |RESOLVED --- Comment #28 from Matthias Klose --- also retried with trunk 20210331, and the two extra --param settings. Can't reproduce it anymore.
[Bug rtl-optimization/99863] [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863
--- Comment #11 from rguenther at suse dot de ---
On Thu, 1 Apr 2021, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863
>
> Jakub Jelinek changed:
>
>What|Removed |Added
>
> CC||jakub at gcc dot gnu.org
>
> --- Comment #10 from Jakub Jelinek ---
> I think the REG_DEAD note isn't the problem here.
> At least, when I dump bb 2 in rest_of_handle_dse right before df_analyze call,
> there is
> (insn 6 3 7 2 (set (reg:CCZ 17 flags)
> (compare:CCZ (reg/v:DI 203 [ y ])
> (const_int 0 [0]))) "pr99863.c":14:12 8 {*cmpdi_ccno_1}
> (nil))
> (insn 7 6 8 2 (set (reg:QI 205)
> (eq:QI (reg:CCZ 17 flags)
> (const_int 0 [0]))) "pr99863.c":14:12 802 {*setcc_qi}
> (expr_list:REG_DEAD (reg:CCZ 17 flags)
> (nil)))
> ...
> (insn 40 38 41 2 (set (reg:QI 220)
> (ne:QI (reg:CCZ 17 flags)
> (const_int 0 [0]))) "pr99863.c":15:11 802 {*setcc_qi}
> (expr_list:REG_DEAD (reg:CCZ 17 flags)
> (nil)))
> but if I dump it right after df_analyze call, I see:
> (insn 6 3 7 2 (set (reg:CCZ 17 flags)
> (compare:CCZ (reg/v:DI 203 [ y ])
> (const_int 0 [0]))) "pr99863.c":14:12 8 {*cmpdi_ccno_1}
> (expr_list:REG_DEAD (reg/v:DI 203 [ y ])
> (nil)))
> (insn 7 6 8 2 (set (reg:QI 205)
> (eq:QI (reg:CCZ 17 flags)
> (const_int 0 [0]))) "pr99863.c":14:12 802 {*setcc_qi}
> (nil))
> ...
> (insn 40 38 41 2 (set (reg:QI 220)
> (ne:QI (reg:CCZ 17 flags)
> (const_int 0 [0]))) "pr99863.c":15:11 802 {*setcc_qi}
> (expr_list:REG_DEAD (reg:CCZ 17 flags)
> (nil)))
>
> i.e. the problematic REG_DEAD note is gone and I think at this point DF knows
> that CC is live there.
> But replace_read has code to check for live hard regs, see
> note_stores (this_insn, look_for_hardregs, regs_set);
> in there etc.
But find_shift_sequence doesn't seem to check whether the emitted
insns contain any extra hardreg clobbers that make the replacement
invalid.
[Bug c++/99283] [modules] ICE in assert_definition, at cp/module.cc:4608
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99283 --- Comment #19 from Nathan Sidwell --- Yes! that seems to have done it!
[Bug c++/99283] [modules] ICE in assert_definition, at cp/module.cc:4608
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99283 --- Comment #18 from Nathan Sidwell --- * 584731ecedf 2021-04-01 | c++: inter-cluster import order [PR 99283]
[Bug c++/99283] [modules] ICE in assert_definition, at cp/module.cc:4608
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99283 --- Comment #17 from CVS Commits --- The master branch has been updated by Nathan Sidwell : https://gcc.gnu.org/g:584731ecedf09c2c067913c4af9ed0a30cf19e8d commit r11-7950-g584731ecedf09c2c067913c4af9ed0a30cf19e8d Author: Nathan Sidwell Date: Thu Apr 1 05:25:53 2021 -0700 c++: inter-cluster import order [PR 99283] I finally managed to reduce the testcase without hitting other bugs. This problem is caused by discovering a duplicate in the middle of reading in the entity in question. I had thougt the import seeding at the beginning of a cluster prevented that, but it is insufficient. Specifically an earlier cluster in the same module can cause the import of a duplicate. Although clusters within a module are well-ordered, there is no ordering between clusters of one module and clusters of another module. And thus we can get duplicate declaration loops. This prevents the problem by also seeding references to earlier clusters in the same module. As the FIXME notes, it is sufficient to reference a single entity in any particular earlier cluster, plus, we also could determine the implicit dependencies and prune that seeding even further. I do not do that -- it decrease the loading that will happen, but would reduce the serialization size. As ever, let's get correctness first. PR c++/99283 gcc/cp/ * module.cc (trees_out::decl_node): Adjust importedness reference assert. (module_state::intercluster_seed): New. Seed both imports and inter-cluster references. Broken out of ... (module_state::write_cluster): ... here. Call it. gcc/testsuite/ * g++.dg/modules/pr99283-6.h: New. * g++.dg/modules/pr99283-6_a.H: New. * g++.dg/modules/pr99283-6_b.H: New. * g++.dg/modules/pr99283-6_c.C: New. * g++.dg/modules/hdr-init-1_c.C: Adjust scan. * g++.dg/modules/indirect-3_c.C: Adjust scan. * g++.dg/modules/indirect-4_c.C: Adjust scan. * g++.dg/modules/lambda-3_b.C: Adjust scan. * g++.dg/modules/late-ret-3_c.C: Adjust scan. * g++.dg/modules/pr99425-1_b.H: Adjust scan. * g++.dg/modules/pr99425-1_c.C: Adjust scan.
[Bug rtl-optimization/99863] [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #10 from Jakub Jelinek ---
I think the REG_DEAD note isn't the problem here.
At least, when I dump bb 2 in rest_of_handle_dse right before df_analyze call,
there is
(insn 6 3 7 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg/v:DI 203 [ y ])
(const_int 0 [0]))) "pr99863.c":14:12 8 {*cmpdi_ccno_1}
(nil))
(insn 7 6 8 2 (set (reg:QI 205)
(eq:QI (reg:CCZ 17 flags)
(const_int 0 [0]))) "pr99863.c":14:12 802 {*setcc_qi}
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(nil)))
...
(insn 40 38 41 2 (set (reg:QI 220)
(ne:QI (reg:CCZ 17 flags)
(const_int 0 [0]))) "pr99863.c":15:11 802 {*setcc_qi}
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(nil)))
but if I dump it right after df_analyze call, I see:
(insn 6 3 7 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg/v:DI 203 [ y ])
(const_int 0 [0]))) "pr99863.c":14:12 8 {*cmpdi_ccno_1}
(expr_list:REG_DEAD (reg/v:DI 203 [ y ])
(nil)))
(insn 7 6 8 2 (set (reg:QI 205)
(eq:QI (reg:CCZ 17 flags)
(const_int 0 [0]))) "pr99863.c":14:12 802 {*setcc_qi}
(nil))
...
(insn 40 38 41 2 (set (reg:QI 220)
(ne:QI (reg:CCZ 17 flags)
(const_int 0 [0]))) "pr99863.c":15:11 802 {*setcc_qi}
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(nil)))
i.e. the problematic REG_DEAD note is gone and I think at this point DF knows
that CC is live there.
But replace_read has code to check for live hard regs, see
note_stores (this_insn, look_for_hardregs, regs_set);
in there etc.
[Bug middle-end/99857] [11 Regression] FAIL: libgomp.c/declare-variant-1.c (test for excess errors) by r11-7926
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99857 H.J. Lu changed: What|Removed |Added Status|RESOLVED|NEW Ever confirmed|0 |1 Last reconfirmed||2021-04-01 Resolution|FIXED |--- --- Comment #2 from H.J. Lu --- > Fixed with g:23ce9945d5efa77c96161443f68e03664705ada3. No, it doesn't fix this regression.
[Bug target/99867] [11 Regression] ICE in to_constant, at poly-int.h:504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99867 Richard Biener changed: What|Removed |Added Target Milestone|--- |11.0
[Bug c++/98481] [10 Regression] std::vector::size_type as return type gets tagged with abi:cxx11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98481 --- Comment #6 from CVS Commits --- The releases/gcc-10 branch has been updated by Richard Biener : https://gcc.gnu.org/g:892024d4af83b258801ff7484bf28f0cf1a1a999 commit r10-9651-g892024d4af83b258801ff7484bf28f0cf1a1a999 Author: Jakub Jelinek Date: Thu Apr 1 09:59:47 2021 +0200 c++, abi: Fix abi_tag attribute handling [PR98481] In GCC10 cp_walk_subtrees has been changed to walk template arguments. As the following testcase, that changed the mangling of some functions. I believe the previous behavior that find_abi_tags_r doesn't recurse into template args has been the correct one, but setting *walk_subtrees = 0 for the types and handling the types subtree walking manually in find_abi_tags_r looks too hard, there are a lot of subtrees and details what should and shouldn't be walked, both in tree.c (walk_type_fields there, which is static) and in cp_walk_subtrees itself. The following patch abuses the fact that *walk_subtrees is an int to tell cp_walk_subtrees it shouldn't walk the template args. But we don't want to introduce an ABI change in the middle of the GCC 10 cycle, so the GCC 10 version of this patch introduces ABI v15 for the fix, which will be available but not default in GCC 10.3. Co-authored-by: Jason Merrill gcc/cp/ChangeLog: PR c++/98481 * class.c (find_abi_tags_r): Set *walk_subtrees to 2 instead of 1 for types. (mark_abi_tags_r): Likewise. * tree.c (cp_walk_subtrees): If *walk_subtrees_p is 2, look through typedefs. gcc/testsuite/ChangeLog: PR c++/98481 * g++.dg/abi/abi-tag24.C: New test. * g++.dg/abi/abi-tag24a.C: New test. * g++.dg/abi/macro0.C: Adjust expected value. gcc/ChangeLog: PR c++/98481 * common.opt (fabi-version): Default to 14. gcc/c-family/ChangeLog: PR c++/98481 * c-opts.c (c_common_post_options): Bump latest_abi_version.
[Bug target/99867] New: [11 Regression] ICE in to_constant, at poly-int.h:504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99867 Bug ID: 99867 Summary: [11 Regression] ICE in to_constant, at poly-int.h:504 Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: asolokha at gmx dot com Target Milestone: --- Target: aarch64-linux-gnu gcc-11.0.1-alpha20210328 snapshot (g:499fa254ae8c9752d8c2cf3130b13ffddfd83546) ICEs when compiling gcc/testsuite/gcc.target/aarch64/sve/acle/general/struct_1.c: % aarch64-linux-gnu-gcc-11.0.1 -c gcc/testsuite/gcc.target/aarch64/sve/acle/general/struct_1.c during RTL pass: expand gcc/testsuite/gcc.target/aarch64/sve/acle/general/struct_1.c: In function 'f': gcc/testsuite/gcc.target/aarch64/sve/acle/general/struct_1.c:7:14: internal compiler error: in to_constant, at poly-int.h:504 7 | svint8x2_t x = *a; | ^ 0x6cfe32 poly_int_pod<2u, unsigned short>::to_constant() const /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/poly-int.h:504 0x6d5651 poly_int_pod<2u, unsigned short>::to_constant() const /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/expr.c:3695 0x6d5651 emit_move_multi_word /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/expr.c:3680 0xb450ce emit_move_insn(rtx_def*, rtx_def*) /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/expr.c:3936 0xb4d8a7 store_expr(tree_node*, rtx_def*, int, bool, bool) /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/expr.c:6072 0xb4f2c0 expand_assignment(tree_node*, tree_node*, bool) /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/expr.c:5622 0xa158d7 expand_gimple_stmt_1 /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/cfgexpand.c:3910 0xa158d7 expand_gimple_stmt /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/cfgexpand.c:4008 0xa1bbea expand_gimple_basic_block /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/cfgexpand.c:6045 0xa1d78f execute /var/tmp/portage/cross-aarch64-linux-gnu/gcc-11.0.1_alpha20210328/work/gcc-11-20210328/gcc/cfgexpand.c:6729 It does not ICE when provided w/ -march containing "+sve", so I wonder if this PR is really a duplicate of PR99657.
[Bug rtl-optimization/99863] [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863 --- Comment #9 from Eric Botcazou --- > Richard, did you mean to CC me for another PR by any chance? Never mind, I was confused by your commit.
[Bug rtl-optimization/99863] [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863 Eric Botcazou changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #8 from Eric Botcazou --- Richard, did you mean to CC me for another PR by any chance?
[Bug c++/99858] Wrong throw-expression behaviour with reference to pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99858
--- Comment #2 from Jonathan Wakely ---
As requested by https://gcc.gnu.org/bugs/ please provide code, not just a URL.
Reduced:
extern "C" int printf(const char*, ...);
int main() try {
try {
throw (void*)1;
} catch (void*& ptr) {
printf("%p %p\n", ptr, );
ptr = nullptr;
throw;
}
} catch (void*& ptr) {
printf("%p %p\n", ptr, );
}
Not a regression. I'll take a look at the EH code.
[Bug rtl-optimization/99863] [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863 --- Comment #7 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:512429a885e87bef51057a001681b7d8d106e807 commit r11-7949-g512429a885e87bef51057a001681b7d8d106e807 Author: Richard Biener Date: Thu Apr 1 11:51:33 2021 +0200 tree-optimization/99863 - clear vector CTOR TREE_SIDE_EFFECTS When we gimplify a vector CTOR the original CONSTRUCTOR tree remains but we fail to recompute flags such as TREE_SIDE_EFFECTS. This causes later GENERIC folding of them in vector lowering to give up since the match.pd machinery is careful about TREE_SIDE_EFFECTS. Fixing this makes vector lowering produce much less garbage and thus following the IL for PR99793 easier. 2021-04-01 Richard Biener PR tree-optimization/99863 * gimplify.c (gimplify_init_constructor): Recompute vector constructor flags.
[Bug rtl-optimization/99863] [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863
Richard Biener changed:
What|Removed |Added
Component|target |rtl-optimization
--- Comment #6 from Richard Biener ---
(In reply to Richard Biener from comment #5)
> (In reply to Martin Liška from comment #4)
> > Started with r10-7268-g529ea7d9596b26ba.
>
> Reverting on trunk fixes the issue. Good vs. bad assembly shows the likely
> culprit:
>
> shrq$32, %rax
> - movq%rax, %r8
> - testq %rdi, %rdi
> + movq%rax, %rdi
> setne %al
And this is
(insn 6 3 7 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg/v:DI 177 [ u64_0 ])
(const_int 0 [0]))) "t.c":14:30 8 {*cmpdi_ccno_1}
(nil))
(insn 7 6 8 2 (set (reg:QI 179)
(eq:QI (reg:CCZ 17 flags)
(const_int 0 [0]))) "t.c":14:30 802 {*setcc_qi}
(expr_list:REG_DEAD (reg:CCZ 17 flags)
(nil)))
...
(insn 23 22 24 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg/v:DI 177 [ u64_0 ])
(const_int 0 [0]))) "t.c":15:19 8 {*cmpdi_ccno_1}
(nil))
(insn 24 23 25 2 (set (reg:QI 190)
(ne:QI (reg:CCZ 17 flags)
(const_int 0 [0]))) "t.c":15:19 802 {*setcc_qi}
(nil))
deferring deletion of insn with uid = 23.
likely somehow seeing the set as a noop move. trial is (reg:CCZ 17 flags)
but likely CSE doesn't track CC flag clobbers appropriately though there's
no other CC clobber insn visible at this point. At least CSE1 fails
to remove the REG_DEAD note on reg:CCZ in insn 7?
Later we happily insert CC clobbers inbetween - notably DSE1 (eh?!)
produces
(insn 166 12 168 2 (set (reg:SI 262)
(subreg:SI (reg:DI 182 [ foo0_v256u32_0 ]) 0)) "t.c":14:36 75
{*movsi_internal}
(nil))
(insn 168 166 167 2 (set (reg:DI 263)
(reg:DI 182 [ foo0_v256u32_0 ])) "t.c":14:36 74 {*movdi_internal}
(expr_list:REG_DEAD (reg:DI 182 [ foo0_v256u32_0 ])
(nil)))
(insn 167 168 169 2 (parallel [
(set (reg:DI 263)
(lshiftrt:DI (reg:DI 263)
(const_int 32 [0x20])))
(clobber (reg:CC 17 flags))
]) "t.c":14:36 703 {*lshrdi3_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
which uses subregs/shifts to elide a load/store pair (I think).
[Bug target/99647] arm: GCC generates invalid MVE vmov instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99647 Alex Coplan changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot gnu.org Last reconfirmed||2021-04-01 Ever confirmed|0 |1 --- Comment #2 from Alex Coplan --- Taking a look at this.
[Bug c++/99859] constexpr evaluation with member function is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99859
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
Last reconfirmed||2021-04-01
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #2 from Jakub Jelinek ---
We want testcases in our bugzilla rather than external links.
No need for any headers,
template
struct intrusive_ptr
{
T *ptr = nullptr;
constexpr explicit intrusive_ptr(T* p) : ptr(p) {
++ptr->count_;
}
constexpr ~intrusive_ptr() {
if (ptr->dec() == 0)
//if (--ptr->count_ == 0)
delete ptr;
}
constexpr intrusive_ptr(intrusive_ptr const& a) : ptr(a.ptr) {
++ptr->count_;
}
};
struct Foo {
int count_ = 0;
constexpr int dec() {
return --count_;
}
};
template class intrusive_ptr;
constexpr void bar(intrusive_ptr a)
{
// if (a.ptr->count_ != 2) throw 1;
}
constexpr bool foo() {
intrusive_ptr a(new Foo());
bar(a);
return true;
}
static_assert(foo());
reproduces too. Wonder if it isn't related to the instantiation of
intrusive_ptr::~intrusive_ptr() while constexpr evaluating the static
assert.
[Bug target/99863] [10/11 Regression] wrong code with -O -fno-tree-forwprop -mno-sse2 since r10-7268-g529ea7d9596b26ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99863 --- Comment #5 from Richard Biener --- (In reply to Martin Liška from comment #4) > Started with r10-7268-g529ea7d9596b26ba. Reverting on trunk fixes the issue. Good vs. bad assembly shows the likely culprit: shrq$32, %rax - movq%rax, %r8 - testq %rdi, %rdi + movq%rax, %rdi setne %al
[Bug ipa/98265] [10/11 Regression] gcc-10 has significantly worse code generated with -O2 compared to -O1 (or gcc-9 -O2) when using the Eigen C++ library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98265 Jan Hubicka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jan Hubicka --- Trunk now generates on the unreduced testcase: .file "test.cpp" .text .p2align 4 .globl _Z1f .type _Z1f, @function _Z1f: .LFB6287: .cfi_startproc mulss %xmm3, %xmm0 movq%rdi, %rax mulss %xmm3, %xmm1 mulss %xmm3, %xmm2 movss %xmm0, (%rdi) movss %xmm1, 4(%rdi) movss %xmm2, 8(%rdi) ret .cfi_endproc .LFE6287: .size _Z1f, .-_Z1f .ident "GCC: (GNU) 11.0.1 20210331 (experimental)" .section.note.GNU-stack,"",@progbits
[Bug ipa/98265] [10/11 Regression] gcc-10 has significantly worse code generated with -O2 compared to -O1 (or gcc-9 -O2) when using the Eigen C++ library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98265 --- Comment #9 from CVS Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:3064fc21aa29d8e04b23c0b52dc4f67de1da6b2f commit r11-7948-g3064fc21aa29d8e04b23c0b52dc4f67de1da6b2f Author: Jan Hubicka Date: Thu Apr 1 12:11:39 2021 +0200 Add testcase for PR98265 gcc/testsuite/ChangeLog: 2021-04-01 Jan Hubicka PR ipa/98265 * gcc.dg/tree-ssa/pr98265.C: New test.
