[Bug tree-optimization/100494] [11/12 Regression] Unterminated recursion in gimple-range.cc (x86_64-w64-mingw32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494 --- Comment #15 from Andrew Macleod --- Stack frame depth issued should be completely resolved in GCC12 now by patches for PR 103231 and a follow up for PR 103464.
[Bug tree-optimization/100494] [11/12 Regression] Unterminated recursion in gimple-range.cc (x86_64-w64-mingw32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494 Andrew Macleod changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #14 from Andrew Macleod --- The call chain is a bit less deep in GCC 12 now, but I doubt it can still operate with a stack as small as the original. As there is no un-terminated recursion, I will now close this as I don't plan any additional reductions in the call chain beyond what has been done. Future enhancements may improve it further however.
[Bug tree-optimization/100494] [11/12 Regression] Unterminated recursion in gimple-range.cc (x86_64-w64-mingw32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494 Richard Biener changed: What|Removed |Added Target Milestone|11.2|11.3 --- Comment #13 from Richard Biener --- GCC 11.2 is being released, retargeting bugs to GCC 11.3
[Bug tree-optimization/100494] [11/12 Regression] Unterminated recursion in gimple-range.cc (x86_64-w64-mingw32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494 --- Comment #12 from Andrew Macleod --- My understanding from a quick check around is we usually expect 8-10 MB of stack space. I have an idea how to flatten the call stack a bit, so leave this open for that purpose if nothing else.
[Bug tree-optimization/100494] [11/12 Regression] Unterminated recursion in gimple-range.cc (x86_64-w64-mingw32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494 --- Comment #11 from J.M. Eubank --- Confirmed that building with a larger default stack size on Windows works to bootstrap GCC and binutils and dependencies - I chose -Wl,--stack=10485760 (10 MiB) but probably 2-4 MiB would be sufficient.
[Bug tree-optimization/100494] [11/12 Regression] Unterminated recursion in gimple-range.cc (x86_64-w64-mingw32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494 --- Comment #10 from Andrew Macleod --- I would imagine there is some check I should be making that i was unaware of.. but since I'm unaware of it, I don't know what it is :-) This wouldn't be a "dont use -O2" issue, this would be an "Andrew, check the darn limits before going hogwild on call depth" issue
[Bug tree-optimization/100494] [11/12 Regression] Unterminated recursion in gimple-range.cc (x86_64-w64-mingw32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494 --- Comment #9 from J.M. Eubank --- > I am unfamiliar with what mitigations/flags the compiler has for trying to > control this. It would certainly be possible to monitor the call depth and > cease at a certain point, but Im not sure what needs to be queried. Is this > information communicated by a target in some way? and checked against some > criteria for passes which may need to limit their consumption? +1, this would be nice? I'm running a build with -Wl,--stack=10485760 (10 MiB) to see if this alleviates the problem. However, I'm definitely curious to see how this might be handled for other actually constrained targets where that's not an option - do they simply recommend not to use -O2?
[Bug tree-optimization/100494] [11/12 Regression] Unterminated recursion in gimple-range.cc (x86_64-w64-mingw32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494 --- Comment #8 from Andrew Macleod --- ah. So this is an issue with excessive stack consumption. yeah, we don't really try to reign that in, so certain patterns can get quite deep. I am unfamiliar with what mitigations/flags the compiler has for trying to control this. It would certainly be possible to monitor the call depth and cease at a certain point, but Im not sure what needs to be queried. Is this information communicated by a target in some way? and checked against some criteria for passes which may need to limit their consumption?
[Bug tree-optimization/100494] [11/12 Regression] Unterminated recursion in gimple-range.cc (x86_64-w64-mingw32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494 --- Comment #7 from J.M. Eubank --- Created attachment 51024 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51024=edit sha1.c.038t.evrp.gz > Does the compilation not finish? or just take ma very long time? On the > other targets it finishes very quickly, spending very little time in EVRP. > Its unclear to me why this target would be so different, unless a deep call > stack is a problem. The default stack limit is 1 MiB, so a bit of quick math from the above addresses I posted puts us at 1.2 MiB - this definitely is in line with chkstk failing as we go out of bounds, I think. > Does the issue go away with --param=evrp-mode=legacy ? Yes, it does! > If it does seem to go into an infinite loop, can you try it with >-fdump-tree-evrp-details --param=evrp-mode=trace Attached. joeub@DESKTOP-1LUONFR MINGW64 /crossdev/gccmaster/build-cross4/binutils/libiberty $ /crossdev/gccmaster/host-toolchain-cross4/bin/x86_64-w64-mingw32-gcc -I . -I C:/crossdev/src/binutils-git-2_36_1/libiberty/../include -iprefix c:\crossdev\gccmaster\host-toolchain-cross4\bin\../lib/gcc/x86_64-w64-mingw32/11.1.0/ -D_REENTRANT -D HAVE_CONFIG_H -D __USE_MINGW_ACCESS -D _GNU_SOURCE C:/crossdev/src/binutils-git-2_36_1/libiberty/sha1.c -g -O2 -c -fdump-tree-evrp-details --param=evrp-mode=trace joeub@DESKTOP-1LUONFR MINGW64 /crossdev/gccmaster/build-cross4/binutils/libiberty $ echo $? 1 <-- indicator for chkstk failure in cc1 joeub@DESKTOP-1LUONFR MINGW64 /crossdev/gccmaster/build-cross4/binutils/libiberty $ gzip sha1.c.038t.evrp
[Bug tree-optimization/100494] [11/12 Regression] Unterminated recursion in gimple-range.cc (x86_64-w64-mingw32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494 --- Comment #6 from Andrew Macleod --- WE collided making comments :-) --- or maybe not.. that traceback doesn't look like it would be affected :-(. The traceback also doesn't look like its in an infinite loop?.. there can be long chains of calls to resolve things on back edges. Looking at the listing for that file, I see at its maximal depth, the call chain is 492 "traceable" statements deep. This does not include range_of_range_op or calc_stmt method calls, so Id expect the peak call depth to be about 30-40% higher than that, so somewhere in the 640-690 deep range from the first hybrid_folder::value_on_edge call. Your call chain is at 619, so that is not completely unexpected. Does the compilation not finish? or just take ma very long time? On the other targets it finishes very quickly, spending very little time in EVRP. Its unclear to me why this target would be so different, unless a deep call stack is a problem. Does the issue go away with --param=evrp-mode=legacy ? If it does seem to go into an infinite loop, can you try it with -fdump-tree-evrp-details --param=evrp-mode=trace That will generate a sha1*.evrp file, and if you are truly in an infinite loop it will become quite long. On x86-64 mine is 48940 lines long when it finishes. If you have to stop it, and its growing excessively, I shouldn't need more than the first 50,000 lines to see what going on.
[Bug tree-optimization/100494] [11/12 Regression] Unterminated recursion in gimple-range.cc (x86_64-w64-mingw32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494 --- Comment #5 from J.M. Eubank --- Unfortunately it doesn't seem to have made a difference in this case. x86_64-w64-mingw32-gcc -c -DHAVE_CONFIG_H -O2 -g -D__USE_MINGW_ACCESS -I. -I/crossdev/src/binutils-git-2_36_1/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -Wshadow=local -ped make[3]: *** [Makefile:1260: sha1.o] Error 1 $ /c/crossdev/gccmaster/host-toolchain-cross4/bin/x86_64-w64-mingw32-gcc -v Using built-in specs. COLLECT_GCC=C:\crossdev\gccmaster\host-toolchain-cross4\bin\x86_64-w64-mingw32-gcc.exe COLLECT_LTO_WRAPPER=c:/crossdev/gccmaster/host-toolchain-cross4/bin/../libexec/gcc/x86_64-w64-mingw32/12.0.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../../../src/gcc-git-ecc5644fa3bc7f37eada2a3e9c627cd1918922e0/configure --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --enable-targets=all --target=x86_64-w64-mingw32 --prefix=/crossdev/prefix-cross2-x86_64-w64-mingw32 --enable-static --disable-shared --enable-languages=ada,c,c++ --disable-werror --with-gnu-ld --disable-nls --disable-win32-registry --disable-bootstrap --enable-sjlj-exceptions --enable-threads=posix Thread model: posix Supported LTO compression algorithms: zlib gcc version 12.0.0 20210614 (experimental) (GCC)
[Bug tree-optimization/100494] [11/12 Regression] Unterminated recursion in gimple-range.cc (x86_64-w64-mingw32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494 --- Comment #4 from Andrew Macleod --- I just checked a patch in for PR 101014 which I suspect will fix this as well.. want to give it a try off trunk? I plan to port it to gcc 11 as well
[Bug tree-optimization/100494] [11/12 Regression] Unterminated recursion in gimple-range.cc (x86_64-w64-mingw32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494 --- Comment #3 from J.M. Eubank --- Yes, this definitely seems specific to the native x86_64-w64-mingw32 build.
[Bug tree-optimization/100494] [11/12 Regression] Unterminated recursion in gimple-range.cc (x86_64-w64-mingw32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494 --- Comment #2 from Aldy Hernandez --- I cannot reproduce on a cross configured with: ~/src/gcc/configure --target=x86_64-w64-mingw32 --enable-languages=c --disable-bootstrap I tried: ./cc1 sha1.i -quiet -mtune=generic -march=x86-64 -g -O2 -Wextra -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -Wshadow=local -Wpedantic -w It works in both the GCC 11 branch and trunk.
[Bug tree-optimization/100494] [11/12 Regression] Unterminated recursion in gimple-range.cc (x86_64-w64-mingw32)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100494 Richard Biener changed: What|Removed |Added Summary|Unterminated recursion in |[11/12 Regression] |gimple-range.cc |Unterminated recursion in |(x86_64-w64-mingw32)|gimple-range.cc ||(x86_64-w64-mingw32) Priority|P3 |P2 Target Milestone|--- |11.2
