| Message ID | 20220525184852.3999906-2-Martin.Jansa@gmail.com |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [kirkstone,1/2] gcc: Upgrade to 11.3 release | expand |
Can you also ask gcc bugzilla for gcc-11 backport ? so we get it into 11.4 On Wed, May 25, 2022 at 11:49 AM Martin Jansa <Martin.Jansa@gmail.com> wrote: > > * https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96204 > * with gcc-11 I'm seeing some components failing with: > > lib32-recipe-sysroot/usr/include/gtest/gtest-printers.h:290:36: error: no matching function for call to 'testing::internal::internal_stream_operator_without_lexical_name_lookup::StreamPrinter::PrintValue(const bluetooth::Uuid&, std::nullptr_t)' > 290 | T, decltype(Printer::PrintValue(std::declval<const T&>(), nullptr)), > | ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ... > lib32-recipe-sysroot/usr/include/gtest/gtest-printers.h:212:33: error: no match for 'operator<<' (operand types are 'std::basic_ostream<char>' and 'const bluetooth::Uuid') > 211 | typename = decltype(std::declval<std::ostream&>() > | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 212 | << std::declval<const T&>())> > | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ > ... > lib32-recipe-sysroot/usr/include/c++/12.0.0/ostream:747:5: error: no type named 'type' in 'struct std::enable_if<false, void>' > > which built fine with gcc-10 and builds fine again with gcc-12, > this backported patch fixes it for gcc-11 as well > > Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> > --- > meta/recipes-devtools/gcc/gcc-11.3.inc | 1 + > ...during-partial-spec-matching-PR96204.patch | 126 ++++++++++++++++++ > 2 files changed, 127 insertions(+) > create mode 100644 meta/recipes-devtools/gcc/gcc/0030-c-access-scope-during-partial-spec-matching-PR96204.patch > > diff --git a/meta/recipes-devtools/gcc/gcc-11.3.inc b/meta/recipes-devtools/gcc/gcc-11.3.inc > index b1ef9d25af..ac2bafde7a 100644 > --- a/meta/recipes-devtools/gcc/gcc-11.3.inc > +++ b/meta/recipes-devtools/gcc/gcc-11.3.inc > @@ -59,6 +59,7 @@ SRC_URI = "\ > file://0027-libatomic-Do-not-enforce-march-on-aarch64.patch \ > file://0028-debug-101473-apply-debug-prefix-maps-before-checksum.patch \ > file://0029-Fix-install-path-of-linux64.h.patch \ > + file://0030-c-access-scope-during-partial-spec-matching-PR96204.patch \ > \ > file://0001-CVE-2021-42574.patch \ > file://0002-CVE-2021-42574.patch \ > diff --git a/meta/recipes-devtools/gcc/gcc/0030-c-access-scope-during-partial-spec-matching-PR96204.patch b/meta/recipes-devtools/gcc/gcc/0030-c-access-scope-during-partial-spec-matching-PR96204.patch > new file mode 100644 > index 0000000000..9d80c875f0 > --- /dev/null > +++ b/meta/recipes-devtools/gcc/gcc/0030-c-access-scope-during-partial-spec-matching-PR96204.patch > @@ -0,0 +1,126 @@ > +From 9f26e34a5a9614a5b66f146752ecef9ea67b3e2d Mon Sep 17 00:00:00 2001 > +From: Patrick Palka <ppalka@redhat.com> > +Date: Sat, 26 Jun 2021 11:05:54 -0400 > +Subject: [PATCH] c++: access scope during partial spec matching [PR96204] > + > +Here, when determining whether the partial specialization matches > +has_type_member<Child>, we do so from the scope of where the template-id > +appears rather than from the scope of the specialization, and this > +causes us to select the partial specialization (since Child::type is > +accessible from Parent). When we later instantiate this partial > +specialization, we've entered the scope of the specialization and so > +substitution into e.g. the DECL_CONTEXT of has_type_member::value fails > +with access errors since the friend declaration that we relied on to > +choose the partial specialization no longer applies. > + > +It seems the appropriate access scope from which to perform partial > +specialization matching is the specialization itself (similar to how > +we check access of base-clauses), which is what this patch implements. > + > + PR c++/96204 > + > +gcc/cp/ChangeLog: > + > + * pt.c (instantiate_class_template_1): Enter the scope of the > + type when calling most_specialized_partial_spec. > + > +gcc/testsuite/ChangeLog: > + > + * g++.dg/template/access40.C: New test. > + * g++.dg/template/access40a.C: New test. > + > +Upstream-Status: Backport [12.1 https://github.com/gcc-mirror/gcc/commit/9f26e34a5a9614a5b66f146752ecef9ea67b3e2d] > + > +--- > + gcc/cp/pt.c | 5 +++- > + gcc/testsuite/g++.dg/template/access40.C | 28 +++++++++++++++++++++++ > + gcc/testsuite/g++.dg/template/access40a.C | 28 +++++++++++++++++++++++ > + 3 files changed, 60 insertions(+), 1 deletion(-) > + create mode 100644 gcc/testsuite/g++.dg/template/access40.C > + create mode 100644 gcc/testsuite/g++.dg/template/access40a.C > + > +diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c > +index e5a2a2cd525..f2039e09cd7 100644 > +--- a/gcc/cp/pt.c > ++++ b/gcc/cp/pt.c > +@@ -11769,8 +11769,11 @@ instantiate_class_template_1 (tree type) > + deferring_access_check_sentinel acs (dk_no_deferred); > + > + /* Determine what specialization of the original template to > +- instantiate. */ > ++ instantiate; do this relative to the scope of the class for > ++ sake of access checking. */ > ++ push_nested_class (type); > + t = most_specialized_partial_spec (type, tf_warning_or_error); > ++ pop_nested_class (); > + if (t == error_mark_node) > + return error_mark_node; > + else if (t) > +diff --git a/gcc/testsuite/g++.dg/template/access40.C b/gcc/testsuite/g++.dg/template/access40.C > +new file mode 100644 > +index 00000000000..d035e99e462 > +--- /dev/null > ++++ b/gcc/testsuite/g++.dg/template/access40.C > +@@ -0,0 +1,28 @@ > ++// PR c++/96204 > ++ > ++template<class, class = void> > ++struct has_type_member { > ++ static const bool value = false; > ++}; > ++ > ++template<class T> > ++struct has_type_member<T, typename T::type> { > ++ static const bool value = true; > ++}; > ++ > ++struct Parent; > ++ > ++struct Child { > ++private: > ++ friend struct Parent; > ++ typedef void type; > ++}; > ++ > ++struct Parent { > ++ static void f() { > ++ // The partial specialization does not match despite Child::type > ++ // being accessible from the current scope. > ++ extern int x[1]; > ++ extern int x[!has_type_member<Child>::value]; > ++ } > ++}; > +diff --git a/gcc/testsuite/g++.dg/template/access40a.C b/gcc/testsuite/g++.dg/template/access40a.C > +new file mode 100644 > +index 00000000000..94025c513b7 > +--- /dev/null > ++++ b/gcc/testsuite/g++.dg/template/access40a.C > +@@ -0,0 +1,28 @@ > ++// PR c++/96204 > ++ > ++template<class, class = void> > ++struct has_type_member { > ++ static const bool value = false; > ++}; > ++ > ++template<class T> > ++struct has_type_member<T, typename T::type> { > ++ static const bool value = true; > ++}; > ++ > ++struct Parent; > ++ > ++struct Child { > ++private: > ++ friend struct has_type_member<Child>; > ++ typedef void type; > ++}; > ++ > ++struct Parent { > ++ static void f() { > ++ // The partial specialization matches because has_type_member<Child> > ++ // is a friend of Child. > ++ extern int x[1]; > ++ extern int x[has_type_member<Child>::value]; > ++ } > ++}; > -- > 2.35.1 > > > -=-=-=-=-=-=-=-=-=-=-=- > Links: You receive all messages sent to this group. > View/Reply Online (#166166): https://lists.openembedded.org/g/openembedded-core/message/166166 > Mute This Topic: https://lists.openembedded.org/mt/91339758/1997914 > Group Owner: openembedded-core+owner@lists.openembedded.org > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [raj.khem@gmail.com] > -=-=-=-=-=-=-=-=-=-=-=- >
On Wed, May 25, 2022 at 9:43 PM Khem Raj <raj.khem@gmail.com> wrote:
> Can you also ask gcc bugzilla for gcc-11 backport ? so we get it into 11.4
Done, in bigger build I came across similar build failure in chromium now,
will double check if it's actually caused by this change and if the 2nd
commit linked to the same gcc PR fixes it.
Steve: please ignore this one for now.
On Wed, May 25, 2022 at 11:10 AM Martin Jansa <martin.jansa@gmail.com> wrote: > > On Wed, May 25, 2022 at 9:43 PM Khem Raj <raj.khem@gmail.com> wrote: >> >> Can you also ask gcc bugzilla for gcc-11 backport ? so we get it into 11.4 > > > Done, in bigger build I came across similar build failure in chromium now, will double check if it's actually caused by this change and if the 2nd commit linked to the same gcc PR fixes it. > > Steve: please ignore this one for now. OK, will do. Steve
diff --git a/meta/recipes-devtools/gcc/gcc-11.3.inc b/meta/recipes-devtools/gcc/gcc-11.3.inc index b1ef9d25af..ac2bafde7a 100644 --- a/meta/recipes-devtools/gcc/gcc-11.3.inc +++ b/meta/recipes-devtools/gcc/gcc-11.3.inc @@ -59,6 +59,7 @@ SRC_URI = "\ file://0027-libatomic-Do-not-enforce-march-on-aarch64.patch \ file://0028-debug-101473-apply-debug-prefix-maps-before-checksum.patch \ file://0029-Fix-install-path-of-linux64.h.patch \ + file://0030-c-access-scope-during-partial-spec-matching-PR96204.patch \ \ file://0001-CVE-2021-42574.patch \ file://0002-CVE-2021-42574.patch \ diff --git a/meta/recipes-devtools/gcc/gcc/0030-c-access-scope-during-partial-spec-matching-PR96204.patch b/meta/recipes-devtools/gcc/gcc/0030-c-access-scope-during-partial-spec-matching-PR96204.patch new file mode 100644 index 0000000000..9d80c875f0 --- /dev/null +++ b/meta/recipes-devtools/gcc/gcc/0030-c-access-scope-during-partial-spec-matching-PR96204.patch @@ -0,0 +1,126 @@ +From 9f26e34a5a9614a5b66f146752ecef9ea67b3e2d Mon Sep 17 00:00:00 2001 +From: Patrick Palka <ppalka@redhat.com> +Date: Sat, 26 Jun 2021 11:05:54 -0400 +Subject: [PATCH] c++: access scope during partial spec matching [PR96204] + +Here, when determining whether the partial specialization matches +has_type_member<Child>, we do so from the scope of where the template-id +appears rather than from the scope of the specialization, and this +causes us to select the partial specialization (since Child::type is +accessible from Parent). When we later instantiate this partial +specialization, we've entered the scope of the specialization and so +substitution into e.g. the DECL_CONTEXT of has_type_member::value fails +with access errors since the friend declaration that we relied on to +choose the partial specialization no longer applies. + +It seems the appropriate access scope from which to perform partial +specialization matching is the specialization itself (similar to how +we check access of base-clauses), which is what this patch implements. + + PR c++/96204 + +gcc/cp/ChangeLog: + + * pt.c (instantiate_class_template_1): Enter the scope of the + type when calling most_specialized_partial_spec. + +gcc/testsuite/ChangeLog: + + * g++.dg/template/access40.C: New test. + * g++.dg/template/access40a.C: New test. + +Upstream-Status: Backport [12.1 https://github.com/gcc-mirror/gcc/commit/9f26e34a5a9614a5b66f146752ecef9ea67b3e2d] + +--- + gcc/cp/pt.c | 5 +++- + gcc/testsuite/g++.dg/template/access40.C | 28 +++++++++++++++++++++++ + gcc/testsuite/g++.dg/template/access40a.C | 28 +++++++++++++++++++++++ + 3 files changed, 60 insertions(+), 1 deletion(-) + create mode 100644 gcc/testsuite/g++.dg/template/access40.C + create mode 100644 gcc/testsuite/g++.dg/template/access40a.C + +diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c +index e5a2a2cd525..f2039e09cd7 100644 +--- a/gcc/cp/pt.c ++++ b/gcc/cp/pt.c +@@ -11769,8 +11769,11 @@ instantiate_class_template_1 (tree type) + deferring_access_check_sentinel acs (dk_no_deferred); + + /* Determine what specialization of the original template to +- instantiate. */ ++ instantiate; do this relative to the scope of the class for ++ sake of access checking. */ ++ push_nested_class (type); + t = most_specialized_partial_spec (type, tf_warning_or_error); ++ pop_nested_class (); + if (t == error_mark_node) + return error_mark_node; + else if (t) +diff --git a/gcc/testsuite/g++.dg/template/access40.C b/gcc/testsuite/g++.dg/template/access40.C +new file mode 100644 +index 00000000000..d035e99e462 +--- /dev/null ++++ b/gcc/testsuite/g++.dg/template/access40.C +@@ -0,0 +1,28 @@ ++// PR c++/96204 ++ ++template<class, class = void> ++struct has_type_member { ++ static const bool value = false; ++}; ++ ++template<class T> ++struct has_type_member<T, typename T::type> { ++ static const bool value = true; ++}; ++ ++struct Parent; ++ ++struct Child { ++private: ++ friend struct Parent; ++ typedef void type; ++}; ++ ++struct Parent { ++ static void f() { ++ // The partial specialization does not match despite Child::type ++ // being accessible from the current scope. ++ extern int x[1]; ++ extern int x[!has_type_member<Child>::value]; ++ } ++}; +diff --git a/gcc/testsuite/g++.dg/template/access40a.C b/gcc/testsuite/g++.dg/template/access40a.C +new file mode 100644 +index 00000000000..94025c513b7 +--- /dev/null ++++ b/gcc/testsuite/g++.dg/template/access40a.C +@@ -0,0 +1,28 @@ ++// PR c++/96204 ++ ++template<class, class = void> ++struct has_type_member { ++ static const bool value = false; ++}; ++ ++template<class T> ++struct has_type_member<T, typename T::type> { ++ static const bool value = true; ++}; ++ ++struct Parent; ++ ++struct Child { ++private: ++ friend struct has_type_member<Child>; ++ typedef void type; ++}; ++ ++struct Parent { ++ static void f() { ++ // The partial specialization matches because has_type_member<Child> ++ // is a friend of Child. ++ extern int x[1]; ++ extern int x[has_type_member<Child>::value]; ++ } ++};
* https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96204 * with gcc-11 I'm seeing some components failing with: lib32-recipe-sysroot/usr/include/gtest/gtest-printers.h:290:36: error: no matching function for call to 'testing::internal::internal_stream_operator_without_lexical_name_lookup::StreamPrinter::PrintValue(const bluetooth::Uuid&, std::nullptr_t)' 290 | T, decltype(Printer::PrintValue(std::declval<const T&>(), nullptr)), | ~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ... lib32-recipe-sysroot/usr/include/gtest/gtest-printers.h:212:33: error: no match for 'operator<<' (operand types are 'std::basic_ostream<char>' and 'const bluetooth::Uuid') 211 | typename = decltype(std::declval<std::ostream&>() | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 212 | << std::declval<const T&>())> | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ ... lib32-recipe-sysroot/usr/include/c++/12.0.0/ostream:747:5: error: no type named 'type' in 'struct std::enable_if<false, void>' which built fine with gcc-10 and builds fine again with gcc-12, this backported patch fixes it for gcc-11 as well Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> --- meta/recipes-devtools/gcc/gcc-11.3.inc | 1 + ...during-partial-spec-matching-PR96204.patch | 126 ++++++++++++++++++ 2 files changed, 127 insertions(+) create mode 100644 meta/recipes-devtools/gcc/gcc/0030-c-access-scope-during-partial-spec-matching-PR96204.patch