Build reproducibility of gcc @ NixOS
Dear GCC development team, We've been trying to build reproducibly the minimal NixOS image, and gcc was one of the last issues we had. We found that disabling profiled bootstrap compilation of GCC allowed us to get a reproducible build of gcc. Our efforts can be followed here: https://github.com/NixOS/nixpkgs/pull/112928 But I measured disabling this optimization to cost around 7-12% depending on the build. Because of this performance regression, we're trying to find a middle ground. Ideally we'd like to keep the performance of gcc as untouched as possible (even if that costs us on compilation time of gcc itself). Compiling gcc twice on the same machine gets us the same output, but compiling on a different architecture gets us a different result. Reading the documentation, it would seem that autoprofiledback bootstrap would use machine metrics and injects them in the build (and we don't use autoprofiledback), But I would not expect the stagetrain of profiledbootstrap to do that. I tried disabling concurrency of the stagetrain without luck. It feels like I'm missing something. Would anyone have any idea what could inject the host's behavior here? Thank you for your help! Best, -- Arthur
[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.
Re: [Patch, fortran] PR99818 - [10/11 Regression] ICE in gfc_get_tree_for_caf_expr, at fortran/trans-expr.c:2186
Paul, This looks OK to me for Trunk. I believe 10 is in freeze so it may have to wait or get release manager approval. Jerry On 4/1/21 6:44 AM, Paul Richard Thomas via Fortran wrote: This one is trivial. The wrong error message was transformed by my patch for PR98897 into an ICE. This patch now produces the correct error. Regtests OK on FC33/x86_64 - OK for the affected branches? Paul Fortran: Fix ICE on wrong code [PR99818]. 2021-04-01 Paul Thomas gcc/fortran/ChangeLog PR fortran/99818 * interface.c (compare_parameter): The codimension attribute is applied to the _data field of class formal arguments. gcc/testsuite/ChangeLog PR fortran/99818 * gfortran.dg/coarray_48.f90: New test.
[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);
}
gcc-8-20210401 is now available
Snapshot gcc-8-20210401 is now available on https://gcc.gnu.org/pub/gcc/snapshots/8-20210401/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 8 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-8 revision 530567da49fbbde99f22fb18a2919c6d705292dc You'll find: gcc-8-20210401.tar.xzComplete GCC SHA256=230bf09639d725fa188d3d5c60f239cd03a2dad052c5930878ac27f61b20e85c SHA1=6b80c54f819ca22eead6fc7c27144d04e1436f4b Diffs from 8-20210325 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
[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%]
}
[committed] analyzer: record per-enode saved_diagnostics
Various places iterate through all of the saved_diagnostics to find
just the ones that are at a given enode. This patch adds a per-enode
record of the diagnostics that are at each node, to save iterating
through all of the diagnostics each time.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as 6e943d5a2e3c581e40ccab46bec986a1f22c70c2.
gcc/analyzer/ChangeLog:
* diagnostic-manager.cc (diagnostic_manager::add_diagnostic): Make
enode param non-constant, and call add_diagnostic on it. Add
enode index to log message.
(diagnostic_manager::add_diagnostic): Make enode param
non-constant.
* diagnostic-manager.h (diagnostic_manager::add_diagnostic):
Likewise for both decls.
* engine.cc
(impl_region_model_context::impl_region_model_context): Likewise
for enode_for_diag.
(impl_sm_context::impl_sm_context): Likewise.
(impl_sm_context::m_enode_for_diag): Likewise.
(exploded_node::dump_dot): Don't pass the diagnostic manager
to dump_saved_diagnostics.
(exploded_node::dump_saved_diagnostics): Drop param. Iterate
directly through all saved diagnostics for the enode, rather
than all saved diagnostics in the diagnostic_manager and
filtering.
(exploded_node::on_stmt): Make non-const.
(exploded_node::on_edge): Likewise.
(exploded_node::on_longjmp): Likewise.
(exploded_node::detect_leaks): Likewise.
(exploded_graph::get_or_create_node): Make enode_for_diag param
non-const.
(exploded_graph_annotator::print_enode): Iterate
directly through all saved diagnostics for the enode, rather
than all saved diagnostics in the diagnostic_manager and
filtering.
* exploded-graph.h
(impl_region_model_context::impl_region_model_context): Make
enode_for_diag param non-constant.
(impl_region_model_context::m_enode_for_diag): Likewise.
(exploded_node::dump_saved_diagnostics): Drop param.
(exploded_node::on_stmt): Make non-const.
(exploded_node::on_edge): Likewise.
(exploded_node::on_longjmp): Likewise.
(exploded_node::detect_leaks): Likewise.
(exploded_node::add_diagnostic): New.
(exploded_node::get_num_diagnostics): New.
(exploded_node::get_saved_diagnostic): New.
(exploded_node::m_saved_diagnostics): New.
(exploded_graph::get_or_create_node): Make enode_for_diag param
non-constant.
* feasible-graph.cc (feasible_node::dump_dot): Drop
diagnostic_manager from call to dump_saved_diagnostics.
* program-state.cc (program_state::on_edge): Convert enode param
to non-const pointer.
(program_state::prune_for_point): Likewise for enode_for_diag
param.
* program-state.h (program_state::on_edge): Convert enode param
to non-const pointer.
(program_state::prune_for_point): Likewise for enode_for_diag
param.
---
gcc/analyzer/diagnostic-manager.cc | 9 +++---
gcc/analyzer/diagnostic-manager.h | 4 +--
gcc/analyzer/engine.cc | 52 +-
gcc/analyzer/exploded-graph.h | 34 +--
gcc/analyzer/feasible-graph.cc | 5 ++-
gcc/analyzer/program-state.cc | 12 +++
gcc/analyzer/program-state.h | 4 +--
7 files changed, 65 insertions(+), 55 deletions(-)
diff --git a/gcc/analyzer/diagnostic-manager.cc
b/gcc/analyzer/diagnostic-manager.cc
index a376755b7ee..9ec3e899e85 100644
--- a/gcc/analyzer/diagnostic-manager.cc
+++ b/gcc/analyzer/diagnostic-manager.cc
@@ -791,7 +791,7 @@ diagnostic_manager::diagnostic_manager (logger *logger,
engine *eng,
void
diagnostic_manager::add_diagnostic (const state_machine *sm,
- const exploded_node *enode,
+ exploded_node *enode,
const supernode *snode, const gimple *stmt,
stmt_finder *finder,
tree var,
@@ -809,16 +809,17 @@ diagnostic_manager::add_diagnostic (const state_machine
*sm,
= new saved_diagnostic (sm, enode, snode, stmt, finder, var, sval,
state, d, m_saved_diagnostics.length ());
m_saved_diagnostics.safe_push (sd);
+ enode->add_diagnostic (sd);
if (get_logger ())
-log ("adding saved diagnostic %i at SN %i: %qs",
+log ("adding saved diagnostic %i at SN %i to EN %i: %qs",
sd->get_index (),
-snode->m_index, d->get_kind ());
+snode->m_index, enode->m_index, d->get_kind ());
}
/* Queue pending_diagnostic D at ENODE for later emission. */
void
-diagnostic_manager::add_diagnostic (const exploded_node *enode,
+diagnostic_manager::add_diagnostic (exploded_node *enode,
const supernode *snode, const gimple *stmt,
[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.
Re: Remove RMS from the GCC Steering Committee
> If RMS had ever done the same (pretty unlikely, Fortran isnt't his > thing), I would have done the same without thinking twice about it. I agree with that sentiment. The fact that somebody has a certain role doesn't necessarily mean that the question is asked with that hat on: it may be nothing more than curiousity.
Re: GCC 10.3 Release Candidate available from gcc.gnu.org
I bootstrap built and tested for powerpc 64 on power 7 and 8 BE and power 8, 9, and 10 LE and I saw nothing unexpected. On 4/1/21 7:35 AM, Richard Biener wrote: The first release candidate for GCC 10.3 is available from https://gcc.gnu.org/pub/gcc/snapshots/10.3.0-RC-20210401/ ftp://gcc.gnu.org/pub/gcc/snapshots/10.3.0-RC-20210401/ and shortly its mirrors. It has been generated from git commit 892024d4af83b258801ff7484bf28f0cf1a1a999. I have so far bootstrapped and tested the release candidate on x86_64-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 10.3 on Thursday, April 8th.
Re: Remove RMS from the GCC Steering Committee
On 01.04.21 22:33, Joseph Myers wrote: And while in that case RMS probably learned of modules and libcody through the SC mailing list, in general he has this habit of asking GNU package developers random questions related to their packages. I've been asked a few questions about gfortran by random people, which I have always tried to answer correctly and courteously, with a copy to the relevant mailing list. If RMS had ever done the same (pretty unlikely, Fortran isnt't his thing), I would have done the same without thinking twice about it.
[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.
Re: [PATCH v9] Practical improvement to libgcc complex divide
I would very much like to get all the details right on my next submission.
I'm submitting this query for feedback before I do the full submission.
Most changes requested require obvious fixes. One has me confused about
the best action to take.
- - - -
On the issue of alloca vs XALLOCAVEC, I discovered that XALLOCAVEC has
been around and recommended since at least 2010, but I could not find
any discussion of why XALLOCAVEC is preferred to alloca. Understanding
the purpose of making the change would help in resolve the following
decision.
Currently,in gcc/c-family/c-cppbuiltin.c, XALLOCAVEC does not appear
at all. alloca appears 13 times. Both appear in other files in the
same directory. In the routine I'm modifying, four current allocations
to macro_name use alloca.
I see four options:
1) Use alloca as that is consistent with the existing style within
the source file. That is my current choice, but disliked by the
reviewer.
2) If I use XALLOCAVEC just for my three new uses of alloca, which
also assign to macro_name, we will have an inconsistent coding
pattern. That violates the principle of maintaining existing style
within a source file or routine. This choice seems ugly.
3) If I use XALLOCATE for my three new uses for alloca and
change the other four allcoations to macro_name in the same
routine but leave the other 9 uses of alloca alone, we have
consistency in the modified routine but not the source file.
If this is the recommended procedure, I'm willing.
4) If I change all uses of alloc to XALLOCATE in the file, that makes
the file consistent but adds source file changes to the patch in
routines that are completely unrelated to my goal of improving complex
divide. It increases risk of causing subtle problems either through
my editing errors or lack of understanding by me of any differences
between alloca and XALLOCATE. I'm less comfortable with this option.
- - - -
- - - -
The rest appear to be editing issues on my part.
I'll will make the following changes.
- - - -
I will fix the type of name_len to const size_t.
- - - -
I will fix abort/exit in the three test files to be:
extern void abort(void);
extern void exit(int status);
- - - -
I will proofread and fix the comments in the three test files.
than/that, missing "to", etc.
- - - -
In libgcc/config/rs6000/_divkc3.c
I see one additional blank line that will be removed.
- - - -
In libgcc/libgcc2.c
- - - -
I admit the names XCTYPE and XMTYPE are not very imaginative. My
intention was represent "extra precision" but the potential confusion
with extended precision did not occur to me at the time. The
XCTYPE/XMTYPE is intended to be the next larger precision to allow the
same source code to be used for both the half precision and float
precision cases.
Maybe it would be better to think "additional precision",
and use ACTYPE and AMTYPE?
- - - -
Comment "...errors than can..." should be "...errors that can..."
Will make the change.
On 3/31/2021 12:03 PM, Bernhard Reutner-Fischer wrote:
On Fri, 26 Mar 2021 23:14:41 +
Patrick McGehearty via Gcc-patches wrote:
diff --git a/gcc/c-family/c-cppbuiltin.c b/gcc/c-family/c-cppbuiltin.c
index 9f993c4..c0d9e57 100644
--- a/gcc/c-family/c-cppbuiltin.c
+++ b/gcc/c-family/c-cppbuiltin.c
@@ -1277,8 +1277,10 @@ c_cpp_builtins (cpp_reader *pfile)
{
scalar_float_mode mode = mode_iter.require ();
const char *name = GET_MODE_NAME (mode);
+ const int name_len = strlen (name);
strlen returns a size_t
Funny that we do not have a pre-seeded mode_name_len array but call
strlen on modes over and over again.
+ char float_h_prefix[16] = "";
char *macro_name
- = (char *) alloca (strlen (name)
+ = (char *) alloca (name_len
+ sizeof ("__LIBGCC__MANT_DIG__"));
sprintf (macro_name, "__LIBGCC_%s_MANT_DIG__", name);
builtin_define_with_int_value (macro_name,
@@ -1286,20 +1288,29 @@ c_cpp_builtins (cpp_reader *pfile)
if (!targetm.scalar_mode_supported_p (mode)
|| !targetm.libgcc_floating_mode_supported_p (mode))
continue;
- macro_name = (char *) alloca (strlen (name)
+ macro_name = (char *) alloca (name_len
+ sizeof ("__LIBGCC_HAS__MODE__"));
sprintf (macro_name, "__LIBGCC_HAS_%s_MODE__", name);
cpp_define (pfile, macro_name);
- macro_name = (char *) alloca (strlen (name)
+ macro_name = (char *) alloca (name_len
+ sizeof ("__LIBGCC__FUNC_EXT__"));
sprintf (macro_name, "__LIBGCC_%s_FUNC_EXT__", name);
The above should have been split out as separate independent patchlet
to get it out of the way.
As noted already the use of alloca is a pre-existing (coding-style) bug
and we should use XALLOCAVEC or appropriately sized fixed buffers to
begin with. The amount of alloca in defining all these is amazing.
Re: [PATCH] c++: placeholder type constraint inside range-for [PR99869]
On 4/1/21 4:09 PM, Patrick Palka wrote:
In the testcase below, during ahead-of-time deduction of a constrained
auto from do_range_for_auto_deduction, we trip over the assert inside
do_auto_deduction that expects the deduction context to be
adc_return_type or adc_variable_type, but the context in this case is
adc_unspecified.
We could safely relax the assert to also accept adc_unspecified, but it
seems the context should really be adc_variable_type in this case.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
OK.
gcc/cp/ChangeLog:
PR c++/99869
* parser.c (do_range_for_auto_deduction): Pass adc_variable_type
to do_auto_deduction.
gcc/testsuite/ChangeLog:
PR c++/99869
* g++.dg/cpp2a/concepts-placeholder6.C: New test.
---
gcc/cp/parser.c| 4 +++-
gcc/testsuite/g++.dg/cpp2a/concepts-placeholder6.C | 10 ++
2 files changed, 13 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-placeholder6.C
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index d0477c42afe..808e5b61b1e 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -12878,7 +12878,9 @@ do_range_for_auto_deduction (tree decl, tree range_expr)
RO_UNARY_STAR,
tf_warning_or_error);
TREE_TYPE (decl) = do_auto_deduction (TREE_TYPE (decl),
- iter_decl, auto_node);
+ iter_decl, auto_node,
+ tf_warning_or_error,
+ adc_variable_type);
}
}
}
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-placeholder6.C
b/gcc/testsuite/g++.dg/cpp2a/concepts-placeholder6.C
new file mode 100644
index 000..18e7b56d77f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-placeholder6.C
@@ -0,0 +1,10 @@
+// PR c++/99869
+// { dg-do compile { target c++20 } }
+
+template concept same_as = __is_same(T, U);
+
+template
+void f() {
+ for (same_as auto c : "") {} // dg-error "constraint" }
+ for (same_as auto c : "") {}
+}
Re: [PATCH v2] c++: GC collects live data when synthesizing operator== [PR99831]
On 4/1/21 5:12 PM, Marek Polacek wrote:
On Thu, Apr 01, 2021 at 03:09:44PM -0400, Jason Merrill wrote:
On 4/1/21 2:15 PM, Marek Polacek wrote:
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. Alternatively, as in this patch, we can create a new
GC root to hold the expression list. Since I'm adding a new global, I
felt compelled to get rid of one, and I actually did find an unused one!
So, 86 it. But I'm also happy to just go with bumping function_depth.
I think bumping function_depth is the right solution; this patch only deals
with one source of unreachable expressions that could be collected
prematurely if complete_type results in GC running.
Fair enough, let's go back to my original patch.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/10?
OK.
And now I should get back to
where we actually want a new GC root...
-- >8 --
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.
---
gcc/cp/method.c | 7 ++-
gcc/cp/pt.c | 1 -
gcc/testsuite/g++.dg/other/gc6.C | 16
3 files changed, 22 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/other/gc6.C
diff --git a/gcc/cp/method.c b/gcc/cp/method.c
index 8ae7496f023..0f416bec35b 100644
--- a/gcc/cp/method.c
+++ b/gcc/cp/method.c
@@ -3131,7 +3131,12 @@ defaulted_late_check (tree fn)
/* 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);
+ {
+ /* Prevent GC. */
+ function_depth++;
+ synthesize_method (fn);
+ function_depth--;
+ }
return;
}
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index dc6f2f37f9b..7956e83c1de 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -65,7 +65,6 @@ static GTY(()) struct pending_template *last_pending_template;
int processing_template_parmlist;
static int template_header_count;
-static GTY(()) tree saved_trees;
static vec inline_parm_levels;
static GTY(()) struct tinst_level *current_tinst_level;
diff --git a/gcc/testsuite/g++.dg/other/gc6.C b/gcc/testsuite/g++.dg/other/gc6.C
new file mode 100644
index 000..ff45dd313d6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/other/gc6.C
@@ -0,0 +1,16 @@
+// PR
[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?
Re: [PATCH v2] c++: GC collects live data when synthesizing operator== [PR99831]
On Thu, Apr 01, 2021 at 03:09:44PM -0400, Jason Merrill wrote:
> On 4/1/21 2:15 PM, Marek Polacek wrote:
> > 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. Alternatively, as in this patch, we can create a new
> > GC root to hold the expression list. Since I'm adding a new global, I
> > felt compelled to get rid of one, and I actually did find an unused one!
> > So, 86 it. But I'm also happy to just go with bumping function_depth.
>
> I think bumping function_depth is the right solution; this patch only deals
> with one source of unreachable expressions that could be collected
> prematurely if complete_type results in GC running.
Fair enough, let's go back to my original patch.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/10?
And now I should get back to
where we actually want a new GC root...
-- >8 --
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.
---
gcc/cp/method.c | 7 ++-
gcc/cp/pt.c | 1 -
gcc/testsuite/g++.dg/other/gc6.C | 16
3 files changed, 22 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/other/gc6.C
diff --git a/gcc/cp/method.c b/gcc/cp/method.c
index 8ae7496f023..0f416bec35b 100644
--- a/gcc/cp/method.c
+++ b/gcc/cp/method.c
@@ -3131,7 +3131,12 @@ defaulted_late_check (tree fn)
/* 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);
+ {
+ /* Prevent GC. */
+ function_depth++;
+ synthesize_method (fn);
+ function_depth--;
+ }
return;
}
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index dc6f2f37f9b..7956e83c1de 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -65,7 +65,6 @@ static GTY(()) struct pending_template *last_pending_template;
int processing_template_parmlist;
static int template_header_count;
-static GTY(()) tree saved_trees;
static vec inline_parm_levels;
static GTY(()) struct tinst_level *current_tinst_level;
diff --git a/gcc/testsuite/g++.dg/other/gc6.C b/gcc/testsuite/g++.dg/other/gc6.C
new file mode 100644
index 000..ff45dd313d6
--- /dev/null
+++
[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).
Re: Remove RMS from the GCC Steering Committee
On 4/1/21 10:33 PM, Joseph Myers wrote: RMS once asked me about the status of fused multiply-add support in glibc. I don't know why. He wasn't asking for any changes or objecting to anything the glibc maintainers had done. I'd hope that future Chief GNUisances won't try to get involved in details like that as part of their role as Chief GNUisance, because it's clearly outside the scope of such a role, and that if interested in such details as an individual free software developer (but not directly involved in development of the package in question) they will do more research of their own first and then approach the usual public mailing lists or other public discussion areas rather than individual developers. So what? He asked you. I don't know why he asked and I don't see a bad intent in it. This bashing is getting ridiculous now... regards, chris
Re: GCC 10.3 Release Candidate available from gcc.gnu.org
On Thu, Apr 01, 2021 at 08:49:19PM +0100, Jonathan Wakely via Gcc wrote: > On Thu, 1 Apr 2021 at 20:23, Iain Sandoe wrote: > > > > Richard Biener wrote: > > > > > On April 1, 2021 4:08:21 PM GMT+02:00, Eric Botcazou > > > wrote: > > >>> I have so far bootstrapped and tested the release candidate on > > >>> x86_64-linux. Please test it and report any issues to bugzilla. > > > > On x86 Darwin, a lot of new libstdc++ experimental/filesystem fails. > > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99875 > > I missed a backport, this is needed for gcc-10 branch: > https://gcc.gnu.org/cgi-bin/gcc-gitref.cgi?r=r11-7239 > Only affects the testsuite, but in a util header that is used by lots of > tests. > > I'll wait for RM approval before pushing the backport. Ok. Jakub
[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.
Re: [PATCH] x86: Don't generate uiret with -mcmodel=kernel
On Thu, Apr 1, 2021 at 10:47 PM H.J. Lu wrote: > > On Thu, Apr 1, 2021 at 1:28 PM Jan Hubicka wrote: > > > > > On Thu, Apr 1, 2021 at 6:54 PM H.J. Lu wrote: > > > > > > > > Since uiret should be used only for user interrupt handler return, don't > > > > generate uiret in interrupt handler return with -mcmodel=kernel even if > > > > UINTR is enabled. > > > > > > NAK, -mcmodel should not affect ISAs, in the same way it doesn't switch > > > off SSE. > > > > Agreed, while kernel name might not be bit too suggestive, code models > > was intended to be quite general, so it may make sense to compile things > > that are not kernels with kernel cmodel... > > > > Then kernel must be built with -mno-uintr if there are kernel interrupt > handlers > in C. That means that other UINTR intrinsics won't be available to > kernel source > and inline asm statement should be used instead. This is what the kernel does anyway. It doesn't care for compiler builtins. Uros.
Re: [PATCH] x86: Don't generate uiret with -mcmodel=kernel
On Thu, Apr 1, 2021 at 1:28 PM Jan Hubicka wrote: > > > On Thu, Apr 1, 2021 at 6:54 PM H.J. Lu wrote: > > > > > > Since uiret should be used only for user interrupt handler return, don't > > > generate uiret in interrupt handler return with -mcmodel=kernel even if > > > UINTR is enabled. > > > > NAK, -mcmodel should not affect ISAs, in the same way it doesn't switch off > > SSE. > > Agreed, while kernel name might not be bit too suggestive, code models > was intended to be quite general, so it may make sense to compile things > that are not kernels with kernel cmodel... > Then kernel must be built with -mno-uintr if there are kernel interrupt handlers in C. That means that other UINTR intrinsics won't be available to kernel source and inline asm statement should be used instead. -- H.J.
[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;
}
Re: Remove RMS from the GCC Steering Committee
On Thu, 1 Apr 2021, Ian Lance Taylor via Gcc wrote: > > 2) Last year, I asked for libcody to be added as a subcomponent, with > > its Apachev2 license intact. AFAICT RMS was involved in that licensing > > discussion, /for which I never received a response/. He was not at the > > FSF then, so he could not render any FSF licensing opinion. Why was he > > involved? If he was not involved, how did he learn of it in order to > > ask me questions about C++ modules? I only emailed the SC and the > > timing is too coincidental to draw a different conclusion. > > Yes, we definitely dropped the ball on that. Sorry. If that ever > happens again I would encourage you to ping. > > I checked the mailing list archives. Jeff and I expressed support for > using libcody. Nobody else said anything. Certainly RMS didn't say > anything, and it would have been astonishing if he had. But, yes, he > was CC'ed. And while in that case RMS probably learned of modules and libcody through the SC mailing list, in general he has this habit of asking GNU package developers random questions related to their packages. RMS once asked me about the status of fused multiply-add support in glibc. I don't know why. He wasn't asking for any changes or objecting to anything the glibc maintainers had done. I'd hope that future Chief GNUisances won't try to get involved in details like that as part of their role as Chief GNUisance, because it's clearly outside the scope of such a role, and that if interested in such details as an individual free software developer (but not directly involved in development of the package in question) they will do more research of their own first and then approach the usual public mailing lists or other public discussion areas rather than individual developers. -- Joseph S. Myers jos...@codesourcery.com
[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
Re: GCC 10.3 Release Candidate available from gcc.gnu.org
On Thu, 1 Apr 2021 at 21:08, Richard Biener wrote: > > On April 1, 2021 9:49:19 PM GMT+02:00, Jonathan Wakely via Gcc > wrote: > >On Thu, 1 Apr 2021 at 20:23, Iain Sandoe wrote: > >> > >> Richard Biener wrote: > >> > >> > On April 1, 2021 4:08:21 PM GMT+02:00, Eric Botcazou > >> > wrote: > >> >>> I have so far bootstrapped and tested the release candidate on > >> >>> x86_64-linux. Please test it and report any issues to bugzilla. > >> > >> On x86 Darwin, a lot of new libstdc++ experimental/filesystem fails. > >> > >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99875 > > > >I missed a backport, this is needed for gcc-10 branch: > >https://gcc.gnu.org/cgi-bin/gcc-gitref.cgi?r=r11-7239 > >Only affects the testsuite, but in a util header that is used by lots > >of tests. > > > >I'll wait for RM approval before pushing the backport. > > This is OK. Pushed, thanks.
[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)
Re: [PATCH] x86: Don't generate uiret with -mcmodel=kernel
> On Thu, Apr 1, 2021 at 6:54 PM H.J. Lu wrote:
> >
> > Since uiret should be used only for user interrupt handler return, don't
> > generate uiret in interrupt handler return with -mcmodel=kernel even if
> > UINTR is enabled.
>
> NAK, -mcmodel should not affect ISAs, in the same way it doesn't switch off
> SSE.
Agreed, while kernel name might not be bit too suggestive, code models
was intended to be quite general, so it may make sense to compile things
that are not kernels with kernel cmodel...
Honza
>
> Uros.
>
> > gcc/
> >
> > PR target/99870
> > * config/i386/i386.md (interrupt_return): Don't generate uiret
> > for -mcmodel=kernel.
> >
> > gcc/testsuite/
> >
> > * gcc.target/i386/pr99870.c: New test.
> > ---
> > gcc/config/i386/i386.md | 3 ++-
> > gcc/testsuite/gcc.target/i386/pr99870.c | 19 +++
> > 2 files changed, 21 insertions(+), 1 deletion(-)
> > create mode 100644 gcc/testsuite/gcc.target/i386/pr99870.c
> >
> > diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
> > index 9ff35d9a607..1055b4187b2 100644
> > --- a/gcc/config/i386/i386.md
> > +++ b/gcc/config/i386/i386.md
> > @@ -13885,7 +13885,8 @@ (define_insn "interrupt_return"
> > (unspec [(const_int 0)] UNSPEC_INTERRUPT_RETURN)]
> >"reload_completed"
> > {
> > - return TARGET_64BIT ? (TARGET_UINTR ? "uiret" : "iretq") : "iret";
> > + return TARGET_64BIT ? ((TARGET_UINTR && ix86_cmodel != CM_KERNEL)
> > +? "uiret" : "iretq") : "iret";
> > })
> >
> > ;; Used by x86_machine_dependent_reorg to avoid penalty on single byte RET
> > diff --git a/gcc/testsuite/gcc.target/i386/pr99870.c
> > b/gcc/testsuite/gcc.target/i386/pr99870.c
> > new file mode 100644
> > index 000..0dafa001ba9
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/i386/pr99870.c
> > @@ -0,0 +1,19 @@
> > +/* { dg-do compile } */
> > +/* { dg-options "-O2 -march=sapphirerapids -mgeneral-regs-only" } */
> > +/* { dg-additional-options "-mcmodel=kernel" { target { ! ia32 } } } */
> > +
> > +void
> > +__attribute__((interrupt))
> > +fn (void *frame)
> > +{
> > +}
> > +
> > +typedef void (*fn_t) (void *) __attribute__((interrupt));
> > +
> > +fn_t fns[] =
> > +{
> > + fn,
> > +};
> > +
> > +/* { dg-final { scan-assembler-times "\\tiret" 1 { target ia32 } } } */
> > +/* { dg-final { scan-assembler-times "\\tiretq" 1 { target { ! ia32 } } }
> > } */
> > --
> > 2.30.2
> >
[PATCH] c++: placeholder type constraint inside range-for [PR99869]
In the testcase below, during ahead-of-time deduction of a constrained
auto from do_range_for_auto_deduction, we trip over the assert inside
do_auto_deduction that expects the deduction context to be
adc_return_type or adc_variable_type, but the context in this case is
adc_unspecified.
We could safely relax the assert to also accept adc_unspecified, but it
seems the context should really be adc_variable_type in this case.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?
gcc/cp/ChangeLog:
PR c++/99869
* parser.c (do_range_for_auto_deduction): Pass adc_variable_type
to do_auto_deduction.
gcc/testsuite/ChangeLog:
PR c++/99869
* g++.dg/cpp2a/concepts-placeholder6.C: New test.
---
gcc/cp/parser.c| 4 +++-
gcc/testsuite/g++.dg/cpp2a/concepts-placeholder6.C | 10 ++
2 files changed, 13 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/cpp2a/concepts-placeholder6.C
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index d0477c42afe..808e5b61b1e 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -12878,7 +12878,9 @@ do_range_for_auto_deduction (tree decl, tree range_expr)
RO_UNARY_STAR,
tf_warning_or_error);
TREE_TYPE (decl) = do_auto_deduction (TREE_TYPE (decl),
- iter_decl, auto_node);
+ iter_decl, auto_node,
+ tf_warning_or_error,
+ adc_variable_type);
}
}
}
diff --git a/gcc/testsuite/g++.dg/cpp2a/concepts-placeholder6.C
b/gcc/testsuite/g++.dg/cpp2a/concepts-placeholder6.C
new file mode 100644
index 000..18e7b56d77f
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/concepts-placeholder6.C
@@ -0,0 +1,10 @@
+// PR c++/99869
+// { dg-do compile { target c++20 } }
+
+template concept same_as = __is_same(T, U);
+
+template
+void f() {
+ for (same_as auto c : "") {} // dg-error "constraint" }
+ for (same_as auto c : "") {}
+}
--
2.31.1.133.g84d06cdc06
Re: [PATCH] x86: Don't generate uiret with -mcmodel=kernel
On Thu, Apr 1, 2021 at 6:54 PM H.J. Lu wrote:
>
> Since uiret should be used only for user interrupt handler return, don't
> generate uiret in interrupt handler return with -mcmodel=kernel even if
> UINTR is enabled.
NAK, -mcmodel should not affect ISAs, in the same way it doesn't switch off SSE.
Uros.
> gcc/
>
> PR target/99870
> * config/i386/i386.md (interrupt_return): Don't generate uiret
> for -mcmodel=kernel.
>
> gcc/testsuite/
>
> * gcc.target/i386/pr99870.c: New test.
> ---
> gcc/config/i386/i386.md | 3 ++-
> gcc/testsuite/gcc.target/i386/pr99870.c | 19 +++
> 2 files changed, 21 insertions(+), 1 deletion(-)
> create mode 100644 gcc/testsuite/gcc.target/i386/pr99870.c
>
> diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
> index 9ff35d9a607..1055b4187b2 100644
> --- a/gcc/config/i386/i386.md
> +++ b/gcc/config/i386/i386.md
> @@ -13885,7 +13885,8 @@ (define_insn "interrupt_return"
> (unspec [(const_int 0)] UNSPEC_INTERRUPT_RETURN)]
>"reload_completed"
> {
> - return TARGET_64BIT ? (TARGET_UINTR ? "uiret" : "iretq") : "iret";
> + return TARGET_64BIT ? ((TARGET_UINTR && ix86_cmodel != CM_KERNEL)
> +? "uiret" : "iretq") : "iret";
> })
>
> ;; Used by x86_machine_dependent_reorg to avoid penalty on single byte RET
> diff --git a/gcc/testsuite/gcc.target/i386/pr99870.c
> b/gcc/testsuite/gcc.target/i386/pr99870.c
> new file mode 100644
> index 000..0dafa001ba9
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr99870.c
> @@ -0,0 +1,19 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -march=sapphirerapids -mgeneral-regs-only" } */
> +/* { dg-additional-options "-mcmodel=kernel" { target { ! ia32 } } } */
> +
> +void
> +__attribute__((interrupt))
> +fn (void *frame)
> +{
> +}
> +
> +typedef void (*fn_t) (void *) __attribute__((interrupt));
> +
> +fn_t fns[] =
> +{
> + fn,
> +};
> +
> +/* { dg-final { scan-assembler-times "\\tiret" 1 { target ia32 } } } */
> +/* { dg-final { scan-assembler-times "\\tiretq" 1 { target { ! ia32 } } } }
> */
> --
> 2.30.2
>
[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 ***
Re: GCC 10.3 Release Candidate available from gcc.gnu.org
On April 1, 2021 9:49:19 PM GMT+02:00, Jonathan Wakely via Gcc wrote: >On Thu, 1 Apr 2021 at 20:23, Iain Sandoe wrote: >> >> Richard Biener wrote: >> >> > On April 1, 2021 4:08:21 PM GMT+02:00, Eric Botcazou >> > wrote: >> >>> I have so far bootstrapped and tested the release candidate on >> >>> x86_64-linux. Please test it and report any issues to bugzilla. >> >> On x86 Darwin, a lot of new libstdc++ experimental/filesystem fails. >> >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99875 > >I missed a backport, this is needed for gcc-10 branch: >https://gcc.gnu.org/cgi-bin/gcc-gitref.cgi?r=r11-7239 >Only affects the testsuite, but in a util header that is used by lots >of tests. > >I'll wait for RM approval before pushing the backport. This is OK. Richard.
[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.
[pushed] 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.
Tested x86_64-pc-linux-gnu, applying to trunk.
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.
---
gcc/cp/tree.c | 5 +
gcc/testsuite/g++.dg/cpp0x/lambda/lambda-variadic12.C | 9 +
2 files changed, 14 insertions(+)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/lambda/lambda-variadic12.C
diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index dca947bf52a..13cc61c3123 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -5415,6 +5415,11 @@ cp_walk_subtrees (tree *tp, int *walk_subtrees_p,
walk_tree_fn func,
}
break;
+case FUNCTION_TYPE:
+case METHOD_TYPE:
+ WALK_SUBTREE (TYPE_RAISES_EXCEPTIONS (*tp));
+ break;
+
default:
return NULL_TREE;
}
diff --git a/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-variadic12.C
b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-variadic12.C
new file mode 100644
index 000..674615748e6
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-variadic12.C
@@ -0,0 +1,9 @@
+// PR c++/99583
+// { dg-do compile { target c++11 } }
+
+void f(...);
+
+template
+void g() {
+ f([]() noexcept(B) {} ...);
+}
base-commit: af78514a18ca5c9aaa10813bb4dc639d7ccdf0cc
--
2.27.0
Re: GCC 10.3 Release Candidate available from gcc.gnu.org
On Thu, 1 Apr 2021 at 20:23, Iain Sandoe wrote: > > Richard Biener wrote: > > > On April 1, 2021 4:08:21 PM GMT+02:00, Eric Botcazou > > wrote: > >>> I have so far bootstrapped and tested the release candidate on > >>> x86_64-linux. Please test it and report any issues to bugzilla. > > On x86 Darwin, a lot of new libstdc++ experimental/filesystem fails. > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99875 I missed a backport, this is needed for gcc-10 branch: https://gcc.gnu.org/cgi-bin/gcc-gitref.cgi?r=r11-7239 Only affects the testsuite, but in a util header that is used by lots of tests. I'll wait for RM approval before pushing the backport.
[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)
Re: [PATCH] ada/adaint.c (__gnat_copy_attribs): RTEMS should use utime()
L On Thu, Apr 1, 2021, 2:08 PM Bernhard Reutner-Fischer wrote: > On 1 April 2021 21:01:27 CEST, Bernhard Reutner-Fischer < > rep.dot@gmail.com> wrote: > >On 1 April 2021 20:32:34 CEST, Joel Sherrill wrote: > >>Change the preprocessor logic so RTEMS uses utime(). > >>gcc/ada/ > >> * adaint.c (__gnat_copy_attribs): RTEMS should use utime(). > > > >RTEMS probably doesn't care alot about accurate time, from the looks. > >Otherwise it would not mandate use of the obsolescent utime() (AFA SUS > >is concerned WRT nanoseconds precision) it seems? > >They probably know what they're doing I suppose. > >thanks, > >PS I shouldn't reply to none of my business, I know. > RTEMS is a single address space real-time operating system. It's not that we don't care about nanoaecond accurate time. It's just that we don't support the utimesat() call yet. Given a choice, I'll take still compiles and works. :) A filesystem is not required with RTEMS and few deployed systems would have much beyond a static root filesystem anyway. > Meh. Okok. You got me. April 1st ;) > grats :) > We'd be happy to have help implementing the missing POSIX *at() methods. And that's not an April Fools Day joke. :) --joel >
Re: GCC 10.3 Release Candidate available from gcc.gnu.org
Richard Biener wrote: On April 1, 2021 4:08:21 PM GMT+02:00, Eric Botcazou wrote: I have so far bootstrapped and tested the release candidate on x86_64-linux. Please test it and report any issues to bugzilla. On x86 Darwin, a lot of new libstdc++ experimental/filesystem fails. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99875 Iain
Re: Remove RMS from the GCC Steering Committee
On Thu, Apr 1, 2021 at 10:08 AM Nathan Sidwell wrote: > > You, the SC, have chosen to fix this as a clerical error. The most > do-nothing response, other than actually doing nothing. > > I am profoundly disappointed that you have not even acknowledged the > harm RMS has caused. Using passive voiced 'RMS was added' phrasing. > You're not explicitly saying that was incorrect, and neither are you > saying it was correct. Your language attempts to distance you from > your choices. > > 'we no longer feel the listing serves the best interest'. 'Therefore, > we are removing him from the page FULLSTOP'. Well, at least that's not > passive voice, but it is a milque-toast response. You're not removing > him from the SC, merely removing mention of him from the listing. > You're not adding words to the website mentioning this historical > ambiguity/error/misjudgement (you'd say if you were, right?). You're > not adding words acknowledging that RMS's involvement has been > detrimental and repelled contributors. Nor are you apologizing. You're > not owning your mistake. You just hope the problem will silently go > away. The problem will not go away. > > /You/ involved RMS in SC discussions. /You/ treated him as a member > thereof. /You/ gave him controlling rights. > > You have misled the majority of GCC developers, and the wider community > by doing so. If it looks like a duck, walks like a duck, and talks like > a duck, it's a duck. (As compiler developers for duck-typed languages, > you should understand that.) > > You involved RMS prior to 2012, and continued to do so after. Including > after 2019 when he was no longer at the FSF. Two instances I personally > know of: > > 1) Sometime around 2005? maybe later, I lobbied to change gcc's > implementation language to C++. I failed because I'm lazy and learned I > was arguing against an RMS effective veto. (I learned this because Mark > Mitchell informed me that some SC members were also pushing back against > RMS's opposition to C++. I was not privy to the actual SC discussion.) > If he was not an SC member, why was he even in that private > conversation? The public ML would have been more appropriate place for > non-SC opinions to be voiced. Just think, we could have transitioned to > C++ earlier than we did, if it were not for the SC's inclusio of RMS. > > 2) Last year, I asked for libcody to be added as a subcomponent, with > its Apachev2 license intact. AFAICT RMS was involved in that licensing > discussion, /for which I never received a response/. He was not at the > FSF then, so he could not render any FSF licensing opinion. Why was he > involved? If he was not involved, how did he learn of it in order to > ask me questions about C++ modules? I only emailed the SC and the > timing is too coincidental to draw a different conclusion. > > Interactions I've had with the SC, beyond maintainer appointment, seem > to run into RMS. (In the original email I mentioned a third interaction > about RMS's position on the SC, which didn't do so, but also was > decidedly one way.) > > You, the SC, do not state that you will not continue to involve RMS in > discussions, just as you have done for the past 20 years. You merely > feel the listing is unfortunate. > > Your final paragraph is the corporate BS of hollow men. Nice words, no > specific actions. > > Richard Biener pointed out dysfunction in the SC. The case of the > missing question I asked in 2019 also points to that. This response > gives me no confidence that things will materially change. I call for > the dissolution of the SC, replacing it with a more open, functional and > inclusive body (which includes, nothing). > > nathan > > FWIW, I am surprised that you, the SC, chose to respond only to the > mailing list, and not CC me, the original complainant, of your decision. > Perhaps that seems petty, but it is personally insulting. Nathan, you are clearly angry and frustrated. I'm sorry about that. I'm going to give some of my own personal opinions. I'm not at all speaking for the committee, and other committee members may disagree. The steering committee is just a bunch of GCC hackers who originally self-organized to manage the EGCS fork. As it says at https://gcc.gnu.org/steering.html, "committee members were chosen to represent the interests of communities." I was not on the steering committee at the time, but I was somewhat involved with thinking about who should be, and that statement accurately describes what we were trying to do. The intent was to ensure that when decisions were made that covered the GCC project as a whole, all interested groups would have a representative. In practice the steering committee makes few decisions. Naturally, members of the committee work to improve GCC in various ways. That work almost never involves any sort of steering committee discussion. I think you want the steering committee to issue a statement about RMS's behavior. I
[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.
Re: [PATCH] c++: GC collects live data when synthesizing operator== [PR99831]
On 4/1/21 2:15 PM, Marek Polacek wrote:
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. Alternatively, as in this patch, we can create a new
GC root to hold the expression list. Since I'm adding a new global, I
felt compelled to get rid of one, and I actually did find an unused one!
So, 86 it. But I'm also happy to just go with bumping function_depth.
I think bumping function_depth is the right solution; this patch only
deals with one source of unreachable expressions that could be collected
prematurely if complete_type results in GC running.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/10?
gcc/cp/ChangeLog:
PR c++/99831
* parser.c (cp_parser_functional_cast): Make the expression list
a GC root.
* pt.c: Remove the saved_trees global.
gcc/testsuite/ChangeLog:
PR c++/99831
* g++.dg/other/gc6.C: New test.
---
gcc/cp/parser.c | 20
gcc/cp/pt.c | 1 -
gcc/testsuite/g++.dg/other/gc6.C | 16
3 files changed, 28 insertions(+), 9 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/other/gc6.C
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index d0477c42afe..28d7a8be258 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -30569,13 +30569,17 @@ cp_parser_simple_cast_expression (cp_parser *parser)
}
/* Parse a functional cast to TYPE. Returns an expression
- representing the cast. */
+ representing the cast. Preserve the expression list across
+ a garbage collect (by making it a GC root), which can occur
+ in finish_compound_literal -> complete_type, when we synthesize
+ a constexpr comparison function. */
+
+static GTY(()) tree fncast_expression_list;
static cp_expr
cp_parser_functional_cast (cp_parser* parser, tree type)
{
vec *vec;
- tree expression_list;
cp_expr cast;
bool nonconst_p;
@@ -30588,12 +30592,12 @@ cp_parser_functional_cast (cp_parser* parser, tree type)
{
cp_lexer_set_source_position (parser->lexer);
maybe_warn_cpp0x (CPP0X_INITIALIZER_LISTS);
- expression_list = cp_parser_braced_list (parser, _p);
- CONSTRUCTOR_IS_DIRECT_INIT (expression_list) = 1;
+ fncast_expression_list = cp_parser_braced_list (parser, _p);
+ CONSTRUCTOR_IS_DIRECT_INIT (fncast_expression_list) = 1;
if (TREE_CODE (type) == TYPE_DECL)
type = TREE_TYPE (type);
- cast = finish_compound_literal (type, expression_list,
+ cast = finish_compound_literal (type, fncast_expression_list,
tf_warning_or_error, fcl_functional);
/* Create a location of the form:
type_name{i, f}
@@ -30612,10 +30616,10 @@ cp_parser_functional_cast (cp_parser* parser, tree
type)
/*allow_expansion_p=*/true,
/*non_constant_p=*/NULL);
if (vec == NULL)
-expression_list = error_mark_node;
+fncast_expression_list = error_mark_node;
else
{
- expression_list = build_tree_list_vec (vec);
+ fncast_expression_list = build_tree_list_vec (vec);
release_tree_vector (vec);
}
@@ -30626,7 +30630,7 @@ cp_parser_functional_cast (cp_parser* parser, tree type)
finishing at the closing paren. */
location_t combined_loc = make_location (start_loc, start_loc,
parser->lexer);
- cast = build_functional_cast (combined_loc, type, expression_list,
+ cast = build_functional_cast (combined_loc, type, fncast_expression_list,
tf_warning_or_error);
/* [expr.const]/1: In an integral constant expression "only type
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index dc6f2f37f9b..7956e83c1de 100644
--- a/gcc/cp/pt.c
+++
Re: [PATCH] ada/adaint.c (__gnat_copy_attribs): RTEMS should use utime()
On 1 April 2021 21:01:27 CEST, Bernhard Reutner-Fischer wrote: >On 1 April 2021 20:32:34 CEST, Joel Sherrill wrote: >>Change the preprocessor logic so RTEMS uses utime(). >>gcc/ada/ >> * adaint.c (__gnat_copy_attribs): RTEMS should use utime(). > >RTEMS probably doesn't care alot about accurate time, from the looks. >Otherwise it would not mandate use of the obsolescent utime() (AFA SUS >is concerned WRT nanoseconds precision) it seems? >They probably know what they're doing I suppose. >thanks, >PS I shouldn't reply to none of my business, I know.. Meh. Okok. You got me. April 1st ;) grats :)
Re: [PATCH] ada/adaint.c (__gnat_copy_attribs): RTEMS should use utime()
On 1 April 2021 20:32:34 CEST, Joel Sherrill wrote: >Change the preprocessor logic so RTEMS uses utime(). >gcc/ada/ > * adaint.c (__gnat_copy_attribs): RTEMS should use utime(). RTEMS probably doesn't care alot about accurate time, from the looks. Otherwise it would not mandate use of the obsolescent utime() (AFA SUS is concerned WRT nanoseconds precision) it seems? They probably know what they're doing I suppose. thanks, PS I shouldn't reply to none of my business, I know.. >--- > gcc/ada/adaint.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > >diff --git a/gcc/ada/adaint.c b/gcc/ada/adaint.c >index 0a90c92402c..d3b83f61076 100644 >--- a/gcc/ada/adaint.c >+++ b/gcc/ada/adaint.c >@@ -3270,7 +3270,7 @@ __gnat_copy_attribs (char *from ATTRIBUTE_UNUSED, >char *to ATTRIBUTE_UNUSED, > return -1; > } > >-#if (defined (__vxworks) && _WRS_VXWORKS_MAJOR < 7) >+#if (defined (__vxworks) && _WRS_VXWORKS_MAJOR < 7) || >defined(__rtems__) > > /* VxWorks prior to 7 only has utime. */ >
Re: [PATCH] x86: Don't generate uiret with -mcmodel=kernel
On 1 April 2021 20:31:13 CEST, Bernhard Reutner-Fischer
wrote:
>On 1 April 2021 18:54:07 CEST, "H.J. Lu via Gcc-patches"
> wrote:
>>Since uiret should be used only for user interrupt handler return,
>>don't
>>generate uiret in interrupt handler return with -mcmodel=kernel even
>if
>>UINTR is enabled.
>>
>>gcc/
>>
>> PR target/99870
>> * config/i386/i386.md (interrupt_return): Don't generate uiret
>> for -mcmodel=kernel.
>>
>>gcc/testsuite/
>>
>> * gcc.target/i386/pr99870.c: New test.
>>---
>> gcc/config/i386/i386.md | 3 ++-
>> gcc/testsuite/gcc.target/i386/pr99870.c | 19 +++
>> 2 files changed, 21 insertions(+), 1 deletion(-)
>> create mode 100644 gcc/testsuite/gcc.target/i386/pr99870.c
>>
>>diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
>>index 9ff35d9a607..1055b4187b2 100644
>>--- a/gcc/config/i386/i386.md
>>+++ b/gcc/config/i386/i386.md
>>@@ -13885,7 +13885,8 @@ (define_insn "interrupt_return"
>>(unspec [(const_int 0)] UNSPEC_INTERRUPT_RETURN)]
>> "reload_completed"
>> {
>>- return TARGET_64BIT ? (TARGET_UINTR ? "uiret" : "iretq") : "iret";
>>+ return TARGET_64BIT ? ((TARGET_UINTR && ix86_cmodel != CM_KERNEL)
>>+ ? "uiret" : "iretq") : "iret";
>> })
>>
>>;; Used by x86_machine_dependent_reorg to avoid penalty on single byte
>>RET
>>diff --git a/gcc/testsuite/gcc.target/i386/pr99870.c
>>b/gcc/testsuite/gcc.target/i386/pr99870.c
>>new file mode 100644
>>index 000..0dafa001ba9
>>--- /dev/null
>>+++ b/gcc/testsuite/gcc.target/i386/pr99870.c
>>@@ -0,0 +1,19 @@
>>+/* { dg-do compile } */
>>+/* { dg-options "-O2 -march=sapphirerapids -mgeneral-regs-only" } */
>>+/* { dg-additional-options "-mcmodel=kernel" { target { ! ia32 } } }
>>*/
>>+
>>+void
>>+__attribute__((interrupt))
>>+fn (void *frame)
Oh and of course that named param should trigger an unused parm warning making
the test fail as is.
Why wasn't that flagged? Isn't this warning on by default?
>>+{
>>+}
>>+
>>+typedef void (*fn_t) (void *) __attribute__((interrupt));
>>+
>>+fn_t fns[] =
>>+{
>>+ fn,
>>+};
>>+
>>+/* { dg-final { scan-assembler-times "\\tiret" 1 { target ia32 } } }
>
>This matches ia32 and the others as well (x32 and amd64 or x86_64)
>doesn't it.
>>*/
>>+/* { dg-final { scan-assembler-times "\\tiretq" 1 { target { ! ia32 }
>>} } } */
>
>So this is superfluous without a trailing anchor for the first, fwiw.
>Thanks,
[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.
[PATCH] ada/adaint.c (__gnat_copy_attribs): RTEMS should use utime()
Change the preprocessor logic so RTEMS uses utime(). gcc/ada/ * adaint.c (__gnat_copy_attribs): RTEMS should use utime(). --- gcc/ada/adaint.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/ada/adaint.c b/gcc/ada/adaint.c index 0a90c92402c..d3b83f61076 100644 --- a/gcc/ada/adaint.c +++ b/gcc/ada/adaint.c @@ -3270,7 +3270,7 @@ __gnat_copy_attribs (char *from ATTRIBUTE_UNUSED, char *to ATTRIBUTE_UNUSED, return -1; } -#if (defined (__vxworks) && _WRS_VXWORKS_MAJOR < 7) +#if (defined (__vxworks) && _WRS_VXWORKS_MAJOR < 7) || defined(__rtems__) /* VxWorks prior to 7 only has utime. */ -- 2.24.4
[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?
Re: [PATCH] x86: Don't generate uiret with -mcmodel=kernel
On 1 April 2021 18:54:07 CEST, "H.J. Lu via Gcc-patches"
wrote:
>Since uiret should be used only for user interrupt handler return,
>don't
>generate uiret in interrupt handler return with -mcmodel=kernel even if
>UINTR is enabled.
>
>gcc/
>
> PR target/99870
> * config/i386/i386.md (interrupt_return): Don't generate uiret
> for -mcmodel=kernel.
>
>gcc/testsuite/
>
> * gcc.target/i386/pr99870.c: New test.
>---
> gcc/config/i386/i386.md | 3 ++-
> gcc/testsuite/gcc.target/i386/pr99870.c | 19 +++
> 2 files changed, 21 insertions(+), 1 deletion(-)
> create mode 100644 gcc/testsuite/gcc.target/i386/pr99870.c
>
>diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
>index 9ff35d9a607..1055b4187b2 100644
>--- a/gcc/config/i386/i386.md
>+++ b/gcc/config/i386/i386.md
>@@ -13885,7 +13885,8 @@ (define_insn "interrupt_return"
>(unspec [(const_int 0)] UNSPEC_INTERRUPT_RETURN)]
> "reload_completed"
> {
>- return TARGET_64BIT ? (TARGET_UINTR ? "uiret" : "iretq") : "iret";
>+ return TARGET_64BIT ? ((TARGET_UINTR && ix86_cmodel != CM_KERNEL)
>+ ? "uiret" : "iretq") : "iret";
> })
>
>;; Used by x86_machine_dependent_reorg to avoid penalty on single byte
>RET
>diff --git a/gcc/testsuite/gcc.target/i386/pr99870.c
>b/gcc/testsuite/gcc.target/i386/pr99870.c
>new file mode 100644
>index 000..0dafa001ba9
>--- /dev/null
>+++ b/gcc/testsuite/gcc.target/i386/pr99870.c
>@@ -0,0 +1,19 @@
>+/* { dg-do compile } */
>+/* { dg-options "-O2 -march=sapphirerapids -mgeneral-regs-only" } */
>+/* { dg-additional-options "-mcmodel=kernel" { target { ! ia32 } } }
>*/
>+
>+void
>+__attribute__((interrupt))
>+fn (void *frame)
>+{
>+}
>+
>+typedef void (*fn_t) (void *) __attribute__((interrupt));
>+
>+fn_t fns[] =
>+{
>+ fn,
>+};
>+
>+/* { dg-final { scan-assembler-times "\\tiret" 1 { target ia32 } } }
This matches ia32 and the others as well (x32 and amd64 or x86_64) doesn't it.
>*/
>+/* { dg-final { scan-assembler-times "\\tiretq" 1 { target { ! ia32 }
>} } } */
So this is superfluous without a trailing anchor for the first, fwiw.
Thanks,
[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
[PATCH] 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. Alternatively, as in this patch, we can create a new
GC root to hold the expression list. Since I'm adding a new global, I
felt compelled to get rid of one, and I actually did find an unused one!
So, 86 it. But I'm also happy to just go with bumping function_depth.
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk/10?
gcc/cp/ChangeLog:
PR c++/99831
* parser.c (cp_parser_functional_cast): Make the expression list
a GC root.
* pt.c: Remove the saved_trees global.
gcc/testsuite/ChangeLog:
PR c++/99831
* g++.dg/other/gc6.C: New test.
---
gcc/cp/parser.c | 20
gcc/cp/pt.c | 1 -
gcc/testsuite/g++.dg/other/gc6.C | 16
3 files changed, 28 insertions(+), 9 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/other/gc6.C
diff --git a/gcc/cp/parser.c b/gcc/cp/parser.c
index d0477c42afe..28d7a8be258 100644
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -30569,13 +30569,17 @@ cp_parser_simple_cast_expression (cp_parser *parser)
}
/* Parse a functional cast to TYPE. Returns an expression
- representing the cast. */
+ representing the cast. Preserve the expression list across
+ a garbage collect (by making it a GC root), which can occur
+ in finish_compound_literal -> complete_type, when we synthesize
+ a constexpr comparison function. */
+
+static GTY(()) tree fncast_expression_list;
static cp_expr
cp_parser_functional_cast (cp_parser* parser, tree type)
{
vec *vec;
- tree expression_list;
cp_expr cast;
bool nonconst_p;
@@ -30588,12 +30592,12 @@ cp_parser_functional_cast (cp_parser* parser, tree
type)
{
cp_lexer_set_source_position (parser->lexer);
maybe_warn_cpp0x (CPP0X_INITIALIZER_LISTS);
- expression_list = cp_parser_braced_list (parser, _p);
- CONSTRUCTOR_IS_DIRECT_INIT (expression_list) = 1;
+ fncast_expression_list = cp_parser_braced_list (parser, _p);
+ CONSTRUCTOR_IS_DIRECT_INIT (fncast_expression_list) = 1;
if (TREE_CODE (type) == TYPE_DECL)
type = TREE_TYPE (type);
- cast = finish_compound_literal (type, expression_list,
+ cast = finish_compound_literal (type, fncast_expression_list,
tf_warning_or_error, fcl_functional);
/* Create a location of the form:
type_name{i, f}
@@ -30612,10 +30616,10 @@ cp_parser_functional_cast (cp_parser* parser, tree
type)
/*allow_expansion_p=*/true,
/*non_constant_p=*/NULL);
if (vec == NULL)
-expression_list = error_mark_node;
+fncast_expression_list = error_mark_node;
else
{
- expression_list = build_tree_list_vec (vec);
+ fncast_expression_list = build_tree_list_vec (vec);
release_tree_vector (vec);
}
@@ -30626,7 +30630,7 @@ cp_parser_functional_cast (cp_parser* parser, tree type)
finishing at the closing paren. */
location_t combined_loc = make_location (start_loc, start_loc,
parser->lexer);
- cast = build_functional_cast (combined_loc, type, expression_list,
+ cast = build_functional_cast (combined_loc, type, fncast_expression_list,
tf_warning_or_error);
/* [expr.const]/1: In an integral constant expression "only type
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index dc6f2f37f9b..7956e83c1de 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -65,7 +65,6 @@ static GTY(()) struct pending_template *last_pending_template;
int processing_template_parmlist;
static int template_header_count;
-static GTY(()) tree saved_trees;
static vec inline_parm_levels;
static GTY(()) struct tinst_level *current_tinst_level;
diff
[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.
Re: [committed] libstdc++: Test errno macros directly, not via autoconf [PR 93151]
On 01/04/21 18:47 +0200, Eric Botcazou wrote: Thanks, pushed. I can confirm that the build failure we had is now gone, thanks! Eric, are you building the RC with --enable-maintainer-mode maybe? Or regenerating the autoconf files yourself? The latter, we have local configure changes so we regenerate the script. Aha, that explains it then. And it's useful that you noticed this before the final release!
[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
Re: [PATCH] arm: Fix PCS for SFmode -> SImode libcalls [PR99748]
On 01/04/2021 17:11, Alex Coplan via Gcc-patches wrote:
Hi all,
This patch fixes PR99748 which shows us trying to pass the argument to
__aeabi_f2iz in the VFP register s0 when the library function is
expecting to use the GPR r0. It also fixes the __aeabi_f2uiz case which
was broken in the same way.
For the testcase in the PR, here is the code we generate before the
patch (with -mfloat-abi=hard -march=armv8.1-m.main+mve -O0):
main:
push{r7, lr}
sub sp, sp, #8
add r7, sp, #0
mov r3, #1065353216
str r3, [r7, #4]@ float
vldr.32 s0, [r7, #4]
bl __aeabi_f2iz
mov r3, r0
cmp r3, #1
[...]
This becomes:
main:
push{r7, lr}
sub sp, sp, #8
add r7, sp, #0
mov r3, #1065353216
str r3, [r7, #4]@ float
ldr r0, [r7, #4]@ float
bl __aeabi_f2iz
mov r3, r0
cmp r3, #1
[...]
after the patch. We see a similar change for the same testcase with a
cast to unsigned instead of int.
Testing:
* Bootstrapped and regtested on arm-linux-gnueabihf, no regressions.
* Regtested an arm-eabi cross configured with --with-float=hard
--with-arch=armv8.1-m.main+mve. This shows that the patch fixes the
following execution failures:
FAIL->PASS: gcc.c-torture/execute/2605-1.c -O0 execution test
FAIL->PASS: gcc.c-torture/execute/conversion.c -O0 execution test
FAIL->PASS: gcc.c-torture/execute/float-floor.c -O0 execution test
FAIL->PASS: gcc.c-torture/execute/float-floor.c -O1 execution test
FAIL->PASS: gcc.c-torture/execute/float-floor.c -O2 execution test
FAIL->PASS: gcc.c-torture/execute/float-floor.c -O2 -flto
-fno-use-linker-plugin -flto-partition=none execution test
FAIL->PASS: gcc.c-torture/execute/float-floor.c -O3 -g execution test
FAIL->PASS: gcc.c-torture/execute/float-floor.c -Os execution test
FAIL->PASS: gcc.c-torture/execute/gofast.c -O0 execution test
FAIL->PASS: gcc.dg/torture/float32-basic.c -O0 execution test
FAIL->PASS: gcc.dg/torture/float32-basic.c -O1 execution test
FAIL->PASS: gcc.dg/torture/float32-basic.c -O2 execution test
FAIL->PASS: gcc.dg/torture/float32-basic.c -O2 -flto
-fno-use-linker-plugin -flto-partition=none execution test
FAIL->PASS: gcc.dg/torture/float32-basic.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects execution test
FAIL->PASS: gcc.dg/torture/float32-basic.c -O3 -g execution test
FAIL->PASS: gcc.dg/torture/float32-basic.c -Os execution test
OK for trunk?
Thanks,
Alex
gcc/ChangeLog:
* config/arm/arm.c (arm_libcall_uses_aapcs_base): Also use base
PCS for [su]fix_optab.
OK.
As a wrong code bug we should probably be looking to backport this if
needed (though it's likely too late now for 10.3).
R.
Re: GCC 10.3 Release Candidate available from gcc.gnu.org
On April 1, 2021 4:08:21 PM GMT+02:00, Eric Botcazou wrote: >> I have so far bootstrapped and tested the release candidate on >> x86_64-linux. Please test it and report any issues to bugzilla. > >It does not build for Windows: > https://gcc.gnu.org/pipermail/gcc-patches/2021-April/567582.html Backporting the followup fix is approved. Richard.
[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.
Re: [PATCH] c++: Refine check for CTAD placeholder [PR99586]
On 4/1/21 10:30 AM, Patrick Palka wrote:
In the below testcase, during finish_compound_literal for A{},
type_uses_auto finds and returns the CTAD placeholder for B{V}, which
tricks us into attempting CTAD on A{} and leads to bogus errors.
AFAICT 'type' will always be a bare 'auto' in the CTAD case, so we don't
need to look deeply to find it; checking template_placeholder_p instead
should suffice here.
Bootstrapped and regtested on x86_64-pc-linux-gnu, and also on cmcstl2
and range-v3. Does this look OK for trunk, or perhaps stage1?
OK for trunk.
gcc/cp/ChangeLog:
PR c++/99586
* semantics.c (finish_compound_literal): Check
template_placeholder_p instead of type_uses_auto.
gcc/testsuite/ChangeLog:
PR c++/99586
* g++.dg/cpp2a/nontype-class42.C: New test.
---
gcc/cp/semantics.c | 15 +++
gcc/testsuite/g++.dg/cpp2a/nontype-class42.C | 8
2 files changed, 15 insertions(+), 8 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp2a/nontype-class42.C
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index b02596f73bd..8eaaaefe2d6 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -3036,14 +3036,13 @@ finish_compound_literal (tree type, tree
compound_literal,
return error_mark_node;
}
- if (tree anode = type_uses_auto (type))
-if (CLASS_PLACEHOLDER_TEMPLATE (anode))
- {
- type = do_auto_deduction (type, compound_literal, anode, complain,
- adc_variable_type);
- if (type == error_mark_node)
- return error_mark_node;
- }
+ if (template_placeholder_p (type))
+{
+ type = do_auto_deduction (type, compound_literal, type, complain,
+ adc_variable_type);
+ if (type == error_mark_node)
+ return error_mark_node;
+}
/* Used to hold a copy of the compound literal in a template. */
tree orig_cl = NULL_TREE;
diff --git a/gcc/testsuite/g++.dg/cpp2a/nontype-class42.C
b/gcc/testsuite/g++.dg/cpp2a/nontype-class42.C
new file mode 100644
index 000..a688bee6f3d
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/nontype-class42.C
@@ -0,0 +1,8 @@
+// PR c++/99586
+// { dg-do compile { target c++20 } }
+
+template
+struct B { constexpr B(T) { } };
+
+template struct A{};
+template auto a = A{};
Re: Remove RMS from the GCC Steering Committee
On 3/31/21 2:27 PM, David Edelsohn via Gcc wrote: [I previously sent this from another email account, but it seems to be lost. I am sending this on behalf of the GCC Steering Committee.] In 2012 RMS was added to the GCC Steering Committee web page based on his role in the GNU Project, though his role as a member of the Steering Committee has been ambiguous and he was not a member of the Steering Committee when EGCS became GCC[1]. We no longer feel that this listing serves the best interests of the GCC developer and user community. Therefore, we are removing him from the page. GCC supports the principles of Free Software and has remained aligned with the GNU Project since EGCS became GCC, but effectively has continued to operate as an autonomous project. The GCC Steering Committee is committed to providing a friendly, safe and welcoming environment for all, regardless of gender identity and expression, sexual orientation, disabilities, neurodiversity, physical appearance, body size, ethnicity, nationality, race, age, religion, or similar personal characteristics. - The GCC Steering Committee [1] https://static.lwn.net/1999/0429/a/gcc.html You, the SC, have chosen to fix this as a clerical error. The most do-nothing response, other than actually doing nothing. I am profoundly disappointed that you have not even acknowledged the harm RMS has caused. Using passive voiced 'RMS was added' phrasing. You're not explicitly saying that was incorrect, and neither are you saying it was correct. Your language attempts to distance you from your choices. 'we no longer feel the listing serves the best interest'. 'Therefore, we are removing him from the page FULLSTOP'. Well, at least that's not passive voice, but it is a milque-toast response. You're not removing him from the SC, merely removing mention of him from the listing. You're not adding words to the website mentioning this historical ambiguity/error/misjudgement (you'd say if you were, right?). You're not adding words acknowledging that RMS's involvement has been detrimental and repelled contributors. Nor are you apologizing. You're not owning your mistake. You just hope the problem will silently go away. The problem will not go away. /You/ involved RMS in SC discussions. /You/ treated him as a member thereof. /You/ gave him controlling rights. You have misled the majority of GCC developers, and the wider community by doing so. If it looks like a duck, walks like a duck, and talks like a duck, it's a duck. (As compiler developers for duck-typed languages, you should understand that.) You involved RMS prior to 2012, and continued to do so after. Including after 2019 when he was no longer at the FSF. Two instances I personally know of: 1) Sometime around 2005? maybe later, I lobbied to change gcc's implementation language to C++. I failed because I'm lazy and learned I was arguing against an RMS effective veto. (I learned this because Mark Mitchell informed me that some SC members were also pushing back against RMS's opposition to C++. I was not privy to the actual SC discussion.) If he was not an SC member, why was he even in that private conversation? The public ML would have been more appropriate place for non-SC opinions to be voiced. Just think, we could have transitioned to C++ earlier than we did, if it were not for the SC's inclusio of RMS. 2) Last year, I asked for libcody to be added as a subcomponent, with its Apachev2 license intact. AFAICT RMS was involved in that licensing discussion, /for which I never received a response/. He was not at the FSF then, so he could not render any FSF licensing opinion. Why was he involved? If he was not involved, how did he learn of it in order to ask me questions about C++ modules? I only emailed the SC and the timing is too coincidental to draw a different conclusion. Interactions I've had with the SC, beyond maintainer appointment, seem to run into RMS. (In the original email I mentioned a third interaction about RMS's position on the SC, which didn't do so, but also was decidedly one way.) You, the SC, do not state that you will not continue to involve RMS in discussions, just as you have done for the past 20 years. You merely feel the listing is unfortunate. Your final paragraph is the corporate BS of hollow men. Nice words, no specific actions. Richard Biener pointed out dysfunction in the SC. The case of the missing question I asked in 2019 also points to that. This response gives me no confidence that things will materially change. I call for the dissolution of the SC, replacing it with a more open, functional and inclusive body (which includes, nothing). nathan FWIW, I am surprised that you, the SC, chose to respond only to the mailing list, and not CC me, the original complainant, of your decision. Perhaps that seems petty, but it is personally insulting. -- Nathan Sidwell
[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.
[PATCH] x86: Don't generate uiret with -mcmodel=kernel
Since uiret should be used only for user interrupt handler return, don't
generate uiret in interrupt handler return with -mcmodel=kernel even if
UINTR is enabled.
gcc/
PR target/99870
* config/i386/i386.md (interrupt_return): Don't generate uiret
for -mcmodel=kernel.
gcc/testsuite/
* gcc.target/i386/pr99870.c: New test.
---
gcc/config/i386/i386.md | 3 ++-
gcc/testsuite/gcc.target/i386/pr99870.c | 19 +++
2 files changed, 21 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gcc.target/i386/pr99870.c
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 9ff35d9a607..1055b4187b2 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -13885,7 +13885,8 @@ (define_insn "interrupt_return"
(unspec [(const_int 0)] UNSPEC_INTERRUPT_RETURN)]
"reload_completed"
{
- return TARGET_64BIT ? (TARGET_UINTR ? "uiret" : "iretq") : "iret";
+ return TARGET_64BIT ? ((TARGET_UINTR && ix86_cmodel != CM_KERNEL)
+? "uiret" : "iretq") : "iret";
})
;; Used by x86_machine_dependent_reorg to avoid penalty on single byte RET
diff --git a/gcc/testsuite/gcc.target/i386/pr99870.c
b/gcc/testsuite/gcc.target/i386/pr99870.c
new file mode 100644
index 000..0dafa001ba9
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/pr99870.c
@@ -0,0 +1,19 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -march=sapphirerapids -mgeneral-regs-only" } */
+/* { dg-additional-options "-mcmodel=kernel" { target { ! ia32 } } } */
+
+void
+__attribute__((interrupt))
+fn (void *frame)
+{
+}
+
+typedef void (*fn_t) (void *) __attribute__((interrupt));
+
+fn_t fns[] =
+{
+ fn,
+};
+
+/* { dg-final { scan-assembler-times "\\tiret" 1 { target ia32 } } } */
+/* { dg-final { scan-assembler-times "\\tiretq" 1 { target { ! ia32 } } } } */
--
2.30.2
Re: [committed] libstdc++: Test errno macros directly, not via autoconf [PR 93151]
> Thanks, pushed. I can confirm that the build failure we had is now gone, thanks! > Eric, are you building the RC with --enable-maintainer-mode maybe? Or > regenerating the autoconf files yourself? The latter, we have local configure changes so we regenerate the script. -- Eric Botcazou
Re: [PATCH V5 0/6] Support for the CTF and BTF debug formats
ping > [Changes from V4: > - Rebased to latest master. > - Support for DATASEC in BTF. > - Bug fixes in the CTF support. > - Be more silent: do not inform() the user anymore if -gctf is used > along with a frontend for which there is no CTF support. Ignore > the request instead. > - Got rid of lang_GNU_GIMPLE, which is not needed. > - New preparatory patch that abstracts the tests on write_symbols > in a predicate. > - New preparatory patch that provides an internal interface to the > DWARF internal structures. This makes it possible to not have to > #include dwarf2ctf.c in dwarf2out.c. Note that we only added the > minimum set of functions/data types we need for dwarf2ctf. Note > also that we didn't add prefixes to avoid massive renames in > dwarf2out.c. We also add a few new accessor functions. See the > particular patch description. > - Fixes to allow using -gctf along with -gdwarf. > - More testing: > + More BTF tests. > + More CTF tests. > + Tests for mixing -gctf and -gdwarf. > + Regression tests in x86_64 and aarch64. > + LTO testing. > + 1612 Gentoo packages built with CTF support, no failures.] > > Hi people! > > Last year we submitted a first patch series introducing support for > the CTF debugging format in GCC [1]. We got a lot of feedback that > prompted us to change the approach used to generate the debug info, > and this patch series is the result of that. > > This series also add support for the BTF debug format, which is needed > by the BPF backend (more on this below.) > > This implementation works, but there are several points that need > discussion and agreement with the upstream community, as they impact > the way debugging options work. We are also proposing a way to add > additional debugging formats in the future. See below for more > details. > > Finally, a patch makes the BPF GCC backend to use the DWARF debug > hooks in order to make -gbtf available to it. > > [1] https://gcc.gnu.org/legacy-ml/gcc-patches/2019-05/msg01297.html > > About CTF > = > > CTF is a debugging format designed in order to express C types in a > very compact way. The key is compactness and simplicity. For more > information see: > > - CTF specification > http://www.esperi.org.uk/~oranix/ctf/ctf-spec.pdf > > - Compact C-Type support in the GNU toolchain (talk + slides) > https://linuxplumbersconf.org/event/4/contributions/396/ > > - On type de-duplication in CTF (talk + slides) > https://linuxplumbersconf.org/event/7/contributions/725/ > > About BTF > = > > BTF is a debugging format, similar to CTF, that is used in the Linux > kernel as the debugging format for BPF programs. From the kernel > documentation: > > "BTF (BPF Type Format) is the metadata format which encodes the debug > info related to BPF program/map. The name BTF was used initially to > describe data types. The BTF was later extended to include function > info for defined subroutines, and line info for source/line > information." > > Supporting BTF in GCC is important because compiled BPF programs > (which GCC supports as a target) require the type information in order > to be loaded and run in diverse kernel versions. This mechanism is > known as CO-RE (compile-once, run-everywhere) and is described in the > "Update of the BPF support in the GNU Toolchain" talk mentioned below. > > The BTF is documented in the Linux kernel documentation tree: > - linux/Documentation/bpf/btf.rst > > CTF in the GNU Toolchain > > > During the last year we have been working in adding support for CTF to > several components of the GNU toolchain: > > - binutils support is already upstream. It supports linking objects > with CTF information with full type de-duplication. > > - GDB support is to be sent upstream very shortly. It makes the > debugger capable to use the CTF information whenever available. > This is useful in cases where DWARF has been stripped out but CTF is > kept. > > - GCC support is being discussed and submitted in this series. > > Overview of the Implementation > == > > dwarf2out.c > > The enabled debug formats are hooked in dwarf2out_early_finish. > > dwarf2int.h > > Internal interface that exports a few functions and data types > defined in dwarf2out.c. > > dwarf2ctf.c > > Code that tranform the internal GCC DWARF DIEs into CTF container > structures. This file uses the dwarf2int.h interface. > > ctfc.c > ctfc.h > > These two files implement the "CTF container", which is shared > among CTF and BTF, due to the many similarities between both > formats. > > ctfout.c > > Code that emits assembler with the .ctf section data, from the CTF > container. > > btfout.c > > Code that emits assembler with the .BTF section data, from the CTF > container. > > From debug hooks to debug formats > = > > Our first attempt in adding CTF to
