[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806 Amyspark changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #20 from Amyspark --- 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!
[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806 --- Comment #19 from Amyspark --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806 Richard Biener changed: What|Removed |Added Status|NEW |WAITING --- Comment #18 from Richard Biener --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806 Richard Biener changed: What|Removed |Added Target Milestone|13.2|13.3 --- Comment #17 from Richard Biener --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806 --- Comment #16 from Sam James --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806
--- Comment #15 from Jakub Jelinek ---
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 0x00c4eee1 in layout_class_type (t=, virtuals_p=0x7fffd4c8)
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806 --- Comment #14 from Sam James --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806 Alexander Monakov changed: What|Removed |Added CC||amonakov at gcc dot gnu.org --- Comment #13 from Alexander Monakov --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806
Sam James 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 ---
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
[Bug tree-optimization/109806] [13/14 Regression] 13.1.0 cc1plus stack smashing crash with C array of complex structs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #11 from Sam James --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806 Christoph Reiter changed: What|Removed |Added CC||reiter.christoph at gmail dot com --- Comment #10 from Christoph Reiter --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806
--- Comment #9 from Amyspark ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109806
Andrew Pinski 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 ---
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 0x01f7c9dc in gori_compute::compute_operand1_range (this=0x32aea00,
r=..., handler=..., lhs=..., name=0x779c3318, src=..., rel=0x0) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-gori.cc:1081
#1 0x01f7ad71 in gori_compute::compute_operand_range (this=0x32aea00,
r=..., stmt=0x779cf0a0, lhs=..., name=0x779c3318, src=..., rel=0x0) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-gori.cc:711
#2 0x01f7eeed in gori_compute::compute_operand_range (rel=0x0,
src=..., name=0x779c3318, lhs=..., stmt=0x779cf0a0, 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=0x779c1f00, name=name@entry=0x779c3318, q=...) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-gori.cc:1422
#4 0x01f6f65f in ranger_cache::range_from_dom (this=,
r=..., name=0x779c3318, start_bb=,
mode=ranger_cache::RFD_FILL) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-cache.cc:1629
#5 0x01f7140a in ranger_cache::range_from_dom
(mode=ranger_cache::RFD_FILL, start_bb=0x779b5ae0, name=0x779c3318,
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=0x779c3318,
bb=0x779b5ae0, def_bb=0x779b5a80) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-cache.cc:1317
#7 0x01f72082 in ranger_cache::block_range (this=0x32ae9f0, r=...,
bb=0x779b5ae0, name=0x779c3318, calc=true) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-cache.cc:1144
#8 0x01f68dda in gimple_ranger::range_on_entry (this=0x32ae9d0, r=...,
bb=0x779b5ae0, name=0x779c3318) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range.cc:156
#9 0x01f6be2a in gimple_ranger::range_of_expr (this=0x32ae9d0, r=...,
expr=0x779c3318, stmt=) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range.cc:130
#10 0x01f762bf in fold_using_range::range_of_range_op (this=, r=..., handler=..., src=...) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/value-range.h:611
#11 0x01f77db3 in fold_using_range::fold_stmt (this=0x7ffd5560,
r=..., s=0x779d0108, src=..., name=0x779c3438) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range-fold.cc:490
#12 0x01f6999a in gimple_ranger::fold_range_internal
(name=0x779c3438, s=0x779d0108, 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=0x779c3318) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range.cc:392
#14 0x01f6a45b in gimple_ranger::range_of_stmt (this=0x32ae9d0, r=...,
s=0x779caf00, name=) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range.cc:314
#15 0x01f6a629 in gimple_ranger::register_inferred_ranges
(this=0x32ae9d0, s=s@entry=0x779caf00) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/gimple-range.cc:474
#16 0x0154d2b1 in rvrp_folder::pre_fold_bb (this=0x7fffd940,
bb=0x779b5a80) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-vrp.cc:944
#17 0x0144a976 in substitute_and_fold_dom_walker::before_dom_children
(this=0x7fffd890, bb=0x779b5a80) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-ssa-propagate.cc:734
#18 0x01f38f3f in dom_walker::walk (this=0x7fffd890,
bb=0x779b5a80) at /home/apinski/src/upstream-gcc-git/gcc/gcc/domwalk.cc:311
#19 0x01449816 in substitute_and_fold_engine::substitute_and_fold
(this=this@entry=0x7fffd940, block=block@entry=0x0) at
/home/apinski/src/upstream-gcc-git/gcc/gcc/tree-ssa-propagate.cc:971
#20 0x0154b6ca in execute_ranger_vrp (fun=0x779c52e0,
