[Bug c++/110315] New: [13 Regression] g++ crashes with a segmentation fault while compiling a large const std::vector of std::string since r13-6566-ge0324e2629e25a90

[Bug c++/110315] New: [13 Regression] g++ crashes with a segmentation fault while compiling a large const std::vector of std::string since r13-6566-ge0324e2629e25a90

[glebfm at altlinux dot org]

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

            Bug ID: 110315
           Summary: [13 Regression] g++ crashes with a segmentation fault
                    while compiling a large const std::vector of
                    std::string since r13-6566-ge0324e2629e25a90
           Product: gcc
           Version: 13.1.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: glebfm at altlinux dot org
  Target Milestone: ---

Created attachment 55366
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55366&action=edit
preprocessed source

$ ~/gcc-test/bin/g++ --version
g++ (GCC) 13.1.1 20230619
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ ~/gcc-test/bin/g++ -O -c test.ii
g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See <https://gcc.gnu.org/bugs/> for instructions.

$ gdb -q --args
/usr/src/gcc-test/libexec/gcc/x86_64-pc-linux-gnu/13.1.1/cc1plus -quiet -O
test.cpp -o test.o
Reading symbols from
/usr/src/gcc-test/libexec/gcc/x86_64-pc-linux-gnu/13.1.1/cc1plus...
(gdb) run
Starting program:
/usr/src/gcc-test/libexec/gcc/x86_64-pc-linux-gnu/13.1.1/cc1plus -quiet -O
test.cpp -o test.o
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x0000000001aafe51 in fold_using_range::range_of_phi
(this=this@entry=0x7ffffbfffcaf, r=warning: RTTI symbol not found for class
'int_range<255u>'
..., phi=phi@entry=0x7ffff2d4c000, src=...) at
../../gcc/gimple-range-fold.cc:733
733     {
(gdb) bt
#0  0x0000000001aafe51 in fold_using_range::range_of_phi
(this=this@entry=0x7ffffbfffcaf, r=warning: RTTI symbol not found for class
'int_range<255u>'
..., phi=phi@entry=0x7ffff2d4c000, src=...)
    at ../../gcc/gimple-range-fold.cc:733
#1  0x0000000001ab2289 in fold_using_range::fold_stmt (this=0x7ffffbfffcaf,
r=warning: RTTI symbol not found for class 'int_range<255u>'
..., s=0x7ffff2d4c000, src=..., name=0x7ffff2d4b480) at
../../gcc/gimple-range-fold.cc:491
#2  0x0000000001aa5292 in gimple_ranger::fold_range_internal
(name=0x7ffff2d4b480, s=0x7ffff2d4c000, r=warning: RTTI symbol not found for
class 'int_range<255u>'
..., this=0x29069a0) at ../../gcc/gimple-range.cc:257
#3  gimple_ranger::range_of_stmt (this=0x29069a0, r=warning: RTTI symbol not
found for class 'int_range<255u>'
..., s=0x7ffff2d4c000, name=<optimized out>) at ../../gcc/gimple-range.cc:318
#4  0x0000000001aa3fbb in gimple_ranger::range_on_entry
(this=this@entry=0x29069a0, r=warning: RTTI symbol not found for class
'int_range<255u>'
..., bb=0x7ffff34b0720, name=name@entry=0x7ffff2d4b480)
    at ../../gcc/gimple-range.cc:153
#5  0x0000000001aa6cff in gimple_ranger::range_of_expr (this=0x29069a0,
r=warning: RTTI symbol not found for class 'int_range<255u>'
..., expr=0x7ffff2d4b480, stmt=<optimized out>) at
../../gcc/gimple-range.cc:130
#6  0x0000000001aa418a in gimple_ranger::range_on_exit (this=0x29069a0,
r=warning: RTTI symbol not found for class 'int_range<255u>'
..., bb=0x7ffff34b0720, name=0x7ffff2d4b480) at ../../gcc/gimple-range.cc:187
#7  0x0000000001aa728a in gimple_ranger::range_on_edge (this=0x29069a0,
r=warning: RTTI symbol not found for class 'int_range<255u>'
..., e=0x7ffff325a720, name=0x7ffff2d4b480) at ../../gcc/gimple-range.cc:233
#8  0x0000000001ab012f in fold_using_range::range_of_phi
(this=this@entry=0x7ffffc0073af, r=warning: RTTI symbol not found for class
'int_range<255u>'
..., phi=phi@entry=0x7ffff2d4c100, src=...) at ../../gcc/value-range.h:634
#9  0x0000000001ab2289 in fold_using_range::fold_stmt (this=0x7ffffc0073af,
r=warning: RTTI symbol not found for class 'int_range<255u>'
..., s=0x7ffff2d4c100, src=..., name=0x7ffff2d4b4c8) at
../../gcc/gimple-range-fold.cc:491
#10 0x0000000001aa5292 in gimple_ranger::fold_range_internal
(name=0x7ffff2d4b4c8, s=0x7ffff2d4c100, r=warning: RTTI symbol not found for
class 'int_range<255u>'
#11 gimple_ranger::range_of_stmt (this=0x29069a0, r=warning: RTTI symbol not
found for class 'int_range<255u>'
..., s=0x7ffff2d4c100, name=<optimized out>) at ../../gcc/gimple-range.cc:318
#12 0x0000000001aa3fbb in gimple_ranger::range_on_entry
(this=this@entry=0x29069a0, r=warning: RTTI symbol not found for class
'int_range<255u>'
..., bb=0x7ffff34b0900, name=name@entry=0x7ffff2d4b4c8)
    at ../../gcc/gimple-range.cc:153
#13 0x0000000001aa6cff in gimple_ranger::range_of_expr (this=0x29069a0,
r=warning: RTTI symbol not found for class 'int_range<255u>'
..., expr=0x7ffff2d4b4c8, stmt=<optimized out>) at
../../gcc/gimple-range.cc:130
#14 0x0000000001aa418a in gimple_ranger::range_on_exit (this=0x29069a0,
r=warning: RTTI symbol not found for class 'int_range<255u>'
..., bb=0x7ffff34b0900, name=0x7ffff2d4b4c8) at ../../gcc/gimple-range.cc:187
#15 0x0000000001aa728a in gimple_ranger::range_on_edge (this=0x29069a0,
r=warning: RTTI symbol not found for class 'int_range<255u>'
..., e=0x7ffff325a840, name=0x7ffff2d4b4c8) at ../../gcc/gimple-range.cc:233
[...]
--Type <RET> for more, q to quit, c to continue without paging--c
[...]
#17640 0x0000000000de11bb in compile_file () at ../../gcc/toplev.cc:471
#17641 0x00000000006adb68 in do_compile (no_backend=false) at
../../gcc/toplev.cc:2125
#17642 toplev::main (this=this@entry=0x7fffffffe296, argc=<optimized out>,
argc@entry=6, argv=<optimized out>, argv@entry=0x7fffffffe3c8) at
../../gcc/toplev.cc:2277
#17643 0x00000000006af7cb in main (argc=6, argv=0x7fffffffe3c8) at
../../gcc/main.cc:39

The provided source code is a modified version of the original source code,
which can be found at
https://github.com/mbasaglia/glaxnimate/blob/master/src/gui/emoji/emoji_data.[ch]pp.
 The only change made in this modified version is the substitution of QString
with std::string.  The compiler encounters a segmentation fault when processing
either version.
The removal of approximately 400 emojis from the vector allows the source code
to be compiled successfully.

I isolated the regression to commit e0324e2629e25a90c13c68b4eef1e47b091970c3
(r13-6566-ge0324e2629e25a90) using git bisect.  I attempted to reproduce the
issue with the trunk (r14-1922-g53953b6f31f18ac2), it appears that the issue
does not occur there.

[Bug tree-optimization/110315] [13 Regression] g++ crashes with a segmentation fault while compiling a large const std::vector of std::string since r13-6566-ge0324e2629e25a90

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.2
          Component|c++                         |tree-optimization

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
My bet is you could reproduce it before r13-4562-g3da5ae7a347b7d74765053f4a08
and your bisect just produced one revision which just happened to undo part of
the front-end optimizations done in r13-4562 (and a few others afterwards).

[Bug tree-optimization/110315] [13 Regression] g++ crashes with a segmentation fault while compiling a large const std::vector of std::string since r13-6566-ge0324e2629e25a90

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aldyh at gcc dot gnu.org,
                   |                            |amacleod at redhat dot com
           Priority|P3                          |P2
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2023-07-19
             Status|UNCONFIRMED                 |NEW

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Confirmed.  Not sure whether it's possible to backport any of the stack usage
reduction in ranger from trunk or whether it's other recursion limiting that
avoids this there (besides different IL from the frontend ...).

Andrew/Aldy?  The call chain is 20000 frames deep when it faults on me
(with a -O0 built cc1plus running in gdb).

[Bug tree-optimization/110315] [13 Regression] g++ crashes with a segmentation fault while compiling a large const std::vector of std::string since r13-6566-ge0324e2629e25a90

[amacleod at redhat dot com]

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

--- Comment #3 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Richard Biener from comment #2)
> Confirmed.  Not sure whether it's possible to backport any of the stack
> usage reduction in ranger from trunk or whether it's other recursion
> limiting that
> avoids this there (besides different IL from the frontend ...).
> 
> Andrew/Aldy?  The call chain is 20000 frames deep when it faults on me
> (with a -O0 built cc1plus running in gdb).

I'll have a look

[Bug tree-optimization/110315] [13 Regression] g++ crashes with a segmentation fault while compiling a large const std::vector of std::string since r13-6566-ge0324e2629e25a90

[amacleod at redhat dot com]

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

--- Comment #4 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Richard Biener from comment #2)
> Confirmed.  Not sure whether it's possible to backport any of the stack
> usage reduction in ranger from trunk or whether it's other recursion
> limiting that
> avoids this there (besides different IL from the frontend ...).
> 
> Andrew/Aldy?  The call chain is 20000 frames deep when it faults on me
> (with a -O0 built cc1plus running in gdb).

huh.  I am not seeing this with the current gcc 13 release branch?  or at least
I cant get my stage 1 compiler to fail like this

[Bug tree-optimization/110315] [13 Regression] g++ crashes with a segmentation fault while compiling a large const std::vector of std::string since r13-6566-ge0324e2629e25a90

[amacleod at redhat dot com]

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

--- Comment #5 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Andrew Macleod from comment #4)
> (In reply to Richard Biener from comment #2)
> > Confirmed.  Not sure whether it's possible to backport any of the stack
> > usage reduction in ranger from trunk or whether it's other recursion
> > limiting that
> > avoids this there (besides different IL from the frontend ...).
> > 
> > Andrew/Aldy?  The call chain is 20000 frames deep when it faults on me
> > (with a -O0 built cc1plus running in gdb).
> 
> huh.  I am not seeing this with the current gcc 13 release branch?  or at
> least I cant get my stage 1 compiler to fail like this

hold on.. I think it was picking up the wrong code nbase.  stay tuned. :-P

[Bug tree-optimization/110315] [13 Regression] g++ crashes with a segmentation fault while compiling a large const std::vector of std::string since r13-6566-ge0324e2629e25a90

[amacleod at redhat dot com]

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

--- Comment #6 from Andrew Macleod <amacleod at redhat dot com> ---
I think the difference is actually Aldys work to reduce the size of Value_Range
rather than other stack saving changes.  I think I can make some adjustments so
that our usage of Value_Range are on leaf functions in some places instead of
remaining in the call chain.

I'll get back to you

[Bug tree-optimization/110315] [13 Regression] g++ crashes with a segmentation fault while compiling a large const std::vector of std::string since r13-6566-ge0324e2629e25a90

[amacleod at redhat dot com]

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

--- Comment #7 from Andrew Macleod <amacleod at redhat dot com> ---
Created attachment 55591
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55591&action=edit
potental patch

I've attached Aldy's patch for PR109695 which he had backported to GCC13 back
in May.
This does resolve the issue.. Assuming we want to apply it GCC13.  The original
variant has been in trunk for a while now.  Im running this thru a
bootstrap/regression run now.

I don't know if there is anything further you want to try it with?

[Bug tree-optimization/110315] [13 Regression] g++ crashes with a segmentation fault while compiling a large const std::vector of std::string since r13-6566-ge0324e2629e25a90

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|13.2                        |13.3

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 13.2 is being released, retargeting bugs to GCC 13.3.

[Bug tree-optimization/110315] [13 Regression] g++ crashes with a segmentation fault while compiling a large const std::vector of std::string since r13-6566-ge0324e2629e25a90

[glebfm at altlinux dot org]

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

--- Comment #9 from Gleb Fotengauer-Malinovskiy <glebfm at altlinux dot org> ---
(In reply to Andrew Macleod from comment #7)
> Created attachment 55591 [details]
> potental patch
> 
> I've attached Aldy's patch for PR109695 which he had backported to GCC13
> back in May.
> This does resolve the issue.. Assuming we want to apply it GCC13.  The
> original variant has been in trunk for a while now.  Im running this thru a
> bootstrap/regression run now.
> 
> I don't know if there is anything further you want to try it with?

We have applied this patch in the ALT Sisyphus gcc13 package and have not
encountered any regressions so far (we do daily test rebuilds of the entire
repository for x86_64 arch).  Additionally, we were able to rebuild the
glaxnimate package with gcc13.

[Bug tree-optimization/110315] [13 Regression] g++ crashes with a segmentation fault while compiling a large const std::vector of std::string since r13-6566-ge0324e2629e25a90

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Macleod from comment #7)
> Created attachment 55591 [details]
> potental patch
> 
> I've attached Aldy's patch for PR109695 which he had backported to GCC13
> back in May.
> This does resolve the issue.. Assuming we want to apply it GCC13.  The
> original variant has been in trunk for a while now.  Im running this thru a
> bootstrap/regression run now.
> 
> I don't know if there is anything further you want to try it with?

Can we consider this please?

[Bug tree-optimization/110315] [13 Regression] g++ crashes with a segmentation fault while compiling a large const std::vector of std::string since r13-6566-ge0324e2629e25a90

[amacleod at redhat dot com]

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

--- Comment #11 from Andrew Macleod <amacleod at redhat dot com> ---
(In reply to Richard Biener from comment #10)
> (In reply to Andrew Macleod from comment #7)
> > Created attachment 55591 [details]
> > potental patch
> > 
> > I've attached Aldy's patch for PR109695 which he had backported to GCC13
> > back in May.
> > This does resolve the issue.. Assuming we want to apply it GCC13.  The
> > original variant has been in trunk for a while now.  Im running this thru a
> > bootstrap/regression run now.
> > 
> > I don't know if there is anything further you want to try it with?
> 
> Can we consider this please?

sure. OK for gcc 13 after another round of regressions?

[Bug tree-optimization/110315] [13 Regression] g++ crashes with a segmentation fault while compiling a large const std::vector of std::string since r13-6566-ge0324e2629e25a90

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:70639014a69cf50fe11dc1adbfe1db4c7760ce69

commit r13-7841-g70639014a69cf50fe11dc1adbfe1db4c7760ce69
Author: Andrew MacLeod <amacleod@redhat.com>
Date:   Tue Sep 26 09:44:39 2023 -0400

    Reduce the initial size of int_range_max.

    This patch adds the ability to resize ranges as needed, defaulting to no
    resizing.  int_range_max now defaults to 3 sub-ranges (instead of 255)
    and grows to 255 when the range being calculated does not fit.

            PR tree-optimization/110315
            * value-range-storage.h (vrange_allocator::alloc_irange): Adjust
            new params.
            * value-range.cc (irange::operator=): Resize range.
            (irange::irange_union): Same.
            (irange::irange_intersect): Same.
            (irange::invert): Same.
            * value-range.h (irange::maybe_resize): New.
            (~int_range): New.
            (int_range_max): Default to 3 sub-ranges and resize as needed.
            (int_range::int_range): Adjust for resizing.
            (int_range::operator=): Same.

[Bug tree-optimization/110315] [13 Regression] g++ crashes with a segmentation fault while compiling a large const std::vector of std::string since r13-6566-ge0324e2629e25a90

[amacleod at redhat dot com]

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

Andrew Macleod <amacleod at redhat dot com> changed:

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

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