[OE-core] [PATCH 2/2] gcc-7.3: Backport fixes for std::pair high memory usage

[Khem Raj]

V2 is good to install

On Sun, Jul 29, 2018 at 9:42 PM Joel Stanley <joel at jms.id.au> wrote:

> C++ applications that contain a specfic use of std::pair with tempates
> cause the build to require many gigabytes of RAM to build.
>
> This is a fix that was applied to the upstream GCC 7 branch.
>
> Change-Id: I213f96d1d6332e2dce5765482ff3413f1abd7ff8
> Signed-off-by: Joel Stanley <joel at jms.id.au>
> ---
>  meta/recipes-devtools/gcc/gcc-7.3.inc         |  1 +
>  ...-PR-c-80290-memory-hog-with-std-pair.patch | 58 +++++++++++++++++++
>  2 files changed, 59 insertions(+)
>  create mode 100644
> meta/recipes-devtools/gcc/gcc-7.3/0001-PR-c-80290-memory-hog-with-std-pair.patch
>
> diff --git a/meta/recipes-devtools/gcc/gcc-7.3.inc
> b/meta/recipes-devtools/gcc/gcc-7.3.inc
> index 81320dc52a59..c7c88f12e499 100644
> --- a/meta/recipes-devtools/gcc/gcc-7.3.inc
> +++ b/meta/recipes-devtools/gcc/gcc-7.3.inc
> @@ -80,6 +80,7 @@ BACKPORTS = "\
>             file://0001-Fix-internal-compiler-error-in-testcase.patch \
>             file://0001-PR-rtl-optimization-83030.patch \
>             file://0001-Fix-ppc64le-build-Partial-backport-r256656.patch \
> +           file://0001-PR-c-80290-memory-hog-with-std-pair.patch \
>  "
>
>  SRC_URI[md5sum] = "be2da21680f27624f3a87055c4ba5af2"
> diff --git
> a/meta/recipes-devtools/gcc/gcc-7.3/0001-PR-c-80290-memory-hog-with-std-pair.patch
> b/meta/recipes-devtools/gcc/gcc-7.3/0001-PR-c-80290-memory-hog-with-std-pair.patch
> new file mode 100644
> index 000000000000..ba43af92fff1
> --- /dev/null
> +++
> b/meta/recipes-devtools/gcc/gcc-7.3/0001-PR-c-80290-memory-hog-with-std-pair.patch
> @@ -0,0 +1,58 @@
> +From 8c014bceeca6a558519e86b16a8142accc41e94f Mon Sep 17 00:00:00 2001
> +From: jason <jason at 138bc75d-0d04-0410-961f-82ee72b054a4>
> +Date: Thu, 28 Jun 2018 00:25:21 +0000
> +Subject: [PATCH]       PR c++/80290 - memory-hog with std::pair.
> +
> +       * pt.c (type_unification_real): Skip non-dependent conversion
> +       check for a nested list argument.
> +       (braced_init_depth): New.
> +
> +git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-7-branch@262204
> 138bc75d-0d04-0410-961f-82ee72b054a4
> +Signed-off-by: Joel Stanley <joel at jms.id.au>
> +---
> + gcc/cp/pt.c      | 22 ++++++++++++++++++++++
> + 1 file changed, 22 insertions(+)
> +
> +diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
> +index 79cfd0129226..71077a3b0498 100644
> +--- a/gcc/cp/pt.c
> ++++ b/gcc/cp/pt.c
> +@@ -19242,6 +19242,24 @@ try_array_deduction (tree tparms, tree targs,
> tree parm)
> +                         /*nondeduced*/false, array_deduction_r);
> + }
> +
> ++/* Returns how many levels of { } INIT contains.  */
> ++
> ++static int
> ++braced_init_depth (tree init)
> ++{
> ++  if (!init || !BRACE_ENCLOSED_INITIALIZER_P (init))
> ++    return 0;
> ++  unsigned i; tree val;
> ++  unsigned max = 0;
> ++  FOR_EACH_CONSTRUCTOR_VALUE (CONSTRUCTOR_ELTS (init), i, val)
> ++    {
> ++      unsigned elt_d = braced_init_depth (val);
> ++      if (elt_d > max)
> ++      max = elt_d;
> ++    }
> ++  return max + 1;
> ++}
> ++
> + /* Most parms like fn_type_unification.
> +
> +    If SUBR is 1, we're being called recursively (to unify the
> +@@ -19478,6 +19496,10 @@ type_unification_real (tree tparms,
> +
> +           if (uses_template_parms (parm))
> +             continue;
> ++          /* Workaround for c++/80290: avoid combinatorial explosion on
> ++             deeply nested braced init-lists.  */
> ++          if (braced_init_depth (arg) > 2)
> ++            continue;
> +           if (check_non_deducible_conversion (parm, arg, strict, flags,
> +                                               explain_p))
> +             return 1;
> +--
> +2.17.1
> +
> --
> 2.17.1
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20180729/9fcb0e76/attachment-0002.html>