[Bug c++/96926] [9/10/11 Regression] Tuple element w/ member reference to incomplete template type rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96926 --- Comment #5 from Jason Merrill --- (In reply to Jason Merrill from comment #4) > I think perhaps it's wrong to do substitution at this point because X has no > default argument. Giving it a default argument causes clang 10 to also > reject the testcase. ...but changing that doesn't help real testcases, since the tuple constructors do have default args for their constructor parms.
[Bug c++/98844] Deduction guides don't inhibit the aggregate deduction candidate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98844 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Fixed by r11-7096.
[Bug c++/96926] [9/10/11 Regression] Tuple element w/ member reference to incomplete template type rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96926
--- Comment #4 from Jason Merrill ---
Further reduced:
template struct A {
using type = typename T::type;
};
template class B {
template ::type X>
B(U);
};
struct C {
B b;
C();
};
int main() {
C c;
}
We run into trouble trying to implicitly declare the copy constructor for C,
which involves overload resolution to find the constructor called for copying
B.
After r262172, when we consider the constructor template, we try to substitute
the default template argument for V into the type of X, which involves
instantiating A, which fails. Before r262172, we would see that we can't
convert B to int, and give up on the candidate before getting to this
substitution. But r262172 moves the convertibility checking until after we're
done with deduction, as per http://wg21.link/cwg2369
I think perhaps it's wrong to do substitution at this point because X has no
default argument. Giving it a default argument causes clang 10 to also reject
the testcase.
[Bug c++/98820] Placeholder (auto) non-type template parameter wrongly deduced to 'const' for class type arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98820 Marek Polacek changed: What|Removed |Added Keywords||rejects-valid CC||mpolacek at gcc dot gnu.org Last reconfirmed||2021-02-12 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Marek Polacek --- Confirmed, I guess.
[Bug c++/98810] [9/10/11 Regression] [C++20] ICE in tsubst_copy, at cp/pt.c:16771
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98810 Marek Polacek changed: What|Removed |Added Priority|P3 |P2 Summary|[C++20] ICE in tsubst_copy, |[9/10/11 Regression] |at cp/pt.c:16771|[C++20] ICE in tsubst_copy, ||at cp/pt.c:16771 CC||jason at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Target Milestone|--- |9.4 --- Comment #2 from Marek Polacek --- r273592
[Bug c++/98804] GCC misparses template in pack expansion as comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98804 Marek Polacek changed: What|Removed |Added Last reconfirmed||2021-02-12 CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Marek Polacek --- Confirmed.
[Bug c++/97034] [11 Regression] ICE on C++20 code: gcc_assert failure in return type deduction (gcc/cp/pt.c:26984 in type_dependent_expression_p(tree_node*))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97034 --- Comment #8 from Marek Polacek --- Alternative patch that I'm more happy about: --- a/gcc/cp/pt.c +++ b/gcc/cp/pt.c @@ -28761,6 +28761,7 @@ build_deduction_guide (tree type, tree ctor, tree outer_args, tsubst_flags_t com tree ded_fn = build_lang_decl_loc (loc, FUNCTION_DECL, dguide_name (type), fntype); + DECL_CONTEXT (ded_fn) = type; DECL_ARGUMENTS (ded_fn) = fargs; DECL_ARTIFICIAL (ded_fn) = true; DECL_NONCONVERTING_P (ded_fn) = explicit_p;
[Bug c++/96926] [9/10/11 Regression] Tuple element w/ member reference to incomplete template type rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96926 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/97742] [10/11 Regression] endless loop with code reduced by creduce/cvise
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97742 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/97296] [10/11 Regression] g++ accepts-invalid after DR2352 fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97296 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Marek Polacek --- Yeah, I'll take a look in the coming weeks.
[Bug c++/97296] [10/11 Regression] g++ accepts-invalid after DR2352 fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97296 Jason Merrill changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org --- Comment #1 from Jason Merrill --- Marek, since those were your changes, are you planning to take this one?
[Bug c++/96078] [10/11 Regression] flatten attribute on constructor and destructor causes spurious warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96078 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org CC||jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug c++/98326] [10/11 Regression] ICE: in create_tmp_var, at gimple-expr.c:482, converting stateless generic-lambda to function pointer since r10-599-gc652ff8312433483
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98326 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jason Merrill --- Fixed for 10.3/11.
[Bug c++/96905] [10/11 Regression] ICE with consteval function: internal compiler error: in cp_gimplify_expr, at cp/cp-gimplify.c:827
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96905 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Jason Merrill --- Fixed for 10.3/11.
[Bug c++/94546] [10 Regression] unimplemented: unexpected AST of kind nontype_argument_pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94546 --- Comment #6 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:ac001ddd0cb635dec0145bf577ac796894bda398 commit r11-7204-gac001ddd0cb635dec0145bf577ac796894bda398 Author: Jason Merrill Date: Thu Feb 11 19:45:22 2021 -0500 c++: variadic lambda template and empty pack [PR97246] In get<0>, Is is empty, so the first parameter pack of the lambda is empty, but after the fix for PR94546 we were wrongly associating it with the partial instantiation of 'v'. gcc/cp/ChangeLog: PR c++/97246 PR c++/94546 * pt.c (extract_fnparm_pack): Check DECL_PACK_P here. (register_parameter_specializations): Not here. gcc/testsuite/ChangeLog: PR c++/97246 * g++.dg/cpp2a/lambda-generic-variadic21.C: New test.
[Bug c++/97246] [10/11 regression] mismatched argument pack lengths since r10-7865-gaedd04caa945260e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97246 --- Comment #2 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:ac001ddd0cb635dec0145bf577ac796894bda398 commit r11-7204-gac001ddd0cb635dec0145bf577ac796894bda398 Author: Jason Merrill Date: Thu Feb 11 19:45:22 2021 -0500 c++: variadic lambda template and empty pack [PR97246] In get<0>, Is is empty, so the first parameter pack of the lambda is empty, but after the fix for PR94546 we were wrongly associating it with the partial instantiation of 'v'. gcc/cp/ChangeLog: PR c++/97246 PR c++/94546 * pt.c (extract_fnparm_pack): Check DECL_PACK_P here. (register_parameter_specializations): Not here. gcc/testsuite/ChangeLog: PR c++/97246 * g++.dg/cpp2a/lambda-generic-variadic21.C: New test.
[Bug c++/96905] [10/11 Regression] ICE with consteval function: internal compiler error: in cp_gimplify_expr, at cp/cp-gimplify.c:827
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96905 --- Comment #7 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:86d8ecf28e6c20b3e6866a5b1551a339edc8d14d commit r10-9363-g86d8ecf28e6c20b3e6866a5b1551a339edc8d14d Author: Jason Merrill Date: Mon Feb 8 17:16:14 2021 -0500 c++: consteval and explicit instantiation [PR96905] Normally, an explicit instantiation means we want to write out the instantiation. But not for a consteval function. gcc/cp/ChangeLog: PR c++/96905 * pt.c (mark_decl_instantiated): Exit early if consteval. gcc/testsuite/ChangeLog: PR c++/96905 * g++.dg/cpp2a/consteval-expinst1.C: New test.
[Bug middle-end/20408] Unnecessary code generated for empty structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408 --- Comment #25 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:031e97207463710797625382baff112b6c3ade51 commit r10-9362-g031e97207463710797625382baff112b6c3ade51 Author: Jason Merrill Date: Mon Feb 8 17:04:03 2021 -0500 c++: generic lambda, fn* conv, empty class [PR98326] Here, in the thunk returned from the captureless lambda conversion to pointer-to-function, we try to pass through invisible reference parameters by reference, without doing a copy. The empty class copy optimization was messing that up. gcc/cp/ChangeLog: PR c++/98326 PR c++/20408 * cp-gimplify.c (simple_empty_class_p): Don't touch an invisiref parm. gcc/testsuite/ChangeLog: PR c++/98326 * g++.dg/cpp1y/lambda-generic-empty1.C: New test.
[Bug c++/98326] [10/11 Regression] ICE: in create_tmp_var, at gimple-expr.c:482, converting stateless generic-lambda to function pointer since r10-599-gc652ff8312433483
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98326 --- Comment #4 from CVS Commits --- The releases/gcc-10 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:031e97207463710797625382baff112b6c3ade51 commit r10-9362-g031e97207463710797625382baff112b6c3ade51 Author: Jason Merrill Date: Mon Feb 8 17:04:03 2021 -0500 c++: generic lambda, fn* conv, empty class [PR98326] Here, in the thunk returned from the captureless lambda conversion to pointer-to-function, we try to pass through invisible reference parameters by reference, without doing a copy. The empty class copy optimization was messing that up. gcc/cp/ChangeLog: PR c++/98326 PR c++/20408 * cp-gimplify.c (simple_empty_class_p): Don't touch an invisiref parm. gcc/testsuite/ChangeLog: PR c++/98326 * g++.dg/cpp1y/lambda-generic-empty1.C: New test.
[Bug c++/97034] [11 Regression] ICE on C++20 code: gcc_assert failure in return type deduction (gcc/cp/pt.c:26984 in type_dependent_expression_p(tree_node*))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97034
--- Comment #7 from Marek Polacek ---
Candidate patch:
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -27279,7 +27279,10 @@ type_dependent_expression_p (tree expression)
&& DECL_UNIQUE_FRIEND_P (expression)
&& (!DECL_FRIEND_CONTEXT (expression)
|| dependent_type_p (DECL_FRIEND_CONTEXT (expression
- && !DECL_LOCAL_DECL_P (expression))
+ && !DECL_LOCAL_DECL_P (expression)
+ /* We build deduction guides without any DECL_CONTEXT, but they can
+be type-dependent. */
+ && !deduction_guide_p (expression))
{
gcc_assert (!dependent_type_p (TREE_TYPE (expression))
|| undeduced_auto_decl (expression));
[Bug analyzer/98969] [11 Regression] ICE: Segmentation fault (in print_mem_ref)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98969 --- Comment #11 from David Malcolm --- As noted above, the ICE is fixed, but the leak false positive is not yet fixed.
[Bug analyzer/98969] [11 Regression] ICE: Segmentation fault (in print_mem_ref)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98969 --- Comment #10 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:467a48205279cab368dbeb02879e4b721516 commit r11-7202-g467a48205279cab368dbeb02879e4b721516 Author: David Malcolm Date: Thu Feb 11 20:31:28 2021 -0500 analyzer: fix ICE in print_mem_ref [PR98969] PR analyzer/98969 and PR analyzer/99064 describes ICEs, in both cases within print_mem_ref, when falsely reporting memory leaks - though it is possible to generate the ICE on other diagnostics (which I added in one of the test cases). This patch fixes the ICE, leaving the fix for the leak false positives as followup work. The analyzer uses region_model::get_representative_path_var and region_model::get_representative_tree to map back from its svalue and region classes to the tree type used by the rest of the compiler, and, in particular, for diagnostics. The root cause of the ICE is sloppiness about types within those functions; specifically when casts were stripped off svalues. To track these down I added wrapper functions that verify that the types of the results are correct, and in doing so found various other type-safety issues, which the patch also fixes. Doing so led to various changes in diagnostics messages due to more accurate types, but I felt that these changes weren't desirable. For example, the warning at CVE-2005-1689-minimal.c line 48 which expects: double-'free' of 'inbuf.data' changed fo double-'free' of '(char *)inbuf.data' So I added stripping of top-level casts where necessary to avoid cluttering diagnostics. Finally, the more accurate types led to worse results from readability_comparator, where e.g. the event message at line 50 of sensitive-1.c regressed from the precise: passing sensitive value 'password' in call to 'called_by_test_5' from 'test_5' to the vaguer: calling 'called_by_test_5' from 'test_5' This was due to erroneously picking the initial value of "password" in the caller frame as the best value within the *callee* frame, due to "char *" vs "const char *", which confuses the logic for tracking values that pass along callgraph edges. The patch fixes this by combining the readability tests for tree and stack depth, rather than performing them in sequence, so that it favors the value in the deepest frame. As noted above, the patch fixes the ICEs, but does not fix the leak false positives. gcc/analyzer/ChangeLog: PR analyzer/98969 * engine.cc (readability): Add names for the various arbitrary values. Handle NOP_EXPR and INTEGER_CST. (readability_comparator): Combine the readability tests for tree and stack depth, rather than performing them sequentially. (impl_region_model_context::on_state_leak): Strip off top-level casts. * region-model.cc (region_model::get_representative_path_var): Add type-checking, moving the bulk of the implementation to... (region_model::get_representative_path_var_1): ...here. Respect types in casts by recursing and re-adding the cast, rather than merely stripping them off. Use the correct type when handling region_svalue. (region_model::get_representative_tree): Strip off any top-level cast. (region_model::get_representative_path_var): Add type-checking, moving the bulk of the implementation to... (region_model::get_representative_path_var_1): ...here. * region-model.h (region_model::get_representative_path_var_1): New decl (region_model::get_representative_path_var_1): New decl. * store.cc (append_pathvar_with_type): New. (binding_cluster::get_representative_path_vars): Cast path_vars to the correct type when adding them to *OUT_PVS. gcc/testsuite/ChangeLog: PR analyzer/98969 * g++.dg/analyzer/pr99064.C: New test. * gcc.dg/analyzer/pr98969.c: New test.
[Bug analyzer/99064] [11 regression] ICE analyzer::print_mem_ref
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99064 --- Comment #3 from CVS Commits --- The master branch has been updated by David Malcolm : https://gcc.gnu.org/g:467a48205279cab368dbeb02879e4b721516 commit r11-7202-g467a48205279cab368dbeb02879e4b721516 Author: David Malcolm Date: Thu Feb 11 20:31:28 2021 -0500 analyzer: fix ICE in print_mem_ref [PR98969] PR analyzer/98969 and PR analyzer/99064 describes ICEs, in both cases within print_mem_ref, when falsely reporting memory leaks - though it is possible to generate the ICE on other diagnostics (which I added in one of the test cases). This patch fixes the ICE, leaving the fix for the leak false positives as followup work. The analyzer uses region_model::get_representative_path_var and region_model::get_representative_tree to map back from its svalue and region classes to the tree type used by the rest of the compiler, and, in particular, for diagnostics. The root cause of the ICE is sloppiness about types within those functions; specifically when casts were stripped off svalues. To track these down I added wrapper functions that verify that the types of the results are correct, and in doing so found various other type-safety issues, which the patch also fixes. Doing so led to various changes in diagnostics messages due to more accurate types, but I felt that these changes weren't desirable. For example, the warning at CVE-2005-1689-minimal.c line 48 which expects: double-'free' of 'inbuf.data' changed fo double-'free' of '(char *)inbuf.data' So I added stripping of top-level casts where necessary to avoid cluttering diagnostics. Finally, the more accurate types led to worse results from readability_comparator, where e.g. the event message at line 50 of sensitive-1.c regressed from the precise: passing sensitive value 'password' in call to 'called_by_test_5' from 'test_5' to the vaguer: calling 'called_by_test_5' from 'test_5' This was due to erroneously picking the initial value of "password" in the caller frame as the best value within the *callee* frame, due to "char *" vs "const char *", which confuses the logic for tracking values that pass along callgraph edges. The patch fixes this by combining the readability tests for tree and stack depth, rather than performing them in sequence, so that it favors the value in the deepest frame. As noted above, the patch fixes the ICEs, but does not fix the leak false positives. gcc/analyzer/ChangeLog: PR analyzer/98969 * engine.cc (readability): Add names for the various arbitrary values. Handle NOP_EXPR and INTEGER_CST. (readability_comparator): Combine the readability tests for tree and stack depth, rather than performing them sequentially. (impl_region_model_context::on_state_leak): Strip off top-level casts. * region-model.cc (region_model::get_representative_path_var): Add type-checking, moving the bulk of the implementation to... (region_model::get_representative_path_var_1): ...here. Respect types in casts by recursing and re-adding the cast, rather than merely stripping them off. Use the correct type when handling region_svalue. (region_model::get_representative_tree): Strip off any top-level cast. (region_model::get_representative_path_var): Add type-checking, moving the bulk of the implementation to... (region_model::get_representative_path_var_1): ...here. * region-model.h (region_model::get_representative_path_var_1): New decl (region_model::get_representative_path_var_1): New decl. * store.cc (append_pathvar_with_type): New. (binding_cluster::get_representative_path_vars): Cast path_vars to the correct type when adding them to *OUT_PVS. gcc/testsuite/ChangeLog: PR analyzer/98969 * g++.dg/analyzer/pr99064.C: New test. * gcc.dg/analyzer/pr98969.c: New test.
[Bug c++/97034] [11 Regression] ICE on C++20 code: gcc_assert failure in return type deduction (gcc/cp/pt.c:26984 in type_dependent_expression_p(tree_node*))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97034
--- Comment #6 from Marek Polacek ---
(In reply to Arthur O'Dwyer from comment #5)
> Is mine the same bug? Mine is also a regression (trunk crashes where GCC
> 10.2 had succeeded).
>
> // https://godbolt.org/z/Ysh6as
> struct C { void f(auto) noexcept; };
> void C::f(auto) noexcept(C::x) {}
>
> Compile with -std=c++20:
>
>
> :3:29: error: 'x' is not a member of 'C'
> 3 | void C::f(auto) noexcept(C::x) {}
> | ^
> :3:6: error: declaration of 'void C::f(auto:2)' has a different
> exception specifier
> 3 | void C::f(auto) noexcept(C::x) {}
> | ^
> :2:17: note: from previous declaration 'void C::f(auto:1) noexcept'
> 2 | struct C { void f(auto) noexcept; };
> | ^
> :3:30: internal compiler error: in type_dependent_expression_p, at
> cp/pt.c:27166
> 3 | void C::f(auto) noexcept(C::x) {}
> | ^
> 0x1cc31d9 internal_error(char const*, ...)
> ???:0
> 0x6b25f7 fancy_abort(char const*, int, char const*)
> ???:0
> 0x8ee70a type_dependent_expression_p(tree_node*)
> ???:0
> 0x137d4f3 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
> void*, hash_set >*,
> tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
> void*, hash_set >*))
> ???:0
> 0x1381b55 walk_tree_without_duplicates_1(tree_node**, tree_node*
> (*)(tree_node**, int*, void*), void*, tree_node* (*)(tree_node**, int*,
> tree_node* (*)(tree_node**, int*, void*), void*, hash_set default_hash_traits >*))
> ???:0
> 0x8ea937 instantiation_dependent_uneval_expression_p(tree_node*)
> ???:0
> 0x8f2198 instantiation_dependent_expression_p(tree_node*)
> ???:0
> 0x8f2216 uses_template_parms(tree_node*)
> ???:0
> 0x78ffe8 duplicate_decls(tree_node*, tree_node*, bool, bool)
> ???:0
> 0x79a2b6 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
> decl_context, int, tree_node**)
> ???:0
> 0x79dda6 start_function(cp_decl_specifier_seq*, cp_declarator const*,
> tree_node*)
> ???:0
> 0x8d803d c_parse_file()
> ???:0
> 0xa54072 c_common_parse_file()
> ???:0
I think that is a different problem (the original problem here was with
deduction guides).
[Bug c++/99078] New: Optimizer moves struct initialization into loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99078
Bug ID: 99078
Summary: Optimizer moves struct initialization into loop
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: magiblot at hotmail dot com
Target Milestone: ---
Consider the following piece of code (https://godbolt.org/z/WhTcbd):
> struct S
> {
> char c[24];
> };
>
> void copy(S *dest, unsigned count)
> {
> S s {};
> for (int i = 0; i < 7; ++i)
> s.c[i] = i;
> for (int i = 8; i < 15; ++i)
> s.c[i] = i;
> for (int i = 16; i < 23; ++i)
> s.c[i] = i;
> while (count--)
> *dest++ = s;
> }
The generated assembly with -O2 looks like this:
> copy(S*, unsigned int):
> mov QWORD PTR [rsp-24], 0
> pxorxmm0, xmm0
> movups XMMWORD PTR [rsp-40], xmm0
> testesi, esi
> je .L1
> mov esi, esi
> lea rax, [rsi+rsi*2]
> lea rdx, [rdi+rax*8]
> .L3:
> mov eax, 1541
> mov ecx, 3340
> mov esi, 5396
> mov DWORD PTR [rsp-39], 67305985
> mov WORD PTR [rsp-35], ax
> add rdi, 24
> mov DWORD PTR [rsp-32], 185207048
> mov WORD PTR [rsp-28], cx
> mov BYTE PTR [rsp-26], 14
> movdqu xmm1, XMMWORD PTR [rsp-40]
> mov DWORD PTR [rsp-24], 319951120
> mov WORD PTR [rsp-20], si
> mov BYTE PTR [rsp-18], 22
> mov rax, QWORD PTR [rsp-24]
> movups XMMWORD PTR [rdi-24], xmm1
> mov QWORD PTR [rdi-8], rax
> cmp rdi, rdx
> jne .L3
> .L1:
> ret
It can be seen that the struct initialization has been moved into the loop,
which is a severe pessimization.
The issue cannot be reproduced if the struct is initialized this way:
> S s;
> memset(&s, 0, sizeof(s));
But the following still reproduces the issue:
> S s {};
> memset(&s, 0, sizeof(s));
Replacing the assignment inside the loop with memcpy does not affect the
result.
According to Godbolt, the generated assembly has not changed since GCC 7.2. GCC
7.1 does not use vector registers but still initializes the struct inside the
loop. GCC 6.4 and earlier do not use vector registers either but do initialize
the struct outside the loop, as expected.
EXPECTED RESULT
Ideally, the loop body would be optimized into something like this:
> movdqu xmm1, XMMWORD PTR [rsp-40]
> mov rax, QWORD PTR [rsp-24]
> .L3:
> add rdi, 24
> movups XMMWORD PTR [rdi-24], xmm1
> mov QWORD PTR [rdi-8], rax
> cmp rdi, rdx
> jne .L3
> .L1:
> ret
Thank you.
[Bug middle-end/93644] [10/11 Regression] spurious -Wreturn-local-addr with PHI of PHI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93644 --- Comment #14 from Martin Sebor --- I looks like this might be another opportunity to use the predicate analysis from tree-ssa-uninit.c (once it's generalized).
[Bug tree-optimization/96966] [8/9/10/11 Regression] redundant memcpy not eliminated after pointer subtraction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96966 --- Comment #3 from Martin Sebor --- No change in GCC 11.
[Bug c/21860] Frontends should be adding DECL_EXPRs for TYPE_DECLs, at least when the type has SAVE_EXPRs in it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21860 Martin Sebor changed: What|Removed |Added Status|NEW |WAITING CC||msebor at gcc dot gnu.org --- Comment #3 from Martin Sebor --- This bug hasn't been updated in over 15 years. Is is still relevant?
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87296 --- Comment #11 from Martin Sebor --- I should note: The changes are too intrusive to backport.
[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 Bug 88443 depends on bug 87296, which changed state. Bug 87296 Summary: [8/9/10/11 Regression] -Wstringop-overflow false positive due to using MEM_REF type of &MEM https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87296 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
gcc-bugs@gcc.gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87296 Martin Sebor changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|8.5 |11.0 Status|NEW |RESOLVED Blocks||88443 Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org --- Comment #10 from Martin Sebor --- GCC 11 no longer warns for these test cases, most likely as a result of r11-3827. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 [Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
[Bug middle-end/21433] The COMPONENT_REF case of expand_expr_real_1 is probably wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21433 Martin Sebor changed: What|Removed |Added Target Milestone|--- |12.0 Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot gnu.org Keywords||patch --- Comment #4 from Martin Sebor --- Patch proposed for GCC 12: https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565211.html
[Bug tree-optimization/99074] gcc 8 and above is crashing with dynamic_cast<>() on null pointer with optimization level -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99074
Martin Sebor changed:
What|Removed |Added
Keywords||diagnostic
Last reconfirmed||2021-02-12
CC||msebor at gcc dot gnu.org
Resolution|INVALID |---
Target Milestone|--- |12.0
Status|RESOLVED|ASSIGNED
Ever confirmed|0 |1
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
--- Comment #2 from Martin Sebor ---
True, it's undefined, and regrettably not caught by -Wnonnull. The warning
runs both too early (in the FE) and too late (in CCP). But can we do better
than simply crashing? Clang can, as can ICC (no crash there). It seems to me
the call to __dynamic_cast with the null pointer could be intercepted. At
compile-time, GCC could warn, and at runtime, the call could return null. The
following is a proof of concept that does that:
$ /build/gcc-master/gcc/xg++ -B /build/gcc-master/gcc -nostdinc++ -L
/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -O2 -Wall
pr99074.C &&
LD_LIBRARY_PATH=/build/gcc-master/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
./a.out
In member function ‘Object* AbstractBase::_to_object()’,
inlined from ‘int main()’ at pr99074.C:24:39:
pr99074.C:12:35: warning: argument 1 null where non-null expected [-Wnonnull]
12 | Object* _to_object() { return dynamic_cast(this); }
| ^~~
pr99074.C: In function ‘int main()’:
pr99074.C:12:61: note: in a call to function ‘void* __dynamic_cast(const void*,
const __cxxabiv1::__class_type_info*, const __cxxabiv1::__class_type_info*,
long int)’ declared ‘nonnull’
12 | Object* _to_object() { return dynamic_cast(this); }
| ^
object is: (nil)
Let me confirm this bug and propose the change below.
diff --git a/gcc/cp/rtti.c b/gcc/cp/rtti.c
index b41d95469c6..c54e431de31 100644
--- a/gcc/cp/rtti.c
+++ b/gcc/cp/rtti.c
@@ -30,6 +30,7 @@ along with GCC; see the file COPYING3. If not see
#include "stor-layout.h"
#include "c-family/c-pragma.h"
#include "gcc-rich-location.h"
+#include "attribs.h"
/* C++ returns type information to the user in struct type_info
objects. We also use type information to implement dynamic_cast and
@@ -767,6 +768,10 @@ build_dynamic_cast_1 (location_t loc, tree type, tree
expr,
dcast_fn = (build_library_fn_ptr
(fn_name, fn_type, ECF_LEAF | ECF_PURE |
ECF_NOTHROW));
pop_abi_namespace (flags);
+
+ tree attr = tree_cons (get_identifier ("nonnull"), 0, 0);
+ decl_attributes (&dcast_fn, attr, 0);
+
dynamic_cast_node = dcast_fn;
}
result = build_cxx_call (dcast_fn, 4, elems, complain);
diff --git a/libstdc++-v3/libsupc++/dyncast.cc
b/libstdc++-v3/libsupc++/dyncast.cc
index b7d98495ad3..6e9d81b312d 100644
--- a/libstdc++-v3/libsupc++/dyncast.cc
+++ b/libstdc++-v3/libsupc++/dyncast.cc
@@ -47,6 +47,8 @@ __dynamic_cast (const void *src_ptr,// object started
from
const __class_type_info *dst_type, // desired target type
ptrdiff_t src2dst) // how src and dst are related
{
+ if (!src_ptr)
+return NULL;
const void *vtable = *static_cast (src_ptr);
const vtable_prefix *prefix =
(adjust_pointer
[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959
--- Comment #17 from Peter Bergner ---
(In reply to Peter Bergner from comment #16)
> The question I have is, there are 2 expanders which I think we also need to
> guard with similar tests. They are vsx_load_ and vsx_store_.
> Segher, I assume we want to verify we don't have an altivec style & ~16
> address there too, correct? Just like we do in vector.md's mov
> pattern.
Ie, adding the following hunks to the patch above:
@@ -1241,7 +1245,8 @@
"VECTOR_MEM_VSX_P (mode)"
{
/* Expand to swaps if needed, prior to swap optimization. */
- if (!BYTES_BIG_ENDIAN && !TARGET_P9_VECTOR)
+ if (!BYTES_BIG_ENDIAN && !TARGET_P9_VECTOR
+ && !altivec_indexed_or_indirect_operand(operands[1], mode))
{
rs6000_emit_le_vsx_move (operands[0], operands[1], mode);
DONE;
@@ -1254,7 +1259,8 @@
"VECTOR_MEM_VSX_P (mode)"
{
/* Expand to swaps if needed, prior to swap optimization. */
- if (!BYTES_BIG_ENDIAN && !TARGET_P9_VECTOR)
+ if (!BYTES_BIG_ENDIAN && !TARGET_P9_VECTOR
+ && !altivec_indexed_or_indirect_operand(operands[0], mode))
{
rs6000_emit_le_vsx_move (operands[0], operands[1], mode);
DONE;
[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959 --- Comment #16 from Peter Bergner --- (In reply to Bill Schmidt from comment #14) > We should definitely not be allowing the AltiVec "& ~16" flavors into these > patterns. I'm not certain whether your fix is the best way to achieve that, > but it could well be; I'll defer to Segher on that. So I _think_ the patch above is correct. Ie, we shouldn't split the insn which calls the rs6000_emit_le_vsx_* functions if the mem address isn't valid for the patterns the splitter is going to create. The question I have is, there are 2 expanders which I think we also need to guard with similar tests. They are vsx_load_ and vsx_store_. Segher, I assume we want to verify we don't have an altivec style & ~16 address there too, correct? Just like we do in vector.md's mov pattern.
[Bug middle-end/21433] The COMPONENT_REF case of expand_expr_real_1 is probably wrong
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=21433 --- Comment #3 from Martin Sebor --- Created attachment 50171 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50171&action=edit Proposed patch. Patched to remove the CONSTRUCTOR code and replace it with an assert that it doesn't come up. Tested on x86_64-linux.
[Bug libstdc++/99077] [9/10/11 Regression] Cannot build libstdc++ with -fno-rtti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99077
--- Comment #2 from Jonathan Wakely ---
--- a/libstdc++-v3/src/c++11/cxx11-ios_failure.cc
+++ b/libstdc++-v3/src/c++11/cxx11-ios_failure.cc
@@ -114,7 +114,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__ios_failure(const char* s) : failure(s)
{ __construct_ios_failure(buf, runtime_error::what()); }
-__ios_failure(const char* s, int e) : failure(s, to_error_code(e))
+__ios_failure(const char* s, const error_code& e) : failure(s, e)
{ __construct_ios_failure(buf, runtime_error::what()); }
~__ios_failure()
@@ -125,10 +125,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
// There are assertions in src/c++98/ios_failure.cc to ensure the size
// and alignment assumptions are valid.
alignas(runtime_error) unsigned char buf[sizeof(runtime_error)];
-
-static error_code
-to_error_code(int e)
-{ return e ? error_code(e, system_category()) : io_errc::stream; }
};
// Custom type info for __ios_failure.
@@ -171,7 +167,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
void
__throw_ios_failure(const char* str __attribute__((unused)),
int err __attribute__((unused)))
- { _GLIBCXX_THROW_OR_ABORT(__ios_failure(_(str), err)); }
+ {
+_GLIBCXX_THROW_OR_ABORT(__ios_failure(_(str),
+ err ? error_code(err, generic_category()) : io_errc::stream));
+ }
_GLIBCXX_END_NAMESPACE_VERSION
} // namespace
[Bug libstdc++/99077] [9/10/11 Regression] Cannot build libstdc++ with -fno-rtti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99077 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Known to fail||10.2.0, 11.0, 9.3.0 Last reconfirmed||2021-02-11 Target Milestone|--- |9.4 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Known to work||8.4.0 --- Comment #1 from Jonathan Wakely --- I have a patch
[Bug libstdc++/99077] New: [9/10/11 Regression] Cannot build libstdc++ with -fno-rtti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99077
Bug ID: 99077
Summary: [9/10/11 Regression] Cannot build libstdc++ with
-fno-rtti
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: build
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
In file included from
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/iosfwd:38,
from
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/ios:38,
from
/home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++11/cxx11-ios_failure.cc:30:
/home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++11/cxx11-ios_failure.cc: In
function ‘void std::__throw_ios_failure(const char*, int)’:
/home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++11/cxx11-ios_failure.cc:174:54:
error: no matching function for call to ‘std::ios_base::failure::failure(char*,
int&)’
174 | { _GLIBCXX_THROW_OR_ABORT(__ios_failure(_(str), err)); }
| ^
/home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++11/cxx11-ios_failure.cc:93:3:
note: candidate: ‘std::ios_base::failure::failure(const char*, const
std::error_code&)’
93 | ios_base::failure::failure(const char* __str, const error_code& __ec)
| ^~~~
/home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++11/cxx11-ios_failure.cc:93:67:
note: no known conversion for argument 2 from ‘int’ to ‘const
std::error_code&’
93 | ios_base::failure::failure(const char* __str, const error_code& __ec)
| ~~^~~~
/home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++11/cxx11-ios_failure.cc:90:3:
note: candidate: ‘std::ios_base::failure::failure(const string&, const
std::error_code&)’
90 | ios_base::failure::failure(const string& __str, const error_code&
__ec)
| ^~~~
/home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++11/cxx11-ios_failure.cc:90:69:
note: no known conversion for argument 2 from ‘int’ to ‘const
std::error_code&’
90 | ios_base::failure::failure(const string& __str, const error_code&
__ec)
|
~~^~~~
/home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++11/cxx11-ios_failure.cc:87:3:
note: candidate: ‘std::ios_base::failure::failure(const string&)’
87 | ios_base::failure::failure(const string& __str)
| ^~~~
/home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++11/cxx11-ios_failure.cc:87:3:
note: candidate expects 1 argument, 2 provided
In file included from
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/ios:42,
from
/home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++11/cxx11-ios_failure.cc:30:
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/ios_base.h:255:34:
note: candidate: ‘std::ios_base::failure::failure(const
std::ios_base::failure&)’
255 | class _GLIBCXX_ABI_TAG_CXX11 failure : public system_error
| ^~~
/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/ios_base.h:255:34:
note: candidate expects 1 argument, 2 provided
/home/jwakely/src/gcc/gcc/libstdc++-v3/src/c++11/cxx11-ios_failure.cc:174:58:
warning: ‘noreturn’ function does return
174 | { _GLIBCXX_THROW_OR_ABORT(__ios_failure(_(str), err)); }
| ^
make[3]: *** [Makefile:855: cxx11-ios_failure-lt.s] Error 1
[Bug c++/12277] eliminate and warn on dynamic casts with known NULL results
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12277 Martin Sebor changed: What|Removed |Added Last reconfirmed|2017-01-11 00:00:00 |2021-2-11 Known to fail|7.0 |11.0, 7.5.0 --- Comment #11 from Martin Sebor --- No improvement in GCC 11.
[Bug c++/95888] [9 Regression] Regression in 9.3. GCC freezes when compiling code using boost::poly_collection::segment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95888 Marek Polacek changed: What|Removed |Added Resolution|--- |FIXED Summary|[9/10 Regression] |[9 Regression] Regression |Regression in 9.3. GCC |in 9.3. GCC freezes when |freezes when compiling code |compiling code using |using |boost::poly_collection::seg |boost::poly_collection::seg |ment |ment| Status|ASSIGNED|RESOLVED --- Comment #11 from Marek Polacek --- Fixed.
[Bug c++/95888] [9/10 Regression] Regression in 9.3. GCC freezes when compiling code using boost::poly_collection::segment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95888 --- Comment #10 from CVS Commits --- The releases/gcc-10 branch has been updated by Marek Polacek : https://gcc.gnu.org/g:60dbb46b5b3c52d0483d676eabd4dfe32110e61b commit r10-9360-g60dbb46b5b3c52d0483d676eabd4dfe32110e61b Author: Marek Polacek Date: Tue Feb 9 15:17:48 2021 -0500 c++: Endless loop with targ deduction in member tmpl [PR95888] My r10-7007 patch tweaked tsubst not to reduce the template level of template parameters when tf_partial. That caused infinite looping in is_specialization_of: we ended up with a class template specialization whose TREE_TYPE (CLASSTYPE_TI_TEMPLATE (t)) == t, so the second for loop in is_specialization_of never finished. There's a lot going on in this test, but essentially: the template fn here has two template parameters, we call it with one explicitly provided, the other one has to be deduced. So we'll find ourselves in fn_type_unification which uses tf_partial when tsubsting the *explicit* template arguments into the function type. That leads to tsubstituting the return type, C. C is a member template; its most general template is template template struct B::C we figure out (tsubst_template_args) that the template argument list is . They come from different levels, one comes from B, the other one from fn. So now we lookup_template_class to see if we have C. We do the /* This is a full instantiation of a member template. Find the partial instantiation of which this is an instance. */ TREE_VEC_LENGTH (arglist)--; // arglist is now , not found = tsubst (gen_tmpl, arglist, complain, NULL_TREE); TREE_VEC_LENGTH (arglist)++; magic which is looking for the partial instantiation, in this case, that would be template struct B::C. Note we're still in a tf_partial context! So the tsubst_template_args in the tsubst (which tries to substitute into ) returns , but V's template level hasn't been reduced! After tsubst_template_args, tsubst_template_decl looks to see if we already have this specialization: // t = template_decl C // full_args = spec = retrieve_specialization (t, full_args, hash); but doesn't find the one we created a while ago, when processing B b; in the test, because V's levels don't match. Whereupon tsubst_template_decl creates a new TEMPLATE_DECL, one that leads to the infinite looping problem. Fixed by using tf_none when looking for an existing partial instantiation. It also occurred to me that I should be able to trigger a similar problem with 'auto', since r10-7007 removed an is_auto check. And lo, I constructed deduce10.C which exhibits the same issue with pre-r10-7007 compilers. This patch fixes that problem as well. I'm ecstatic. gcc/cp/ChangeLog: PR c++/95888 * pt.c (lookup_template_class_1): Pass tf_none to tsubst when looking for the partial instantiation. gcc/testsuite/ChangeLog: PR c++/95888 * g++.dg/template/deduce10.C: New test. * g++.dg/template/deduce9.C: New test. (cherry picked from commit 88cfd531c69b3c1fe7a3c183d83cfeacc8f69402)
[Bug c++/97246] [10/11 regression] mismatched argument pack lengths since r10-7865-gaedd04caa945260e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97246 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug c++/96905] [10/11 Regression] ICE with consteval function: internal compiler error: in cp_gimplify_expr, at cp/cp-gimplify.c:827
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96905 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug target/98959] ICE in extract_constrain_insn, at recog.c:2670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98959 --- Comment #15 from Peter Bergner --- (In reply to Jakub Jelinek from comment #10) > The important difference from my auto-host.h to your auto-host.h which > causes this ICE is that you don't have HAVE_LD_LARGE_TOC defined. > Manually commenting it out makes the ICE reproduceable. FYI, given HAVE_LD_LARGE_TOC controls the -mcmodel= default, I tried using a normal build (ie, did not #undef HAVE_LD_LARGE_TOC in auto-host.h) and was able to recreate the ICE by using the options: -fno-schedule-insns -O2 -mcmodel=small
[Bug c++/81866] [8 Regression] ICE with a default template parameter which is a template class nested in a template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81866
--- Comment #8 from Sokolov Viacheslav ---
looks like the following is the same bug: https://godbolt.org/z/1vTqs3
template
struct A
{
template
struct B
{
};
};
A<>::B b;
results in (on trunk)
: In substitution of 'template B()-> A<>::B<
> [with = void]':
:10:8: required from here
:5:12: internal compiler error: in retrieve_specialization, at
cp/pt.c:1248
5 | struct B
|^
0x1ce8359 internal_error(char const*, ...)
???:0
0x6b702d fancy_abort(char const*, int, char const*)
???:0
0x91364f tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x9498ff instantiate_template(tree_node*, tree_node*, int)
???:0
0x9513f6 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
???:0
0x6de832 build_new_function_call(tree_node*, vec**, int)
???:0
0x906642 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
???:0
0x7b05d4 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
???:0
0x8de81d c_parse_file()
???:0
0xa5c452 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/96474] Internal compiler error with template struct inside template struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96474
Sokolov Viacheslav changed:
What|Removed |Added
CC||soko.slav at yandex dot ru
--- Comment #3 from Sokolov Viacheslav ---
Looks like the following is the same bug: https://godbolt.org/z/YzEh3Y
template
struct A
{
template
struct B
{
};
};
A<>::B b;
results in (on trunk)
: In substitution of 'template B()-> A<>::B<
> [with = void]':
:10:8: required from here
:5:12: internal compiler error: in retrieve_specialization, at
cp/pt.c:1248
5 | struct B
|^
0x1ce8359 internal_error(char const*, ...)
???:0
0x6b702d fancy_abort(char const*, int, char const*)
???:0
0x91364f tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x9498ff instantiate_template(tree_node*, tree_node*, int)
???:0
0x9513f6 fn_type_unification(tree_node*, tree_node*, tree_node*, tree_node*
const*, unsigned int, tree_node*, unification_kind_t, int, conversion**, bool,
bool)
???:0
0x6de832 build_new_function_call(tree_node*, vec**, int)
???:0
0x906642 do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
???:0
0x7b05d4 cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
???:0
0x8de81d c_parse_file()
???:0
0xa5c452 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/99076] Unclear error message when trailing angle bracket is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99076 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-02-11 Ever confirmed|0 |1 Keywords||diagnostic CC||mpolacek at gcc dot gnu.org
[Bug c++/99076] New: Unclear error message when trailing angle bracket is missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99076 Bug ID: 99076 Summary: Unclear error message when trailing angle bracket is missing Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: bugzi...@poradnik-webmastera.com Target Milestone: --- [code] #include #include template< typename Key, typename T, typename Compare = std::less, typename Allocator = std::allocator> > using SecureMemMap = std::map>; [/code] When this is compiled using g++, it gives following error message: [out] :9:53: error: template argument 4 is invalid 9 | using SecureMemMap = std::map>; | [/out] Above message is not very helpful, it is hard to tell what is wrong here. clang++ does better job here. Please improve g++ message in a similar way: [out] :9:87: error: expected '>' using SecureMemMap = std::map>; ^ :9:30: note: to match this '<' using SecureMemMap = std::map>; ^ [/out]
[Bug target/99041] combine creates invalid address which ICEs in decompose_normal_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99041 --- Comment #10 from Peter Bergner --- (In reply to Peter Bergner from comment #9) > Fixed on trunk. > > I will check whether we need this on the GCC10 branch as well. I believe we > probably will. Confirmed, we need this on GCC10 as well. Segher approved the backport offline. I'll let the trunk commit bake a few days and then will push the backport.
[Bug c++/95888] [9/10 Regression] Regression in 9.3. GCC freezes when compiling code using boost::poly_collection::segment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95888 Marek Polacek changed: What|Removed |Added Summary|[9/10/11 Regression]|[9/10 Regression] |Regression in 9.3. GCC |Regression in 9.3. GCC |freezes when compiling code |freezes when compiling code |using |using |boost::poly_collection::seg |boost::poly_collection::seg |ment|ment --- Comment #9 from Marek Polacek --- Fixed on trunk so far. Testing gcc10 now.
[Bug c++/95888] [9/10/11 Regression] Regression in 9.3. GCC freezes when compiling code using boost::poly_collection::segment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95888 --- Comment #8 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:88cfd531c69b3c1fe7a3c183d83cfeacc8f69402 commit r11-7197-g88cfd531c69b3c1fe7a3c183d83cfeacc8f69402 Author: Marek Polacek Date: Tue Feb 9 15:17:48 2021 -0500 c++: Endless loop with targ deduction in member tmpl [PR95888] My r10-7007 patch tweaked tsubst not to reduce the template level of template parameters when tf_partial. That caused infinite looping in is_specialization_of: we ended up with a class template specialization whose TREE_TYPE (CLASSTYPE_TI_TEMPLATE (t)) == t, so the second for loop in is_specialization_of never finished. There's a lot going on in this test, but essentially: the template fn here has two template parameters, we call it with one explicitly provided, the other one has to be deduced. So we'll find ourselves in fn_type_unification which uses tf_partial when tsubsting the *explicit* template arguments into the function type. That leads to tsubstituting the return type, C. C is a member template; its most general template is template template struct B::C we figure out (tsubst_template_args) that the template argument list is . They come from different levels, one comes from B, the other one from fn. So now we lookup_template_class to see if we have C. We do the /* This is a full instantiation of a member template. Find the partial instantiation of which this is an instance. */ TREE_VEC_LENGTH (arglist)--; // arglist is now , not found = tsubst (gen_tmpl, arglist, complain, NULL_TREE); TREE_VEC_LENGTH (arglist)++; magic which is looking for the partial instantiation, in this case, that would be template struct B::C. Note we're still in a tf_partial context! So the tsubst_template_args in the tsubst (which tries to substitute into ) returns , but V's template level hasn't been reduced! After tsubst_template_args, tsubst_template_decl looks to see if we already have this specialization: // t = template_decl C // full_args = spec = retrieve_specialization (t, full_args, hash); but doesn't find the one we created a while ago, when processing B b; in the test, because V's levels don't match. Whereupon tsubst_template_decl creates a new TEMPLATE_DECL, one that leads to the infinite looping problem. Fixed by using tf_none when looking for an existing partial instantiation. It also occurred to me that I should be able to trigger a similar problem with 'auto', since r10-7007 removed an is_auto check. And lo, I constructed deduce10.C which exhibits the same issue with pre-r10-7007 compilers. This patch fixes that problem as well. I'm ecstatic. gcc/cp/ChangeLog: PR c++/95888 * pt.c (lookup_template_class_1): Pass tf_none to tsubst when looking for the partial instantiation. gcc/testsuite/ChangeLog: PR c++/95888 * g++.dg/template/deduce10.C: New test. * g++.dg/template/deduce9.C: New test.
[Bug target/99041] combine creates invalid address which ICEs in decompose_normal_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99041 --- Comment #9 from Peter Bergner --- Fixed on trunk. I will check whether we need this on the GCC10 branch as well. I believe we probably will.
[Bug target/99041] combine creates invalid address which ICEs in decompose_normal_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99041 --- Comment #8 from CVS Commits --- The master branch has been updated by Peter Bergner : https://gcc.gnu.org/g:2432c47970024db6410708b582a901259dabaae1 commit r11-7196-g2432c47970024db6410708b582a901259dabaae1 Author: Peter Bergner Date: Thu Feb 11 14:15:26 2021 -0600 rs6000: Fix invalid address used in MMA built-in function The mma_assemble_input_operand predicate is too lenient on the memory operands it will accept, leading to an ICE when illegitimate addresses are passed in. The solution is to only accept memory operands with addresses that are valid for quad word memory accesses. The test case is a minimized test case from the Eigen library. The creduced test case is very noisy with respect to warnings, so the test case has added -w to silence them. 2021-02-11 Peter Bergner gcc/ PR target/99041 * config/rs6000/predicates.md (mma_assemble_input_operand): Restrict memory addresses that are legal for quad word accesses. gcc/testsuite/ PR target/99041 * g++.target/powerpc/pr99041.C: New test.
[Bug libstdc++/59048] operator== between std::string and const char* slower than strcmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59048 AK changed: What|Removed |Added CC||hiraditya at msn dot com --- Comment #17 from AK --- Now that we have string_view, will it be possible to avoid creating a copy?
[Bug c/99075] Wrong classification of functions memchr and memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99075
Martin Sebor changed:
What|Removed |Added
Resolution|--- |INVALID
CC||msebor at gcc dot gnu.org
Status|UNCONFIRMED |RESOLVED
--- Comment #1 from Martin Sebor ---
The term "string manipulation" is used in -Wstringop-overflow where the text in
-Wstringop-overread comes from. The functions are indeed declared in
which the C standard refers to as a "string handling header" and
describes as:
The header declares one type and several functions, and defines one
macro useful for manipulating arrays of character type and other objects
treated as arrays of character type.
That's also where "string manipulation" came from.
-Wstringop-overread is issued for any string (or raw memory) function that
might read past the end of an array. memchr and memcpy are just a couple of
examples. It applies to memcmp and strcmp as well, and others. For example:
$ cat t.c && gcc -S t.c
const char a[] = { 1, 2, 3 };
volatile int i;
void f (void)
{
i = __builtin_memcmp (a, a + 1, 3);
i = __builtin_strcmp (a, a + 1);
}
t.c: In function ‘f’:
t.c:7:7: warning: ‘__builtin_memcmp’ specified bound 3 exceeds the size 2 of
unterminated array [-Wstringop-overread]
7 | i = __builtin_memcmp (a, a + 1, 3);
| ^~
t.c:1:12: note: referenced argument declared here
1 | const char a[] = { 1, 2, 3 };
|^
t.c:8:7: warning: ‘__builtin_strcmp’ argument missing terminating nul
[-Wstringop-overread]
8 | i = __builtin_strcmp (a, a + 1);
| ^~~
t.c:1:12: note: referenced argument declared here
1 | const char a[] = { 1, 2, 3 };
|^
I would not be opposed to rewording the text (or replacing memcpy with strcpy)
if someone wanted to do make that change but using the term "memory
manipulation" instead wouldn't be correct. The manual has this:
Warn for calls to string manipulation functions such as memchr, or strcpy
that are determined to read past the end of the source sequence.
so that would work. In any event, I see nothing wrong with how it's phrased
now to consider this report valid.
[Bug target/99070] ICE in extract_constrain_insn, at recog.c:2670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99070 --- Comment #4 from acsawdey at gcc dot gnu.org --- OK, I see the fail with -mcpu=power9. Looks like I botched something with addressing and allowed D-form addresses when it should be DS-form. On power10 this would result in selection of a prefix D-form load, which then causes the ld-cmpi to be split. On anything previous we just ICE.
[Bug target/99070] ICE in extract_constrain_insn, at recog.c:2670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99070 --- Comment #3 from Jakub Jelinek --- In my case (it was a cross-compiler from x86_64-linux) ../configure --target powerpc64-linux-gnu --disable-bootstrap --enable-languages=c,c++,fortran,lto
[Bug target/99070] ICE in extract_constrain_insn, at recog.c:2670
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99070 acsawdey at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |acsawdey at gcc dot gnu.org --- Comment #2 from acsawdey at gcc dot gnu.org --- What are the build flags for this compiler?
[Bug fortran/98897] Erroneous procedure attribute for associate name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98897 Paul Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Paul Thomas --- Fixed on 10- and 11-branches. Thanks for the report, Damian. Paul PS See PR99065 for the reason for the delay.
[Bug fortran/98897] Erroneous procedure attribute for associate name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98897 --- Comment #5 from CVS Commits --- The releases/gcc-10 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:9d3b9a3e70e634c7c48bb12bb35ec8219024f98b commit r10-9358-g9d3b9a3e70e634c7c48bb12bb35ec8219024f98b Author: Paul Thomas Date: Thu Feb 11 13:24:50 2021 + Fortran: Fix calls to associate name typebound subroutines [PR98897]. 2021-02-11 Paul Thomas gcc/fortran PR fortran/98897 * match.c (gfc_match_call): Include associate names as possible entities with typebound subroutines. The target needs to be resolved for the type. gcc/testsuite/ PR fortran/98897 * gfortran.dg/typebound_call_32.f90: New test. (cherry picked from commit ff6903288d96aa1d28ae4912b1270985475f3ba8)
[Bug rtl-optimization/96264] [10/11 Regression] wrong code with -Os -fno-forward-propagate -fschedule-insns -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96264
Jakub Jelinek changed:
What|Removed |Added
Keywords||ra
CC||vmakarov at gcc dot gnu.org
--- Comment #10 from Jakub Jelinek ---
And on the current trunk I see similar thing, looking for "ca)" in *.ira and
*.reload dumps shows:
(insn 30 750 32 2 (parallel [
(set (reg:DI 247)
(ashiftrt:DI (reg:DI 119 [ _15 ])
(const_int 63 [0x3f])))
(clobber (reg:DI 98 ca))
]) "pr96264.c":12:20 281 {ashrdi3}
(expr_list:REG_UNUSED (reg:DI 98 ca)
(nil)))
(insn 32 30 87 2 (parallel [
(set (reg:DI 540 [ _22 ])
(minus:DI (reg:DI 538 [ _19 ])
(reg:DI 119 [ _15 ])))
(set (reg:DI 98 ca)
(leu:DI (reg:DI 119 [ _15 ])
(reg:DI 538 [ _19 ])))
]) "pr96264.c":12:12 104 {subfdi3_carry}
(expr_list:REG_DEAD (reg:DI 538 [ _19 ])
(nil)))
(insn 87 32 86 2 (parallel [
(set (reg:HI 277)
(vec_select:HI (reg:V8HI 129 [ _36 ])
(parallel [
(const_int 4 [0x4])
])))
(clobber (reg:V8HI 2668))
]) "pr96264.c":13:10 1365 {*vsx_extract_v8hi_p8}
(expr_list:REG_UNUSED (reg:V8HI 2668)
(nil)))
(insn 86 87 33 2 (set (reg:V8HI 135 [ _42 ])
(plus:V8HI (reg:V8HI 259 [ _41 ])
(reg:V8HI 273))) "pr96264.c":13:15 1614 {addv8hi3}
(expr_list:REG_DEAD (reg:V8HI 259 [ _41 ])
(nil)))
(insn 33 86 751 2 (parallel [
(set (reg:DI 541 [ _22+8 ])
(plus:DI (plus:DI (not:DI (reg:DI 247))
(reg:DI 98 ca))
(reg:DI 539 [ _19+8 ])))
(clobber (reg:DI 98 ca))
]) "pr96264.c":12:12 108 {*subfdi3_carry_in_internal}
(expr_list:REG_DEAD (reg:DI 539 [ _19+8 ])
(expr_list:REG_DEAD (reg:DI 98 ca)
(expr_list:REG_UNUSED (reg:DI 98 ca)
(nil)
...
(insn 34 216 763 2 (parallel [
(set (reg:DI 544 [ _26 ])
(minus:DI (reg:DI 542 [ _23 ])
(reg:DI 119 [ _15 ])))
(set (reg:DI 98 ca)
(leu:DI (reg:DI 119 [ _15 ])
(reg:DI 542 [ _23 ])))
]) "pr96264.c":12:12 104 {subfdi3_carry}
(expr_list:REG_DEAD (reg:DI 542 [ _23 ])
(nil)))
(insn 763 34 221 2 (set (reg:DI 543 [ _23+8 ])
(mem/j/c:DI (plus:DI (reg/f:DI 244)
(const_int 8 [0x8])) [1 BIT_FIELD_REF +8 S8 A64]))
"pr96264.c":12:12 636 {*movdi_internal64}
(expr_list:REG_DEAD (reg/f:DI 244)
(nil)))
(insn 221 763 768 2 (set (reg:DI 189 [ _96 ])
(zero_extend:DI (subreg:HI (reg:SI 384) 0))) "pr96264.c":13:10 11
{zero_extendhidi2}
(expr_list:REG_DEAD (reg:SI 384)
(nil)))
(insn 768 221 35 2 (parallel [
(set (mem/c:DI (plus:DI (reg/f:DI 110 sfp)
(const_int 352 [0x160])) [1 S8 A128])
(reg:DI 544 [ _26 ]))
(set (reg/f:DI 525)
(plus:DI (reg/f:DI 110 sfp)
(const_int 352 [0x160])))
]) "pr96264.c":12:12 644 {movdi_di_update}
(expr_list:REG_DEAD (reg:DI 544 [ _26 ])
(nil)))
(insn 35 768 226 2 (parallel [
(set (reg:DI 545 [ _26+8 ])
(plus:DI (plus:DI (not:DI (reg:DI 247))
(reg:DI 98 ca))
(reg:DI 543 [ _23+8 ])))
(clobber (reg:DI 98 ca))
]) "pr96264.c":12:12 108 {*subfdi3_carry_in_internal}
(expr_list:REG_DEAD (reg:DI 543 [ _23+8 ])
(expr_list:REG_DEAD (reg:DI 98 ca)
(expr_list:REG_UNUSED (reg:DI 98 ca)
(expr_list:REG_EQUIV (mem/c:DI (plus:DI (reg/f:DI 525)
(const_int 8 [0x8])) [1 S8 A64])
(nil))
...
(insn 36 141 761 2 (parallel [
(set (reg:DI 548 [ _30 ])
(minus:DI (reg:DI 546 [ _27 ])
(reg:DI 119 [ _15 ])))
(set (reg:DI 98 ca)
(leu:DI (reg:DI 119 [ _15 ])
(reg:DI 546 [ _27 ])))
]) "pr96264.c":12:12 104 {subfdi3_carry}
(expr_list:REG_DEAD (reg:DI 546 [ _27 ])
(nil)))
(insn 761 36 146 2 (set (reg:DI 547 [ _27+8 ])
(mem/j/c:DI (plus:DI (reg/f:DI 242)
(const_int 8 [0x8])) [1 BIT_FIELD_REF +8 S8 A64]))
"pr96264.c":12:12 636 {*movdi_internal64}
(expr_list:REG_DEAD (reg/f:DI 242)
(nil)))
(insn 146 761 770 2 (set (reg:DI 159 [ _66 ])
(zero_extend:DI (subreg:HI (reg:SI 324) 0))) "pr96264.c":13:10 11
{zero_extendhidi2}
(expr_list:REG_DEAD (reg:SI 324)
(nil)))
(insn 770 146 37 2 (parallel [
(set (mem
[Bug rtl-optimization/96264] [10/11 Regression] wrong code with -Os -fno-forward-propagate -fschedule-insns -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96264
--- Comment #9 from Jakub Jelinek ---
So, using the r10-135 compiler, seems things go wrong during RA.
In *.ira, we have:
(insn 35 34 217 2 (parallel [
(set (reg:DI 544 [ _29 ])
(minus:DI (reg:DI 542 [ _26 ])
(reg:DI 123 [ _14 ])))
(set (reg:DI 76 ca)
(leu:DI (reg:DI 123 [ _14 ])
(reg:DI 542 [ _26 ])))
]) "pr96264.c":12:12 107 {subfdi3_carry}
(expr_list:REG_DEAD (reg:DI 542 [ _26 ])
(nil)))
...
(insn 36 195 37 2 (parallel [
(set (reg:DI 545 [ _29+8 ])
(plus:DI (plus:DI (not:DI (reg:DI 251))
(reg:DI 76 ca))
(reg:DI 543 [ _26+8 ])))
(clobber (reg:DI 76 ca))
]) "pr96264.c":12:12 111 {*subfdi3_carry_in_internal}
(expr_list:REG_DEAD (reg:DI 543 [ _26+8 ])
(expr_list:REG_DEAD (reg:DI 76 ca)
(expr_list:REG_UNUSED (reg:DI 76 ca)
(expr_list:REG_EQUIV (mem/c:DI (plus:DI (reg/f:DI 522)
(const_int 8 [0x8])) [1 S8 A64])
(nil))
with lots of insns in between in ... but nothing that would use or set or
clobber (reg:DI 76 ca) - including tons of division instructions etc.
But in *.reload I see:
(insn 35 34 3298 2 (parallel [
(set (reg:DI 7 7 [orig:544 _29 ] [544])
(minus:DI (reg:DI 7 7 [orig:542 _26 ] [542])
(reg:DI 5 5 [orig:123 _14 ] [123])))
(set (reg:DI 76 ca)
(leu:DI (reg:DI 5 5 [orig:123 _14 ] [123])
(reg:DI 7 7 [orig:542 _26 ] [542])))
]) "pr96264.c":12:12 107 {subfdi3_carry}
(nil))
...
(insn 193 192 195 2 (set (reg:DI 3 3 [orig:186 _88 ] [186])
(zero_extend:DI (reg:HI 3 3 [366]))) "pr96264.c":13:10 14
{zero_extendhidi2}
(nil))
(insn 195 193 3317 2 (set (reg:SI 10 10 [369])
(udiv:SI (reg:SI 10 10 [276])
(reg:SI 3 3 [orig:186 _88 ] [186]))) "pr96264.c":13:10 168
{udivsi3}
(nil))
(insn 3317 195 3402 2 (set (reg:DI 3 3 [orig:543 _26+8 ] [543])
(mem/c:DI (plus:DI (reg/f:DI 1 1)
(const_int 568 [0x238])) [4 %sfp+568 S8 A64]))
"pr96264.c":12:12 608 {*movdi_internal64}
(nil))
(insn 3402 3317 3387 2 (parallel [
(set (reg:DI 11 11 [251])
(ashiftrt:DI (reg:DI 5 5 [orig:123 _14 ] [123])
(const_int 63 [0x3f])))
(clobber (reg:DI 76 ca))
]) "pr96264.c":12:12 275 {ashrdi3}
(nil))
(note 3387 3402 36 2 NOTE_INSN_DELETED)
(insn 36 3387 3318 2 (parallel [
(set (reg:DI 3 3 [orig:545 _29+8 ] [545])
(plus:DI (plus:DI (not:DI (reg:DI 11 11 [251]))
(reg:DI 76 ca))
(reg:DI 3 3 [orig:543 _26+8 ] [543])))
(clobber (reg:DI 76 ca))
]) "pr96264.c":12:12 111 {*subfdi3_carry_in_internal}
(expr_list:REG_EQUIV (mem/c:DI (plus:DI (reg/f:DI 522)
(const_int 8 [0x8])) [1 S8 A64])
(nil)))
i.e. insn 3402 that clobbers (reg:DI 76 ca) has been added in between the
setter of that (insn 35) and user (insn 36). That is why one gets
0x00010002 in the third int128 of the result rather
than 2.
[Bug c/99055] memory leak in warn_parm_array_mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99055 --- Comment #2 from Martin Sebor --- Created attachment 50170 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50170&action=edit Valgrind leak output with patch from comment #1 applied. Attached is Valgrind leak output with the patch from comment #1 applied. The file is too big to post to gcc-patches.
[Bug libstdc++/79246] [C++17] with versioned namespace: FAIL: 27_io/manipulators/standard/wchar_t/2.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79246 --- Comment #2 from Jonathan Wakely --- And this one which is probably something minor but I haven't investigated: FAIL: 30_threads/promise/requirements/lwg3466.cc (test for excess errors) Excess errors: /home/jwakely/build8/x86_64-pc-linux-gnu/libstdc++-v3/include/ext/aligned_buffer.h:54: error: data member '__gnu_cxx::__aligned_membuf::_Tp2::_M_t' invalidly declared function type Probably due to: #if _GLIBCXX_INLINE_VERSION template using __aligned_buffer = __aligned_membuf<_Tp>; #else
[Bug libstdc++/99058] Consider adding a note about std::optional ABI break to the C++17 status table
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99058 --- Comment #9 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:ce43c906049b828c0472d8499b52ac6233c869d0 commit r11-7194-gce43c906049b828c0472d8499b52ac6233c869d0 Author: Jonathan Wakely Date: Thu Feb 11 15:35:23 2021 + libstdc++: Document when C++11/14/17 support became stable [PR 99058] libstdc++-v3/ChangeLog: PR libstdc++/99058 * doc/xml/manual/status_cxx2011.xml: Document when support became stable. * doc/xml/manual/status_cxx2014.xml: Likewise. * doc/xml/manual/status_cxx2017.xml: Likewise. * doc/html/manual/status.html: Regenerate.
[Bug libstdc++/79246] [C++17] with versioned namespace: FAIL: 27_io/manipulators/standard/wchar_t/2.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79246 --- Comment #1 from Jonathan Wakely --- I don't see that error now, but do see these: FAIL: 27_io/ios_base/failure/cxx11.cc (test for excess errors) Excess errors: /usr/bin/ld: Dwarf Error: found dwarf version '5', this reader only handles version 2, 3 and 4 information. cxx11.cc:(.text._Z6test02v+0x13): undefined reference to `std::__8::iostream_category()' cxx11.cc:(.text._Z6test01v+0x104): undefined reference to `std::__8::iostream_category()' collect2: error: ld returned 1 exit status UNRESOLVED: 27_io/ios_base/failure/cxx11.cc compilation failed to produce executable FAIL: 22_locale/codecvt/char16_t-char8_t.cc (test for excess errors) Excess errors: /usr/bin/ld: Dwarf Error: found dwarf version '5', this reader only handles version 2, 3 and 4 information. char16_t-char8_t.cc:(.text._Z6test01v+0x25): undefined reference to `_ZNSt3__87codecvtIDsDu11__mbstate_tE2idE' char16_t-char8_t.cc:(.text._Z6test01v+0x6b): undefined reference to `_ZNSt3__87codecvtIDsDu11__mbstate_tE2idE' collect2: error: ld returned 1 exit status UNRESOLVED: 22_locale/codecvt/char16_t-char8_t.cc compilation failed to produce executable FAIL: 22_locale/codecvt/char32_t-char8_t.cc (test for excess errors) Excess errors: /usr/bin/ld: Dwarf Error: found dwarf version '5', this reader only handles version 2, 3 and 4 information. char32_t-char8_t.cc:(.text._Z6test01v+0x25): undefined reference to `_ZNSt3__87codecvtIDiDu11__mbstate_tE2idE' char32_t-char8_t.cc:(.text._Z6test01v+0x6b): undefined reference to `_ZNSt3__87codecvtIDiDu11__mbstate_tE2idE' collect2: error: ld returned 1 exit status UNRESOLVED: 22_locale/codecvt/char32_t-char8_t.cc compilation failed to produce executable FAIL: 22_locale/codecvt/utf8-char8_t.cc (test for excess errors) Excess errors: /usr/bin/ld: Dwarf Error: found dwarf version '5', this reader only handles version 2, 3 and 4 information. utf8-char8_t.cc:(.text._Z4testIDsEvPKT_[_Z4testIDsEvPKT_]+0x52): undefined reference to `_ZNSt3__87codecvtIDsDu11__mbstate_tE2idE' utf8-char8_t.cc:(.text._Z4testIDiEvPKT_[_Z4testIDiEvPKT_]+0x5b): undefined reference to `_ZNSt3__87codecvtIDiDu11__mbstate_tE2idE' collect2: error: ld returned 1 exit status UNRESOLVED: 22_locale/codecvt/utf8-char8_t.cc compilation failed to produce executable
[Bug d/98910] [11 regression] locale_t undefined on Solaris
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98910 Iain Buclaw changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #7 from Iain Buclaw --- I'll mark this as resolved as it is building for me on sparc-sun-solaris2.11
[Bug tree-optimization/99074] gcc 8 and above is crashing with dynamic_cast<>() on null pointer with optimization level -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99074 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jakub Jelinek --- Your testcase is invalid, contains undefined behavior as can be seen e.g. if you built it with -fsanitize=undefined. Calling a non-static member function on a nullptr object is UB. And anything can happen afterwards.
[Bug c/99075] New: Wrong classification of functions memchr and memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99075 Bug ID: 99075 Summary: Wrong classification of functions memchr and memcpy Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: roland.illig at gmx dot de Target Milestone: --- While translating GCC 11 into German, I ran into the following diagnostic: > Warn about reading past the end of a source array in string manipulation > functions like memchr and memcpy. This diagnostic is wrong. Neither memchr nor memcpy are string manipulation functions. It's true that they are declared in the header , but that is a historic accident rather than good namespace design. The word "string" in the diagnostic should be replaced with "memory", corresponding to the function names. By the way, does the warning apply to memcmp as well?
[Bug tree-optimization/99074] New: gcc 8 and above is crashing with dynamic_cast<>() on null pointer with optimization level -O1 and above
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99074
Bug ID: 99074
Summary: gcc 8 and above is crashing with dynamic_cast<>() on
null pointer with optimization level -O1 and above
Product: gcc
Version: 8.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: keith.halligan at microfocus dot com
Target Milestone: ---
Created attachment 50169
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50169&action=edit
comparison of the disassembly at -O0, O1, and -O2 levels
When compiling the small snippet below with g++/gcc v8.3.1 the dynamic_cast<>()
operator with a null pointer argument will result in a segmentation fault at
optimizations levels from -O1 and above.
I am running this on both RHEL 8 and SLES 15, in addition I installed gcc-9 and
gcc-10 toolchain packages, and the crashes were noticed on these newer
compilers as well.
I've also tested the code on RHEL 5 and 7 with gcc 4.1 and 4.8, and there's no
crash at any optimization levels
I've attached a file showing the difference in disassembly between -O0 and -O1,
it looks at lower levels the call to dynamic_cast is bypassed under certain
conditions, that doesn't happen at -O1 and above.
The code was compiled with: g++ -Wall -m32 -O2 -o test_dyn_cast
test_dyn_cast.cpp -v -save-temps
=
// file: test_dyn_cast.cpp
//
#include
class Base {
public:
virtual ~Base() {}
virtual void op() = 0;
};
class Object: public virtual Base {
};
class AbstractBase : public virtual Base {
public:
Object* _to_object() { return dynamic_cast(this); }
};
class MyAbstractClass : public virtual AbstractBase {
public:
static MyAbstractClass* _nil() { return 0; }
};
int main(void) {
MyAbstractClass *my_abs_type = MyAbstractClass::_nil();
AbstractBase *abs_base = my_abs_type;
Object *obj = abs_base->_to_object();
printf("object is: %p\n", obj);
return 0;
}
==
$ g++ -Wall -m32 -O2 -o test_dyn_cast test_dyn_cast.cpp -v -save-temps
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,lto --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-shared --enable-threads=posix --enable-checking=release
--enable-multilib --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id --with-gcc-major-version-only
--with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl
--disable-libmpx --enable-offload-targets=nvptx-none --without-cuda-driver
--enable-gnu-indirect-function --enable-cet --with-tune=generic
--with-arch_32=x86-64 --build=x86_64-redhat-linux
Thread model: posix
gcc version 8.3.1 20191121 (Red Hat 8.3.1-5) (GCC)
COLLECT_GCC_OPTIONS='-Wall' '-m32' '-O2' '-o' 'test_dyn_cast' '-v'
'-save-temps' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/libexec/gcc/x86_64-redhat-linux/8/cc1plus -E -quiet -v -imultilib 32
-D_GNU_SOURCE test_dyn_cast.cpp -m32 -mtune=generic -march=x86-64 -Wall -O2
-fpch-preprocess -o test_dyn_cast.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/8/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-redhat-linux/8/../../../../x86_64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8
/usr/lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8/x86_64-redhat-linux/32
/usr/lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8/backward
/usr/lib/gcc/x86_64-redhat-linux/8/include
/usr/local/include
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-Wall' '-m32' '-O2' '-o' 'test_dyn_cast' '-v'
'-save-temps' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/libexec/gcc/x86_64-redhat-linux/8/cc1plus -fpreprocessed test_dyn_cast.ii
-quiet -dumpbase test_dyn_cast.cpp -m32 -mtune=generic -march=x86-64 -auxbase
test_dyn_cast -O2 -Wall -version -o test_dyn_cast.s
GNU C++14 (GCC) version 8.3.1 20191121 (Red Hat 8.3.1-5) (x86_64-redhat-linux)
compiled by GNU C version 8.3.1 20191121 (Red Hat 8.3.1-5), GMP version
6.1.2, MPFR version 3.1.6-p2, MPC version 1.0.2, isl version isl-0.16.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (GCC) version 8.3.1 20191121 (Red Hat 8.3.1-5) (x86_64-redhat-linux)
compiled by GNU C version 8.3.1 20191121 (Red Hat 8.3.1-5), GMP version
6.1.2, MPFR version 3.1.6-p2, MPC version 1.0.2, isl version isl-0.16.1-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler execu
[Bug c++/99033] [9/10 Regression] ICE in tree_to_poly_int64, at tree.c:3091
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99033 Jakub Jelinek changed: What|Removed |Added Summary|[9/10/11 Regression] ICE in |[9/10 Regression] ICE in |tree_to_poly_int64, at |tree_to_poly_int64, at |tree.c:3091 |tree.c:3091 --- Comment #5 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug c++/99033] [9/10/11 Regression] ICE in tree_to_poly_int64, at tree.c:3091
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99033 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:2dcdd15d0bafb9b45a8d7ff580217bd6ac1f0975 commit r11-7193-g2dcdd15d0bafb9b45a8d7ff580217bd6ac1f0975 Author: Jakub Jelinek Date: Thu Feb 11 17:24:17 2021 +0100 c++: Fix zero initialization of flexible array members [PR99033] array_type_nelts returns error_mark_node for type of flexible array members and build_zero_init_1 was placing an error_mark_node into the CONSTRUCTOR, on which e.g. varasm ICEs. I think there is nothing erroneous on zero initialization of flexible array members though, such arrays should simply get no elements, like they do if such classes are constructed (everything except when some larger initializer comes from an explicit initializer). So, this patch handles [] arrays in zero initialization like [0] arrays and fixes handling of the [0] arrays - the tree_int_cst_equal (max_index, integer_minus_one_node) check didn't do what it thought it would do, max_index is typically unsigned integer (sizetype) and so it is never equal to a -1. What the patch doesn't do and maybe would be desirable is if it returns error_mark_node for other reasons let the recursive callers not stick that into CONSTRUCTOR but return error_mark_node instead. But I don't have a testcase where that would be needed right now. 2021-02-11 Jakub Jelinek PR c++/99033 * init.c (build_zero_init_1): Handle zero initialiation of flexible array members like initialization of [0] arrays. Use integer_minus_onep instead of comparison to integer_minus_one_node and integer_zerop instead of comparison against size_zero_node. Formatting fixes. * g++.dg/ext/flexary38.C: New test.
[Bug rtl-optimization/96264] [10/11 Regression] wrong code with -Os -fno-forward-propagate -fschedule-insns -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96264 --- Comment #8 from seurer at gcc dot gnu.org --- Enabling -fno-forward-propagate triggers the problem. seurer@genoa:~/gcc/git/build/gcc-10-test$ whichgcc Now at commit g:a7eb97ad269b6509bd7b31ca373daea98e4d7e85, r10-135 seurer@genoa:~/gcc/git/build/gcc-10-test$ ~/gcc/git/install/gcc-10-test/bin/gcc -Os -fno-forward-propagate -fschedule-insns -fno-tree-ter t1.c -static seurer@genoa:~/gcc/git/build/gcc-10-test$ ./a.out Aborted (core dumped) seurer@genoa:~/gcc/git/build/gcc-10-test$ seurer@genoa:~/gcc/git/build/gcc-10-test$ ~/gcc/git/install/gcc-10-test/bin/gcc -Os -fschedule-insns -fno-tree-ter t1.c -static seurer@genoa:~/gcc/git/build/gcc-10-test$ ./a.out seurer@genoa:~/gcc/git/build/gcc-10-test$
[Bug preprocessor/99073] New: Preprocessing with -CC adds unwanted junk
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99073
Bug ID: 99073
Summary: Preprocessing with -CC adds unwanted junk
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
This code:
#define TEST_CODE( \
PARAM_01, \
PARAM_02, \
PARAM_03, \
PARAM_04) \
void function_name(PARAM_01 arg) { /*
*/ line_one; /*
*/ line two; /*
*/ PARAM_03; /*
*/}
TEST_CODE( \
param_value_01, \
param_value_02, \
param_value_03, \
param_value_04)
When preprocessed with "gcc -E -nostdinc -CC" produces the following:
# 1 "test.h"
# 1 ""
# 1 ""
# 1 "test.h"
# 15 "test.h"
void function_name(param_value_01 arg) { /*
arg) { /*
*/
# 15 "test.h"
line_one; /*
*/
# 15 "test.h"
line two; /*
*/
# 15 "test.h"
param_value_03; /*
*/}
The "arg) { /*" shouldn't be there.
(The -nostdinc isn't relevant to the bug, it just avoids including the comments
in std-predef.h in the output)
With -P to reduce the noise of the line markers:
$ gcc -E -CC test.h -nostdinc -P
void function_name(param_value_01 arg) { /*
arg) { /*
*/ line_one; /*
*/ line two; /*
*/ param_value_03; /*
*/}
[Bug c++/99063] [9/10 Regression] ICE in prep_operand, at cp/call.c:5842
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99063 Marek Polacek changed: What|Removed |Added Summary|[9/10/11 Regression] ICE in |[9/10 Regression] ICE in |prep_operand, at|prep_operand, at |cp/call.c:5842 |cp/call.c:5842 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Marek Polacek --- Fixed in GCC 11. Invalid code so probably not worth backporting.
[Bug c++/99063] [9/10/11 Regression] ICE in prep_operand, at cp/call.c:5842
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99063 --- Comment #3 from CVS Commits --- The master branch has been updated by Marek Polacek : https://gcc.gnu.org/g:f0da1c0cb7661ee9111bc475efddae80a026de34 commit r11-7192-gf0da1c0cb7661ee9111bc475efddae80a026de34 Author: Marek Polacek Date: Wed Feb 10 22:51:30 2021 -0500 c++: ICE with unexpanded pack in do-while [PR99063] Here an unexpanded parameter pack snuck into prep_operand which doesn't expect to see an operand without a type, and since r247842 NONTYPE_ARGUMENT_PACK doesn't have a type anymore. This only happens with the do-while loop whose condition may not contain a declaration so we never called finish_cond which checks for unexpanded parameter packs. So use check_for_bare_parameter_packs to remedy that. gcc/cp/ChangeLog: PR c++/99063 * semantics.c (finish_do_stmt): Check for unexpanded parameter packs. gcc/testsuite/ChangeLog: PR c++/99063 * g++.dg/cpp0x/variadic-crash6.C: New test.
[Bug inline-asm/98262] Internal compiler error when clobbering m68k frame pointer in extended asm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98262 --- Comment #3 from Thomas Jager --- I've now had the same `gcc_unreachable` reached when compiling code that uses `-mpcrel` with a thread-local variable. It may be that `m68k_decompose_address` doesn't properly handle all cases, or that something generated earlier that is passed to it is bad.
[Bug libstdc++/82178] bootstrap fails on ppc64 for --enable-symvers=gnu-versioned-namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82178 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |12.0
[Bug libstdc++/82178] bootstrap fails on ppc64 for --enable-symvers=gnu-versioned-namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82178 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-02-11
[Bug c++/97582] [9/10 Regression] ICE tree check: expected function_type or method_type, have error_mark in add_function_candidate, at cp/call.c:2146 since r9-6405-gbddee796d0b4800b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97582 Patrick Palka changed: What|Removed |Added Summary|[9/10/11 Regression] ICE|[9/10 Regression] ICE tree |tree check: expected|check: expected |function_type or|function_type or |method_type, have |method_type, have |error_mark in |error_mark in |add_function_candidate, at |add_function_candidate, at |cp/call.c:2146 since|cp/call.c:2146 since |r9-6405-gbddee796d0b4800b |r9-6405-gbddee796d0b4800b --- Comment #4 from Patrick Palka --- Fixed for GCC 11 so far.
[Bug c++/97582] [9/10/11 Regression] ICE tree check: expected function_type or method_type, have error_mark in add_function_candidate, at cp/call.c:2146 since r9-6405-gbddee796d0b4800b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97582 --- Comment #3 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:cb168f779c87c1e0c37d22ea82dfb93ff8c873bc commit r11-7191-gcb168f779c87c1e0c37d22ea82dfb93ff8c873bc Author: Patrick Palka Date: Thu Feb 11 10:59:54 2021 -0500 c++: Fix ICE from op_unqualified_lookup [PR97582] In this testcase, we're crashing because the lookup of operator+ from within the generic lambda via lookup_name finds multiple bindings (C1::operator+ and C2::operator+) and returns a TREE_LIST thereof, something which op_unqualified_lookup (and push_operator_bindings) isn't prepared to handle. This patch extends op_unqualified_lookup and push_operator_bindings to handle such an ambiguous lookup result in the natural way. gcc/cp/ChangeLog: PR c++/97582 * name-lookup.c (op_unqualified_lookup): Handle an ambiguous lookup result by discarding it if the first element is a class-scope declaration, otherwise return it. (push_operator_bindings): Handle an ambiguous lookup result by doing push_local_binding on each element in the list. gcc/testsuite/ChangeLog: PR c++/97582 * g++.dg/cpp0x/lambda/lambda-template17.C: New test.
[Bug rtl-optimization/96264] [10/11 Regression] wrong code with -Os -fno-forward-propagate -fschedule-insns -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96264 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- My bisection also points at r10-135-ga7eb97ad269b6509bd7b31ca373daea98e4d7e85
[Bug rtl-optimization/96264] [10/11 Regression] wrong code with -Os -fno-forward-propagate -fschedule-insns -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96264 --- Comment #6 from Richard Biener --- (In reply to seurer from comment #5) > I too am able to duplicate this on a native powerpc64 LE machine. Changing > any of the compilation options (-Os -fno-forward-propagate -fschedule-insns > -fno-tree-ter) generates code that works. > > The revision that causes it is: > > g:a7eb97ad269b6509bd7b31ca373daea98e4d7e85, r10-135 > > commit a7eb97ad269b6509bd7b31ca373daea98e4d7e85 (HEAD) > Author: Richard Biener > Date: Fri May 3 10:39:56 2019 + > > re PR middle-end/88963 (gcc generates terrible code for vectors of 64+ > length which are not natively supported) > > 2019-05-03 Richard Biener > > PR tree-optimization/88963 > * tree-ssa-forwprop.c (pass_forwprop::execute): Rewrite > vector loads feeding only BIT_FIELD_REFs to component > loads. Rewrite stores fed by CONSTRUCTORs to component > stores. > > * gcc.dg/tree-ssa/ssa-fre-31.c: Disable forwprop. > * gcc.target/i386/pr88963-1.c: New testcase. > * gcc.target/i386/pr88963-2.c: Likewise. > > From-SVN: r270844 > > I compared the assembler output from r10-134 and r10-135 for the test case > and the differences are significant. Assembler output of the two revisions > attached. Note -fno-forward-propagate is an RTL optimization so if enabling that fixes the issue the issue cannot really be the above rev. but it's probably exposed by it only. Note this is only done for vector load/stores using BLKmode. Somebody needs to look at the RTL details to see what's the difference with RTL fwprop or scheduling for example (at least for scheduling there are existing dbg-counters that might help pointing to the breaking (non-)transform)
[Bug target/98931] [11 Regression] arm: Assembly fails with "branch out of range or not a multiple of 2" since r11-2012
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98931 akrl at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from akrl at gcc dot gnu.org --- Fixed into master by 38c5703449c.
[Bug c++/96311] [8/9/10/11 Regression] false positive for -Wunused-but-set-variable (const/constexpr identifier used in generic lambda)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96311
--- Comment #4 from Jakub Jelinek ---
If I compare
void
foo ()
{
constexpr int used = 0;
[](auto unused)
{
return used;
};
}
void
bar ()
{
constexpr int used = 0;
[](int unused)
{
return used;
};
}
then in bar mark_exp_read is called on used from check_return_expr ->
convert_for_initialization -> convert_from_assignment ->
perform_implicit_conversion_flags -> mark_rvalue_use -> mark_use ->
mark_exp_read, but for the generic lambda check_return_expr takes the goto
dependent; and doesn't mark anything.
It is only marked during instantiation of the lambda, such as when (0) as added
in between } and ; and in that case the warning is gone.
More complete testcase:
void
foo ()
{
constexpr int used = 0;
[](auto unused)
{
return used;
};
}
void
bar ()
{
constexpr int used = 0;
[](int unused)
{
return used;
};
}
void
baz ()
{
constexpr int used = 0;
[](auto unused)
{
return used;
} (0);
}
void
qux ()
{
constexpr int used = 0;
[](auto unused)
{
return used + 1;
};
}
void
corge ()
{
constexpr int used = 0;
[](auto unused)
{
return used + unused;
};
}
This shows that if the variable is used in some non-dependent expression as in
qux (and not directly in return statement), it is marked already without
instantiation, but when it is only used directly in return stmt or used in a
dependent expression, it is marked only during instantiation of the lambda.
Though, when the lambda isn't really instantiated, the variable is not really
used, so not 100% sure the warning is unwanted.
[Bug target/98931] [11 Regression] arm: Assembly fails with "branch out of range or not a multiple of 2" since r11-2012
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98931 --- Comment #14 from CVS Commits --- The master branch has been updated by Andrea Corallo : https://gcc.gnu.org/g:38c5703449c0638618ba6896f0d039c3868ad4e0 commit r11-7190-g38c5703449c0638618ba6896f0d039c3868ad4e0 Author: Andrea Corallo Date: Wed Feb 3 15:21:54 2021 +0100 arm: Low overhead loop handle long range branches [PR98931] gcc/ PR target/98931 * config/arm/thumb2.md (*doloop_end_internal): Generate alternative sequence to handle long range branches. gcc/testsuite/ PR target/98931 * gcc.target/arm/pr98931.c: New testcase.
[Bug analyzer/95000] -fanalyzer confused by switch on non-int type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95000 --- Comment #5 from Dmitry G. Dyachenko --- gcc version 11.0.0 20210210 (experimental) [master revision bd0e37f68a3:deed5164277:72932511053596091ad291539022b51d9f2ba418] PASS for me
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 98772, which changed state. Bug 98772 Summary: Widening patterns causing missed vectorization https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98772 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/98772] Widening patterns causing missed vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98772 Joel Hutton changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Joel Hutton --- fixed on trunk
[Bug analyzer/94713] Analyzer is buggy on uninitialized pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94713 Dmitry G. Dyachenko changed: What|Removed |Added CC||dimhen at gmail dot com --- Comment #1 from Dmitry G. Dyachenko --- gcc version 11.0.0 20210210 (experimental) [master revision bd0e37f68a3:deed5164277:72932511053596091ad291539022b51d9f2ba418] PASS for me
[Bug tree-optimization/98772] Widening patterns causing missed vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98772 --- Comment #5 from CVS Commits --- The master branch has been updated by Joel Hutton : https://gcc.gnu.org/g:4af29981ab57ad7ef4467e371e4145cce9c16eaa commit r11-7189-g4af29981ab57ad7ef4467e371e4145cce9c16eaa Author: Joel Hutton Date: Thu Feb 11 14:59:26 2021 + [aarch64][vect] Support V8QI->V8HI WIDEN_ patterns In the case where 8 out of every 16 elements are widened using a widening pattern and the next 8 are skipped, the patterns are not recognized. This is because they are normally used in a pair, such as VEC_WIDEN_MINUS_HI/LO, to achieve a v16qi->v16hi conversion for example. This patch adds support for V8QI->V8HI patterns. gcc/ChangeLog: PR tree-optimization/98772 * optabs-tree.c (supportable_half_widening_operation): New function to check for supportable V8QI->V8HI widening patterns. * optabs-tree.h (supportable_half_widening_operation): New function. * tree-vect-stmts.c (vect_create_half_widening_stmts): New function to create promotion stmts for V8QI->V8HI widening patterns. (vectorizable_conversion): Add case for V8QI->V8HI. gcc/testsuite/ChangeLog: PR tree-optimization/98772 * gcc.target/aarch64/pr98772.c: New test.
[Bug target/96166] [10/11 Regression] -O3/-ftree-slp-vectorize turns ROL into a mess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96166 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Started with r10-1361-g9f962469cabc7fdc2ee830125a5cb4e61e1632e4
[Bug rtl-optimization/96264] [10/11 Regression] wrong code with -Os -fno-forward-propagate -fschedule-insns -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96264 seurer at gcc dot gnu.org changed: What|Removed |Added Host|x86_64-pc-linux-gnu |x86_64-pc-linux-gnu, ||powerpc64le-linux-gnu CC||bergner at gcc dot gnu.org, ||rguenth at gcc dot gnu.org, ||wschmidt at gcc dot gnu.org Build||powerpc64le-linux-gnu --- Comment #5 from seurer at gcc dot gnu.org --- I too am able to duplicate this on a native powerpc64 LE machine. Changing any of the compilation options (-Os -fno-forward-propagate -fschedule-insns -fno-tree-ter) generates code that works. The revision that causes it is: g:a7eb97ad269b6509bd7b31ca373daea98e4d7e85, r10-135 commit a7eb97ad269b6509bd7b31ca373daea98e4d7e85 (HEAD) Author: Richard Biener Date: Fri May 3 10:39:56 2019 + re PR middle-end/88963 (gcc generates terrible code for vectors of 64+ length which are not natively supported) 2019-05-03 Richard Biener PR tree-optimization/88963 * tree-ssa-forwprop.c (pass_forwprop::execute): Rewrite vector loads feeding only BIT_FIELD_REFs to component loads. Rewrite stores fed by CONSTRUCTORs to component stores. * gcc.dg/tree-ssa/ssa-fre-31.c: Disable forwprop. * gcc.target/i386/pr88963-1.c: New testcase. * gcc.target/i386/pr88963-2.c: Likewise. From-SVN: r270844 I compared the assembler output from r10-134 and r10-135 for the test case and the differences are significant. Assembler output of the two revisions attached.
[Bug c++/99072] New: [modules] Compiling header unit with partial preprocessing (-E -fdirectives-only) twice causes CRC mismatch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99072 Bug ID: 99072 Summary: [modules] Compiling header unit with partial preprocessing (-E -fdirectives-only) twice causes CRC mismatch Product: gcc Version: 11.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: boris at kolpackov dot net Target Milestone: --- With partial preprocessing (-E -fdirectives-only) compiling the same header with the same options twice results in two CRC-incompatible .gcm files: cat
[Bug analyzer/93695] Allocation and freeing memory for array members in loops is not handled properly by the analyzer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93695 Dmitry G. Dyachenko changed: What|Removed |Added CC||dimhen at gmail dot com --- Comment #2 from Dmitry G. Dyachenko --- gcc version 11.0.0 20210210 (experimental) [master revision bd0e37f68a3:deed5164277:72932511053596091ad291539022b51d9f2ba418] PASS for me
[Bug rtl-optimization/96264] [10/11 Regression] wrong code with -Os -fno-forward-propagate -fschedule-insns -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96264 --- Comment #4 from seurer at gcc dot gnu.org --- Created attachment 50168 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50168&action=edit Assembler output from broken revision
[Bug rtl-optimization/96264] [10/11 Regression] wrong code with -Os -fno-forward-propagate -fschedule-insns -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96264 seurer at gcc dot gnu.org changed: What|Removed |Added CC||seurer at gcc dot gnu.org --- Comment #3 from seurer at gcc dot gnu.org --- Created attachment 50167 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50167&action=edit Assembler output from working revision
[Bug target/98998] [11 Regression] ICE in change_address_1, at emit-rtl.c:2275 since r11-3427
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98998 Christophe Lyon changed: What|Removed |Added CC||clyon at gcc dot gnu.org --- Comment #6 from Christophe Lyon --- (In reply to Jakub Jelinek from comment #5) > Thanks, will test it. > No idea what to do for testcase though, lost in all the incompatible options > and can't find a single gcc.target/arm/ test with -mpure-code in dg-*options. Such tests are in gcc.target/arm/pure-code/
[Bug c++/99071] [modules] ICE with initializer_list & iostream
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99071 Nathan Sidwell changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2021-02-11 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org
