Hi Jason,
Sorry for not noticing your response.
>>Unfortunately, your patch breaks
>>
>>template <class T>
>>struct A
>>{
>> void f(T);
>>};
>>template <class T>
>>void A<T>::f(const T)
>>{ }
1. Perhaps I misunderstand your comment, but my patch does NOT fix this issue.
Neither does current GCC fix this code, if it is incorrect grammatically. In
other words, tested in www.godbolt.org and all major compilers accept it. And
my patch does NOT affects GCC current behavior, meaning my patched GCC still
accepts it like now. So, I don't think my patch breaks it because this code is
never fixed. (Whether this code is correct or not, I keep an open mind.)
>>which is certainly questionable code, but is currently also accepted by
>>clang and EDG compilers.
2. Like I said above, I am not even sure if it is an issue since most compilers
accept it. But my patch does NOT touch this issue at all. In essential, my
patch ONLY deals with dependent type starting with keyword "typename" or
"decltype". Just like my email subject, my patch only fixes one particular case
of this "family" of bugs, that is "typename" or "decltype" cases.
>>Why doesn't the PR92010 fix address these testcases as well?
3. PR92010 creates new functions of "rebuild_function_or_method_type" and by
using gdb to trace PR101402 code as following:
template<class T> struct A {
typedef T arr[3];
};
template<class T> void f(const typename A<T>::arr) { } // #1
template void f<int>(const A<int>::arr); // #2
I added some print function declaration code before and after calling
"maybe_rebuild_function_decl_type" to print out its parameter "r" which is
function declaration inside "tsubst_function_decl".
Here is the result:
a) Before calling, the function declaration is "void f(int*)" and after
calling, it is adjusted to correct one as "void f(const int*)". However, after
this line "SET_DECL_IMPLICIT_INSTANTIATION (r);", it fallback to original
dependent type as "void f(typename A<T>::arr) [with T = int; typename A<T>::arr
= int [3]]" till end. This completely defeats the purpose of template
substitution effort.
b) On the other hand, by screening input parameter of
"rebuild_function_or_method_type", I can see it is using an incorrect function
type as "void(typename A<T>::arr)" which already drops "const" prematurely.
This is due to previous #1 template function declaration parsing. So, This
gives us the clear idea of the root cause of this kind of bugs. It happens
during template function declaration stage #1 when producing template
declarator. Instead of doing a later-correction-effort in PR92010, my patch
tries to at least avoid dropping "const" in case of "typename" and "decltype"
during template function declaration stage in #1.
Best regards,
Qingzhe Huang
From: Jason Merrill <ja...@redhat.com>
Sent: September 24, 2021 3:11 PM
To: nick huang <nickhuan...@hotmail.com>; gcc-patches@gcc.gnu.org
<gcc-patches@gcc.gnu.org>
Subject: Re: *PING* [PATCH] c++: fix cases of core1001/1322 by not dropping
cv-qualifier of function parameter of type of typename or
decltype[PR101402,PR102033,PR102034,PR102039,PR102044]
I already responded to this patch:
https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579527.html
