[Bug c++/84281] Heap grows indefinitely

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84281

--- Comment #14 from Jason Merrill  ---
Author: jason
Date: Mon Nov 26 15:53:48 2018
New Revision: 266469

URL: https://gcc.gnu.org/viewcvs?rev=266469=gcc=rev
Log:
PR c++/84281

2018-02-12  Richard Biener  

* constexpr.c (cxx_eval_vec_init_1): Use a RANGE_EXPR to compact
uniform constructors and delay allocating them fully.

Modified:
branches/gcc-7-branch/gcc/cp/ChangeLog
branches/gcc-7-branch/gcc/cp/constexpr.c

[Bug c++/84281] Heap grows indefinitely

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84281

Jason Merrill  changed:

   What|Removed |Added

 CC||mirzayanovmr at gmail dot com

--- Comment #13 from Jason Merrill  ---
*** Bug 68203 has been marked as a duplicate of this bug. ***

[Bug c++/84281] Heap grows indefinitely

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84281

Jason Merrill  changed:

   What|Removed |Added

 CC||m101010a at gmail dot com

--- Comment #12 from Jason Merrill  ---
*** Bug 56671 has been marked as a duplicate of this bug. ***

[Bug c++/84281] Heap grows indefinitely

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84281

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Richard Biener  ---
As said, fixed.

[Bug c++/84281] Heap grows indefinitely

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84281

Richard Biener  changed:

   What|Removed |Added

  Known to work||8.0
  Known to fail||7.3.0

--- Comment #10 from Richard Biener  ---
Fixed on trunk.

[Bug c++/84281] Heap grows indefinitely

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84281

--- Comment #9 from Richard Biener  ---
Author: rguenth
Date: Mon Feb 12 07:31:56 2018
New Revision: 257580

URL: https://gcc.gnu.org/viewcvs?rev=257580=gcc=rev
Log:
2018-02-12  Richard Biener  

PR c++/84281
* constexpr.c (cxx_eval_vec_init_1): Use a RANGE_EXPR to compact
uniform constructors and delay allocating them fully.

Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c

[Bug c++/84281] Heap grows indefinitely

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84281

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #8 from Richard Biener  ---
Seems that worked out fine ...

[Bug c++/84281] Heap grows indefinitely

[fiesh at zefix dot tv]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84281

--- Comment #7 from fiesh at zefix dot tv ---
Oh, I just realize I misunderstood what ice-on-invalid means.  Sorry about
that!

[Bug c++/84281] Heap grows indefinitely

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84281

Richard Biener  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org,
   ||nathan at gcc dot gnu.org

--- Comment #6 from Richard Biener  ---
The following makes it finish instantanously.  I'm a bit worried about the
assert in cxx_eval_store_expression which for ARRAY constructors asserts

  if (code == ARRAY_TYPE)
{
  HOST_WIDE_INT i
= find_array_ctor_elt (*valp, index, /*insert*/true);
  gcc_assert (i >= 0);
  cep = CONSTRUCTOR_ELT (*valp, i);
  gcc_assert (TREE_CODE (cep->index) != RANGE_EXPR);

not sure if we need to handle RANGE_EXPR here (simply split the thing!).

Jason/Nathan, can any of you pick this up please?  This is an opportunity
to save a lot of memory/compile-time for I guess quite common cases
(no need to unshare all the elements nor allocate the index INTEGER_CSTs
which is what gobbles up all the memory in this case...).  I'll throw the
patch to testing just in case - but double checking the above assert
by you would be nice (not sure how we could ever end up storing into
sth generated by cxx_eval_vec_init_1, but ...).  Not sure how good
testing coverage is in this area either.

Index: gcc/cp/constexpr.c
===
--- gcc/cp/constexpr.c  (revision 257491)
+++ gcc/cp/constexpr.c  (working copy)
@@ -2885,7 +2885,6 @@ cxx_eval_vec_init_1 (const constexpr_ctx
   unsigned HOST_WIDE_INT max = tree_to_uhwi (array_type_nelts_top (atype));
   verify_ctor_sanity (ctx, atype);
   vec **p = _ELTS (ctx->ctor);
-  vec_alloc (*p, max + 1);
   bool pre_init = false;
   unsigned HOST_WIDE_INT i;

@@ -2978,13 +2977,14 @@ cxx_eval_vec_init_1 (const constexpr_ctx
{
  if (new_ctx.ctor != ctx->ctor)
eltinit = new_ctx.ctor;
- for (i = 1; i < max; ++i)
-   {
- idx = build_int_cst (size_type_node, i);
- CONSTRUCTOR_APPEND_ELT (*p, idx, unshare_constructor (eltinit));
-   }
+ tree range = build2 (RANGE_EXPR, size_type_node,
+  build_int_cst (size_type_node, 1),
+  build_int_cst (size_type_node, max - 1));
+ CONSTRUCTOR_APPEND_ELT (*p, range, unshare_constructor (eltinit));
  break;
}
+  else
+   vec_safe_reserve (*p, max + 1);
 }

   if (!*non_constant_p)

[Bug c++/84281] Heap grows indefinitely

[fiesh at zefix dot tv]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84281

--- Comment #5 from fiesh at zefix dot tv ---
The test case was reduced from an actual translation unit that stalled our
build server.  Since the translation unit itself was invalid C++, the test case
is too. I think it shouldn't be part of the contract that only valid code may
be passed to the compiler.  Therefore to me this is not invalid.

[Bug c++/84281] Heap grows indefinitely

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84281

Martin Sebor  changed:

   What|Removed |Added

   Keywords||error-recovery,
   ||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-02-09
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #4 from Martin Sebor  ---
Confirmed.  Unless C++ has evolved more than I know the code is badly mangled,
so ice-on-invalid.  GCC also prints some error messages before it gets into a
loop so error-recovery.

[Bug c++/84281] Heap grows indefinitely

[dmalcolm at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84281

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #3 from David Malcolm  ---
Briefly tested on trunk, 7, 6, and 5; all of them seem to hang and consume
multiple gigabytes of memory:

  PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND 
12459 david 20   0 44.088g 0.041t   4752 t   0.0 33.5  15:42.05 cc1plus 
12452 david 20   0 10.470g 0.010t 56 t   0.0  8.0   1:31.62 cc1plus

Seems to be stuck in cxx_eval_vec_init_1 building an initializer (or
initializers?) for a very large array of very large integers.

(gdb) call debug_tree (atype)
 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x718ca738 precision:64 min  max 
pointer_to_this >
BLK
size  constant 274877906880>
unit-size  constant 34359738360>
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x71a2a1f8
domain  unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x718ca000 precision:64 min  max >
type_6 DI size  unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x71a2a150 precision:64 min  max >>

[Bug c++/84281] Heap grows indefinitely

[fiesh at zefix dot tv]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84281

--- Comment #2 from fiesh at zefix dot tv ---
I guess that depends on the definition of "meaningful".  It reproduces the
problem, so I'd say yes. ;)

[Bug c++/84281] Heap grows indefinitely

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84281

Richard Biener  changed:

   What|Removed |Added

   Keywords||memory-hog

--- Comment #1 from Richard Biener  ---
Is the reduced example still meaningful?