[Bug c++/109806] New: 13.1.0 cc1plus stack smashing crash with C array of complex structs

[Bug c++/109806] New: 13.1.0 cc1plus stack smashing crash with C array of complex structs

[amy at amyspark dot me]

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

            Bug ID: 109806
           Summary: 13.1.0 cc1plus stack smashing crash with C array of
                    complex structs
           Product: gcc
           Version: 13.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: amy at amyspark dot me
  Target Milestone: ---

Hi,

Coming from
https://github.com/msys2/MINGW-packages/pull/16968#issuecomment-1541465457.
I've found a crash in cc1plus 13.1.0 when building an array of ~68 structs in
C++. The crash yields no report or crash handling, it just causes g++  to
return exit code 1.

However, I was able to trap the cc1plus execution line, and then run it
manually under GDB. This yielded a symbolicated stacktrace that I've uploaded
along with the preprocessed file (it's 1.6MB, so it was impossible to attach
them here uncompressed):

https://gist.github.com/amyspark/be93638fc5b5779594dd138aa8995860

GCC version data:

Using built-in specs.
COLLECT_GCC=D:\msys64\ucrt64\bin\gcc.exe
COLLECT_LTO_WRAPPER=D:/msys64/ucrt64/bin/../lib/gcc/x86_64-w64-mingw32/13.1.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-13.1.0/configure --prefix=/ucrt64
--with-local-prefix=/ucrt64/local --build=x86_64-w64-mingw32
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32
--with-native-system-header-dir=/ucrt64/include --libexecdir=/ucrt64/lib
--enable-bootstrap --enable-checking=release --with-arch=nocona
--with-tune=generic --enable-languages=c,lto,c++,fortran,ada,objc,obj-c++,jit
--enable-shared --enable-static --enable-libatomic --enable-threads=posix
--enable-graphite --enable-fully-dynamic-string
--enable-libstdcxx-filesystem-ts --enable-libstdcxx-time
--disable-libstdcxx-pch --enable-lto --enable-libgomp --disable-libssp
--disable-multilib --disable-rpath --disable-win32-registry --disable-nls
--disable-werror --disable-symvers --with-libiconv --with-system-zlib
--with-gmp=/ucrt64 --with-mpfr=/ucrt64 --with-mpc=/ucrt64 --with-isl=/ucrt64
--with-pkgversion=Rev4, Built by MSYS2 project
--with-bugurl=https://github.com/msys2/MINGW-packages/issues --with-gnu-as
--with-gnu-ld --enable-libstdcxx-debug --with-boot-ldflags="-static-libstdc++"
--with-stage1-ldflags="-static-libstdc++"
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.1.0 (Rev4, Built by MSYS2 project) 

Prior to https://github.com/msys2/MINGW-packages/pull/17094, the CFLAGS value
was (I added debug !strip to the PKGBUILD options to get debugging symbols):

-g -march=nocona -msahf -mtune=generic -O2 -pipe -Wp,-D_FORTIFY_SOURCE=2
-fstack-protector-strong -ggdb -Og
-ffile-prefix-map=/c/Users/Amalia/Desktop/MINGW-packages/mingw-w64-gcc/src=/usr/src/debug/mingw-w64-gcc

[Bug tree-optimization/109806] 13.1.0 cc1plus stack smashing crash with C array of complex structs

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
>it's 1.6MB, so it was impossible to attach them here uncompressed

Can you try to compress it and attach it?

[Bug tree-optimization/109806] 13.1.0 cc1plus stack smashing crash with C array of complex structs

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amacleod at redhat dot com

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Likely a duplicate of a bug where ranger runs out of stack on windows targets.

[Bug tree-optimization/109806] 13.1.0 cc1plus stack smashing crash with C array of complex structs

[amy at amyspark dot me]

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

--- Comment #3 from Amyspark <amy at amyspark dot me> ---
Created attachment 55046
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55046&action=edit
ZIP copy of the Github gist

[Bug tree-optimization/109806] 13.1.0 cc1plus stack smashing crash with C array of complex structs

[amy at amyspark dot me]

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

--- Comment #4 from Amyspark <amy at amyspark dot me> ---
(In reply to Richard Biener from comment #2)
> Likely a duplicate of a bug where ranger runs out of stack on windows
> targets.

I think you mean bug 109695? If so, it affects GCC 13 as well.

[Bug tree-optimization/109806] 13.1.0 cc1plus stack smashing crash with C array of complex structs

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Amyspark from comment #4)
> (In reply to Richard Biener from comment #2)
> > Likely a duplicate of a bug where ranger runs out of stack on windows
> > targets.
> 
> I think you mean bug 109695? If so, it affects GCC 13 as well.

Yeah, the rev in that bug increases stack requirement even more though, but
yes, I think the problem is the same in principle.

[Bug tree-optimization/109806] 13.1.0 cc1plus stack smashing crash with C array of complex structs

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Reducing .... (I can get the fault if we reduce the stack limit down to 1024 on
Linux via `ulimit -s 1024` ).

[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |13.2
     Ever confirmed|0                           |1
            Summary|13.1.0 cc1plus stack        |[13/14 Regression] 13.1.0
                   |smashing crash with C array |cc1plus stack smashing
                   |of complex structs          |crash with C array of
                   |                            |complex structs
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2023-05-11
           Severity|normal                      |critical
           Keywords|                            |memory-hog

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Simple testcase:
```
struct basic_string {
  ~basic_string() { }
};
const basic_string data[] = { {} };
```

This fails with `ulimit -s 1024` which is not unreasonable limit even. The
default on Linux is 8MB, I just reduced it down to 1MB.

Backtrace:
#0  0x0000000001f7c9dc in gori_compute::compute_operand1_range (this=0x32aea00,
r=..., handler=..., lhs=..., name=0x7ffff79c3318, src=..., rel=0x0) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-gori.cc:1081
#1  0x0000000001f7ad71 in gori_compute::compute_operand_range (this=0x32aea00,
r=..., stmt=0x7ffff79cf0a0, lhs=..., name=0x7ffff79c3318, src=..., rel=0x0) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-gori.cc:711
#2  0x0000000001f7eeed in gori_compute::compute_operand_range (rel=0x0,
src=..., name=0x7ffff79c3318, lhs=..., stmt=0x7ffff79cf0a0, r=...,
this=0x32aea00) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-gori.cc:611
#3  gori_compute::outgoing_edge_range_p (this=this@entry=0x32aea00, r=...,
e=e@entry=0x7ffff79c1f00, name=name@entry=0x7ffff79c3318, q=...) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-gori.cc:1422
#4  0x0000000001f6f65f in ranger_cache::range_from_dom (this=<optimized out>,
r=..., name=0x7ffff79c3318, start_bb=<optimized out>,
mode=ranger_cache::RFD_FILL) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-cache.cc:1629
#5  0x0000000001f7140a in ranger_cache::range_from_dom
(mode=ranger_cache::RFD_FILL, start_bb=0x7ffff79b5ae0, name=0x7ffff79c3318,
r=..., this=0x32ae9f0) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-cache.cc:1526
#6  ranger_cache::fill_block_cache (this=0x32ae9f0, name=0x7ffff79c3318,
bb=0x7ffff79b5ae0, def_bb=0x7ffff79b5a80) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-cache.cc:1317
#7  0x0000000001f72082 in ranger_cache::block_range (this=0x32ae9f0, r=...,
bb=0x7ffff79b5ae0, name=0x7ffff79c3318, calc=true) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-cache.cc:1144
#8  0x0000000001f68dda in gimple_ranger::range_on_entry (this=0x32ae9d0, r=...,
bb=0x7ffff79b5ae0, name=0x7ffff79c3318) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range.cc:156
#9  0x0000000001f6be2a in gimple_ranger::range_of_expr (this=0x32ae9d0, r=...,
expr=0x7ffff79c3318, stmt=<optimized out>) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range.cc:130
#10 0x0000000001f762bf in fold_using_range::range_of_range_op (this=<optimized
out>, r=..., handler=..., src=...) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/value-range.h:611
#11 0x0000000001f77db3 in fold_using_range::fold_stmt (this=0x7ffffffd5560,
r=..., s=0x7ffff79d0108, src=..., name=0x7ffff79c3438) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-fold.cc:490
#12 0x0000000001f6999a in gimple_ranger::fold_range_internal
(name=0x7ffff79c3438, s=0x7ffff79d0108, r=..., this=0x32ae9d0) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range.cc:257
#13 gimple_ranger::prefill_stmt_dependencies (this=0x32ae9d0,
ssa=0x7ffff79c3318) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range.cc:392
#14 0x0000000001f6a45b in gimple_ranger::range_of_stmt (this=0x32ae9d0, r=...,
s=0x7ffff79caf00, name=<optimized out>) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range.cc:314
#15 0x0000000001f6a629 in gimple_ranger::register_inferred_ranges
(this=0x32ae9d0, s=s@entry=0x7ffff79caf00) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range.cc:474
#16 0x000000000154d2b1 in rvrp_folder::pre_fold_bb (this=0x7fffffffd940,
bb=0x7ffff79b5a80) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-vrp.cc:944
#17 0x000000000144a976 in substitute_and_fold_dom_walker::before_dom_children
(this=0x7fffffffd890, bb=0x7ffff79b5a80) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-ssa-propagate.cc:734
#18 0x0000000001f38f3f in dom_walker::walk (this=0x7fffffffd890,
bb=0x7ffff79b5a80) at /home/apinski/src/upstream-gcc-git/gcc/gcc/domwalk.cc:311
#19 0x0000000001449816 in substitute_and_fold_engine::substitute_and_fold
(this=this@entry=0x7fffffffd940, block=block@entry=0x0) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-ssa-propagate.cc:971
#20 0x000000000154b6ca in execute_ranger_vrp (fun=0x7ffff79c52e0,
warn_array_bounds_p=false, final_p=false) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-vrp.cc:997


compute_operand1_range has a stack size of `120k` which seems large in itself
really.

[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Strange.  On 13 branch it compiles fine for me with ulimit -s 128.  Fails with
ulimit -s 64, but in that case gdb doesn't start either.

[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs

[amy at amyspark dot me]

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

--- Comment #9 from Amyspark <amy at amyspark dot me> ---
(In reply to Andrew Pinski from comment #7)
> Simple testcase:
> ```
> struct basic_string {
>   ~basic_string() { }
> };
> const basic_string data[] = { {} };
> ```
> 
> This fails with `ulimit -s 1024` which is not unreasonable limit even. The
> default on Linux is 8MB, I just reduced it down to 1MB.
> 

The default in Windows is 1MB last time I checked with my G'MIC fork, perhaps
that's why it's easier to reproduce there.

[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs

[reiter.christoph at gmail dot com]

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

Christoph Reiter <reiter.christoph at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |reiter.christoph at gmail dot com

--- Comment #10 from Christoph Reiter <reiter.christoph at gmail dot com> ---
I've compared [0] the stack size of the two builds now, and it looks like me
setting BOOT_LDFLAGS [1] somehow made the build skip the stack size adjustment
here:
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=config/mh-mingw;h=e91367a711284148e16849d3066fb94599204a6c;hb=HEAD#l15
leading to the low Windows stack size defaults

So this might not be a bug, but having built gcc wrong.

[0] objdump.exe -x /ucrt64/lib/gcc/x86_64-w64-mingw32/13.1.0/cc1plus.exe | grep
SizeOfStackReserve
[1]
https://github.com/msys2/MINGW-packages/commit/518e217a129eeeb92e5090f1bb14deaf0ed70edf#diff-cf683a120abf18dd9f774ea5df77137d01e19f359f7cb40c1fc152355cde7b80R265

[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs

[sjames at gcc dot gnu.org]

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

Sam James <sjames at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sjames at gcc dot gnu.org

--- Comment #11 from Sam James <sjames at gcc dot gnu.org> ---
There's still a bug here wrt ranger using a huge amount of stack, I think, but
I see - thanks.

[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs

[sjames at gcc dot gnu.org]

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

Sam James <sjames at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aldyh at gcc dot gnu.org
           See Also|                            |https://bugs.gentoo.org/sho
                   |                            |w_bug.cgi?id=906380

--- Comment #12 from Sam James <sjames at gcc dot gnu.org> ---
I think I'm hitting this on musl too. Reported in Gentoo at
https://bugs.gentoo.org/906380.

For me, this crashes on x86_64-gentoo-linux-musl:
```
struct SimpleRefCounted {
  virtual void addRef();
};
struct timespec {
  long tv_nsec;
  int : 0;
};
struct ClockImpl : SimpleRefCounted {
  timespec _startTime;
};
struct Clock {
  Clock();
};
Clock::Clock() { ClockImpl(); }
```

with:
```
# g++ /tmp/foo.cxx -O2 -wrapper valgrind
==1239523== Memcheck, a memory error detector
==1239523== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==1239523== Using Valgrind-3.21.0 and LibVEX; rerun with -h for copyright info
==1239523== Command: /usr/libexec/gcc/x86_64-gentoo-linux-musl/13/cc1plus
-quiet -D_GNU_SOURCE /tmp/foo.cxx -quiet -dumpdir a- -dumpbase foo.cxx
-dumpbase-ext .cxx -mtune=generic -march=x86-64 -O2 -fcf-protection -o
/tmp/ccigHfiN.s
==1239523==
==1239523== Invalid read of size 1
==1239523==    at 0x97844C: to_wide (tree.h:6257)
==1239523==    by 0x97844C: irange::set_varying(tree_node*) (value-range.h:959)
==1239523==    by 0x10C1A45: range_query::get_tree_range(vrange&, tree_node*,
gimple*) (value-query.cc:252)
==1239523==    by 0x1B52256: gimple_ranger::range_of_stmt(vrange&, gimple*,
tree_node*) (gimple-range.cc:298)
==1239523==    by 0x1B52778: gimple_ranger::register_inferred_ranges(gimple*)
(gimple-range.cc:474)
==1239523==    by 0x109FB19: rvrp_folder::fold_stmt(gimple_stmt_iterator*)
(tree-vrp.cc:1079)
==1239523==    by 0xFA9ED3:
substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
(tree-ssa-propagate.cc:848)
==1239523==    by 0x1B24C2E: dom_walker::walk(basic_block_def*)
(domwalk.cc:311)
==1239523==    by 0xFA9312:
substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
(tree-ssa-propagate.cc:971)
==1239523==    by 0x109DB80: execute_ranger_vrp(function*, bool, bool)
(tree-vrp.cc:1107)
==1239523==    by 0xD3A0EA: execute_one_pass(opt_pass*) (passes.cc:2651)
==1239523==    by 0xD3A9AF: execute_pass_list_1(opt_pass*) (passes.cc:2760)
==1239523==    by 0xD3A9C1: execute_pass_list_1(opt_pass*) (passes.cc:2761)
==1239523==  Address 0x4 is not stack'd, malloc'd or (recently) free'd
==1239523==
during GIMPLE pass: evrp
/tmp/foo.cxx: In constructor 'Clock::Clock()':
/tmp/foo.cxx:14:31: internal compiler error: Segmentation fault
   14 | Clock::Clock() { ClockImpl(); }
      |                               ^

0xe10df3 crash_signal
       
/usr/src/debug/sys-devel/gcc-13.1.1_p20230513/gcc-13-20230513/gcc/toplev.cc:314
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://bugs.gentoo.org/> for instructions.
```

(Obviously crashes w/o valgrind too, just the output is way less helpful.)

Note that musl has a small default stack size, as I mentioned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109695#c18.

[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs

[amonakov at gcc dot gnu.org]

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

Alexander Monakov <amonakov at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amonakov at gcc dot gnu.org

--- Comment #13 from Alexander Monakov <amonakov at gcc dot gnu.org> ---
The 128KB stack size is for *secondary* threads on musl (i.e. those created via
pthread_create). The main thread has the same stack as on glibc (GCC extends it
to 128MB unless there's a hard limit).

This doesn't look like a stack exhaustion and should be a separate bug.

[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs

[sjames at gcc dot gnu.org]

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

--- Comment #14 from Sam James <sjames at gcc dot gnu.org> ---
(In reply to Alexander Monakov from comment #13)
> The 128KB stack size is for *secondary* threads on musl (i.e. those created
> via pthread_create). The main thread has the same stack as on glibc (GCC
> extends it to 128MB unless there's a hard limit).

To be fair, I didn't know if gcc did everything in a single thread. Thanks.

> 
> This doesn't look like a stack exhaustion and should be a separate bug.

I asked on IRC and was pointed here rather than file a dupe, but I'll file one
now in that case.

[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
That ICE is because layout_class_type calls c_build_bitfield_integer_type with
width of 0 and that type is then seen by ranger for some reason:
#7  0x0000000000c4eee1 in layout_class_type (t=<record_type 0x7fffea2ee348
timespec>, virtuals_p=0x7fffffffd4c8)
    at ../../gcc/cp/class.cc:6858
6853              tree ftype = TREE_TYPE (field);
6854              width = tree_to_uhwi (DECL_SIZE (field));
6855              if (width != TYPE_PRECISION (ftype))
6856                {
6857                  TREE_TYPE (field)
6858                    = c_build_bitfield_integer_type (width,
6859                                                     TYPE_UNSIGNED
(ftype));
6860                  TREE_TYPE (field)
6861                    = cp_build_qualified_type (TREE_TYPE (field),
6862                                               cp_type_quals (ftype));
I think unnamed bitfields are just padding and shouldn't have this called.

[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs

[sjames at gcc dot gnu.org]

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

--- Comment #16 from Sam James <sjames at gcc dot gnu.org> ---
Filed my musl one as PR109868, sorry for clogging up this one!

[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs

[rguenth at gcc dot gnu.org]

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

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

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

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

[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |WAITING

--- Comment #18 from Richard Biener <rguenth at gcc dot gnu.org> ---
Note ranger memory usage should be significantly lower now, the relevant change
was also backported to the GCC 13 branch, but after 13.2 was released so only
for GCC 13.3.

Can the original reporter please check with a GCC 13 build from after Sep 26
(r13-7841-g70639014a69cf5)?

[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs

[amy at amyspark dot me]

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

--- Comment #19 from Amyspark <amy at amyspark dot me> ---
Working on it. Is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110315 the patch
you referred to earlier, Richard?

[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs

[amy at amyspark dot me]

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

Amyspark <amy at amyspark dot me> changed:

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

--- Comment #20 from Amyspark <amy at amyspark dot me> ---
Update: verified this now works:

- MSYS2's current GCC (13.2.0
https://github.com/msys2/MINGW-packages/commits/master/mingw-w64-gcc, having
the GCC-enlarged stack)

- with commit 928c204030fe6c8856b76fd3d6f3583902389ad3 from releases/gcc-13
(plus the "breaking" flags reverted in
https://github.com/msys2/MINGW-packages/commit/7e396296feeb89af1e9c00f5d7e39ba992de2150,
shortening the stack as described earlier) .

Thanks!