[Bug tree-optimization/103464] New: ICE on valid code at -O1 (with -ftree-vrp and ulimit -s 512) on x86_64-linux-gnu: Segmentation fault

[Bug tree-optimization/103464] New: ICE on valid code at -O1 (with -ftree-vrp and ulimit -s 512) on x86_64-linux-gnu: Segmentation fault

[zhendong.su at inf dot ethz.ch]

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

            Bug ID: 103464
           Summary: ICE on valid code at -O1 (with -ftree-vrp and ulimit
                    -s 512) on x86_64-linux-gnu: Segmentation fault
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

[519] % ulimit -s 512
[520] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20211129 (experimental) [master r12-4647-g3f861a5c8fd] (GCC) 
[521] % 
[521] % gcctk -O1 -ftree-vrp small.c
gcctk: internal compiler error: Segmentation fault signal terminated program
cc1
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
[522] % 
[522] % cat small.c
int a, b, c;
long d;
int main() {
  int e, f, g;
  long h, i;
  if (a)
  L1:
    goto L2;
  while (a) {
    if (c)
      goto L3;
    e = f;
    int j = g;
    if (0)
    L2:
      i = j;
    d = e;
    if (b)
    L3:
      if (a) {
        g = f = h;
        goto L1;
      }
    h = i;
  }
  return 0;
}

[Bug tree-optimization/103464] ICE on valid code at -O1 (with -ftree-vrp and ulimit -s 512) on x86_64-linux-gnu: Segmentation fault

[zhendong.su at inf dot ethz.ch]

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

--- Comment #1 from Zhendong Su <zhendong.su at inf dot ethz.ch> ---
Backtrace:

#0  irange::irange (nranges=255, base=0x7ffffff7edd0, this=0x7ffffff7edc0)
    at ../../gcc-trunk/gcc/value-range.h:400
#1  int_range<255u>::int_range (this=0x7ffffff7edc0) at
../../gcc-trunk/gcc/value-range.h:410
#2  gimple_ranger::range_on_edge (this=0x3076dc0, r=..., e=0x7ffff706ed50,
name=0x7ffff70793f0)
    at ../../gcc-trunk/gcc/gimple-range.cc:200
#3  0x0000000001bca0f0 in fold_using_range::range_of_phi
(this=this@entry=0x7ffffff81f0f, r=..., 
    phi=phi@entry=0x7ffff704cf00, src=...) at
../../gcc-trunk/gcc/gimple-range-fold.cc:796
#4  0x0000000001bce741 in fold_using_range::fold_stmt
(this=this@entry=0x7ffffff81f0f, r=..., 
    s=s@entry=0x7ffff704cf00, src=..., name=name@entry=0x7ffff7079318)
    at ../../gcc-trunk/gcc/gimple-range-fold.cc:554
#5  0x0000000001bbc070 in gimple_ranger::fold_range_internal
(this=this@entry=0x3076dc0, r=..., 
    s=s@entry=0x7ffff704cf00, name=name@entry=0x7ffff7079318)
    at ../../gcc-trunk/gcc/gimple-range.cc:250
#6  0x0000000001bbce55 in gimple_ranger::range_of_stmt (this=0x3076dc0, r=...,
s=0x7ffff704cf00, 
    name=0x7ffff7079318) at ../../gcc-trunk/gcc/gimple-range.cc:311
#7  0x0000000001bbd7f0 in gimple_ranger::range_of_expr (this=0x3076dc0, r=..., 
    expr=0x7ffff7079318, stmt=<optimized out>) at
../../gcc-trunk/gcc/gimple-range.cc:120
#8  0x0000000001bbbdcf in gimple_ranger::range_on_exit (this=0x3076dc0, r=...,
bb=0x7ffff6f1a548, 
    name=0x7ffff7079318) at ../../gcc-trunk/gcc/gimple-range.cc:185
#9  0x0000000001bbd9e7 in gimple_ranger::range_on_edge (this=0x3076dc0, r=...,
e=0x7ffff706ee70, 
    name=0x7ffff7079318) at ../../gcc-trunk/gcc/gimple-range.cc:229
#10 0x0000000001bca0f0 in fold_using_range::range_of_phi
(this=this@entry=0x7ffffff8723f, r=..., 
    phi=phi@entry=0x7ffff707a100, src=...) at
../../gcc-trunk/gcc/gimple-range-fold.cc:796
#11 0x0000000001bce741 in fold_using_range::fold_stmt
(this=this@entry=0x7ffffff8723f, r=..., 
    s=s@entry=0x7ffff707a100, src=..., name=name@entry=0x7ffff70793a8)
    at ../../gcc-trunk/gcc/gimple-range-fold.cc:554
#12 0x0000000001bbc070 in gimple_ranger::fold_range_internal
(this=this@entry=0x3076dc0, r=..., 
    s=s@entry=0x7ffff707a100, name=name@entry=0x7ffff70793a8)
    at ../../gcc-trunk/gcc/gimple-range.cc:250
#13 0x0000000001bbce55 in gimple_ranger::range_of_stmt (this=0x3076dc0, r=...,
s=0x7ffff707a100, 
    name=0x7ffff70793a8) at ../../gcc-trunk/gcc/gimple-range.cc:311
#14 0x0000000001bbd7f0 in gimple_ranger::range_of_expr (this=0x3076dc0, r=..., 
    expr=0x7ffff70793a8, stmt=<optimized out>) at
../../gcc-trunk/gcc/gimple-range.cc:120
#15 0x0000000001bbbdcf in gimple_ranger::range_on_exit (this=0x3076dc0, r=...,
bb=0x7ffff6f1a680, 
    name=0x7ffff70793a8) at ../../gcc-trunk/gcc/gimple-range.cc:185
#16 0x0000000001bbd9e7 in gimple_ranger::range_on_edge (this=0x3076dc0, r=...,
e=0x7ffff706ef30, 
    name=0x7ffff70793a8) at ../../gcc-trunk/gcc/gimple-range.cc:229
#17 0x0000000001bca0f0 in fold_using_range::range_of_phi
(this=this@entry=0x7ffffff8c56f, r=..., 
    phi=phi@entry=0x7ffff707a200, src=...) at
../../gcc-trunk/gcc/gimple-range-fold.cc:796
#18 0x0000000001bce741 in fold_using_range::fold_stmt
(this=this@entry=0x7ffffff8c56f, r=..., 
    s=s@entry=0x7ffff707a200, src=..., name=name@entry=0x7ffff70793f0)
    at ../../gcc-trunk/gcc/gimple-range-fold.cc:554
#19 0x0000000001bbc070 in gimple_ranger::fold_range_internal
(this=this@entry=0x3076dc0, r=..., 
    s=s@entry=0x7ffff707a200, name=name@entry=0x7ffff70793f0)
    at ../../gcc-trunk/gcc/gimple-range.cc:250
#20 0x0000000001bbce55 in gimple_ranger::range_of_stmt (this=0x3076dc0, r=...,
s=0x7ffff707a200, 
    name=0x7ffff70793f0) at ../../gcc-trunk/gcc/gimple-range.cc:311
...

[Bug tree-optimization/103464] ICE on valid code at -O1 (with -ftree-vrp and ulimit -s 512) on x86_64-linux-gnu: Segmentation fault since r12-5522-g661c02e54ea72fb5

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2021-11-29
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW
                 CC|                            |amacleod at redhat dot com,
                   |                            |marxin at gcc dot gnu.org
            Summary|ICE on valid code at -O1    |ICE on valid code at -O1
                   |(with -ftree-vrp and ulimit |(with -ftree-vrp and ulimit
                   |-s 512) on                  |-s 512) on
                   |x86_64-linux-gnu:           |x86_64-linux-gnu:
                   |Segmentation fault          |Segmentation fault since
                   |                            |r12-5522-g661c02e54ea72fb5

--- Comment #2 from Martin Liška <marxin at gcc dot gnu.org> ---
Started with r12-5522-g661c02e54ea72fb5, note that ulimit -s 600 works fine and
I'm not fully convinced such a small stack limit should be an issue?

Shouldn't we documented what's expected (required) minimal stack for GCC?

[Bug tree-optimization/103464] ICE on valid code at -O1 (with -ftree-vrp and ulimit -s 512) on x86_64-linux-gnu: Segmentation fault since r12-5522-g661c02e54ea72fb5

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
There might be another bug report about this same thing already.

[Bug tree-optimization/103464] ICE on valid code at -O1 (with -ftree-vrp and ulimit -s 512) on x86_64-linux-gnu: Segmentation fault since r12-5522-g661c02e54ea72fb5

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
What we should avoid is recursion depths worse than that, but it's quite hard
to assess this.  I've added some prints to fold_using_range::range_of_phi with
>>> entering and <<< exiting the function, printing the PHI address and the basic-block the PHI is in.  That results in

PHI 0x7ffff6681400 >>> 3
PHI 0x7ffff6681600 >>> 7
PHI 0x7ffff6681800 >>> 10
PHI 0x7ffff6681700 >>> 9
PHI 0x7ffff6681500 >>> 6
PHI 0x7ffff6681d00 >>> 10
PHI 0x7ffff6681c00 >>> 9
PHI 0x7ffff6681a00 >>> 6
PHI 0x7ffff6681900 >>> 3
PHI 0x7ffff66af500 >>> 7
PHI 0x7ffff66af600 >>> 10
PHI 0x7ffff66af900 >>> 9
PHI 0x7ffff66af700 >>> 6
PHI 0x7ffff66afb00 >>> 3
PHI 0x7ffff66afd00 >>> 7
PHI 0x7ffff66aff00 >>> 10
PHI 0x7ffff66afe00 >>> 9
PHI 0x7ffff66afc00 >>> 6
PHI 0x7ffff66af200 >>> 10
PHI 0x7ffff66af100 >>> 9
Segmentation fault (core dumped)

which shows that while we never recurse to the same PHI we seem to recursively
go between PHIs in a CFG cycle thus the recursion depth is
CFG cycle size * "PHI width".

It might make sense to simply limit the recursion depth with a --param or
to avoid visiting backedges at all.

[Bug tree-optimization/103464] ICE on valid code at -O1 (with -ftree-vrp and ulimit -s 512) on x86_64-linux-gnu: Segmentation fault since r12-5522-g661c02e54ea72fb5

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Martin Liška from comment #2)
> Started with r12-5522-g661c02e54ea72fb5, note that ulimit -s 600 works fine
> and I'm not fully convinced such a small stack limit should be an issue?
> 
> Shouldn't we documented what's expected (required) minimal stack for GCC?

The testcase is quite small though and for example on SLES the default stack
size limit is 8192.  But yes, we have other cases that recursively visit
SSA use-def chains (which is exactly the case here), like SCEV, but IIRC
all of those have limits in place (at the expense of missed optimizations,
of course).

[Bug tree-optimization/103464] [12 Regression] ICE on valid code at -O1 (with -ftree-vrp and ulimit -s 512) on x86_64-linux-gnu: Segmentation fault since r12-5522-g661c02e54ea72fb5

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org
   Target Milestone|---                         |12.0
            Summary|ICE on valid code at -O1    |[12 Regression] ICE on
                   |(with -ftree-vrp and ulimit |valid code at -O1 (with
                   |-s 512) on                  |-ftree-vrp and ulimit -s
                   |x86_64-linux-gnu:           |512) on x86_64-linux-gnu:
                   |Segmentation fault since    |Segmentation fault since
                   |r12-5522-g661c02e54ea72fb5  |r12-5522-g661c02e54ea72fb5

[Bug tree-optimization/103464] [12 Regression] ICE on valid code at -O1 (with -ftree-vrp and ulimit -s 512) on x86_64-linux-gnu: Segmentation fault since r12-5522-g661c02e54ea72fb5

[zhendong.su at inf dot ethz.ch]

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

--- Comment #6 from Zhendong Su <zhendong.su at inf dot ethz.ch> ---
(In reply to Martin Liška from comment #2)
> Started with r12-5522-g661c02e54ea72fb5, note that ulimit -s 600 works fine
> and I'm not fully convinced such a small stack limit should be an issue?
> 
> Shouldn't we documented what's expected (required) minimal stack for GCC?

The original test doesn't need the ulimit, but it was extremely difficult to
reduce to a reasonable size.

[539] % gcctk -O1 -ftree-vrp good.c -w
gcctk: internal compiler error: Segmentation fault signal terminated program
cc1
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
[540] % wc good.c
 1182  6408 76232 good.c
[541] %

[Bug tree-optimization/103464] [12 Regression] ICE on valid code at -O1 (with -ftree-vrp and ulimit -s 512) on x86_64-linux-gnu: Segmentation fault since r12-5522-g661c02e54ea72fb5

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
I'd also note that int_range_max is quite large (4k), and ranger uses those a
lot on the stack.

[Bug tree-optimization/103464] [12 Regression] ICE on valid code at -O1 (with -ftree-vrp and ulimit -s 512) on x86_64-linux-gnu: Segmentation fault since r12-5522-g661c02e54ea72fb5

[marxin at gcc dot gnu.org]

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

--- Comment #8 from Martin Liška <marxin at gcc dot gnu.org> ---
(In reply to Zhendong Su from comment #6)
> (In reply to Martin Liška from comment #2)
> > Started with r12-5522-g661c02e54ea72fb5, note that ulimit -s 600 works fine
> > and I'm not fully convinced such a small stack limit should be an issue?
> > 
> > Shouldn't we documented what's expected (required) minimal stack for GCC?
> 
> The original test doesn't need the ulimit, but it was extremely difficult to
> reduce to a reasonable size.

Can you please attach the original test-case?

[Bug tree-optimization/103464] [12 Regression] ICE on valid code at -O1 (with -ftree-vrp and ulimit -s 512) on x86_64-linux-gnu: Segmentation fault since r12-5522-g661c02e54ea72fb5

[zhendong.su at inf dot ethz.ch]

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

--- Comment #9 from Zhendong Su <zhendong.su at inf dot ethz.ch> ---
Created attachment 51893
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51893&action=edit
partially reduced test

[Bug tree-optimization/103464] [12 Regression] ICE on valid code at -O1 (with -ftree-vrp and ulimit -s 512) on x86_64-linux-gnu: Segmentation fault since r12-5522-g661c02e54ea72fb5

[zhendong.su at inf dot ethz.ch]

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

--- Comment #10 from Zhendong Su <zhendong.su at inf dot ethz.ch> ---
> Can you please attach the original test-case?

Added. 

This was a partially reduced test; the original was:
 15041  70889 783444 t.c

[Bug tree-optimization/103464] [12 Regression] ICE on valid code at -O1 (with -ftree-vrp and ulimit -s 512) on x86_64-linux-gnu: Segmentation fault since r12-5522-g661c02e54ea72fb5

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Zhendong Su from comment #9)
> Created attachment 51893 [details]
> partially reduced test

What's your default (unreduced) ulimit -s?

[Bug tree-optimization/103464] [12 Regression] ICE on valid code at -O1 (with -ftree-vrp and ulimit -s 512) on x86_64-linux-gnu: Segmentation fault since r12-5522-g661c02e54ea72fb5

[zhendong.su at inf dot ethz.ch]

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

--- Comment #12 from Zhendong Su <zhendong.su at inf dot ethz.ch> ---
(In reply to Richard Biener from comment #11)
> (In reply to Zhendong Su from comment #9)
> > Created attachment 51893 [details]
> > partially reduced test
> 
> What's your default (unreduced) ulimit -s?

8192

[Bug tree-optimization/103464] [12 Regression] ICE on valid code at -O1 (with -ftree-vrp and ulimit -s 512) on x86_64-linux-gnu: Segmentation fault since r12-5522-g661c02e54ea72fb5

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
Note that r12-5522-g661c02e54ea72fb5 doubled the stack use of the frame by
adding another int_range_max local to range_of_phi.

First of all in the rev we should have used intersect_, not union_, and if we
consider that we can simply treat it like single_arg (which we even set),
and thus elide equiv_range completely by using arg_range which is already
computed?  If there are only equivalences to the PHI def then the PHI must
be undefined (but I wonder how such PHI is even possible - did you have a
testcase for this?)

[Bug tree-optimization/103464] [12 Regression] ICE on valid code at -O1 (with -ftree-vrp and ulimit -s 512) on x86_64-linux-gnu: Segmentation fault since r12-5522-g661c02e54ea72fb5

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #13)
> Note that r12-5522-g661c02e54ea72fb5 doubled the stack use of the frame by
> adding another int_range_max local to range_of_phi.
> 
> First of all in the rev we should have used intersect_, not union_, and if we
> consider that we can simply treat it like single_arg (which we even set),
> and thus elide equiv_range completely by using arg_range which is already
> computed?  If there are only equivalences to the PHI def then the PHI must
> be undefined (but I wonder how such PHI is even possible - did you have a
> testcase for this?)

So we run into this visiting single arg PHIs where surprisingly we already
have registered an equivalence.  Special-casing single-arg PHIs might make
sense anyway.

[Bug tree-optimization/103464] [12 Regression] ICE on valid code at -O1 (with -ftree-vrp and ulimit -s 512) on x86_64-linux-gnu: Segmentation fault since r12-5522-g661c02e54ea72fb5

[amacleod at redhat dot com]

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

--- Comment #15 from Andrew Macleod <amacleod at redhat dot com> ---
Created attachment 51897
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51897&action=edit
Patch to not recurse for PHIs

First, there was a bug in the original patch, proposed fix for PR 103440 has
been posted to the mailing list.  It really needs to be applied.

Next, we can also include PHIs in the stack flattening fix for range-of-stmt..
which will remove all the recursion depth when dealing with PHIs.  Ive attached
it here.  Does that resolve the problem?   We should see much less recursion
depth.

Im running it through testing now.

[Bug tree-optimization/103464] [12 Regression] ICE on valid code at -O1 (with -ftree-vrp and ulimit -s 512) on x86_64-linux-gnu: Segmentation fault since r12-5522-g661c02e54ea72fb5

[amacleod at redhat dot com]

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

--- Comment #16 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Richard Biener from comment #13)
> Note that r12-5522-g661c02e54ea72fb5 doubled the stack use of the frame by
> adding another int_range_max local to range_of_phi.
> 
> First of all in the rev we should have used intersect_, not union_, and if we
> consider that we can simply treat it like single_arg (which we even set),

It needs to be union... we accumulate all the incoming ranges. we start with
UNDEFINED and add to it any ranges we find coming in on edges.

> and thus elide equiv_range completely by using arg_range which is already
> computed?  If there are only equivalences to the PHI def then the PHI must
> be undefined (but I wonder how such PHI is even possible - did you have a
> testcase for this?)


The original patch is a bit wrong, but to address the question, the argument is
not necessarily equivalent everywhere...  just in the source block for the phi
argument. and may not be equivalent in this block. Just on the edge. 

When the argument was equivalent in the source block, it means it cannot
provide any new information to the range being calculated (because it had to
get its range from this def), and so we ignore the range unless there are no
other ranges provided for input.  Then we give up and use it.   

This is simply a mechanism to help defer pessimistic assumptions around back
edges in some common patterns we see.

[Bug tree-optimization/103464] [12 Regression] ICE on valid code at -O1 (with -ftree-vrp and ulimit -s 512) on x86_64-linux-gnu: Segmentation fault since r12-5522-g661c02e54ea72fb5

[cvs-commit at gcc dot gnu.org]

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

--- Comment #17 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Andrew Macleod <amacleod@gcc.gnu.org>:

https://gcc.gnu.org/g:cb137e85720654e41db370d952df226654e576a6

commit r12-5688-gcb137e85720654e41db370d952df226654e576a6
Author: Andrew MacLeod <amacleod@redhat.com>
Date:   Mon Nov 29 12:00:26 2021 -0500

    Also pre-process PHIs in range-of-stmt.

            PR tree-optimization/103464
            * gimple-range.cc (gimple_ranger::prefill_name): Process phis also.
            (gimple_ranger::prefill_stmt_dependencies): Ditto.

[Bug tree-optimization/103464] [12 Regression] ICE on valid code at -O1 (with -ftree-vrp and ulimit -s 512) on x86_64-linux-gnu: Segmentation fault since r12-5522-g661c02e54ea72fb5

[amacleod at redhat dot com]

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

Andrew Macleod <amacleod at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #18 from Andrew Macleod <amacleod at redhat dot com> ---
fixed.

[Bug tree-optimization/103464] [12 Regression] ICE on valid code at -O1 (with -ftree-vrp and ulimit -s 512) on x86_64-linux-gnu: Segmentation fault since r12-5522-g661c02e54ea72fb5

[cvs-commit at gcc dot gnu.org]

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

--- Comment #19 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Andrew Macleod
<amacleod@gcc.gnu.org>:

https://gcc.gnu.org/g:3760d9d7b5410f16236ed15d02ec1d8a7d16fddb

commit r11-9452-g3760d9d7b5410f16236ed15d02ec1d8a7d16fddb
Author: Andrew MacLeod <amacleod@redhat.com>
Date:   Tue Dec 7 12:09:33 2021 -0500

    Directly resolve range_of_stmt dependencies. (Port of PR 103231/103464)

    All ranger API entries eventually call range_of_stmt to ensure there is an
    initial global value to work with.  This can cause very deep call chains
when
    satisfied via the normal API.  Instead, push any dependencies onto a stack
    and evaluate them in a depth first manner, mirroring what would have
happened
    via the normal API calls.

            PR tree-optimization/103603
            gcc/
            * gimple-range.cc (gimple_ranger::gimple_ranger): Create stmt
stack.
            (gimple_ranger::~gimple_ranger): New.
            (gimple_ranger::range_of_stmt): Process dependencies if they have
no
            global cache entry.
            (gimple_ranger::prefill_name): New.
            (gimple_ranger::prefill_stmt_dependencies): New.
            * gimple-range.h (class gimple_ranger): Add prototypes.