[Bug c++/109018] decltype of dependent expressions lookup should be done only when doing template function definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109018
--- Comment #8 from qingzhe huang ---
I gdb a little bit and I feel this issue is fixable. See the comparison of
"unq" and "function" below is not compatible because "function" is
"IDENTIFIER_NODE" and "unq" is "VIEW_CONVERT_EXPR". If we check and convert
"unq", we will find they are matching.
(gdb) info b
Num Type Disp Enb AddressWhat
1 breakpoint keep y 0x00d0bafc in
tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool, bool) at
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/pt.cc:20608
breakpoint already hit 1 time
(gdb) l 20608
20603 (function, args, complain, in_decl, true,
20604integral_constant_expression_p));
20605 if (unq == error_mark_node)
20606 RETURN (error_mark_node);
20607
20608 if (unq != function)
20609 {
20610 char const *const msg
20611 = G_("%qD was not declared in this scope, "
20612 "and no declarations were found by "
(gdb) p IDENTIFIER_POINTER(function)
$16 = 0x770c42c0 "g"
(gdb) p IDENTIFIER_POINTER(DECL_NAME(TREE_OPERAND(unq,0)))
$17 = 0x770c42c0 "g"
(gdb) p TREE_CODE(function)
$18 = IDENTIFIER_NODE
(gdb) p TREE_CODE(unq)
$19 = VIEW_CONVERT_EXPR
(gdb)
[Bug c++/109018] decltype of dependent expressions lookup should be done only when doing template function definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109018 --- Comment #7 from qingzhe huang --- I find another argument from decltype in cppreference (https://en.cppreference.com/w/cpp/language/decltype#Explanation) quote: Because no temporary object is created, the type need not be complete or have an available destructor, and can be abstract. This rule doesn't apply to sub-expressions: in decltype(f(g())), g() must have a complete type, but f() need not. Does this mean that here "f" needs not be available when "g" is int which is always complete? So, in our example the function "g" (aka "f" here) needs not be available.
[Bug c++/109018] decltype of dependent expressions lookup should be done only when doing template function definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109018 --- Comment #6 from qingzhe huang --- I agree "Note g can be still found after the declaration via argument dependent lookup." Can we view this issue from a different angle? The real work of parsing should be started at "template function definition". So, if the "template function declaration" is invalid because of "scope" of "g", then the "valid" definition DOES NOT belong to the "invalid" declaration. i.e. There are tons of invalid declaration are discarded as they are not required for template function instantiation.
[Bug c++/109018] decltype of dependent expressions lookup should be done only when doing template function definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109018
qingzhe huang changed:
What|Removed |Added
Resolution|INVALID |FIXED
CC||nickhuang99 at hotmail dot com
--- Comment #4 from qingzhe huang ---
Thank you for your detailed explanation and really appreciate it.
My only pleading argument is that the root cause of error is from GCC cannot
find correct prototype in "template declaration" which is __NOT__ mandatory for
template definition.
For example, if I commented out the invalid template function declaration, the
parser works without issue. (https://www.godbolt.org/z/1qnTnrE1Y). So, my
argument is that GCC report error due to something which is not always
necessary. Why cannot parser postpone reporting when actually template
definition starts? Even there is not declaration, definition has all
information to work.
This will pass compilation if template declaration is commented:
// template
// decltype(g(T())) h(); // decltype(g(T())) is a dependent type
int g(int);
template
decltype(g(T())) h()
{ // redeclaration of h() uses earlier lookup
return g(T()); // although the lookup here does find g(int)
}
int i = h(); // template argument substitution fails; g(int)
// was not in scope at the first declaration of h()
[Bug c++/109018] New: decltype of dependent expressions lookup should be done only when doing template function definition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109018
Bug ID: 109018
Summary: decltype of dependent expressions lookup should be
done only when doing template function definition
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
In
cppreference.com(https://en.cppreference.com/w/cpp/language/function_template#Function_template_overloading)
gives this example about dependent expression lookup issue. However, it turns
out only GCC has this parsing issue. Both clang and MSVC can solve this with no
issue.(https://www.godbolt.org/z/9anx871rr)
template
decltype(g(T())) h(); // decltype(g(T())) is a dependent type
int g(int);
template
decltype(g(T())) h()
{ // redeclaration of h() uses earlier lookup
return g(T()); // although the lookup here does find g(int)
}
int i = h(); // template argument substitution fails; g(int)
// was not in scope at the first declaration of h()
[Bug c++/104699] zero-length-array is not considered as an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104699 --- Comment #6 from qingzhe huang --- Really appreciate the detailed explanation! Very clear and completely convinced.
[Bug c++/104706] New: make_unique cannot create struct of size of 0 due to default_delete's static_assert failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104706
Bug ID: 104706
Summary: make_unique cannot create struct of size of 0 due to
default_delete's static_assert failure
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
See code in compiler explorer: https://www.godbolt.org/z/cb8973Ys1
struct of size of 0 does have its usage and it is supported by GNU C
(https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html). However, make_unique
makes it impossible to create such an unique_ptr because its default_delete
requires "A" must have non-zero size.
struct A{
alignas(int[0]) int ptr[0];
};
void test(){
unique_ptr ptr=make_unique();
}
error: static assertion failed: can't delete pointer to incomplete type
83 | static_assert(sizeof(_Tp)>0,
| ~~~^~
I am not arguing that static_assert is reasonable. My point is that
"make_shared" can actually deal this properly. i.e.
shared_ptr ptr=make_shared();
gives no error at all.
[Bug c++/104699] zero-length-array is not considered as an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104699
qingzhe huang changed:
What|Removed |Added
CC||nickhuang99 at hotmail dot com
--- Comment #2 from qingzhe huang ---
(In reply to Jonathan Wakely from comment #1)
> It says GNU C, not C++. But in any case, that example works fine for me, as
> does the simpler:
>
> template struct S { };
> S s;
>
> Please provide the info you were asked to provide by https://gcc.gnu.org/bugs
https://www.godbolt.org/z/8xa1dTzdM
#include
static_assert( ! std::is_array::value);
And as a directly result, it causes "make_shared" fails with "int[0]"
https://www.godbolt.org/z/8nE6qojaE
shared_ptr ptr=make_shared();
...
error: request for member '~int [0]' in '* __location', which is of non-class
type 'int [0]'
88 | __location->~_Tp();
| ~^~~
This is the direct result of template specialization "is_array" is
ill-format code or something.
[Bug c++/104699] New: zero-length-array is not considered as an array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104699 Bug ID: 104699 Summary: zero-length-array is not considered as an array Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nickhuang99 at hotmail dot com Target Milestone: --- GCC clearly states that "declaring zero-length arrays is allowed in GNU C as an extension". https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html However, parser rejects to recognize int[0] as an array. i.e. static_assert(! std::is_array::value); This is not an issue of library function "is_array". Instead it is the specialization of "is_array" which is not considered valid.
[Bug c++/104568] New: ICE [regression c++20] caused by option "-std=c++20 -Wall" when operand of operator new has size equal to 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104568
Bug ID: 104568
Summary: ICE [regression c++20] caused by option "-std=c++20
-Wall" when operand of operator new has size equal to
0
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
See the following program causes ICE with flag ONLY of "-std=c++20 -Wall" which
proves it to be a regression of c++20.
The root cause is very simple that "std::default_delete" has a static_assert to
require element size pointed by pointer to be bigger than 0. A empty array of
"int[0]" violates this assertion, all other flag gives the correct root cause
without crash. However, "-std=c++20 -Wall" option issues very confusing error
message "Floating point exception" and crashes.
#include
using namespace std;
typedef int Ary0[0];
int main(){
unique_ptr ptr;
ptr.reset(new Ary0[0]);
return 0;
}
tests/unique.cpp: In function ‘int main()’:
tests/unique.cpp:7:18: internal compiler error: Floating point exception
7 | ptr.reset(new Ary0[0]);
| ~^
0x1522a90 crash_signal
/home/nick/Downloads/gcc-dev/gcc/gcc/toplev.cc:322
0xbd4829 build_new_constexpr_heap_type(tree_node*, tree_node*, tree_node*)
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/init.cc:2944
0xb2f837 cxx_eval_constant_expression
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/constexpr.cc:7262
0xb2f1cf cxx_eval_constant_expression
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/constexpr.cc:7147
0xb30dd1 cxx_eval_outermost_constant_expr
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/constexpr.cc:7700
0xb319d2 maybe_constant_value(tree_node*, tree_node*, bool)
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/constexpr.cc:7990
0xbcbd84 fold_for_warn(tree_node*)
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/expr.cc:416
0xddaed6 check_function_restrict
/home/nick/Downloads/gcc-dev/gcc/gcc/c-family/c-common.cc:5704
0xddc1d9 check_function_arguments(unsigned int, tree_node const*, tree_node
const*, int, tree_node**, vec*)
/home/nick/Downloads/gcc-dev/gcc/gcc/c-family/c-common.cc:6091
0xaf16fe build_over_call
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/call.cc:9662
0xaf5a03 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/call.cc:11146
0xc70cd6 cp_parser_postfix_expression
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/parser.cc:7844
0xc73625 cp_parser_unary_expression
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/parser.cc:9033
0xc74c64 cp_parser_cast_expression
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/parser.cc:9937
0xc74d82 cp_parser_binary_expression
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/parser.cc:10039
0xc75b61 cp_parser_assignment_expression
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/parser.cc:10343
0xc75ec3 cp_parser_expression
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/parser.cc:10513
0xc7adb5 cp_parser_expression_statement
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/parser.cc:12709
0xc7a795 cp_parser_statement
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/parser.cc:12505
0xc7b23c cp_parser_statement_seq_opt
/home/nick/Downloads/gcc-dev/gcc/gcc/cp/parser.cc:12854
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c++/104548] New: parser rejects alias template id of lambda in unevaluated-context and accepts when no alias is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104548
Bug ID: 104548
Summary: parser rejects alias template id of lambda in
unevaluated-context and accepts when no alias is used
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
I feel this issue is related with PR104537 and PR104358
Parser rejects following code with alias of template id:
https://www.godbolt.org/z/eec3T5ebj
template
using FunPtr=decltype(+[](T t)->T{return t+1;});
template
auto foo(T t, FunPtr funPtr){
return funPtr(t);
}
void test(){
// parser rejects when using alias
foo(5, [](int t){return t+1;});
}
:14:21: error: invalid user-defined conversion from
'test()::' to 'int' [-fpermissive]
14 | foo(5, [](int t){return t+1;});
| ^~
And accepts exact same code when NO alias is used:
template
auto foo(T t, decltype(+[](T t)->T{return t+1;}) lam){
return lam(t);
}
void test(){
// parser accepts when no alias is used
foo(5, [](int t){return t+1;});
}
[Bug c++/104537] New: ICE when generic-lambda as function parameter fails to be converted to pointer to function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104537
Bug ID: 104537
Summary: ICE when generic-lambda as function parameter fails to
be converted to pointer to function
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
Consider this invalid conversion for this generic-lambda to pointer to function
which is defined by "decltype(+[](T&& t )->T{return t+1;}".
This ICE happens when original accepted parameter type changed from "T" to
"T&&".
See compiler explorer (https://www.godbolt.org/z/fde1bc3zE)
I suspect this is some related issue with another unconfirmed case PR104358.
template
auto foo(T&& t, decltype(+[](T&& t )->T{return t+1;}) lam){
return lam(t);
}
void test(){
foo(5, [](int t){return t+1;});
}
:8:21: error: invalid user-defined conversion from
'test()::' to 'int (*)(int&&)' [-fpermissive]
8 | foo(5, [](int t){return t+1;});
| ^~
...
internal compiler error: error reporting routines re-entered.
0x2174365 warning_at(unsigned int, int, char const*, ...)
...
[Bug c++/104358] Assignable template lambda as function parameter is incorrectly reduced to type of "int"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104358
--- Comment #2 from qingzhe huang ---
Here are more tests (https://www.godbolt.org/z/5qc8jTGa8) to show that only
msvc is giving the correct result.
It just illustrates the use cases of this definition and why it should be
allowed.
1. By using operator "+", here the type "Lambda" is just a free function
pointer.
template
using Lambda=decltype(+[](T){});
static_assert(is_same_v, void(*)(int)>);
2. The "foo" takes "Lambda" as parameter
template
T foo(T&&, Lambda);
3. As "Lambda" is just a function pointer, "foo" should allow both free
function pointer or lambda(by conversion operator) to be used as argument. And
because GCC mistakenly consider "foo" signature as "int(*)(int&&,
/*Lambda*/int)", this is not possible.
static_assert(is_same_v), int(*)(int&&, int)>);
These are use cases for "foo":
a) using lambda directly
foo(5, [](int n){});// lambda conversion operator!
b) using converted function pointer from lambda by operator "+"
auto funptr=+[](int n){};
foo(5, funptr);
c) directly using a function pointer
void(*ptr)(int)=funptr;
foo(5, ptr);
[Bug c++/104358] Assignable template lambda as function parameter is incorrectly reduced to type of "int"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104358
--- Comment #1 from qingzhe huang ---
Sorry about the long description and here is the short version to highlight the
core issue. Given this template function with a templated lambda as parameter:
template
using Lambda=decltype(+[](T){});
template
auto foo(T&&, Lambda)->T;
GCC considers the parameter "Lambda" as type "int" which is wrong:
static_assert(is_same_v),
int(*)(int&&, /*"Lambda"*/ int)>);
[Bug c++/104319] better error message for parsing error when >= or >> ends a template variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104319
--- Comment #10 from qingzhe huang ---
Here I have another test case. It involves an anonymous template argument which
confuses me for a lot at the time which clang is doing a great job to clarify
the reason for me.
https://www.godbolt.org/z/YGfMncGeW
template ::value,
bool>=true //there should be a space in ">="
>
struct TestStruct{};
[Bug c++/104319] better error message for parsing error when >= or >> ends a template variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104319 --- Comment #6 from qingzhe huang --- But clang can give similar clear message by pointing out the space. Just like ">>" instead "> >" after c++98, I think GCC can do better to recognize ">>=" is possible of "> >=". Just considering even though ">>" is one token, still parser now consider the case of ">" and ">" as to two closing brackets for two nested templates. My point is that even though ">>=" is one token, it doesn't prevent parser from splitting the token into possible two tokens. Not always the longest match algorithms in tokenization. My suggestion is that how about we calculate all possible superset of all other operators. For example, ">>=" is equivalent to ">" and ">=". Or ">>" and "=". there are tokens who is using longest match to return only the longest ones. It is just my naive thought.
[Bug c++/104358] New: Assignable template lambda as function parameter is incorrectly reduced to type of "int"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104358
Bug ID: 104358
Summary: Assignable template lambda as function parameter is
incorrectly reduced to type of "int"
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
Please see code at https://www.godbolt.org/z/o3bxxsYPK
All other compilers parses this correctly.
#include
#include
using namespace std;
//1. I have a callback which happens to be an assignable lambda
template
using Lambda=decltype(+[](T){});
// which is esstially a function pointer
static_assert(is_same_v, void(*)(int)>);
//2. Here is my data handle function which takes a data and the callback
template
auto foo(T&&, Lambda)->T;
//3. However, parser consider the callback as type of "int"
static_assert( ! is_same_v), int(*)(int&&, void(*)(int))>);
// lambda type is always considered as "int"
static_assert(is_same_v), int(*)(int&&, int)>);
static_assert(is_same_v), bool(*)(bool&&, int)>);
// this is impossible as callback CANNOT be "int"
static_assert( ! is_same_v, int>);
//4. This won't happen for a traditional function pointer
template
using FunPtr=void(*)(T);
static_assert(is_same_v, void(*)(int)>);
//5. let's define a similar function with callback
template
auto bar(T&&, FunPtr)->T;
// there is no way for parser to consider callback as type of "int"
static_assert(is_same_v), int(*)(int&&, void(*)(int))>);
[Bug c++/104319] better error message for parsing error when >= ends a template variable.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104319 --- Comment #2 from qingzhe huang --- A slightly different case with operator ">=" after template-id causing identical error message is: https://www.godbolt.org/z/7ajvfM4rb #include template constexpr std::size_t zero=0; template constexpr bool Bool=zero>=0; :7:21: error: parse error in template argument list 7 | constexpr bool Bool=zero>=0; | ^~ Compiler returned: 1
[Bug c++/104319] New: "parse error of template argument list" due to missing space in ">==", a better error message should be given
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104319
Bug ID: 104319
Summary: "parse error of template argument list" due to missing
space in ">==", a better error message should be given
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
consider following code (https://www.godbolt.org/z/4drb17Pqn):
template
struct A{
constexpr static int value=0;
};
template
constexpr int Zero=A::value;
static_assert(Zero==0);
:8:15: error: parse error in template argument list
8 | static_assert(Zero==0);
| ^~~~
:8:15: error: template argument 1 is invalid
Compiler returned: 1
clang gives much clear reason:
error: a space is required between a right angle bracket and an equals sign
(use '> =')
static_assert(Zero==0);
^~
> =
clearly "Zero" can be considered template id to avoid template argument
list error message.
[Bug c++/104255] parsing function signature fails when it uses a function parameter outside of an unevaluated context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104255 --- Comment #4 from qingzhe huang --- (In reply to Patrick Palka from comment #2) > > error: use of parameter outside function body before ‘)’ token > > due to 'e' being used outside of an unevaluated context within the signature > of the function. Sorry for my being unable to grasp your meaning before. Now I can see your point that the "e" of A is from declaration of parameter of function "g". Now that we agree the value from parameter clause should not be used in trailing return type, then it should also not be used in requires clause etc. (https://eel.is/c++draft/basic.scope.param#1.3) But this works: template auto f(int n) requires (n>0); This is violating our assumption. So, I am not convinced that (https://eel.is/c++draft/basic.scope.param#note-1) "A function parameter cannot be used for its value within the parameter-declaration-clause" is really meaningful. Or I misunderstand it??? https://www.godbolt.org/z/759oGdr94
[Bug c++/104255] parsing function signature fails when it uses a function parameter outside of an unevaluated context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104255
--- Comment #3 from qingzhe huang ---
(In reply to Patrick Palka from comment #2)
> The error message is obscure, but it seems what GCC has issue with here is
> the use of the function parameter seq2 in the trailing return type occurring
> outside of an unevaluated context.
>
The error messages are issued in a cascading fashion, the "outside function
parameter" is issued much later which maybe far-fetched from core one, in my
guess.
> I'm not totally sure if the testcase is valid
> (https://eel.is/c++draft/basic.scope.param#note-1 might suggest it's not?),
> but one workaround is to replace the use of seq2 in the trailing return type
> with decltype(seq2){} (which works because index_sequence is an empty type).
This is about "parameter-declaration-clause" which is not our case, because
"f(e)" is not function declaration part, instead an invoking of function of
which "e" is not "declaration" at all, but an argument of function.
> Here's a minimal testcase demonstrating the issue
>
> struct empty { };
> constexpr int f(empty) { return 0; }
> template struct A { };
> auto g(empty e) -> A;
Again, GCC is only one rejecting this code
(https://www.godbolt.org/z/1bvMavKKd) which makes me suspect that GCC may not
be correct.
> which is rejected with
>
> error: use of parameter outside function body before ‘)’ token
>
> due to 'e' being used outside of an unevaluated context within the signature
> of the function.
BTW, this has nothing to do with c++20(no -std=c++20 is needed) which
eliminates potential issues of many c++20 new features. Thank you for your
simplified case which is a much clearer one to demonstrate the core issue.
[Bug c++/104255] parsing trailing return type fails with parameter pack expansion when two parameter packs at present
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104255
--- Comment #1 from qingzhe huang ---
Just a FYI, this version is a bit simplified from this original code.
(https://www.godbolt.org/z/n7ajzr46f) because this is an actual meaningful
function to reverse a given index_sequence. You can see if trailing return type
works, it doesn't need to define the function body so that the template
function works exactly like a meta function.
template
auto get_reverse_sequence_helper(index_sequenceindexes,
index_sequencenumbers)
// If this trailing return type is OK, we don't need actually define
// function body.
->index_sequence< (getSeqByIndex(numbers))... >
{
return index_sequence< (getSeqByIndex(numbers))...
>{};
}
[Bug c++/104255] New: parsing trailing return type fails with parameter pack expansion when two parameter packs at present
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104255
Bug ID: 104255
Summary: parsing trailing return type fails with parameter pack
expansion when two parameter packs at present
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
The following template function causes error when we define trailing return
type which is identical to what function body actual returning
( https://www.godbolt.org/z/n3nbW785o )
template
constexpr size_t identity2(index_sequenceseq){
return N;
}
template
auto getSeq2(index_sequenceseq1, index_sequenceseq2)
// this trailing return type causing parsing error of parameter pack
->index_sequence<(identity2(seq2))...>;
{
return index_sequence<(identity2(seq2))...>{};
}
As a positive example against above, when "identity1" takes no parameter pack
as template argument, it works fine.
template
constexpr size_t identity1(){
return N;
}
template
auto getSeq1(index_sequenceindexes)
// trailing return type works, no need to define function body at all.
->index_sequence<(identity1())...>;
clang13/MSVC all work as expected.
[Bug c++/104113] invalid template argument causes the type to become int which confuses the rest of the diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104113 --- Comment #6 from qingzhe huang --- How about this simple fix? (see the patch above.) Instead of return "error_mark_node" by condition of "!cp_parser_simulate_error", we now report error immediately. The rational of this fix is that "cp_parser_simulate_error" is only making sense when we already see error, i.e. "CP_PARSER_STATUS_KIND_ERROR". Otherwise, we should just report error. I did a full build and check, it seems fine with me. For example, 104091.cpp: In function ‘void g()’: 104091.cpp:8:7: error: ‘auto’ not permitted in template argument 8 | A x = A(); | ^~~~ 104091.cpp:8:13: error: variable ‘A x’ has initializer but incomplete type 8 | A x = A(); | ^ Also I noticed previous testcase (i.e. g++.dg/DRs/dr625.C) is too relaxed with error message by allowing inaccurate "invalid template argument" or "cannot convert ..." instead of "auto not permitted". If this makes sense to you, I am happy to provide more testcases and correct those old testcases.
[Bug c++/104113] invalid template argument causes the type to become int which confuses the rest of the diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104113
--- Comment #5 from qingzhe huang ---
Created attachment 52257
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52257=edit
cp_parser_simulate_error logic
diff --git a/gcc/cp/parser.cc b/gcc/cp/parser.cc
index b262b765a9a..988631a4248 100644
--- a/gcc/cp/parser.cc
+++ b/gcc/cp/parser.cc
@@ -24206,8 +24206,9 @@ cp_parser_type_id_1 (cp_parser *parser, cp_parser_flags
flags,
/* OK */;
else
{
- if (!cp_parser_simulate_error (parser))
- {
+ if (parser->context && parser->context->status ==
CP_PARSER_STATUS_KIND_ERROR
+ && cp_parser_simulate_error (parser))
+ return error_mark_node;
location_t loc = type_specifier_seq.locations[ds_type_spec];
if (tree tmpl = CLASS_PLACEHOLDER_TEMPLATE (auto_node))
{
@@ -24221,8 +24222,6 @@ cp_parser_type_id_1 (cp_parser *parser, cp_parser_flags
flags,
auto_node);
else
error_at (loc, "invalid use of %qT", auto_node);
- }
- return error_mark_node;
}
}
[Bug c++/104138] ICE in is_base_type with lambda is passed as parameter with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104138 --- Comment #2 from qingzhe huang --- Can we remove the phrase "with -g" from subject because it doesn't require to compile with "-g" option? This will help for future subject search.
[Bug c++/104138] New: ICE when lambda is passed as parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104138
Bug ID: 104138
Summary: ICE when lambda is passed as parameter
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
Considering following valid code which compiles with clang13. It defines a
concept to restrict template parameter as type of lambda. Then the concept is
used to constraint class A to have a lambda as constructor parameter. The ICE
happens when a lambda object is passed to constructor of A.
#include
using Lambda=decltype(+[](){});
template
concept IsLambda=std::is_same::value;
template
struct A{
A(L lam){
lam();
}
};
auto lam=+[](){};
auto a=A(lam);
https://www.godbolt.org/z/Pxv95Eb14
[Bug c++/104137] New: ICE when lambda has parameter of decltype of a non-convertable lambda
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104137
Bug ID: 104137
Summary: ICE when lambda has parameter of decltype of a
non-convertable lambda
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
The following lambda has a wrong parameter type of non-convertible lambda and
causes ICE: (with -std=c++20)
void test2(){
// this has wrong type parameter
return [](decltype([](){})){
}([](){});
}
The correct parameter type is convertible lambda and compiling has no issue
void test1(){
// this has correct parameter
return [](decltype(+[](){})){
}([](){});
}
https://www.godbolt.org/z/fbcr16jv4
[Bug c++/104113] New: DR 625 forbids "auto" being used in template argument and parser fails to issue correct error message for it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104113
Bug ID: 104113
Summary: DR 625 forbids "auto" being used in template argument
and parser fails to issue correct error message for it
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
DR 625 forbids "auto" to be used in template argument. And developer has
specific error message for this and fails to issue it for the very case:
(https://www.godbolt.org/z/198fn1jr1)
template struct A {};
template void f(A x) {}
void g()
{
f(A());
A x = A();
}
The error message is very misleading. Note that only the 2nd error message is
parser confirmed error message which is considered as conversion issue instead
of "auto" being forbidden to be in template argument. (The 1st error message is
parser tentative parsing issued.)
: In function 'void g()':
:14:11: error: template argument 1 is invalid
14 | A x = A();
| ^
:14:17: error: cannot convert 'A' to 'int' in initialization
14 | A x = A();
| ^~
| |
| A
And this case can be reduced as
template
struct A{};
A x = A();
This is related to PR104091, however, it is very different because this one is
not affected by "-std=c++XX"
[Bug c++/104091] New: -std=c++20 causing meaningless error message "'auto' not allowed in alias declaration" which should be "missing template arguments after ..."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104091
Bug ID: 104091
Summary: -std=c++20 causing meaningless error message "'auto'
not allowed in alias declaration" which should be
"missing template arguments after ..."
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
considering following snippet of code:
templatetypename Template>
struct Specialization{};
templatetypename Template, typename...Args>
struct Specialization, Template>{
using type=Template;
};
Using -std=c++20 gives meaningless error message of "'auto' not allowed in
alias declaration". While -std=c++17 or before all give correct error message:
"missing template arguments after 'Template<...auto...>'". And -std=c++14 is
even better with "invalid use of template-name 'Template' without an argument
list".
See https://godbolt.org/z/Wb9nKzcPT
[Bug c++/102925] [11.2]ICE with concept of std::convertible_to with lambda in unevaluated-context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102925
--- Comment #2 from qingzhe huang ---
I suspect this is related to template-specialization-related issue because if I
use original implementation of "std::convertible_to" to declare my concept
(https://en.cppreference.com/w/cpp/concepts/convertible_to),
template
concept convertible_to =
std::is_convertible_v &&
requires {
static_cast(std::declval());
};
then it works. (https://www.godbolt.org/z/99eoToze3)
See this concept is not a specialization of concept "std::convertible_to"
template
concept IsLambda=std::is_convertible_v
&& requires{
static_cast(std::declval());
};
[Bug c++/102925] New: [11.2]ICE with concept of std::convertible_to with lambda in unevaluated-context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102925
Bug ID: 102925
Summary: [11.2]ICE with concept of std::convertible_to with
lambda in unevaluated-context
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
The following code causes ICE in 11.2 when clang and MSVC++ all work fine.
(https://www.godbolt.org/z/eGq118ohT)
This ICE is fixed in trunk with a different issue of no matching template
declaration for template specialization.
#include
template
concept IsLambda=std::convertible_to;
template
void foo(T t){ t();}
template<>
void foo(decltype(+[]{}) t){
t();
}
:10:6: error: template-id 'foo' for 'void foo(void (*)())'
does not match any template declaration
10 | void foo(decltype(+[]{}) t){
| ^~~~
:7:6: note: candidate is: 'template requires IsLambda
void foo(T)'
7 | void foo(T t){ t();}
| ^~~
Compiler returned: 1
[Bug c++/24666] [meta-bug] array decaying to pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24666 Bug 24666 depends on bug 102033, which changed state. Bug 102033 Summary: template function signature incorrectly drops top-level cv-qualifiers causing template specialization failing to match https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102033 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug c++/102033] template function signature incorrectly drops top-level cv-qualifiers causing template specialization failing to match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102033 qingzhe huang changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from qingzhe huang --- fixed by patch under PR101402
[Bug c++/24666] [meta-bug] array decaying to pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24666 Bug 24666 depends on bug 102044, which changed state. Bug 102044 Summary: another case of template function signature incorrectly dropping top-level cv-qualifier with function parameter of array of template function pointer https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102044 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/102044] another case of template function signature incorrectly dropping top-level cv-qualifier with function parameter of array of template function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102044 qingzhe huang changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from qingzhe huang --- fixed by patch under PR101402
[Bug c++/24666] [meta-bug] array decaying to pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24666 Bug 24666 depends on bug 102039, which changed state. Bug 102039 Summary: another case of template function signature incorrectly dropping top-level cv-qualifier with function parameter dependent on template argument https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102039 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/102039] another case of template function signature incorrectly dropping top-level cv-qualifier with function parameter dependent on template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102039 qingzhe huang changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from qingzhe huang --- fixed by patch under PR101402
[Bug c++/102799] decltype with lambda without body error cause ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102799 --- Comment #1 from qingzhe huang --- Forget to mention that obviously this only happens with "-std=c++20" because of lambda in unevaluated context support.
[Bug c++/102799] New: decltype with lambda without body error cause ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102799
Bug ID: 102799
Summary: decltype with lambda without body error cause ICE
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
The lambda in outside "decltype" forget to add lambda body which cause ICE
where clang clearly points out this root cause. MSVC++ at least reports error
without crash.
decltype([](decltype([]{}))) gibish;
g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug testsuite/102735] New: privatization-1-compute.c results in both XFAIL and PASS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102735 Bug ID: 102735 Summary: privatization-1-compute.c results in both XFAIL and PASS Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: nickhuang99 at hotmail dot com Target Milestone: --- This testcase "c-c++-common/goacc/privatization-1-compute.c" results as both XFAIL and PASS which confuses "contrib/compare_tests". This appears to be so since this testcase is first checked-in. XFAIL: c-c++-common/goacc/privatization-1-compute.c -std=c++98 TODO (test for warnings, line 27) XFAIL: c-c++-common/goacc/privatization-1-compute.c -std=c++98 TODO (test for warnings, line 27) XFAIL: c-c++-common/goacc/privatization-1-compute.c -std=c++98 TODO (test for warnings, line 27) XFAIL: c-c++-common/goacc/privatization-1-compute.c -std=c++98 TODO (test for warnings, line 27) XFAIL: c-c++-common/goacc/privatization-1-compute.c -std=c++98 TODO (test for warnings, line 27) XFAIL: c-c++-common/goacc/privatization-1-compute.c -std=c++98 TODO (test for warnings, line 27) XFAIL: c-c++-common/goacc/privatization-1-compute.c -std=c++98 TODO (test for warnings, line 27) XFAIL: c-c++-common/goacc/privatization-1-compute.c -std=c++98 TODO (test for warnings, line 27) XFAIL: c-c++-common/goacc/privatization-1-compute.c -std=c++98 TODO (test for warnings, line 27) XFAIL: c-c++-common/goacc/privatization-1-compute.c -std=c++98 TODO (test for warnings, line 27) XFAIL: c-c++-common/goacc/privatization-1-compute.c -std=c++98 TODO (test for warnings, line 27) XFAIL: c-c++-common/goacc/privatization-1-compute.c -std=c++98 TODO (test for warnings, line 27) XFAIL: c-c++-common/goacc/privatization-1-compute.c -std=c++98 TODO (test for warnings, line 27) XFAIL: c-c++-common/goacc/privatization-1-compute.c -std=c++98 TODO (test for warnings, line 27) XFAIL: c-c++-common/goacc/privatization-1-compute.c -std=c++98 TODO (test for warnings, line 27) XFAIL: c-c++-common/goacc/privatization-1-compute.c -std=c++98 TODO (test for warnings, line 27) PASS: c-c++-common/goacc/privatization-1-compute.c -std=c++98 TODO (test for warnings, line 27) PASS: c-c++-common/goacc/privatization-1-compute.c -std=c++98 TODO (test for warnings, line 27) PASS: c-c++-common/goacc/privatization-1-compute.c -std=c++98 (test for warnings, line 27) PASS: c-c++-common/goacc/privatization-1-compute.c -std=c++98 TODO (test for warnings, line 27) PASS: c-c++-common/goacc/privatization-1-compute.c -std=c++98 TODO (test for warnings, line 27) PASS: c-c++-common/goacc/privatization-1-compute.c -std=c++98 (test for warnings, line 27) PASS: c-c++-common/goacc/privatization-1-compute.c -std=c++98 (test for warnings, line 27) PASS: c-c++-common/goacc/privatization-1-compute.c -std=c++98 (test for warnings, line 27) PASS: c-c++-common/goacc/privatization-1-compute.c -std=c++98 (test for warnings, line 27) PASS: c-c++-common/goacc/privatization-1-compute.c -std=c++98 (test for warnings, line 27) PASS: c-c++-common/goacc/privatization-1-compute.c -std=c++98 (test for excess errors) XFAIL: c-c++-common/goacc/privatization-1-compute.c -std=c++14 TODO (test for warnings, line 27) XFAIL: c-c++-common/goacc/privatization-1-compute.c -std=c++14 TODO (test for warnings, line 27) XFAIL: c-c++-common/goacc/privatization-1-compute.c -std=c++14 TODO (test for warnings, line 27) XFAIL: c-c++-common/goacc/privatization-1-compute.c -std=c++14 TODO (test for warnings, line 27) XFAIL: c-c++-common/goacc/privatization-1-compute.c -std=c++14 TODO (test for warnings, line 27) XFAIL: c-c++-common/goacc/privatization-1-compute.c -std=c++14 TODO (test for warnings, line 27) XFAIL: c-c++-common/goacc/privatization-1-compute.c -std=c++14 TODO (test for warnings, line 27) XFAIL: c-c++-common/goacc/privatization-1-compute.c -std=c++14 TODO (test for warnings, line 27) XFAIL: c-c++-common/goacc/privatization-1-compute.c -std=c++14 TODO (test for warnings, line 27) XFAIL: c-c++-common/goacc/privatization-1-compute.c -std=c++14 TODO (test for warnings, line 27) XFAIL: c-c++-common/goacc/privatization-1-compute.c -std=c++14 TODO (test for warnings, line 27) XFAIL: c-c++-common/goacc/privatization-1-compute.c -std=c++14 TODO (test for warnings, line 27) XFAIL: c-c++-common/goacc/privatization-1-compute.c -std=c++14 TODO (test for warnings, line 27) XFAIL: c-c++-common/goacc/privatization-1-compute.c -std=c++14 TODO (test for warnings, line 27) XFAIL: c-c++-common/goacc/privatization-1-compute.c -std=c++14 TODO (test for warnings, line 27) XFAIL: c-c++-common/goacc/privatization-1-compute.c -std=c++14 TODO (test for warnings, line 27) PASS: c-c++-common/goacc/privatization-1-compute.c -std=c++14 TODO (test for warnings, line 27) PASS: c-c++-common/goacc/privatization-1-compute.c -std=c++14 TODO
[Bug c++/102728] New: requires statement fails to recognize lambda in unevaluated context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102728
Bug ID: 102728
Summary: requires statement fails to recognize lambda in
unevaluated context
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
Consider that this snippet of code gives error of no matching specialization
which is not rooted from lambda in function parameter, instead it is rooted
from "requires" statement violation of lambda in unevaluated-context. The
warning about no-return-statement in lambda within requirement exposes this is
"requires" issue.
#include
template
concept IsLambda=requires(T t){
{t}->std::convertible_to;
};
template // OK if replace IsLambda with "class"
void foo(T t){ t();}
template<>
void foo(decltype(+[]{}) t){
t();
}
Also, a proof that this is not lambda-in-function-parameter issue is that you
can replace template parameter "IsLambda" in template function declaration with
"class" and GCC works fine.
Both clang and MSVC++ accepts above code. (https://www.godbolt.org/z/xhW7Tofao)
: In substitution of 'template requires IsLambda void
foo(T) [with T = void (*)()]':
:12:44: required from here
:5:40: warning: no return statement in function returning non-void
[-Wreturn-type]
5 | {t}->std::convertible_to;
|^~~~
:12:6: error: template-id 'foo' for 'void foo(void (*)())'
does not match any template declaration
12 | void foo(decltype(+[]{}) t){
| ^~~~
:9:6: note: candidate is: 'template requires IsLambda
void foo(T)'
9 | void foo(T t){ t();}
| ^~~
[Bug c++/102721] out-of-line member function definition fails to allow lambda in unevaluated-context of new feature in c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102721
--- Comment #5 from qingzhe huang ---
(In reply to qingzhe huang from comment #4)
> (In reply to Andrew Pinski from comment #2)
> > Note it is not array related either:
> > template<>
> > void A::foo(const decltype(+[]{}))
> > {}
>
> Yes, it is not array-related. But it is definitely member function issue
> with out-of line definition. See this works fine:
>
> template
> void foo(const T){}
>
> template<>
> void foo(const decltype(+[]{})); //declaration
>
> template<>
> void foo(const decltype(+[]{}))
> {}
Also interestingly, consider these following two cases:
1. template-class-member-function:
template
struct A{
void foo(const T){}
};
template<>
void A::foo(const decltype(+[]{})){}
2. class-with-template-member-function:
struct A{
template
void foo(const T){}
};
template<>
void A::foo(const decltype(+[]{})){}
Only case #1 has such issue.
[Bug c++/102721] out-of-line member function definition fails to allow lambda in unevaluated-context of new feature in c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102721
--- Comment #4 from qingzhe huang ---
(In reply to Andrew Pinski from comment #2)
> Note it is not array related either:
> template<>
> void A::foo(const decltype(+[]{}))
> {}
Yes, it is not array-related. But it is definitely member function issue with
out-of line definition. See this works fine:
template
void foo(const T){}
template<>
void foo(const decltype(+[]{})); //declaration
template<>
void foo(const decltype(+[]{}))
{}
[Bug c++/102721] New: out-of-line member function definition fails to allow lambda in unevaluated-context of new feature in c++20
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102721
Bug ID: 102721
Summary: out-of-line member function definition fails to allow
lambda in unevaluated-context of new feature in c++20
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
The following snippet code exposes that GCC parser doesn't comply with c++20
standard to allow lambda in unevaluated context. It seems this out-of-line
definition creates a new lambda type where lambda as operand of "decltype"
should be treated as in unevaluated context. So, it shouldn't create a new
lambda type in out-of-line definition.
Both clang and MSVC++ (https://www.godbolt.org/z/EMbb44fd8) parse this
correctly.
(with "-std=c++20")
template
struct A
{
void foo(const T){}
};
template<>
void A::foo(const decltype(+[]{})[3])
{}
:9:6: error: ambiguating new declaration of 'void A::foo(void (* const*)())'
9 | void A::foo(const decltype(+[]{})[3])
| ^
:5:10: note: old declaration 'void A::foo(T) [with T = void (*
[3])()]'
5 | void foo(const T){}
| ^~~
[Bug c++/102624] testcase lambda-uneval11.C causes cc1plus segment fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102624 --- Comment #2 from qingzhe huang --- (In reply to Richard Biener from comment #1) > so it looks like some diagnostics affect current_function_decl, the key > is omitting -quiet from the command-line that's usually added by the driver. That is absolutely correct. However, I think the real danger is the "announce_function" which is the root cause. The name and behavior makes it look like a harmless-readonly debug output. However, it is effectively doing not only recursing itself, but sidelines by calling "tsubt" which eventually set "current_function_decl" back-and-forth. So, my fix is to comment out this "announce_function" below directory "cp" level because it might recurse itself and interleave with the set/reset "current_function_decl". Does anybody depend on the result of this "announce_function"? Driver? Plugin? Also I want to point out that any debug method using debug printf of format "%F" will suffer the similar issue because they are similar to "announce_function". I personally debug using a lot of this format and it drives me crazy when these seemingly-harmless print/warning function cause crash. Somebody needs to write some really "readonly" debug output helper functions for developers! I may prepare a patch if no objections. BTW, this issue is hidden by option "-quiet" because it suppresses "announce_function" output. #0 announce_function (decl=0x773ab700) at ../../gcc-10.2.0/gcc/toplev.c:230 #1 0x00a03d26 in start_preparsed_function (decl1=0x773ab700, attrs=0x0, flags=3) at ../../gcc-10.2.0/gcc/cp/decl.c:16291 #2 0x00a4cc75 in start_lambda_function (fco=0x773ab700, lambda_expr=0x77399cc0) at ../../gcc-10.2.0/gcc/cp/lambda.c:1425 #3 0x00b25f8f in tsubst_lambda_expr (t=0x77399480, args=0x77383aa0, complain=0, in_decl=0x7738b100) at ../../gcc-10.2.0/gcc/cp/pt.c:19086 #4 0x00b2aa76 in tsubst_copy_and_build (t=0x77399480, args=0x77383aa0, complain=0, in_decl=0x0, function_p=false, integral_constant_expression_p=false) at ../../gcc-10.2.0/gcc/cp/pt.c:20511 #5 0x00b1be1b in tsubst (t=0x7739c000, args=0x77383aa0, complain=0, in_decl=0x0) at ../../gcc-10.2.0/gcc/cp/pt.c:15936 #6 0x00a20637 in dump_template_bindings (pp=0x343cfc0 , parms=0x0, args=0x77383aa0, typenames=0x773a67f8) at ../../gcc-10.2.0/gcc/cp/error.c:416 #7 0x00a23b94 in dump_substitution (pp=0x343cfc0 , t=0x7726b400, template_parms=0x773827f8, template_args=0x77383aa0, flags=4) at ../../gcc-10.2.0/gcc/cp/error.c:1562 #8 0x00a24622 in dump_function_decl (pp=0x343cfc0 , t=0x7726b400, flags=4) at ../../gcc-10.2.0/gcc/cp/error.c:1720 #9 0x00a230b0 in dump_decl (pp=0x343cfc0 , t=0x773a3300, flags=4) at ../../gcc-10.2.0/gcc/cp/error.c:1292 #10 0x00a27805 in decl_as_string (decl=0x773a3300, flags=4) at ../../gcc-10.2.0/gcc/cp/error.c:2995 #11 0x00a278dd in lang_decl_name (decl=0x773a3300, v=2, translate=false) at ../../gcc-10.2.0/gcc/cp/error.c:3029 #12 0x00b78f8a in cxx_printable_name_internal (decl=0x773a3300, v=2, translate=false) at ../../gcc-10.2.0/gcc/cp/tree.c:2596 #13 0x00b7900b in cxx_printable_name (decl=0x773a3300, v=2) at ../../gcc-10.2.0/gcc/cp/tree.c:2605 #14 0x0139c9cf in announce_function (decl=0x773a3300) at ../../gcc-10.2.0/gcc/toplev.c:236
[Bug c++/92010] [8/9 Regression] gcc internal error since 8x on warning write-strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92010 --- Comment #16 from qingzhe huang --- > Ah yeah, I can reproduce the crash when invoking cc1plus directly and also > when > passing -Q to the driver. Might be better to open a separate PR for this as > it > seems to be a latent bug. just opened a new bug: pr102624
[Bug c++/102624] New: testcase lambda-uneval11.C causes cc1plus segment fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102624
Bug ID: 102624
Summary: testcase lambda-uneval11.C causes cc1plus segment
fault
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
The testcase g++.dg/cpp2a/lambda-uneval11.C causes cc1plus segment fault.
Running g++ driver won't expose this crash. Only running cc1plus directly can
expose the crash.
./install/libexec/gcc/x86_64-unknown-linux-gnu/12.0.0/cc1plus -std=c++20
gcc-clone/gcc/testsuite/g++.dg/cpp2a/lambda-uneval11.C
void spam(decltype () (*)[sizeof (T)]) void foo()
static constexpr void::_FUN()
constexpr::operator void (*)()() const static constexpr
void::_FUN() constexpr::operator void (*)()() const
static constexpr void::_FUN()
constexpr::operator void (*)()() const static constexpr
void::_FUN() constexpr::operator void (*)()() const
constexpr::operator void (*)()() const static constexpr
void::_FUN() constexpr::operator void (*)()() const
gcc-clone/gcc/testsuite/g++.dg/cpp2a/lambda-uneval11.C: In instantiation of
‘constexpr::operator void (*)()() const’:
gcc-clone/gcc/testsuite/g++.dg/cpp2a/lambda-uneval11.C:9:12: required from
here
gcc-clone/gcc/testsuite/g++.dg/cpp2a/lambda-uneval11.C:4:25: internal compiler
error: Segmentation fault
4 | template void spam(decltype([]{}) (*s)[sizeof(T)] = nullptr)
| ^~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug c++/92010] [8/9 Regression] gcc internal error since 8x on warning write-strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92010
--- Comment #15 from qingzhe huang ---
>>Might be better to open a separate PR for this as it
seems to be a latent bug.
thanks, I will file a new bug.
From: ppalka at gcc dot gnu.org
Sent: October 5, 2021 5:05 PM
To: nickhuan...@hotmail.com
Subject: [Bug c++/92010] [8/9 Regression] gcc internal error since 8x on
warning write-strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92010
--- Comment #14 from Patrick Palka ---
(In reply to qingzhe huang from comment #13)
> (In reply to Patrick Palka from comment #12)
> > (In reply to qingzhe huang from comment #11)
> > > The testcase g++.dg/cpp2a/lambda-uneval11.C still suffers a segment fault
> > > if
> > > run by compiler cc1plus with latest code.
> >
> > Hmm, I can't reproduce that on latest trunk. Is your working tree clean?
>
> I tested in both 10.2.x and 11.2.x and even latest 12.x with yesterday pull.
> It won't show anything when compiling with driver, i.e. g++, but if you run
> "cc1plus", it will crash. For example,
> ${GCC_INSTALL}/libexec/gcc/x86_64-unknown-linux-gnu/11.2.0/cc1plus
> -std=c++20 ./lambda-uneval11.C
>
> Thank you
Ah yeah, I can reproduce the crash when invoking cc1plus directly and also when
passing -Q to the driver. Might be better to open a separate PR for this as it
seems to be a latent bug.
[Bug c++/92010] [8/9 Regression] gcc internal error since 8x on warning write-strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92010
--- Comment #13 from qingzhe huang ---
(In reply to Patrick Palka from comment #12)
> (In reply to qingzhe huang from comment #11)
> > The testcase g++.dg/cpp2a/lambda-uneval11.C still suffers a segment fault if
> > run by compiler cc1plus with latest code.
>
> Hmm, I can't reproduce that on latest trunk. Is your working tree clean?
I tested in both 10.2.x and 11.2.x and even latest 12.x with yesterday pull. It
won't show anything when compiling with driver, i.e. g++, but if you run
"cc1plus", it will crash. For example,
${GCC_INSTALL}/libexec/gcc/x86_64-unknown-linux-gnu/11.2.0/cc1plus -std=c++20
./lambda-uneval11.C
Thank you
[Bug c++/92010] [8/9 Regression] gcc internal error since 8x on warning write-strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92010
qingzhe huang changed:
What|Removed |Added
CC||nickhuang99 at hotmail dot com
--- Comment #11 from qingzhe huang ---
The testcase g++.dg/cpp2a/lambda-uneval11.C still suffers a segment fault if
run by compiler cc1plus with latest code. And gdb shows that global var
"current_function_decl" is set to 0 when crashed. Should we reopen this bug?
./install/libexec/gcc/x86_64-unknown-linux-gnu/12.0.0/cc1plus -std=c++20
gcc-clone/gcc/testsuite/g++.dg/cpp2a/lambda-uneval11.C
void spam(decltype () (*)[sizeof (T)]) void foo()
static constexpr void::_FUN()
constexpr::operator void (*)()() const static constexpr
void::_FUN() constexpr::operator void (*)()() const
static constexpr void::_FUN()
constexpr::operator void (*)()() const static constexpr
void::_FUN() constexpr::operator void (*)()() const
constexpr::operator void (*)()() const static constexpr
void::_FUN() constexpr::operator void (*)()() const
gcc-clone/gcc/testsuite/g++.dg/cpp2a/lambda-uneval11.C: In instantiation of
‘constexpr::operator void (*)()() const’:
gcc-clone/gcc/testsuite/g++.dg/cpp2a/lambda-uneval11.C:9:12: required from
here
gcc-clone/gcc/testsuite/g++.dg/cpp2a/lambda-uneval11.C:4:25: internal compiler
error: Segmentation fault
4 | template void spam(decltype([]{}) (*s)[sizeof(T)] = nullptr)
| ^~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug c++/102449] New: template parameter with default argument is used without being verified during explicit specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102449
Bug ID: 102449
Summary: template parameter with default argument is used
without being verified during explicit specialization
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
The following snippet code should be rejected because "First" should be checked
with its default argument which is "char"
template
void foo(First,T){}
template<>
void foo(int,double){}
[Bug c++/102410] New: parameter pack expansion twice when there is default parameter during template specialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102410
Bug ID: 102410
Summary: parameter pack expansion twice when there is default
parameter during template specialization
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
The following code should NOT be accepted because parameter pack should be just
"int*" without "double" which is considered as "Extra".
template
void foo(First, Extra, Ts...){}
template<>
void foo(char,double,int*,double){}
As a contrast, the following code is rejected which is wrong.
template
void foo(First, Extra, Ts...){}
template<>
void foo(char,double,int*){}
[Bug c++/102235] New: array not decay to pointer for template function parameter during specialization with parameter pack as template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102235
Bug ID: 102235
Summary: array not decay to pointer for template function
parameter during specialization with parameter pack as
template argument
Product: gcc
Version: 11.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
Consider this snippet with error of no matches of specialization, it is similar
to case PR94501 which happens during implicit conversion. However, the internal
implementation of them might be very different. So, I would rather file this as
a new bug instead of duplicate. The direct reason is that fixing this bug might
not fix this PR94501.
template
void foo(Ts...);
template<>
void foo(int*){}
parameter.cpp:4:6: error: template-id ‘foo’ for ‘void foo(int*)’ does
not match any template declaration
void foo(int*){}
^~
parameter.cpp:2:6: note: candidate is: template void foo(Ts ...)
void foo(Ts...);
^~~
[Bug c++/94501] arrays are not decaying to pointers in variadic function template for conversion to a function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94501
qingzhe huang changed:
What|Removed |Added
CC||nickhuang99 at hotmail dot com
--- Comment #2 from qingzhe huang ---
I believe this case of no specialization matching error is related with this
bug(clang passed, MSVC++ failed like GCC https://godbolt.org/z/KTahxj868).
Possibly it is a duplicate case. However, I can see even though the root cause
are all from template substitution, the "implicit_convert" and
"determine_specialization" are two different path. Should we dup this or create
a new, considering the fix might be quite different in these two cases? Do we
force developper to fix both cases when submitting a patch?
template
void foo(Ts...);
template<>
void foo(int*){}
:3:19: error: no matches converting function 'foo' to type 'void
(*)(int*)'
3 | void (*f)(int*) = foo;
| ^~
:2:6: note: candidate is: 'template void foo(Ts ...)'
2 | void foo(Ts...);
| ^~~
:5:6: error: template-id 'foo' for 'void foo(int*)' does not
match any template declaration
5 | void foo(int*){}
| ^~~
:2:6: note: candidate is: 'template void foo(Ts ...)'
2 | void foo(Ts...);
| ^~~
[Bug testsuite/102122] contrib/compare_tests reports different result with identical sum input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102122 --- Comment #1 from qingzhe huang --- I can see now this is maybe a testcase "gcc.dg/Wvla-parameter-2.c" issue: Do we expect XFAIL and PASS happen at the same time? For example, the input can be simplified as following: XFAIL: gcc.dg/Wvla-parameter-2.c pr? (test for warnings, line 40) PASS: gcc.dg/Wvla-parameter-2.c pr? (test for warnings, line 40) I guess compare_tests doesn't expect such case can occur, right?
[Bug testsuite/102122] New: contrib/compare_tests reports different result with identical sum input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102122 Bug ID: 102122 Summary: contrib/compare_tests reports different result with identical sum input Product: gcc Version: 11.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite Assignee: unassigned at gcc dot gnu.org Reporter: nickhuang99 at hotmail dot com Target Milestone: --- Created attachment 51373 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51373=edit identical sum file if I compare two identical sum input, compare_tests reports: Tests that now fail, but worked before (4 tests): : gcc.dg/Wvla-parameter-2.c pr? (test for warnings, line 40) : gcc.dg/Wvla-parameter-2.c pr? (test for warnings, line 42) : gcc.dg/Wvla-parameter-2.c pr? (test for warnings, line 44) : gcc.dg/Wvla-parameter-2.c pr? (test for warnings, line 46) Tests that now work, but didn't before (4 tests): : gcc.dg/Wvla-parameter-2.c pr? (test for warnings, line 40) : gcc.dg/Wvla-parameter-2.c pr? (test for warnings, line 42) : gcc.dg/Wvla-parameter-2.c pr? (test for warnings, line 44) : gcc.dg/Wvla-parameter-2.c pr? (test for warnings, line 46) What I suspect is the "XFAIL:" part confuses report.
[Bug c++/102044] another case of template function signature incorrectly dropping top-level cv-qualifier with function parameter of array of template function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102044 --- Comment #2 from qingzhe huang --- The root cause of this issue maybe similar to those PR102033, PR102034, PR102042 etc., however, this is still a distinctive case because of its nature. It is not a "typename" indicating its a dependent-type, rather using "decltype". So, in this sense, to tackle this issue may need a different approach. Currently I haven't found a similar function to resolve "decltype" type similar to "resolve_typename_type". If anybody knows one, please let me know.
[Bug c++/102038] another case of template function signature incorrectly dropping top-level cv-qualifier with function parameter of decltype from qualified-id of array member variable of template clas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102038 --- Comment #2 from qingzhe huang --- Understand. Thank you. BTW, is it possible to ask somebody to submit the patch on my behalf? I am very lost of the whole procedure. Sorry for this dumb question.
[Bug c++/102042] specialization after instantiation error possibly rooted from mis-calculating template function signature of parameter of array of template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102042 --- Comment #2 from qingzhe huang --- Just tested with my fix, it can be fixed with my suggested patch in PR102033.
[Bug c++/102042] specialization after instantiation error possibly rooted from mis-calculating template function signature of parameter of array of template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102042
--- Comment #1 from qingzhe huang ---
Slightly change the prototype of "g" from reference to pointer, you have exact
same error. (please note #0 changes to pointer type)
#include
template
void f(const T[N]){}
template
using fPtr=decltype(f)*;
template
fPtr af[N]={};
template
void g(const decltype(af)*){} // #0
static_assert(std::is_same),
void(const fPtr<1,int>(*)[1])>::value, "fun"); // #2
template<>
void g<1,int>(const fPtr<1,int>(*)[1]){}
error: specialization of 'void g(decltype (af)*) [with unsigned int N =
1; T = int; decltype (af) = void (* [1])(const int*)]' after
instantiation
24 | void g<1,int>(const fPtr<1,int>(*)[1]){}
|
[Bug c++/102044] New: another case of template function signature incorrectly dropping top-level cv-qualifier with function parameter of array of template function pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102044
Bug ID: 102044
Summary: another case of template function signature
incorrectly dropping top-level cv-qualifier with
function parameter of array of template function
pointer
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
This may be dup case of PR102033, PR102034 and very probably not related with
PR102042 of which I just changed the function parameter of "g" to const array
instead of const reference of array. So, it can be another test case.
However, clang(https://www.godbolt.org/z/fxzoWK4G8) passes,
MSVC++(https://www.godbolt.org/z/c7Pfbr6b9) fails like GCC. In this sense, I
believe this case might be different from all above cases because MSVC++ does
not fail.
consider:
#include
template
void f(const T[N]){}
template
using fPtr=decltype(f)*;
template
fPtr af[N]={};
template
void g(const decltype(af)){}
static_assert(std::is_same),
fPtr<1,int>[1] >::value, "af is correct"); // #1
static_assert(std::is_same),
void(const fPtr<1,int>[1])>::value, "fun"); // #2
template<>
void g<1,int>(const fPtr<1,int>[1]){}
GCC says:
error: template-id 'g<1, int>' for 'void g(void (* const*)(const int*))' does
not match any template declaration
21 | void g<1,int>(const fPtr<1,int>[1]){}
| ^~~~
fun-array-value.cpp:12:6: note: candidate is: 'template void g(decltype (af))'
12 | void g(const decltype(af)){}
| ^
[Bug c++/102042] New: specialization after instantiation error possibly rooted from mis-calculating template function signature of parameter of array of template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102042
Bug ID: 102042
Summary: specialization after instantiation error possibly
rooted from mis-calculating template function
signature of parameter of array of template function
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
I suspect this is from similar root cause of PR101402, PR102033, PR102034 etc.
when incorrectly dropping top-level cv-qualifier during calculating template
function declarator of which parameter is an array of template function
pointer.
Clearly from "#2" of static assert, GCC already gets correct specialization
"g<1,int>" signature, still the last statement of specialization declaration
causes error with very strange error message.
clang(https://www.godbolt.org/z/5eM5b4GjG) accepts.
MSVC++(https://www.godbolt.org/z/3x9dvsfTh) stumbles like GCC, but a better
clear clue.
#include
template
void f(const T[N]){}
template
using fPtr=decltype(f)*;
template
fPtr af[N]={}; // even without initialization,error still is
template
void g(const decltype(af)&){}
static_assert(std::is_same),
fPtr<1,int>[1] >::value, "af is correct"); // #1
static_assert(std::is_same),
void(fPtr<1,int>const(&)[1])>::value, "fun"); // #2
template<>
void g<1,int>(fPtr<1,int>const(&)[1]){}
GCC gives very misleading error message:
error: specialization of 'void g(decltype (af)&) [with unsigned int N =
1; T = int; decltype (af) = void (* [1])(const int*)]' after
instantiation
21 | void g<1,int>(fPtr<1,int>const(&)[1]){}
| ^
[Bug c++/102039] New: another case of template function signature incorrectly dropping top-level cv-qualifier with function parameter dependent on template argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102039
Bug ID: 102039
Summary: another case of template function signature
incorrectly dropping top-level cv-qualifier with
function parameter dependent on template argument
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
You can say this is another dup of PR101402, but the nature is different
because the dependent-type is now from function template argument itself which
is different from another template class of PR101402. And that is why I file it
to be a possibly future test case.
struct A{
typedef int Arr3[3];
};
template
void f(const typename T::Arr3){}
template<>
void f(const int[3]){}
[Bug c++/102038] New: another case of template function signature incorrectly dropping top-level cv-qualifier with function parameter of decltype from qualified-id of array member variable of template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102038
Bug ID: 102038
Summary: another case of template function signature
incorrectly dropping top-level cv-qualifier with
function parameter of decltype from qualified-id of
array member variable of template class
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
This is a similar case of PR101402,PR102033,PR102034
template
struct A{
template
struct B{
using TB_Alias=TB;
template
struct C{
typedef TC Arr[N];
Arr arr;
};
};
};
template
void f(const decltype(A::template B::template C<>::arr)){}
template<>void f<3, char>(const char [3]){}
I provide this similar bug of PR101402,PR102033,PR102034 in a purpose to expose
more aspect of this issue when using decltype-type, possibly as a future test
case when this "family" of bugs being fixed. More importantly, just a slightly
different of above case is passed by GCC when we are using "reference of array"
which is very interesting for developer to dig.
This passed!
template
struct A{
template
struct B{
using TB_Alias=TB;
template
struct C{
typedef TC Arr[N];
Arr arr;
};
};
};
template
void f(const decltype(A::template B::template C<>::arr) &){}
template<>void f<3, char>(char const(&)[3]){}
[Bug c++/102033] template function signature incorrectly drops top-level cv-qualifiers causing template specialization failing to match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102033
--- Comment #3 from qingzhe huang ---
I can give tons of similar cases with even more complicated template levels
combined with using/typedefs/default arguments. i.e.
template
struct A{
template
struct B{
using TB_Alias=TB;
template
struct C{
typedef TC Arr3[3];
};
};
};
template
void f(const typename A::template B::template C<>::Arr3){}
template <>
void f(const typename A::template B::template
C<>::Arr3){}
The fix are all can be done similarly at point to calculating function
parameter "cv-qualifier" value by passing its result into call
*cp_build_qualified_type* at decl.c:grokparms.
for example:
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 3414cbdc876..473c7b7d75c 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -14493,7 +14493,16 @@ grokparms (tree parmlist, tree *parms)
/* Top-level qualifiers on the parameters are
ignored for function types. */
- type = cp_build_qualified_type (type, 0);
+ int type_quals = 0;
+ /* Top-level qualifiers are reserved for array type. PR101402 */
+ if (TREE_CODE (type) == TYPENAME_TYPE)
+ {
+tree resolved_type = resolve_typename_type(type, false);
+if (resolved_type && TREE_CODE(resolved_type) == ARRAY_TYPE)
+ type_quals = CP_TYPE_CONST_P(type);
+ }
+ type = cp_build_qualified_type (type, type_quals);
+
if (TREE_CODE (type) == METHOD_TYPE)
{
error ("parameter %qD invalidly declared method type", decl);
However, original *resolve_typename_type* function is not working well to cover
all cases. I only fixed one "non-recursive" case with
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 020a4bf2f6d..1944bf4a6ea 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -27989,7 +27989,12 @@ resolve_typename_type (tree type, bool only_current_p)
/* If we failed to resolve it, return the original typename. */
if (!result)
-return type;
+ {
+ if (TREE_CODE (fullname) == TEMPLATE_ID_EXPR
+ && TREE_CODE (decl) == TEMPLATE_DECL)
+ return TREE_TYPE(decl);
+ return type;
+ }
/* If lookup found a typename type, resolve that too. */
if (TREE_CODE (result) == TYPENAME_TYPE && !TYPENAME_IS_RESOLVING_P
(result))
And then I give up because it requires almost a new *resolve_typename_type*
function to cover all possible cases. And I have no GCC write access and the
code is extremely difficult to maintain.
[Bug c++/102034] New: template function signature incorrectly drops top-level cv-qualifiers of parameter from typedef-array of template-template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102034
Bug ID: 102034
Summary: template function signature incorrectly drops
top-level cv-qualifiers of parameter from
typedef-array of template-template
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
Even the following snippet of code has similar root cause as PR101402 and
PR102033, it cannot be easy fixed even with simple improvement of
*resolve_typename_type*. It seems that we need a re-work of this function to
correctly do recursion.
template
struct A{
template
struct B{
typedef TB Arr3[3];
};
};
template
void f(const typename A::template B::Arr3){}
template <>
void f(const typename A::template B::Arr3){}
error: template-id 'f' for 'void f(const char*)' does not match any
template declaration
11 | void f(const typename A::template B::Arr3){}
| ^~~~
template-template.cpp:9:6: note: candidate is: 'template
void f(typename A::B::Arr3)'
9 | void f(const typename A::template B::Arr3){}
| ^
[Bug c++/102033] New: template function signature incorrectly drops top-level cv-qualifiers causing template specialization failing to match
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102033
Bug ID: 102033
Summary: template function signature incorrectly drops
top-level cv-qualifiers causing template
specialization failing to match
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
The following snippet code fails with similar reason as PR101402, but it cannot
be fixed with similar way of using *resolve_typename_type* without further
improvement of itself.
template
struct A{
template
using Type=TB[3];
};
template
void f(const typename A::template Type){}
template <>
void f(const typename A::template Type){}
error: template-id 'f' for 'void f(const char*)' does not match any
template declaration
9 | void f(const typename A::template Type){}
| ^~~~
array-using.cpp:7:6: note: candidate is: 'template void
f(typename A::Type)'
7 | void f(const typename A::template Type){}
| ^
[Bug c++/51851] [core/1001] Overriding a function with a parameter of dependent type fails to override.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51851
--- Comment #7 from qingzhe huang ---
Thank you for clarifications!
I just found a solution for this 10-year-old issue and preparing a patch.
However, the solution is not able to solve more complicated cases which
requires more work.
This issue is so complicated and I am hesitating to file more complicated bugs
which this patch won't work because it requires improvement work of function
*resolve_typename_type* to handle recursive case correctly.
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 3414cbdc876..db0d43b2b08 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -14493,7 +14493,16 @@ grokparms (tree parmlist, tree *parms)
/* Top-level qualifiers on the parameters are
ignored for function types. */
- type = cp_build_qualified_type (type, 0);
+ int type_quals = 0;
+ /* Top-level qualifiers are reserved for array type. PR101783 */
+ if (TREE_CODE (type) == TYPENAME_TYPE)
+ {
+tree resolved_type = resolve_typename_type(type, false);
+if (resolved_type && TREE_CODE(resolved_type) == ARRAY_TYPE)
+ type_quals = CP_TYPE_CONST_P(type);
+ }
+ type = cp_build_qualified_type (type, type_quals);
+
if (TREE_CODE (type) == METHOD_TYPE)
{
error ("parameter %qD invalidly declared method type", decl);
[Bug c++/101783] unnecessary error when top level cv qualifier is dropped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101783 --- Comment #9 from qingzhe huang --- OK, Thank you very much! From: redi at gcc dot gnu.org Sent: August 23, 2021 9:37 AM To: nickhuan...@hotmail.com Subject: [Bug c++/101783] unnecessary error when top level cv qualifier is dropped https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101783 --- Comment #8 from Jonathan Wakely --- No, I cannot approve compiler patches. -- You are receiving this mail because: You reported the bug. You are on the CC list for the bug.
[Bug c++/101783] unnecessary error when top level cv qualifier is dropped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101783 --- Comment #7 from qingzhe huang --- Jonathan, Is it possible for you to review and commit my patch? (https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577040.html). Thank you!
[Bug c++/51851] [core/1001] Overriding a function with a parameter of dependent type fails to override.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51851 --- Comment #4 from qingzhe huang --- At least since release/gcc-10, this test code has been successfully compiled. Can we change its status to Resolved?
[Bug c++/101402] [DR 1001] top cv qualifier not dropped for array type typedef in template class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101402 --- Comment #3 from qingzhe huang --- bug 51851 has been fixed by latest release/gcc-10, but not this issue. So, I suggest to change this bug status to New.
[Bug c++/102002] spec requires typename can be dropped when used as template function return type consisting of template parameter which is at global scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102002 --- Comment #2 from qingzhe huang --- Thank you and my apology.
[Bug c++/102002] New: spec requires typename can be dropped when used as template function return type consisting of template parameter which is at global scope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102002 Bug ID: 102002 Summary: spec requires typename can be dropped when used as template function return type consisting of template parameter which is at global scope Product: gcc Version: 10.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: nickhuang99 at hotmail dot com Target Milestone: --- Spec considers *typename* can be dropped when there is no ambiguous of regarding identifier as type. And example(https://timsong-cpp.github.io/cppwp/temp.res#general-example-5) shows this OK. template T::R f();//OK, return type of a function declaration at global scope However, all compilers including GCC, clang, MSVC++ complains missing typename because error: need ‘typename’ before ‘T::R’ because ‘T’ is a dependent scope 1 | template T::R f(); | ^ | typename Here I quote spec(https://timsong-cpp.github.io/cppwp/temp.res#general-4.1): A qualified or unqualified name is said to be in a type-only context if it is the terminal name of a typename-specifier, nested-name-specifier, elaborated-type-specifier, class-or-decltype ... I understand this relaxation of enforcing *typename* is not so critical. Still it is nice to strictly follow spec.
[Bug c++/101982] [7.5]function parameter should not accept auto as placeholder-type-specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101982 --- Comment #3 from qingzhe huang --- Thank you for clarifications!
[Bug c++/101982] New: function parameter should not accept auto as placeholder-type-specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101982
Bug ID: 101982
Summary: function parameter should not accept auto as
placeholder-type-specifier
Product: gcc
Version: 7.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
GCC7.5 accepts *auto* as placeholder-type-specifier without error or warning.
Considering following code snippet is legal only with -std=c++20:
void f(auto i){}
GCC8.x and later gives warning which is at least not incorrect. As a contrast,
both clang (https://www.godbolt.org/z/9x6E5xrne) and
MSVC(https://www.godbolt.org/z/3hWPsrcqz) considers it is illegal without
-std=c++20 option which is compliant with spec:
warning: use of ‘auto’ in parameter declaration only available with
‘-fconcepts-ts’
[Bug c++/101783] unnecessary error when top level cv qualifier is dropped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101783 nick huang changed: What|Removed |Added CC||nickhuang99 at hotmail dot com --- Comment #5 from nick huang --- Created attachment 51274 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51274=edit suggested fix for PR101783 Here is my suggested fix for this bug. The root cause of this bug is that it considers reference with cv qualifier as an error by generating value for variable "bad_quals". However, this is not correct for case of typedef. Here I quote spec: "Cv-qualified references are ill-formed except when the cv-qualifiers are introduced through the use of a typedef-name ([dcl.typedef], [temp.param]) or decltype-specifier ([dcl.type.decltype]), in which case the cv-qualifiers are ignored."
[Bug c++/101783] unnecessary error when top level cv qualifier is dropped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101783
--- Comment #1 from nick huang ---
The following snippet of code and error gives more clear the issue.
Considering:
template struct A{
typedef T& Type;
};
template
void f(const typename A::Type){}
struct B{};
template <>
void f(const typename A::Type){}
generates following error:
error: ‘const’ qualifiers cannot be applied to ‘A::Type {aka B&}’
void f(const typename A::Type){}
^~~~
This would obviously confuses users about why *const* cannot be applied. Being
unable to apply the *const* to *B&* SHOULD NOT be an error, instead it is
merely a warning to be issued.
[Bug c++/101783] New: unnecessary error when top level cv qualifier is dropped
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101783
Bug ID: 101783
Summary: unnecessary error when top level cv qualifier is
dropped
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
Created attachment 51261
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51261=edit
When no template specialization is at present, static_assert shows correct
function signature. It would impress user this error unnecessary.
The following code:
template struct A{
typedef T& Type; // #0
};
template void f(const typename A::Type){} // #1
template <> void f(const typename A::Type){} // #2
will generate error:
error: ‘const’ qualifiers cannot be applied to ‘A::Type’ {aka ‘int&’}
1. This error is unnecessary because the *const* as top level cv qualifier will
be dropped anyway. Considering following correct static assert even without
template specialization of #2 at presence:
static_assert(std::is_same),void(int&)>::value);
The signature of *f* would drop unnecessary const anyway as top-level cv
qualifier according to spec. So, there is no need to generate error.
2. clang gives a warning but still accept it of which I believe appropriate
(https://www.godbolt.org/z/9qWrj5asq). MSVC accept without complaining
(https://www.godbolt.org/z/3coqMnjjq).
3. I have a simple fix for this. By using *tf_keep_type_decl*, it will suppress
this unnecessary error emit and let returning result being validated anyway. In
other words, suppressing this early error doesn't break anything.
--- a/gcc/cp/parser.c
+++ b/gcc/cp/parser.c
@@ -4104,7 +4104,7 @@ cp_parser_make_typename_type (cp_parser *parser, tree id,
if (identifier_p (id))
{
result = make_typename_type (parser->scope, id, typename_type,
- /*complain=*/tf_none);
+ /*complain=*/tf_keep_type_decl);
if (result == error_mark_node)
cp_parser_diagnose_invalid_type_name (parser, id, id_location);
return result;
[Bug c++/101402] New: top cv qualifier not dropped for array type typedef in template class (core 1001)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101402
Bug ID: 101402
Summary: top cv qualifier not dropped for array type typedef in
template class (core 1001)
Product: gcc
Version: 10.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: nickhuang99 at hotmail dot com
Target Milestone: ---
Created attachment 51127
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51127=edit
a diagnositic message to print functions arguments for comparison
This example code from core
1001(http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1001) is still
giving no matching template declaration error.
template struct A {
typedef T arr[3];
};
template void f(const typename A::arr) { } // #1
template void f(const A::arr);
1. This happens for all gcc versions. The root cause is template function
argument is considered as ‘(const int*)’ instead of ‘(int*)’ (see attached
debug output for details.)
2. C++ standard requires top level cv qualifier being dropped when forming
function type.(https://timsong-cpp.github.io/cppwp/dcl.fct#5)
3. When both 'const' are removed from template function and specialization,
there is no error which proves array type works as long as there is no top
level cv qualifier.
4. I feel this is rather a high-profile bug as the example code is listed in
active core language issues long ago, particularly when both clang and MSVC
have fixed this issue. (see godbolt: https://www.godbolt.org/z/cofrEWEbs)
