Hi Jason,
1. Thank you very much for your detailed comments for my patch and I really
appreciate it! Here is my revised patch:
The root cause of this bug is that it considers reference with
cv-qualifiers 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."
2021-09-25 qingzhe huang <nickhuan...@hotmail.com>
gcc/cp/
PR c++/101783
* tree.c (cp_build_qualified_type_real):
gcc/testsuite/
PR c++/101783
* g++.dg/parse/pr101783.C: New test.
-------------- next part --------------
diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
index 8840932dba2..d5c8daeb340 100644
--- a/gcc/cp/tree.c
+++ b/gcc/cp/tree.c
@@ -1356,11 +1356,18 @@ cp_build_qualified_type_real (tree type,
/* A reference or method type shall not be cv-qualified.
[dcl.ref], [dcl.fct]. This used to be an error, but as of DR 295
(in CD1) we always ignore extra cv-quals on functions. */
+
+ /* 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.
+ */
if (type_quals & (TYPE_QUAL_CONST | TYPE_QUAL_VOLATILE)
&& (TYPE_REF_P (type)
|| FUNC_OR_METHOD_TYPE_P (type)))
{
- if (TYPE_REF_P (type))
+ if (TYPE_REF_P (type)
+ && (!typedef_variant_p (type) || FUNC_OR_METHOD_TYPE_P (type)))
bad_quals |= type_quals & (TYPE_QUAL_CONST | TYPE_QUAL_VOLATILE);
type_quals &= ~(TYPE_QUAL_CONST | TYPE_QUAL_VOLATILE);
}
diff --git a/gcc/testsuite/g++.dg/parse/pr101783.C
b/gcc/testsuite/g++.dg/parse/pr101783.C
new file mode 100644
index 00000000000..4e0a435dd0b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/parse/pr101783.C
@@ -0,0 +1,5 @@
+template<class T> struct A{
+ typedef T& Type;
+};
+template<class T> void f(const typename A<T>::Type){}
+template <> void f<int>(const typename A<int>::Type){}
2.
> In Jonathan's earlier reply he asked how you tested the patch; this
> message still doesn't say anything about that.
I communicated with Mr. Jonathan in private email, worrying my naive question
might pollute the public maillist. The following is major part of this
communication and I attached original part in attachment.
>>>How has this patch been tested? Have you bootstrapped the compiler and
>>>run the full testsuite?
Here is how I am doing:
a) build original 10.2.0 from scratch and make check to get both
"testsuite/gcc/gcc.sum"
and "testsuite/g++/g++.sum".
b) apply my patch and build from scratch and make check to get both two files
above.
c) compare two run's *.sum files to see if there is any difference.
(Later I realized there is tool "contrib/compare_tests" is a good help of
doing so.)
3.
> What is the legal status of your contributions?
I thought small patch didn't require assignment. However, I just sent email to
ass...@gnu.org to request assignment.
Alternatively, I am not sure if adding this "signoff" tag in submission will
help?
Signed-off-by: qingzhe huang <nickhuan...@hotmail.com>
Thank you again!
> On 8/28/21 07:54, nick huang via Gcc-patches wrote:
> > Reference with cv-qualifiers should be ignored instead of causing an error
> > because standard accepts cv-qualified references introduced by typedef which
> > is ignored.
> > Therefore, the fix prevents GCC from reporting error by not setting variable
> > "bad_quals" in case the reference is introduced by typedef. Still the
> > cv-qualifier is silently ignored.
> > Here I quote spec (https://timsong-cpp.github.io/cppwp/dcl.ref#1):
> > "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."
> >
> > PR c++/101783
> >
> > gcc/cp/ChangeLog:
> >
> > 2021-08-27 qingzhe huang <nickhuan...@hotmail.com>
> >
> > * tree.c (cp_build_qualified_type_real):
>
> The git commit verifier rejects this commit message with
>
> Checking 1fa0fbcdd15adf936ab4fae584f841beb35da1bb: FAILED ERR: missing
> description of a change:
> " * tree.c (cp_build_qualified_type_real):"
>
> (your initial patch had a description here, you just need to copy it over)
>
> ERR: PR 101783 in subject but not in changelog:
> "c++: Suppress error when cv-qualified reference is introduced by
> typedef [PR101783]"
>
> (the PR number needs to have a Tab before it)
>
> In Jonathan's earlier reply he asked how you tested the patch; this
> message still doesn't say anything about that.
>
> https://gcc.gnu.org/contribute.html#testing
>
> What is the legal status of your contributions?
>
> https://gcc.gnu.org/contribute.html#legal
>
> Existing code tries to handle this with the tf_ignore_bad_quals, but the
> unnecessary use of typename gets past the code that tries to set the
> flag. But your approach is nice and straightforward, so let's go ahead
> with it.
>
> > gcc/testsuite/ChangeLog:
> >
> > 2021-08-27 qingzhe huang <nickhuan...@hotmail.com>
> >
> > * g++.dg/parse/pr101783.C: New test.
> >
> > diff --git a/gcc/cp/tree.c b/gcc/cp/tree.c
> > index 8840932dba2..7aa4318a574 100644
> > --- a/gcc/cp/tree.c
> > +++ b/gcc/cp/tree.c
> > @@ -1356,12 +1356,22 @@ cp_build_qualified_type_real (tree type,
> > /* A reference or method type shall not be cv-qualified.
> > [dcl.ref], [dcl.fct]. This used to be an error, but as of DR 295
> > (in CD1) we always ignore extra cv-quals on functions. */
> > +
> > + /* PR 101783
>
> Let's cite where this comes from in the standard ([dcl.ref]/1), and not
> the PR number.
>
> > + 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.
> > + */
> > if (type_quals & (TYPE_QUAL_CONST | TYPE_QUAL_VOLATILE)
> > && (TYPE_REF_P (type)
> > || FUNC_OR_METHOD_TYPE_P (type)))
> > {
> > - if (TYPE_REF_P (type))
> > + // do NOT set bad_quals when non-method reference is introduced by
> > typedef.
> > + if (TYPE_REF_P (type)
> > + && (!typedef_variant_p (type) || FUNC_OR_METHOD_TYPE_P (type)))
> > bad_quals |= type_quals & (TYPE_QUAL_CONST | TYPE_QUAL_VOLATILE);
> > + // non-method reference introduced by typedef is also dropped
> > silently
>
> These two // comments seem redundant with the quote from the standard
> above, let's drop them.
>
> > type_quals &= ~(TYPE_QUAL_CONST | TYPE_QUAL_VOLATILE);
> > }
> >
> > diff --git a/gcc/testsuite/g++.dg/parse/pr101783.C
> > b/gcc/testsuite/g++.dg/parse/pr101783.C
> > new file mode 100644
> > index 00000000000..4e0a435dd0b
> > --- /dev/null
> > +++ b/gcc/testsuite/g++.dg/parse/pr101783.C
> > @@ -0,0 +1,5 @@
> > +template<class T> struct A{
> > + typedef T& Type;
> > +};
> > +template<class T> void f(const typename A<T>::Type){}
> > +template <> void f<int>(const typename A<int>::Type){}
> >
> >
> > > >>>How has this ptch been tested? Have you bootstrapped the compiler and
> >>>run the full testsuite?
> Here is how I am doing:
> a) build original 10.2.0 from scratch and make check to get both
> "testsuite/gcc/gcc.sum"
> and "testsuite/g++/g++.sum".
> This is my configure params:
>
> configure
> --prefix=/home/nick/Downloads/gcc-10.2.0-test/gcc_install/gcc-10.2.0_install
> --enable-bootstrap --enable-shared --enable-threads=posix
These are enabled by default.
> --enable-checking=release
You don't want this when testing changes on trunk, it disables important checks.
> --enable-__cxa_atexit --disable-libunwind-exceptions --enable-linker-build-id
All enabled by default.
>--enable-languages=c,c++,lto --disable-vtable-verify
>--with-default-libstdcxx-abi=new --enable-libstdcxx-debug
>--without-included-gettext --enable-plugin --disable-initfini-array
>--disable-libgcj --enable-plugin --disable-multilib --with-tune=generic
>--build=x86_64-unknown-linux-gnu --target=x86_64-unknown-linux-gnu
>--host=x86_64-unknown-linux-gnu --with-pkgversion=nick-nick-HP-Laptop
>
> b) apply my patch and build from scratch and make check to get both two files
> above.
> c) compare two run's *.sum files to see if there is any difference.
>
> If above procedure is correct,
Your configure command is overcomplicated, but apart from the
--enable-checking option it is harmless.
>I will re-do and re-submit the patch email with corrected PR number.
Yes, please do.
