[Bug c++/92559] Returning std∷map breaks tail-recursion optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92559
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-11-19
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
We cannot currently deal with the intermediate stmts in bb 10 and maybe also
not with the EH. I'm not sure whether in the middle-end we really will
ever be able to elide the ctor/dtor of m around the recursive call. Using
by-reference passing might be a way around this (I don't think the return
of std::map is really the issue).
*_20(D) = foo (&D.34875); [return slot optimization]
;;succ: 14 (EH,EXECUTABLE)
;;10 (FALLTHRU,EXECUTABLE)
:
_40 = MEM[(struct _Rb_tree *)&D.34875]._M_impl.D.33073._M_header._M_parent;
std::_Rb_tree,
std::_Select1st >,
std::less, std::allocator > >::_M_erase (&D.34875._M_t, _40);
D.34875 ={v} {CLOBBER};
D.34875 ={v} {CLOBBER};
;;succ: 11 (FALLTHRU,EXECUTABLE)
:
return _20(D);
[Bug other/89863] [meta-bug] Issues that static analyzers (cppcheck, clang-static-analyzer) find that gcc misses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863 Bug 89863 depends on bug 92563, which changed state. Bug 92563 Summary: trunk/gcc/cp/error.c:1988: useless parameter ? https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92563 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID
[Bug c++/92563] trunk/gcc/cp/error.c:1988: useless parameter ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92563 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Richard Biener --- It's really an odd warning - the argument is passed by value, changing such parameters never has an effect outside of the function. So is this really asking to make by-value passing useless and asks for always putting 'const' on such parameters?
[Bug c++/92572] Vague linkage does not work reliably when a matching segment is in a dynamically linked libarary on Linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92572 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-11-19 CC||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- Do you think that 'foo' can be interposed? Your bug lacks some description.
[Bug target/92573] [10 Regression] ICE in extract_insn, at recog.c:2311
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92573 Richard Biener changed: What|Removed |Added Target Milestone|--- |10.0
[Bug ipa/92508] [10 Regression] ICE in do_estimate_edge_time, at ipa-inline-analysis.c:223 since r278159
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92508 --- Comment #19 from Martin Liška --- > We may do something like that, but testsuite requires dejagnu that is > not normally necessary for bootstrapping. I see. > It would also let us to train > -O0 compilation that is quite important for perofrmance, too. Why is that important for performance? I would expect the majority of people use -O2 optimization level.
[Bug ada/92575] New: trunk/gcc/ada/expect.c: 2 * suspicious assignments ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92575 Bug ID: 92575 Summary: trunk/gcc/ada/expect.c: 2 * suspicious assignments ? Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- trunk/gcc/ada/expect.c:265:28: style: Variable 'dead_process' is assigned a value that is never used. [unreadVariable] $ fgrep -n dead_process trunk/gcc/ada/expect.c 128:int *dead_process, 137: *dead_process = 0; 158: *dead_process = i + 1; 227:int *dead_process, 241: *dead_process = 0; 265: dead_process = i + 1; 378:int *dead_process, 392: *dead_process = 0; 450:dead_process = i + 1; 498:int *dead_process ATTRIBUTE_UNUSED, 501: *dead_process = 0; $ Lines 265 and 450 look like errors to me. Maybe better code *dead_process = i + 1; Or should line 498 be copied to lines 128, 227 and 378 ?
[Bug middle-end/92574] Inefficient code for multidimensional array assess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92574
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-11-19
CC||amker at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Richard Biener ---
Confirmed. We're leaving addressing mode selection to RTL since we keep the
array form on GIMPLE and expand from
ip1_8 = ip_7(D) + 1;
itp1_10 = itp_9(D) + 1;
_1 = bar[ip_7(D)][itp_9(D)];
_2 = bar[ip_7(D)][itp1_10];
_3 = _1 + _2;
_4 = bar[ip1_8][itp_9(D)];
_5 = _3 + _4;
_6 = bar[ip1_8][itp1_10];
_12 = _5 + _6;
return _12;
where then we probably do not aggressively enough fwprop/combine (multi-uses
plus required simplifications likely stand in the way). Straight-line code
"IV"OPTs is missing here and SLSR isn't a 1:1 substitute since it doesn't
even attempt to do addressing-mode selection (but it can help the process).
RTL is faced with "badly" associated mults/adds like
8: {r89:DI=r92:DI+0x1;clobber flags:CC;}
30: {r113:DI=r112:DI<<0x1;clobber flags:CC;}
41: {r122:DI=r113:DI+r89:DI;clobber flags:CC;}
42: r123:DI=[r122:DI*0x8+`bar']
and multi-uses of the individual regs.
[Bug c++/92562] Allow [[maybe_unused]] in class member declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92562 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-19 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- GCC already allows it. It's only rejected by GCC because you asked for it to be rejected by GCC, by using -Werror. Please don't use -Werror when reporting bugs about warnings, it just confuses things. Your report is about a warning, not a error, so if you want a better response than "stop using -Werror" or "use "-Wno-error=attributes" then don't use -Werror here. A correct report would be that GCC **warns** for this code, and you don't want it to. I'll confirm it for that, since ignoring it in this case seems harmless (and is useful for compatibility with Clang).
[Bug tree-optimization/92557] [10 Regression] ICE in omp_clause_aligned_alignment, at omp-low.c:4090
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92557 --- Comment #8 from Jakub Jelinek --- Author: jakub Date: Tue Nov 19 08:51:31 2019 New Revision: 278432 URL: https://gcc.gnu.org/viewcvs?rev=278432&root=gcc&view=rev Log: PR tree-optimization/92557 * omp-low.c (omp_clause_aligned_alignment): Punt if TYPE_MODE is not vmode rather than asserting it always is. * gcc.dg/gomp/pr92557.c: New test. Added: trunk/gcc/testsuite/gcc.dg/gomp/pr92557.c Modified: trunk/gcc/ChangeLog trunk/gcc/omp-low.c trunk/gcc/testsuite/ChangeLog
[Bug c++/92504] [9/10 Regression] ICE on gcc-9 -fopenmp: internal compiler error: tree check: expected tree that contains 'decl common' structure, have 'baselink' in get_inner_reference, at expr.c:723
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92504 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Tue Nov 19 08:52:31 2019 New Revision: 278433 URL: https://gcc.gnu.org/viewcvs?rev=278433&root=gcc&view=rev Log: PR c++/92504 * semantics.c (handle_omp_for_class_iterator): Don't call cp_fully_fold on cond. * g++.dg/gomp/pr92504.C: New test. Added: trunk/gcc/testsuite/g++.dg/gomp/pr92504.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug c++/92576] New: Definition of variable template without initializer is treated as declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92576 Bug ID: 92576 Summary: Definition of variable template without initializer is treated as declaration Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- GCC accepts this as a declaration followed by a definition, but it should be two definitions (with the first being ill-formed): template constexpr bool var; template constexpr bool var = false; Clang says: inline.cc:1:37: error: default initialization of an object of const type 'const bool' template constexpr bool var; ^ = false inline.cc:2:37: error: redefinition of 'var' template constexpr bool var = false; ^ inline.cc:1:37: note: previous definition is here template constexpr bool var; ^ 2 errors generated. EDG says: "inline.cc", line 1: error: missing initializer for constexpr variable template constexpr bool var; ^ "inline.cc", line 2: error: variable template "var" has already been defined template constexpr bool var = false; ^ "inline.cc", line 2: error: "constexpr" is not valid here template constexpr bool var = false; ^ 3 errors detected in the compilation of "inline.cc". MSVC says: example.cpp (1): error C2737: 'var': 'constexpr' object must be initialized (2): error C2086: 'const bool var': redefinition (1): note: see declaration of 'var' Compiler returned: 2 I think 'extern' is needed to stop the first line being a definition: template extern constexpr bool var; template constexpr bool var = false; G++ correctly rejects it for a non-template inline variable: constexpr bool var; constexpr bool var = false; inline.cc:1:16: error: uninitialized const ‘var’ [-fpermissive] constexpr bool var; ^~~ inline.cc:2:16: error: redefinition of ‘constexpr const bool var’ constexpr bool var = false; ^~~ inline.cc:1:16: note: ‘constexpr const bool var’ previously declared here constexpr bool var; ^~~
[Bug c++/92576] Definition of variable template without initializer is treated as declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92576 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-19 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #0) > I think 'extern' is needed to stop the first line being a definition: > > template extern constexpr bool var; > template constexpr bool var = false; Actually extern const: template extern const bool var; template constexpr bool var = false;
[Bug middle-end/91450] __builtin_mul_overflow(A,B,R) wrong code if product <
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91450 --- Comment #6 from Jakub Jelinek --- Author: jakub Date: Tue Nov 19 09:15:53 2019 New Revision: 278437 URL: https://gcc.gnu.org/viewcvs?rev=278437&root=gcc&view=rev Log: PR middle-end/91450 * internal-fn.c (expand_mul_overflow): For s1 * s2 -> ur, if one operand is negative and one non-negative, compare the non-negative one against 0 rather than comparing s1 & s2 against 0. Otherwise, don't compare (s1 & s2) == 0, but compare separately both s1 == 0 and s2 == 0, unless one of them is known to be negative. Remove tem2 variable, use tem where tem2 has been used before. * gcc.c-torture/execute/pr91450-1.c: New test. * gcc.c-torture/execute/pr91450-2.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr91450-1.c trunk/gcc/testsuite/gcc.c-torture/execute/pr91450-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/internal-fn.c trunk/gcc/testsuite/ChangeLog
[Bug libstdc++/92577] New: Undefined behavior when using std::map with a noexcept allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92577
Bug ID: 92577
Summary: Undefined behavior when using std::map with a noexcept
allocator
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: lucas.bader at sap dot com
Target Milestone: ---
Created attachment 47296
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47296&action=edit
minimal code example
Using std::map with an allocator with a noexcept specifier leads to undefined
behavior when constructing a node in-place.
Compiled with GCC9 this results in the generation of a ud2 instruction that is
encountered when nullptr be retured by the allocation function:
$ g++ -std=c++17 -O3 allocator_ub.cpp
$ ./a.out
[2]114342 illegal hardware instruction (core dumped) ./a.out
$ objdump -d a.out
00400780
<_ZNSt8_Rb_treeIiSt4pairIKiiESt10_Select1stIS2_ESt4lessIiE10mallocatorIS2_EE17_M_emplace_uniqueIJS0_IiiS0_ISt17_Rb_tree_iteratorIS2_EbEDpOT_>:
...
4008b3: 0f 0b ud2
The corresponding stack trace in gdb is:
#0 0x004008b3 in std::pair >, bool> std::_Rb_tree,
std::_Select1st >, std::less,
mallocator > >::_M_emplace_unique
>(std::pair&&) ()
#1 0x00400632 in main ()
According to the C++17 working draft (8.3.4 paragraph 16):
"If the allocation function has a non-throwing exception specification, it
returns null to
indicate failure to allocate storage and a non-null pointer otherwise. [...]
If the allocation function is a non-allocating form (21.6.2.3) that returns
null, the behavior is undefined."
This is also supported by cppreference.com
(https://en.cppreference.com/w/cpp/language/new) with:
"If the standard placement allocation function returns a null pointer, which is
possible if the user passes a null pointer as the argument, the behavior is
undefined. (since C++17)"
The std::map implementation should handle this appropriately or prohibit using
it with an allocator that is defined noexcept.
When using an allocation function with the noexcept specifier (and thus
returning nullptr on failure), nullptr is passed to placement new (in
stl_tree.h) via the following code:
2406 _M_emplace_unique(_Args&&... __args)
2407 {
2408 _Link_type __z = _M_create_node(std::forward<_Args>(__args)...);
628 _M_create_node(_Args&&... __args)
629 {
630 _Link_type __tmp = _M_get_node();
631 _M_construct_node(__tmp, std::forward<_Args>(__args)...);
579 _M_get_node()
580 { return _Alloc_traits::allocate(_M_get_Node_allocator(), 1); }
609 _M_construct_node(_Link_type __node, _Args&&... __args)
610 {
611 __try
612{
613 ::new(__node) _Rb_tree_node<_Val>;
614 _Alloc_traits::construct(_M_get_Node_allocator(),
615 __node->_M_valptr(),
616 std::forward<_Args>(__args)...);
617}
618 __catch(...)
619{
620 __node->~_Rb_tree_node<_Val>();
621 _M_put_node(__node);
622 __throw_exception_again;
623}
624 }
[Bug c++/92563] trunk/gcc/cp/error.c:1988: useless parameter ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92563 Martin Ettl changed: What|Removed |Added CC||ettl.martin at gmx dot de --- Comment #3 from Martin Ettl --- (In reply to Richard Biener from comment #2) > It's really an odd warning - the argument is passed by value, changing such > parameters never has an effect outside of the function. So is this really > asking to make by-value passing useless and asks for always putting 'const' > on such parameters? Yes it does, bit Cppcheck is configurable and it is possible to suppress this warning: Quoted from Cppcheck's manpage: --suppress= Suppress a specific warning. The format of is: [error id]:[filename]:[line]. The [filename] and [line] are optional. [error id] may be * to suppress all warnings (for a specified file or files). [filename] may contain the wildcard characters * or ?.
[Bug middle-end/91450] __builtin_mul_overflow(A,B,R) wrong code if product <
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91450 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Tue Nov 19 09:26:23 2019 New Revision: 278438 URL: https://gcc.gnu.org/viewcvs?rev=278438&root=gcc&view=rev Log: PR middle-end/91450 * internal-fn.c (expand_mul_overflow): For s1 * s2 -> ur, if one operand is negative and one non-negative, compare the non-negative one against 0 rather than comparing s1 & s2 against 0. Otherwise, don't compare (s1 & s2) == 0, but compare separately both s1 == 0 and s2 == 0, unless one of them is known to be negative. Remove tem2 variable, use tem where tem2 has been used before. * gcc.c-torture/execute/pr91450-1.c: New test. * gcc.c-torture/execute/pr91450-2.c: New test. Added: branches/gcc-9-branch/gcc/testsuite/gcc.c-torture/execute/pr91450-1.c branches/gcc-9-branch/gcc/testsuite/gcc.c-torture/execute/pr91450-2.c Modified: branches/gcc-9-branch/gcc/ChangeLog branches/gcc-9-branch/gcc/internal-fn.c branches/gcc-9-branch/gcc/testsuite/ChangeLog
[Bug target/92578] New: [i386] cmov not generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92578
Bug ID: 92578
Summary: [i386] cmov not generated
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: crazylht at gmail dot com
CC: hjl.tools at gmail dot com
Target Milestone: ---
Cat test.c
int foo(int moves, int movecnt, int komove) {
int newcnt = movecnt;
if (moves == komove)
newcnt--;
return newcnt;
}
gcc10 -O2 test.c -S
cmpl%edx, %edi
movl%esi, %eax
sete%dl
movzbl %dl, %edx
subl%edx, %eax
ret
It could be better like
cmpl %edx, %edi#6.12
lea -1(%rsi), %eax#5.9
cmovne%esi, %eax#6.12
ret
Just like icc did, refer to https://godbolt.org/z/6mqkt8
[Bug target/92549] Use x86 xchg instruction more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92549 --- Comment #7 from Jakub Jelinek --- Author: jakub Date: Tue Nov 19 09:31:59 2019 New Revision: 278439 URL: https://gcc.gnu.org/viewcvs?rev=278439&root=gcc&view=rev Log: PR target/92549 * config/i386/i386.md (peephole2 for *swap): New peephole2. * gcc.target/i386/pr92549.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr92549.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md trunk/gcc/testsuite/ChangeLog
[Bug c++/92576] Definition of variable template without initializer is treated as declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92576 --- Comment #2 from Jonathan Wakely --- Author: redi Date: Tue Nov 19 09:34:59 2019 New Revision: 278440 URL: https://gcc.gnu.org/viewcvs?rev=278440&root=gcc&view=rev Log: libstdc++: Fix declarations of variable templates This code is invalid and rejected by other compilers (see PR 92576). * include/bits/regex.h (ranges::__detail::__enable_view_impl): Fix declaration. * include/bits/stl_multiset.h (ranges::__detail::__enable_view_impl): Likewise. * include/bits/stl_set.h (ranges::__detail::__enable_view_impl): Likewise. * include/bits/unordered_set.h (ranges::__detail::__enable_view_impl): Likewise. * include/debug/multiset.h (ranges::__detail::__enable_view_impl): Likewise. * include/debug/set.h (ranges::__detail::__enable_view_impl): Likewise. * include/debug/unordered_set (ranges::__detail::__enable_view_impl): Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/regex.h trunk/libstdc++-v3/include/bits/stl_multiset.h trunk/libstdc++-v3/include/bits/stl_set.h trunk/libstdc++-v3/include/bits/unordered_set.h trunk/libstdc++-v3/include/debug/multiset.h trunk/libstdc++-v3/include/debug/set.h trunk/libstdc++-v3/include/debug/unordered_set
[Bug c++/92579] New: compiler rejects list initialization of character array member from string literal in return statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92579
Bug ID: 92579
Summary: compiler rejects list initialization of character
array member from string literal in return statement
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: michael.kenzel at gmail dot com
Target Milestone: ---
The following code will reproduce the issue (seems to affect all versions of
gcc that support C++11):
struct blub
{
char a[5];
};
blub f()
{
return {"asdf"}; // error: could not convert '{"asdf"}' from
'' to 'blub'
// return {{'a', 's', 'd', 'f', '\0'}}; // OK
// return blub {"asdf"}; // OK
}
[Bug libstdc++/92577] Undefined behavior when using std::map with a noexcept allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92577 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jonathan Wakely --- Allocators aren't allowed to return null, they have to report failure to allocate by throwing an exception.
[Bug libstdc++/92577] Undefined behavior when using std::map with a noexcept allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92577 --- Comment #2 from Jonathan Wakely --- (Your quotes from the standard are about operator new, not about allocators.)
[Bug c++/92580] New: "if constexpr" not discarding branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92580 Bug ID: 92580 Summary: "if constexpr" not discarding branch Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: paultargosz86 at googlemail dot com Target Milestone: --- "if constexpr" uses std::is_same to check type. depending on the type its using different if-branches, that can have or have not member variables. The "discarded Branch" tries to use nonexistent membervariables and fails therefore. https://godbolt.org/z/jw_BAy differentiation: Bug 85689 is static_assert that is not proposed in "if constexpr" e.g. wg21.link/p0292
[Bug c++/92580] "if constexpr" not discarding branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92580
--- Comment #1 from Paul Targosz ---
//examplecode without godbolt
#include
#include
struct GW_t {
};
template
struct IP_t {
constexpr static uint8_t a = A;
constexpr static uint8_t b = B;
constexpr static uint8_t c = C;
constexpr static uint8_t d = D;
};
template
void workaround() {
std::cout << "connecting to static IP " << int{my_config::a} << "." <<
int{my_config::b} << "." << int{my_config::c} << "." << int{my_config::d};
}
int main() {
// * This two lines are the different configurations
using my_config = GW_t;
// using my_config = IP_t<192,168,0,8>;
if constexpr(std::is_same::value) {
std::cout << "connecting to Gateway";
}
else {
// * first line should work but isn't, second line is the
workaround
std::cout << "connecting to static IP " << int{my_config::a} << "." <<
int{my_config::b} << "." << int{my_config::c} << "." << int{my_config::d};
// workaround();
}
return 0;
}
[Bug c++/92576] Definition of variable template without initializer is treated as declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92576
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org,
||jason at gcc dot gnu.org,
||mpolacek at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
I think there are multiple issues. One is the lack of diagnostic for missing
initializer.
I've tried to do:
--- gcc/cp/decl.c.jj2019-11-16 18:13:28.806818043 +0100
+++ gcc/cp/decl.c 2019-11-19 11:13:03.058266394 +0100
@@ -7500,11 +7500,12 @@ cp_finish_decl (tree decl, tree init, bo
error ("variable concept has no initializer");
init = boolean_true_node;
}
- else if (init
- && init_const_expr_p
- && !TYPE_REF_P (type)
- && decl_maybe_constant_var_p (decl)
- && !(dep_init = value_dependent_init_p (init)))
+ else if ((init
+ && init_const_expr_p
+ && !TYPE_REF_P (type)
+ && decl_maybe_constant_var_p (decl)
+ && !(dep_init = value_dependent_init_p (init)))
+ || (!init && !DECL_EXTERNAL (decl)))
{
/* This variable seems to be a non-dependent constant, so process
its initializer. If check_initializer returns non-null the
but that resulted in
FAIL: g++.dg/cpp2a/concepts-friend3.C -std=c++17 -fconcepts (test for excess
errors)
FAIL: g++.dg/other/crash-9.C -std=c++17 -fconcepts (test for excess errors)
FAIL: g++.dg/eh/pr84968.C -std=gnu++11 (test for errors, line 12)
FAIL: g++.dg/eh/pr84968.C -std=gnu++11 (test for excess errors)
FAIL: g++.dg/eh/pr84968.C -std=gnu++14 (test for errors, line 12)
FAIL: g++.dg/eh/pr84968.C -std=gnu++14 (test for excess errors)
FAIL: g++.dg/eh/pr84968.C -std=gnu++17 (test for errors, line 12)
FAIL: g++.dg/eh/pr84968.C -std=gnu++17 (test for excess errors)
FAIL: g++.dg/eh/pr84968.C -std=gnu++2a (test for errors, line 12)
FAIL: g++.dg/eh/pr84968.C -std=gnu++2a (test for excess errors)
FAIL: g++.dg/eh/pr84968.C -std=gnu++17 -fconcepts (test for errors, line 12)
FAIL: g++.dg/eh/pr84968.C -std=gnu++17 -fconcepts (test for excess errors)
FAIL: g++.dg/cpp2a/consteval14.C (internal compiler error)
FAIL: g++.dg/cpp2a/consteval14.C (test for excess errors)
FAIL: g++.dg/cpp1y/pr68578.C -std=c++14 (test for excess errors)
FAIL: g++.dg/cpp1y/pr68578.C -std=c++17 (test for excess errors)
FAIL: g++.dg/cpp1y/pr68578.C -std=c++2a (test for excess errors)
FAIL: g++.dg/cpp1y/pr68578.C -std=c++17 -fconcepts (test for excess errors)
so maybe we'll need something more similar to the present:
if (!VAR_P (decl) || type_dependent_p)
/* We can't do anything if the decl has dependent type. */;
else if (!init && is_concept_var (decl))
{
error ("variable concept has no initializer");
init = boolean_true_node;
}
and for !init do parts of grok_reference_init if TYPE_REF_P or call
check_for_uninitialized_const_var.
Another thing is we don't diagnose redefinitions, like:
template constexpr bool a = false;
template constexpr bool a = true;
//auto b = a<2>;
[Bug c++/89931] Incorrect compiler error with temporary object used as function arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89931 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-19 Ever confirmed|0 |1
[Bug c++/84930] Brace-closed initialization of cstring (i.e."abcdefghi") to coresponding aggregate types fails in certain situation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84930
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2018-03-28 00:00:00 |2019-11-19
--- Comment #3 from Jonathan Wakely ---
It doesn't work in a return statement either:
struct array { char data[2]; };
void f(array) {}
array g() {
f({"a"});
return {"a"};
}
84930.cc: In function ‘array g()’:
84930.cc:6:12: error: could not convert ‘{"a"}’ from ‘’ to ‘array’
f({"a"});
^
84930.cc:7:16: error: could not convert ‘{"a"}’ from ‘’ to ‘array’
return {"a"};
^
[Bug c++/84930] Brace-closed initialization of cstring (i.e."abcdefghi") to coresponding aggregate types fails in certain situation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84930 Jonathan Wakely changed: What|Removed |Added CC||michael.kenzel at gmail dot com --- Comment #4 from Jonathan Wakely --- *** Bug 92579 has been marked as a duplicate of this bug. ***
[Bug c++/92579] compiler rejects list initialization of character array member from string literal in return statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92579 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- dup *** This bug has been marked as a duplicate of bug 84930 ***
[Bug c++/92580] "if constexpr" not discarding branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92580 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- G++ is correct, your code is ill-formed. *** This bug has been marked as a duplicate of bug 87389 ***
[Bug c++/87389] if constexpr not working properly with static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87389 Jonathan Wakely changed: What|Removed |Added CC||paultargosz86 at googlemail dot co ||m --- Comment #3 from Jonathan Wakely --- *** Bug 92580 has been marked as a duplicate of this bug. ***
[Bug c++/92580] "if constexpr" not discarding branch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92580 --- Comment #3 from Jonathan Wakely --- See PR 85689 as well.
[Bug libstdc++/92577] Undefined behavior when using std::map with a noexcept allocator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92577 --- Comment #3 from Lucas Bader --- Thanks for the clarification. I know that the standard quotes refer to new and I added them under the impression that an allocator is allowed to return nullptr from its allocate function. This would make the call to new in _M_construct_node undefined. In the allocator requirements defined in the standard (20.5.3.5) it only says that "allocate may throw an appropriate exception.". This sounds optional to me, that's why I thought allocate could legally return nullptr.
[Bug c/90677] [9/10 Regression] gcc-9.1.0 fails to build __gcc_diag__ souce: error: 'cgraph_node' is not defined as a type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90677 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #7 from Jakub Jelinek --- Better reduced testcase that shows what actually is happening in the older GCCs: struct cgraph_node; struct tree_node; typedef struct tree_node *tree; struct cgraph_node *cgraph_node (tree); void foo (int, const char *, ...) __attribute__((__format__(__gcc_diag__, 2, 3)));
[Bug c/90677] [9/10 Regression] gcc-9.1.0 fails to build __gcc_diag__ souce: error: 'cgraph_node' is not defined as a type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90677 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- Created attachment 47297 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47297&action=edit gcc10-pr90677.patch Untested fix.
[Bug middle-end/92574] Inefficient code for multidimensional array assess
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92574 --- Comment #2 from bin cheng --- Similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57534 The original idea was handle this as much as possible in ivopt which is difficult given ivopt code has lots of (scev/niter) validity checks. In aforementioned straight-line "ivopts", we only need to factor out common part, choose addressing mode, rewrite memory references. Maybe a light-weight pass to do the job using existing ivopt facility.
[Bug tree-optimization/92581] [10 Regression] condition chains vectorized wrongly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92581 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-11-19 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |10.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- testing patch
[Bug tree-optimization/92581] New: [10 Regression] condition chains vectorized wrongly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92581
Bug ID: 92581
Summary: [10 Regression] condition chains vectorized wrongly
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
Target Milestone: ---
#define N 512
int a[N], b[N];
int __attribute__((noipa))
foo (int aval, int bval)
{
int i, res = 0;
for (i=0; i
[Bug target/92578] [i386] cmov not generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92578 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-19 Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- With newcnt-=2 you get movl%edx, %r8d movl%esi, %eax leal-2(%rsi), %edx cmpl%r8d, %edi cmove %edx, %eax ret so it's if-conversions preference to generate setCC which I'm not sure is really worse here, is it? We're saving a zero extend and some reg-reg moves. I'm sure we have a duplicate report about this.
[Bug c++/92582] New: [10 Regression] internal compiler error: Segmentation fault with concept on constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92582
Bug ID: 92582
Summary: [10 Regression] internal compiler error: Segmentation
fault with concept on constructor
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
Target Milestone: ---
Hi gcc-team,
the following code ices:
```
#include
template
concept bool input_or_output_iterator = std::is_same_v;
template concept convertible_to = requires(From(f)()) {
static_cast(f());
};
template struct reference;
template using reference_t = typename reference::type;
template struct reference {
using type = typename std::iterator_traits::reference;
};
template
requires (!input_or_output_iterator) struct reference {
using type = reference_t()))>;
};
template struct b {
template
static constexpr bool e = convertible_to, int>;
template b(std::initializer_list) requires e;
};
b g{std::vector{}};
```
> g++-git -std=c++17 -fconcepts -c ice.cpp
as well as
> g++-git -std=c++2a -c ice.cpp
results in
```
ice.cpp:19:62: internal compiler error: Segmentation fault
19 | template b(std::initializer_list) requires e;
| ^~~~
0xc4999f crash_signal
/home/marehr/Packages/gcc-git/src/gcc/gcc/toplev.c:328
0x72e6b5 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:18836
0x735eb6 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:18765
0x735eb6 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/pt.c:18423
0x65d8e2 satisfy_constraint_r
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/constraint.cc:2474
0x65e118 satisfy_constraint
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/constraint.cc:2554
0x65f4cb satisfy_associated_constraints
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/constraint.cc:2572
0x65f4cb constraints_satisfied_p
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/constraint.cc:2656
0x627852 add_function_candidate
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:2264
0x629e3c add_template_candidate_real
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:3422
0x62a3c6 add_template_candidate
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:3463
0x62a3c6 add_candidates
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:5781
0x62a6f4 add_candidates
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:5696
0x62a6f4 add_list_candidates
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:3902
0x63281e build_new_method_call_1
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:10086
0x6330d6 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:10268
0x6330d6 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/call.c:9706
0x6abb43 expand_default_init
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/init.c:1970
0x6abb43 expand_aggr_init_1
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/init.c:2085
0x6adab6 build_aggr_init(tree_node*, tree_node*, int, int)
/home/marehr/Packages/gcc-git/src/gcc/gcc/cp/init.c:1820
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/90451] [8/9/10 Regression] "static" function which added "deprecated" print deprecated warning >1 times (twice or even 3 times)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90451 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #6 from Jakub Jelinek --- The 3 messages are there because we call mark_used 3 times in that case: #4 0x02506120 in warning (opt=457, gmsgid=0x27bc403 "%qD is deprecated: %s") at ../../gcc/diagnostic.c:1320 #5 0x0194a43b in warn_deprecated_use (node=, attr=) at ../../gcc/tree.c:13033 #6 0x00a0ac99 in cp_warn_deprecated_use (decl=, complain=3) at ../../gcc/cp/decl2.c:5387 #7 0x00a0c729 in mark_used (decl=, complain=3) at ../../gcc/cp/decl2.c:5507 #8 0x00bd4e01 in finish_qualified_id_expr (qualifying_class=, expr=, done=false, address_p=false, template_p=false, template_arg_p=false, complain=3) at ../../gcc/cp/semantics.c:2119 #9 0x00bdd7e6 in finish_id_expression_1 (id_expression=, decl=, scope=, idk=0x7fffc14c, integral_constant_expression_p=false, allow_non_integral_constant_expression_p=false, non_integral_constant_expression_p=0x7fffea8237e5, template_p=false, done=false, address_p=false, template_arg_p=false, error_msg=0x7fffbcf8, location=295727) at ../../gcc/cp/semantics.c:3918 #10 0x00bddea7 in finish_id_expression (id_expression=, decl=, scope=, idk=0x7fffc14c, integral_constant_expression_p=false, allow_non_integral_constant_expression_p=false, non_integral_constant_expression_p=0x7fffea8237e5, template_p=false, done=false, address_p=false, template_arg_p=false, error_msg=0x7fffbcf8, location=295727) at ../../gcc/cp/semantics.c:4029 first, then #4 0x02506120 in warning (opt=457, gmsgid=0x27bc403 "%qD is deprecated: %s") at ../../gcc/diagnostic.c:1320 #5 0x0194a43b in warn_deprecated_use (node=, attr=) at ../../gcc/tree.c:13033 #6 0x00a0ac99 in cp_warn_deprecated_use (decl=, complain=3) at ../../gcc/cp/decl2.c:5387 #7 0x00a0c729 in mark_used (decl=, complain=3) at ../../gcc/cp/decl2.c:5507 #8 0x008f1dba in build_over_call (cand=0x35231d0, flags=3, complain=3) at ../../gcc/cp/call.c:8947 #9 0x008f6e09 in build_new_method_call_1 (instance=, fns=, args=0x7fffc0d0, conversion_path=, flags=3, fn_p=0x0, complain=3) at ../../gcc/cp/call.c:10194 #10 0x008f72f7 in build_new_method_call (instance=, fns=, args=0x7fffc0d0, conversion_path=, flags=3, fn_p=0x0, complain=3) at ../../gcc/cp/call.c:10269 #11 0x00bd63d7 in finish_call_expr (fn=, args=0x7fffc0d0, disallow_virtual=true, koenig_p=false, complain=3) at ../../gcc/cp/semantics.c:2585 and finally #4 0x02506120 in warning (opt=457, gmsgid=0x27bc403 "%qD is deprecated: %s") at ../../gcc/diagnostic.c:1320 #5 0x0194a43b in warn_deprecated_use (node=, attr=) at ../../gcc/tree.c:13033 #6 0x00a0ac99 in cp_warn_deprecated_use (decl=, complain=3) at ../../gcc/cp/decl2.c:5387 #7 0x00a0c729 in mark_used (decl=, complain=3) at ../../gcc/cp/decl2.c:5507 #8 0x00c43ef5 in cp_build_addr_expr_1 (arg=, strict_lvalue=false, complain=3) at ../../gcc/cp/typeck.c:6256 #9 0x00c44483 in cp_build_addr_expr (arg=, complain=3) at ../../gcc/cp/typeck.c:6304 #10 0x00c34308 in decay_conversion (exp=, complain=3, reject_builtin=false) at ../../gcc/cp/typeck.c:2097 #11 0x008d173f in build_addr_func (function=, complain=3) at ../../gcc/cp/call.c:287 #12 0x008f20c5 in build_over_call (cand=0x35231d0, flags=3, complain=3) at ../../gcc/cp/call.c:8974 #13 0x008f6e09 in build_new_method_call_1 (instance=, fns=, args=0x7fffc0d0, conversion_path=, flags=3, fn_p=0x0, complain=3) at ../../gcc/cp/call.c:10194 #14 0x008f72f7 in build_new_method_call (instance=, fns=, args=0x7fffc0d0, conversion_path=, flags=3, fn_p=0x0, complain=3) at ../../gcc/cp/call.c:10269 #15 0x00bd63d7 in finish_call_expr (fn=, args=0x7fffc0d0, disallow_virtual=true, koenig_p=false, complain=3) at ../../gcc/cp/semantics.c:2585 Now, we can't really cache on the decl whether we've already warned about the deprecated use, because we do want to warn if the deprecated function is called multiple times. So, either we need to avoid calling mark_used for the same expression multiple times, or we need some other way how to avoid the dups.
[Bug libfortran/78314] [aarch64] ieee_support_halting does not report unsupported fpu traps correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314 --- Comment #29 from Maxim Kuvyrkov --- (In reply to Richard Earnshaw from comment #28) > The last release of gcc-7 has now been made, so it's end-of-life and no > further fixes for it will be made. Well, yes, but I'm about to build the final Linaro GCC 7.5 cross-toolchain releases, and I could fix the problem there. E.g., by backporting a fix from GCC-8 or reverting Uros's patch. Backporting from gcc-8 is preferred to reverting, obviously.
[Bug tree-optimization/92543] [10 regression] gcc.dg/vect/vect-alias-check-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92543 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-11-19 Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from rsandifo at gcc dot gnu.org --- Mine.
[Bug middle-end/90597] [9/10 Regression] FAIL: gcc.dg/attr-vector_size.c (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90597 Jakub Jelinek changed: What|Removed |Added Priority|P3 |P4 CC||jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- The problem is that bitsizetype is just 64-bit on hppa64, and so when calling layout_type on VECTOR_TYPE with char element type and 0x2000 nunits, TYPE_SIZE_UNIT is 0x2000 bytes, while TYPE_SIZE is 0. So, either we should reject already vectors with bitsize bigger than half of the address space, or we need to enforce that bitsizetype is actually wide enough to handle number of address space bits + number of bits in byte, or default_vector_alignment should treat TYPE_SIZE 0 with non-zero TYPE_SIZE_UNIT as indication of a huge vector. hppa64 is neither primary nor secondary target though, so making this P4.
[Bug target/92534] [10 regression] gcc.dg/vect/bb-slp-42.c fails after r278262
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92534 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-11-19 Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from rsandifo at gcc dot gnu.org --- Mine.
[Bug tree-optimization/92527] gcc.dg/vect/bb-slp-div-2.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92527 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-11-19 Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from rsandifo at gcc dot gnu.org --- Mine.
[Bug tree-optimization/92526] [10 Regression] ICE in vect_enhance_data_refs_alignment, at tree-vect-data-refs.c:2274 since r278244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92526 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org --- Comment #1 from rsandifo at gcc dot gnu.org --- Mine.
[Bug rtl-optimization/92264] [10 Regression] Compile time hog in 521.wrf_r with -Ofast -march=znver2 -g since r276318
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92264 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-11-19 Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from rsandifo at gcc dot gnu.org --- Mine.
[Bug c++/92583] New: internal compiler error: in tsubst_copy, at cp/pt.c:15552
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92583
Bug ID: 92583
Summary: internal compiler error: in tsubst_copy, at
cp/pt.c:15552
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fiesh at zefix dot tv
Target Milestone: ---
The following code leads to an internal compiler error with gcc 8, 9, and
trunk:
template struct a {};
template using b = int;
template struct e {};
template using h = e;
template void apply(j f, e) {
(f(a{}), ...);
}
template void m(j f) {
using k = b;
using n = h;
apply(f, n{});
}
template void o() {
auto p = [](auto i) {
if constexpr (a{})
;
};
m(p);
}
auto q() { o<0, 1>; }
% g++ -std=c++17 -c h.ii
h.ii: In instantiation of ‘o() [with int = 0; int c =
1]:: [with auto:1 = a<0>]’:
h.ii:6:5: required from ‘void apply(j, e) [with j = o() [with
int = 0; int c = 1]::; k = int; k ...index = {0}]’
h.ii:11:8: required from ‘void m(j) [with auto l = 1; j = o() [with int
= 0; int c = 1]::]’
h.ii:18:7: required from ‘void o() [with int = 0; int c = 1]’
h.ii:20:19: required from here
h.ii:15:5: internal compiler error: in tsubst_copy, at cp/pt.c:15552
15 | if constexpr (a{})
| ^~
0x58f8a4 tsubst_copy
/usr/src/debug/sys-devel/gcc-9.2.0-r2/gcc-9.2.0/gcc/cp/pt.c:15552
0x6c7fc0 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/usr/src/debug/sys-devel/gcc-9.2.0-r2/gcc-9.2.0/gcc/cp/pt.c:19486
0x6d14d5 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/usr/src/debug/sys-devel/gcc-9.2.0-r2/gcc-9.2.0/gcc/cp/pt.c:18242
0x6d14d5 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/usr/src/debug/sys-devel/gcc-9.2.0-r2/gcc-9.2.0/gcc/cp/pt.c:17918
0x6d836a tsubst_template_args
/usr/src/debug/sys-devel/gcc-9.2.0-r2/gcc-9.2.0/gcc/cp/pt.c:12574
0x6db018 tsubst_aggr_type
/usr/src/debug/sys-devel/gcc-9.2.0-r2/gcc-9.2.0/gcc/cp/pt.c:12771
0x6cbe11 tsubst(tree_node*, tree_node*, int, tree_node*)
/usr/src/debug/sys-devel/gcc-9.2.0-r2/gcc-9.2.0/gcc/cp/pt.c:14460
0x6c8299 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/usr/src/debug/sys-devel/gcc-9.2.0-r2/gcc-9.2.0/gcc/cp/pt.c:19373
0x6d14d5 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
/usr/src/debug/sys-devel/gcc-9.2.0-r2/gcc-9.2.0/gcc/cp/pt.c:18242
0x6d14d5 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/usr/src/debug/sys-devel/gcc-9.2.0-r2/gcc-9.2.0/gcc/cp/pt.c:17918
0x6d0720 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/usr/src/debug/sys-devel/gcc-9.2.0-r2/gcc-9.2.0/gcc/cp/pt.c:17270
0x6d0629 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/usr/src/debug/sys-devel/gcc-9.2.0-r2/gcc-9.2.0/gcc/cp/pt.c:17325
0x6d0629 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/usr/src/debug/sys-devel/gcc-9.2.0-r2/gcc-9.2.0/gcc/cp/pt.c:17325
0x6d0629 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
/usr/src/debug/sys-devel/gcc-9.2.0-r2/gcc-9.2.0/gcc/cp/pt.c:17325
0x6cfd2a instantiate_decl(tree_node*, bool, bool)
/usr/src/debug/sys-devel/gcc-9.2.0-r2/gcc-9.2.0/gcc/cp/pt.c:24792
0x638f52 maybe_instantiate_decl
/usr/src/debug/sys-devel/gcc-9.2.0-r2/gcc-9.2.0/gcc/cp/decl2.c:5300
0x638f52 maybe_instantiate_decl
/usr/src/debug/sys-devel/gcc-9.2.0-r2/gcc-9.2.0/gcc/cp/decl2.c:5284
0x63ac08 mark_used(tree_node*, int)
/usr/src/debug/sys-devel/gcc-9.2.0-r2/gcc-9.2.0/gcc/cp/decl2.c:5456
0x5dc7d8 build_over_call
/usr/src/debug/sys-devel/gcc-9.2.0-r2/gcc-9.2.0/gcc/cp/call.c:8677
0x5df7b6 build_op_call_1
/usr/src/debug/sys-devel/gcc-9.2.0-r2/gcc-9.2.0/gcc/cp/call.c:4778
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/92584] New: A 454.calculix optimization opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92584 Bug ID: 92584 Summary: A 454.calculix optimization opportunity Product: gcc Version: 10.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Richi, I noticed the following graph: https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=8.170.0 I noticed that the speed drop back on the trunk happened since r278281. Would you be interested in what loop optimization made the difference?
[Bug tree-optimization/92581] [10 Regression] condition chains vectorized wrongly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92581 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Richard Biener --- Fixed.
[Bug tree-optimization/92581] [10 Regression] condition chains vectorized wrongly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92581 --- Comment #3 from Richard Biener --- Author: rguenth Date: Tue Nov 19 14:00:46 2019 New Revision: 278445 URL: https://gcc.gnu.org/viewcvs?rev=278445&root=gcc&view=rev Log: 2019-11-19 Richard Biener PR tree-optimization/92581 * tree-vect-loop.c (vect_create_epilog_for_reduction): For condition reduction chains gather all conditions involved for computing the index reduction vector. * gcc.dg/vect/vect-cond-reduc-5.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/vect/vect-cond-reduc-5.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-vect-loop.c
[Bug c++/90767] [9/10 Regression] jumbled error message with this and const
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90767 --- Comment #5 from Jakub Jelinek --- Created attachment 47298 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47298&action=edit gcc10-pr90767.patch Untested fix. Though, that only fixes the ugly ... not supported by dump_expr part, the complain_about_bad_argument call still emits worse diagnostics compared to what print_conversion_rejection can emit.
[Bug tree-optimization/92584] A 454.calculix optimization opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92584 --- Comment #1 from rguenther at suse dot de --- On Tue, 19 Nov 2019, marxin at gcc dot gnu.org wrote: > I noticed that the speed drop back on the trunk happened since r278281. > Would you be interested in what loop optimization made the difference? Well, the revs probably caused changes in (early) unrolling with the better performance seen with less unrolling. We know that even more unrolling will increase performance though. Not sure what you are asking?
[Bug tree-optimization/92537] [10 Regression] ICE in vect_slp_analyze_node_operations, at tree-vect-slp.c:2775
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92537
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment #4 from David Binderman ---
Another reduced test case, this time in C:
int a[64];
int b, c, e;
short d;
short f[64];
void g() {
b = 0;
c = d >> 3;
for (; b < 64 - 1; b++) {
e = 0;
e -= a[b] * c;
f[b] = e;
}
}
Flag -O3 required.
[Bug target/90777] [10 Regression] pr84828 testcase ICEs for m32 x86_64,i686-darwin*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90777 Jakub Jelinek changed: What|Removed |Added Keywords||error-recovery Priority|P3 |P4 CC||jakub at gcc dot gnu.org, ||uros at gcc dot gnu.org Component|c++ |target --- Comment #1 from Jakub Jelinek --- On x86_64-linux the testcase ICEs too with -Og -msse -mno-sse2 -mfpmath=sse -m32 First ICE with these options is r210520.
[Bug tree-optimization/92539] [8/9/10 Regression] -Warray-bounds false positive (loop unroll?)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92539 Martin Sebor changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-19 CC||msebor at gcc dot gnu.org Component|c++ |tree-optimization Known to work||7.3.0 Ever confirmed|0 |1 Known to fail||10.0, 8.3.0, 9.2.0 --- Comment #1 from Martin Sebor --- Confirmed. The warning was introduced with r247362 (GCC 8).
[Bug tree-optimization/92527] gcc.dg/vect/bb-slp-div-2.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92527 --- Comment #3 from rsandifo at gcc dot gnu.org --- I have a patch for the bb-slp-21.c failure. Are you still seeing the bb-slp-div-2.c failure? I can't reproduce it with a hacked-up cross, and I'm not sure from the dump why we failed to vectorise the conversion.
[Bug middle-end/90840] [8/9/10 Regression] ICE in simplify_subreg, at simplify-rtx.c:6441
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90840 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Started most likely with r179930 (r179921 still works).
[Bug c++/92078] error: 'struct std::ptr' redeclared with different access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92078 --- Comment #4 from asutton at gcc dot gnu.org --- Author: asutton Date: Tue Nov 19 15:18:50 2019 New Revision: 278450 URL: https://gcc.gnu.org/viewcvs?rev=278450&root=gcc&view=rev Log: PR c++/92078 gcc/cp/ * pt.c (maybe_new_partial_specialization): Apply access to newly created partial specializations. Update comment style. gcc/testsuite/ * g++.dg/cpp2a/concepts-pr92078.C: New. * g++.dg/cpp2a/concepts-requires18.C: Update diagnostics. Added: trunk/gcc/testsuite/g++.dg/cpp2a/concepts-pr92078.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp2a/concepts-requires18.C
[Bug tree-optimization/92527] gcc.dg/vect/bb-slp-div-2.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92527 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #3 from rsandifo at gcc dot gnu.org > --- > I have a patch for the bb-slp-21.c failure. Are you still seeing the > bb-slp-div-2.c failure? I can't reproduce it with a hacked-up cross, and I'm > not sure from the dump why we failed to vectorise the conversion. No, the latter one vanished between 20191115 (r278282) and 20191116 (r278365).
[Bug c++/89913] [8/9/10 Regression] ICE with invalid using declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89913 --- Comment #5 from asutton at gcc dot gnu.org --- Author: asutton Date: Tue Nov 19 15:26:16 2019 New Revision: 278451 URL: https://gcc.gnu.org/viewcvs?rev=278451&root=gcc&view=rev Log: PR c++/89913 gcc/cp/ * pt.c (get_underlying_template): Exit loop if the original type of the alias is null. gcc/testsuite/ * g++.dg/cpp2a/pr89913.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp2a/pr89913.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug target/92534] [10 regression] gcc.dg/vect/bb-slp-42.c fails after r278262
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92534 rsandifo at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|rsandifo at gcc dot gnu.org|unassigned at gcc dot gnu.org --- Comment #2 from rsandifo at gcc dot gnu.org --- Sorry, misread the output and thought it was the scan-assembler tests failing. If it's the execution test then I'm not sure this is necessarily my bug.
[Bug c++/84930] Brace-closed initialization of cstring (i.e."abcdefghi") to coresponding aggregate types fails in certain situation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84930
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #5 from Marek Polacek ---
Somewhat related to my P0960 patch where I needed to handle initializing from
("foo") too.
[Bug bootstrap/92585] New: [10 regression] r278411 breaks bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92585 Bug ID: 92585 Summary: [10 regression] r278411 breaks bootstrap Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- make[3]: Entering directory `/home/seurer/gcc/build/gcc-test2/gcc' /home/seurer/gcc/build/gcc-test2/./prev-gcc/xg++ -B/home/seurer/gcc/build/gcc-test2/./prev-gcc/ -B/home/seurer/gcc/install/gcc-test2/powerpc64-unknown-linux-gnu/bin/ -nostdinc++ -B/home/seurer/gcc/build/gcc-test2/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/home/seurer/gcc/build/gcc-test2/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/home/seurer/gcc/build/gcc-test2/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/seurer/gcc/build/gcc-test2/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++ -L/home/seurer/gcc/build/gcc-test2/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/seurer/gcc/build/gcc-test2/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -g -O2 -fno-checking -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -static-libstdc++ -static-libgcc -no-pie -o build/genmodes \ build/genmodes.o build/errors.o .././libiberty/libiberty.a build/genmodes -h > tmp-modes.h /bin/sh: line 1: 57353 Segmentation fault build/genmodes -h > tmp-modes.h make[3]: *** [s-modes-h] Error 139 make[3]: Leaving directory `/home/seurer/gcc/build/gcc-test2/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/home/seurer/gcc/build/gcc-test2' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/home/seurer/gcc/build/gcc-test2' make: *** [all] Error 2 make[3]: Entering directory `/home/seurer/gcc/build/gcc-test2/gcc' /home/seurer/gcc/build/gcc-test2/./prev-gcc/xg++ -B/home/seurer/gcc/build/gcc-test2/./prev-gcc/ -B/home/seurer/gcc/install/gcc-test2/powerpc64-unknown-linux-gnu/bin/ -nostdinc++ -B/home/seurer/gcc/build/gcc-test2/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs -B/home/seurer/gcc/build/gcc-test2/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -I/home/seurer/gcc/build/gcc-test2/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu -I/home/seurer/gcc/build/gcc-test2/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/include -I/home/seurer/gcc/gcc-test2/libstdc++-v3/libsupc++ -L/home/seurer/gcc/build/gcc-test2/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/seurer/gcc/build/gcc-test2/prev-powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -g -O2 -fno-checking -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -DGENERATOR_FILE -fno-PIE -static-libstdc++ -static-libgcc -no-pie -o build/genmodes \ build/genmodes.o build/errors.o .././libiberty/libiberty.a build/genmodes -h > tmp-modes.h /bin/sh: line 1: 57353 Segmentation fault build/genmodes -h > tmp-modes.h make[3]: *** [s-modes-h] Error 139 make[3]: Leaving directory `/home/seurer/gcc/build/gcc-test2/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/home/seurer/gcc/build/gcc-test2' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/home/seurer/gcc/build/gcc-test2' make: *** [all] Error 2
[Bug bootstrap/92585] [10 regression] r278411 breaks bootstrap
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92585 seurer at gcc dot gnu.org changed: What|Removed |Added Target||powerpc64*-linux-gnu CC||rsandifo at gcc dot gnu.org Host||powerpc64*-linux-gnu Build||powerpc64*-linux-gnu --- Comment #1 from seurer at gcc dot gnu.org --- Breaking revision info: r278411 | rsandifo | 2019-11-18 09:29:03 -0600 (Mon, 18 Nov 2019) | 42 lines Two RTL CC tweaks for SVE pmore/plast conditions SVE has two composite conditions: pmore == at least one bit set && last bit clear plast == no bits set || last bit set So in general we generate them from: A: CC = test bits B: reg1 = first condition C: CC = test bits D: reg2 = second condition E: result = (reg1 op reg2) where op is || or && To fold all this into a single test, we need to be able to remove the redundant C (the cse.c patch) and then fold B, D and E down to a single condition (the simplify-rtx.c patch). The underlying conditions are unsigned, so the simplify-rtx.c part needs to support both unsigned comparisons and AND. However, to avoid opening the can of worms that is ANDing FP comparisons for unordered inputs, I've restricted the new AND handling to cases in which NaNs can be ignored. I think this is still a strict extension of what we have now, it just doesn't go as far as it could. Going further would need an entirely different set of testcases so I think would make more sense as separate work. 2019-11-18 Richard Sandiford gcc/ * cse.c (cse_insn): Delete no-op register moves too. * simplify-rtx.c (comparison_to_mask): Handle unsigned comparisons. Take a second comparison to control the value for NE. (mask_to_comparison): Handle unsigned comparisons. (simplify_logical_relational_operation): Likewise. Update call to comparison_to_mask. Handle AND if !HONOR_NANs. (simplify_binary_operation_1): Call the above for AND too. gcc/testsuite/ * gcc.target/aarch64/sve/acle/asm/ptest_pmore.c: New test.
[Bug target/79262] [8/9/10 Regression] load gap with store gap causing performance regression in 462.libquantum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79262 --- Comment #8 from Wilco --- Author: wilco Date: Tue Nov 19 15:57:54 2019 New Revision: 278452 URL: https://gcc.gnu.org/viewcvs?rev=278452&root=gcc&view=rev Log: [AArch64] PR79262: Adjust vector cost PR79262 has been fixed for almost all AArch64 cpus, however the example is still vectorized in a few cases, resulting in lower performance. Adjust the vector cost slightly so that so that -mcpu=cortex-a53 now has identical performance as -mcpu=cortex-a57 on libquantum. gcc/ PR target/79262 * config/aarch64/aarch64.c (generic_vector_cost): Adjust vec_to_scalar_cost. Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.c
[Bug middle-end/90840] [8/9/10 Regression] ICE in simplify_subreg, at simplify-rtx.c:6441
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90840 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 47299 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47299&action=edit gcc10-pr90840.patch Untested fix.
[Bug target/92578] [i386] cmov not generated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92578 --- Comment #2 from Uroš Bizjak --- (In reply to Richard Biener from comment #1) > With newcnt-=2 you get > > movl%edx, %r8d > movl%esi, %eax > leal-2(%rsi), %edx > cmpl%r8d, %edi > cmove %edx, %eax > ret > > so it's if-conversions preference to generate setCC which I'm not sure is > really worse here, is it? We're saving a zero extend and some reg-reg moves. This if-conversion is intentional, since cmove needs well predicted comparison, which is not always the case. > I'm sure we have a duplicate report about this. PR 79389 shows devastating SciMark2.0 results with cmove for random values of compare operands. Related to PR 56309.
[Bug c++/90842] [8/9/10 Regression] ICE in poplevel, at cp/decl.c:585
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90842 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 47300 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47300&action=edit gcc10-pr90842.patch Untested fix.
[Bug c++/67228] Template partial ordering failure ambiguous overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67228
Alisdair Meredith changed:
What|Removed |Added
CC||alisdairm at me dot com
--- Comment #1 from Alisdair Meredith ---
Finally tracked down a simple reproducer from our own code base, that looks
simpler to run into (we have had a gcc specific workaround for years, but
apparently never filed a bugzilla report):
template
T make(A, Args&&...) { return {}; }
template
T make(A*, Args&&...) { return {}; }
int main() {
int * p = 0;
auto x = make(p, 1);
}
Reproducible on every gcc available on Compiler Explorer, including trunk. All
other C++11 compilers pass this test.
The ambiguity goes away if I remove the parameter pack argument at the call
site (i.e., deduce an empty pack).
[Bug target/79262] [8/9/10 Regression] load gap with store gap causing performance regression in 462.libquantum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79262 Wilco changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from Wilco --- libquantum perf is now the same between Cortex-A53 and A57.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 79262, which changed state. Bug 79262 Summary: [8/9/10 Regression] load gap with store gap causing performance regression in 462.libquantum https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79262 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/67228] Template partial ordering failure ambiguous overload
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67228 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-19 Ever confirmed|0 |1
[Bug target/90867] [8/9/10 Regression] Multiplication or typecast of integer and double always zero when...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90867
Jakub Jelinek changed:
What|Removed |Added
CC||hjl.tools at gmail dot com,
||jakub at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
Started with r228967.
Adjusted testcase because using target attribute on main is a little bit weird:
unsigned long long freq = 36UL; /* 3.6 GHz = 3600.0 MHz */
__attribute__ ((target ("arch=x86-64"))) int
foo ()
{
__builtin_printf ("freq = %f Hz\n", (double)freq);
__builtin_printf ("freq = %f kHz\n", 1e-3 * freq);
__builtin_printf ("freq = %f MHz\n", 1e-6 * freq);
__builtin_printf ("freq = %f GHz\n", 1e-9 * freq);
return 0;
}
int
main ()
{
return foo ();
}
[Bug target/90867] [8/9/10 Regression] Multiplication or typecast of integer and double always zero when...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90867 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 47301 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47301&action=edit gcc10-pr90867.patch Untested fix.
[Bug c/90898] [8/9/10 Regression] ICE in insert_clobber_before_stack_restore, at tree-ssa-ccp.c:2112
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90898 --- Comment #3 from Jakub Jelinek --- Created attachment 47302 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47302&action=edit gcc10-pr90898.patch Untested fix.
[Bug debug/90981] [9 Regression] ICE in dwarf2out_finish, at dwarf2out.c:31644
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90981 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Summary|[9/10 Regression] ICE in|[9 Regression] ICE in |dwarf2out_finish, at|dwarf2out_finish, at |dwarf2out.c:31644 |dwarf2out.c:31644 --- Comment #8 from Jakub Jelinek --- So fixed for 10+? Any plans to backport?
[Bug c/66773] sign-compare warning for == and != are pretty useless
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66773
--- Comment #8 from Segher Boessenkool ---
int f0(void) { return 0x == -1; }
int f1(unsigned x) { return x == -1; }
int f2(int y) { return 0x == y; }
int f3(unsigned x, int y) { return x == y; }
All of them warn the same, and that is good, imo.
[Bug fortran/92586] New: ICE in gimplify_expr, at gimplify.c:13479 with nested allocatable derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92586 Bug ID: 92586 Summary: ICE in gimplify_expr, at gimplify.c:13479 with nested allocatable derived types Product: gcc Version: 9.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: epagone at email dot it Target Milestone: --- Created attachment 47303 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47303&action=edit internal compiler error: in gimplify_expr, at gimplify.c:13479 The attached code exposes an ICE: $ gfortran-9 -Wall -Wextra gimplify_expr_bug.f90 -lstringifor gimplify_expr_bug.f90:31:0: 31 | data_get_foo_s = self%foo(ith)%get_s() | internal compiler error: in gimplify_expr, at gimplify.c:13479 Please submit a full bug report, with preprocessed source if appropriate. See for instructions. $ gfortran-9 -v Using built-in specs. COLLECT_GCC=gfortran-9 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:hsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 9.2.1-17ubuntu1~18.04.1' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-9 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none,hsa --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 9.2.1 20191102 (Ubuntu 9.2.1-17ubuntu1~18.04.1) I apologise if my MWE has not been reduced further and uses the open source library StringiFor (https://github.com/szaghi/StringiFor), but it took me already a lot of time to reduce it to the present form from the original case.
[Bug c++/91073] [9/10 Regression] if constexpr no longer works directly with Concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91073 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek --- Perhaps more important now that -fconcepts is enabled automatically with -std=c++2a.
[Bug fortran/92587] New: Compiler is unable to generate finalization wrapper
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92587 Bug ID: 92587 Summary: Compiler is unable to generate finalization wrapper Product: gcc Version: 9.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: liakhdi at ornl dot gov Target Milestone: --- Created attachment 47304 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47304&action=edit Complete reproducer of the reported ICE There is a regression ICE introduced in gfortran/9.x (all versions up to 9.2.0 produce this ICE). The compiler reports ICE in generate_finalization_wrapper (see below). The complete reproducer is attached (please run make.sh to build it). I could not reduce it yet to a single small source file as stripping things off makes the ICE disappear, so I apologize for supplying multiple source files. Importantly this code compiles fine with gfortran/8.x, so this ICE was introduced in gfortran/9 very early, when gfortran/9 was not yet released. My system is Ubuntu 16.04 with the gcc/9.2.0 release installed from source. gfortran -c -g tensor_recursive.F90 f951: internal compiler error: in generate_finalization_wrapper, at fortran/class.c:2009 0x588c29 generate_finalization_wrapper /home/dima/src/gcc-9.2.0/gcc/fortran/class.c:2009 0x588c29 gfc_find_derived_vtab(gfc_symbol*) /home/dima/src/gcc-9.2.0/gcc/fortran/class.c:2484 0x5e1891 gfc_find_vtab(gfc_typespec*) /home/dima/src/gcc-9.2.0/gcc/fortran/class.c:2865 0x5e1891 gfc_find_vtab(gfc_typespec*) /home/dima/src/gcc-9.2.0/gcc/fortran/class.c:2855 0x62f9b2 gfc_match_assignment() /home/dima/src/gcc-9.2.0/gcc/fortran/match.c:1378 0x64f3f4 match_word /home/dima/src/gcc-9.2.0/gcc/fortran/parse.c:65 0x64f3f4 decode_statement /home/dima/src/gcc-9.2.0/gcc/fortran/parse.c:361 0x652f24 next_free /home/dima/src/gcc-9.2.0/gcc/fortran/parse.c:1241 0x652f24 next_statement /home/dima/src/gcc-9.2.0/gcc/fortran/parse.c:1473 0x655a89 parse_executable /home/dima/src/gcc-9.2.0/gcc/fortran/parse.c:5436 0x6563a1 parse_if_block /home/dima/src/gcc-9.2.0/gcc/fortran/parse.c:4079 0x6563a1 parse_executable /home/dima/src/gcc-9.2.0/gcc/fortran/parse.c:5329 0x6563a1 parse_if_block /home/dima/src/gcc-9.2.0/gcc/fortran/parse.c:4079 0x6563a1 parse_executable /home/dima/src/gcc-9.2.0/gcc/fortran/parse.c:5329 0x656e06 parse_progunit /home/dima/src/gcc-9.2.0/gcc/fortran/parse.c:5706 0x65715e parse_contained /home/dima/src/gcc-9.2.0/gcc/fortran/parse.c:5581 0x657e5e parse_module /home/dima/src/gcc-9.2.0/gcc/fortran/parse.c:5953 0x6582ad gfc_parse_file() /home/dima/src/gcc-9.2.0/gcc/fortran/parse.c:6256 0x6a170f gfc_be_parse_file /home/dima/src/gcc-9.2.0/gcc/fortran/f95-lang.c:204 Thanks, Dmitry
[Bug c++/91165] [10 Regression] error: location references block not in block tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91165 Martin Liška changed: What|Removed |Added Priority|P3 |P1 --- Comment #4 from Martin Liška --- I can confirm that it breaks shaderc package. @Jason: Can you please take a look?
[Bug c++/91165] [10 Regression] error: location references block not in block tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91165
--- Comment #5 from Martin Liška ---
My reduced test-case is probably very similar:
template constexpr _Tp forward(_Tp p1) { return p1; }
template struct A {
_T1 first;
_T2 second;
constexpr A(_T1 p1, _T2 p2) : first(p1), second(p2) {}
};
template
constexpr A<_T1, _T2> make_pair(_T1 &&p1, _T2 p2) {
return A<_T1, _T2>(forward(p1), forward(p2));
}
typedef enum { EShLangCount } EShLanguage;
class B {
A m_fn1() const;
};
const int a = 0;
void DecodeLineDirective() { make_pair(a, ""); }
A B::m_fn1() const { make_pair(EShLangCount, ""); }
[Bug lto/92588] New: [10 Regression] ICE nodes with unreleased memory found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92588 Bug ID: 92588 Summary: [10 Regression] ICE nodes with unreleased memory found Product: gcc Version: 9.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: marxin at gcc dot gnu.org Target Milestone: --- I see the following ICE in openssl package: $ gcc fips_rsagtest.o libssl.a libcrypto.a dh_pmeth.c:304:12: warning: type of ‘dsa_builtin_paramgen’ does not match original declaration [-Wlto-type-mismatch] dsa_gen.c:142:5: note: type mismatch in parameter 10 dsa_gen.c:142:5: note: ‘dsa_builtin_paramgen’ was previously declared here dsa_gen.c:142:5: note: code may be misoptimized unless ‘-fno-strict-aliasing’ is used cryptlib.c:656:21: warning: type of ‘OPENSSL_ia32cap_P’ does not match original declaration [-Wlto-type-mismatch] fips.c:412:33: note: array types have different bounds fips.c:412:33: note: ‘OPENSSL_ia32cap_P’ was previously declared here In function ‘memcpy’, inlined from ‘RSA_eay_public_decrypt’ at rsa_eay.c:754:9: /usr/include/bits/string_fortified.h:34:10: warning: ‘__builtin_memcpy’ specified bound 18446744073709551615 exceeds maximum object size 9223372036854775807 [-Wstringop-overflow=] 34 | return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest)); | ^ OPENSSL_init_library/47123 (OPENSSL_init_library) @0x7f9423afc580 Type: function definition Visibility: visibility_specified visibility:hidden artificial constructor References: Referring: Read from file: /tmp/ccIpL02r.ltrans8.o Availability: not_available Function flags: count:158289380 (estimated locally) body local static_constructor (priority:65535) executed_once Called by: Calls: OPENSSL_init_library/48240 (OPENSSL_init_library) @0x7f9423af56e0 Type: function definition Visibility: visibility_specified visibility:hidden artificial constructor References: Referring: Read from file: /tmp/ccIpL02r.ltrans8.o Clone of OPENSSL_init_library/47123 Availability: not_available Function flags: count:334850 (estimated locally) body local static_constructor (priority:65535) executed_once Called by: Calls: lto1: internal compiler error: nodes with unreleased memory found 0x894911 symbol_table::compile() /home/marxin/Programming/gcc/gcc/cgraphunit.c:2717 0x7f2539 lto_main() /home/marxin/Programming/gcc/gcc/lto/lto.c:657 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <https://gcc.gnu.org/bugs/> for instructions. lto-wrapper: fatal error: gcc returned 1 exit status compilation terminated. /usr/bin/ld: error: lto-wrapper failed collect2: error: ld returned 1 exit status I'm sending LTO bytecode as it's too many files one needs: https://drive.google.com/file/d/1Rd5OIekl9To5tT0Duw5mXNX4BzJ3kBVg/view?usp=sharing GCC compiler version needed: Supported LTO compression algorithms: zlib zstd gcc version 10.0.0 20191119 (experimental) (SUSE Linux)
[Bug lto/92588] [10 Regression] ICE nodes with unreleased memory found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92588 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-11-19 Known to work||9.2.0 Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||10.0 --- Comment #1 from Martin Liška --- @Honza: Can you please take a look?
[Bug lto/92588] [10 Regression] ICE nodes with unreleased memory found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92588 Martin Liška changed: What|Removed |Added Keywords||needs-bisection, ||needs-reduction Version|9.0 |10.0 Target Milestone|--- |10.0
[Bug c++/92439] [concepts] trunk crashes on constraint satisfaction failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92439
--- Comment #2 from Dimitri Gorokhovik ---
Hi Andrew,
could the diagnostics in your patch be further improved?
For example, in this invalid code:
template constexpr bool r () { return true; };
template
requires r ()
constexpr inline static const unsigned s = true;
The error messages are:
test-2.cpp:39:10: error: constraint expression does not have type ‘bool’
39 | requires r ()
| ^
test-2.cpp:39:21: error: expected unqualified-id before ‘)’ token
39 | requires r ()
| ^
which is misleading: r () does have 'bool' type. Instead, it does not
form a valid primary expression. Maybe something could be done about reporting
it specifically as such?
[Bug target/92566] rs6000_preferred_simd_mode isn't very good
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92566 --- Comment #3 from Segher Boessenkool --- It should do something like if (!VECTOR_UNIT_NONE_P (V2DImode)) return V2DImode; and similar for all existing entries. Putting the same conditionals in multiple places is prone to error, as this PR shows.
[Bug c++/91073] [9/10 Regression] if constexpr no longer works directly with Concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91073 --- Comment #5 from Paolo Carlini --- You are right.
[Bug c++/92583] internal compiler error: in tsubst_copy, at cp/pt.c:15552
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92583 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-19 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug c++/92414] [10 Regression] internal compiler error: tree check: expected constructor, have error_mark in cxx_eval_store_expression, at cp/constexpr.c:4009
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92414 --- Comment #3 from Jakub Jelinek --- Author: jakub Date: Tue Nov 19 21:28:22 2019 New Revision: 278468 URL: https://gcc.gnu.org/viewcvs?rev=278468&root=gcc&view=rev Log: PR c++/92414 * constexpr.c (cxx_eval_outermost_constant_expr): If DECL_INITIAL on object is erroneous, return t without trying to evaluate a constexpr dtor. * g++.dg/cpp2a/constexpr-dtor4.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-dtor4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/constexpr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/92569] gfortran read with end directive does not trigger in gfortran 9.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92569 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2019-11-19 Ever confirmed|0 |1 --- Comment #2 from anlauf at gcc dot gnu.org --- Cannot confirm this on Linux with gcc-7 to 10-trunk. Maybe the problem is specific to your OS or distribution?
[Bug c++/91073] [9/10 Regression] if constexpr no longer works directly with Concepts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91073 Jonathan Wakely changed: What|Removed |Added Last reconfirmed|2019-07-03 00:00:00 |2019-11-19 --- Comment #6 from Jonathan Wakely --- N.B. the summary "if constexpr no longer works directly with Concepts" is not true in general. I'm using concepts with if-constexpr extensively in libstdc++ code e.g. https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/bits/range_access.h;h=de074460c16189f29fd2d0b31c81e2231843d2a8;hb=HEAD#l402 The bug only seems to happen when the concept is variadic.
[Bug target/86011] Inefficient code generated for ldivmod with constant value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86011 Patrick Oppenlander changed: What|Removed |Added Version|8.1.0 |9.2.0 --- Comment #3 from Patrick Oppenlander --- Still present in 9.2.0.
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 92320, which changed state. Bug 92320 Summary: Constexpr function pointer derived from lambda is not accepted as template parameter https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92320 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/54367] [meta-bug] lambda expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 Bug 54367 depends on bug 92320, which changed state. Bug 92320 Summary: Constexpr function pointer derived from lambda is not accepted as template parameter https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92320 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/83258] Rejecting function pointer non-type template parameter without linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83258 Eric Gallager changed: What|Removed |Added CC||jleahy+gcc at gmail dot com --- Comment #6 from Eric Gallager --- *** Bug 92320 has been marked as a duplicate of this bug. ***
[Bug c++/92320] Constexpr function pointer derived from lambda is not accepted as template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92320 Eric Gallager changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Eric Gallager --- (In reply to S. Davis Herring from comment #1) > This is a duplicate of PR 83258. OK, closing as such. *** This bug has been marked as a duplicate of bug 83258 ***
