https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117291
--- Comment #14 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #13)
asm-generic/ is a kernel thing, not relevant at all. bits/resource.h is used
by , the header you should use.
That is used by "system.h" under a
#ifdef H
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117291
--- Comment #13 from Peter Bergner ---
(In reply to Segher Boessenkool from comment #12)
> (In reply to Peter Bergner from comment #10)
> > void
> > stack_limit_increase (unsigned long pref ATTRIBUTE_UNUSED)
> > {
> > #if defined(HAVE_SETRLIMIT)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117291
--- Comment #9 from Segher Boessenkool ---
(In reply to Andrew Pinski from comment #2)
> I am not sure if there is not much to be done.
> The front-end is recusive here:
So you found the bug already. Now fix it :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117291
--- Comment #12 from Segher Boessenkool ---
(In reply to Peter Bergner from comment #10)
> void
> stack_limit_increase (unsigned long pref ATTRIBUTE_UNUSED)
> {
> #if defined(HAVE_SETRLIMIT) && defined(HAVE_GETRLIMIT) \
> && defined(RLIMIT_S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117291
--- Comment #11 from Segher Boessenkool ---
(In reply to Richard Biener from comment #5)
> I agree it's difficult to solve. GCC tries to up the stack limit to
> unlimited, why isn't this working for you? Maybe we should remember the
> failure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117291
--- Comment #10 from Peter Bergner ---
(In reply to Andreas Schwab from comment #8)
> See PR c++/49756. It uses 64MB, not unlimited.
[bergner@ltcden2-lp1 ICE]$ ulimit -s 8192
[bergner@ltcden2-lp1 ICE]$ /opt/gcc-nightly/trunk/bin/gcc -S test.c
g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117291
--- Comment #8 from Andreas Schwab ---
See PR c++/49756. It uses 64MB, not unlimited.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117291
--- Comment #7 from Peter Bergner ---
(In reply to Richard Biener from comment #5)
> I agree it's difficult to solve. GCC tries to up the stack limit to
> unlimited, why isn't this working for you? Maybe we should remember the
> failure to do
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117291
Peter Bergner changed:
What|Removed |Added
CC||segher at gcc dot gnu.org
--- Comment #
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117291
--- Comment #5 from Richard Biener ---
I agree it's difficult to solve. GCC tries to up the stack limit to unlimited,
why isn't this working for you? Maybe we should remember the failure to do so
and report that (and make the segfault handler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117291
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117291
--- Comment #3 from Andrew Pinski ---
You could possibility change this function to use a worklist instead. But I am
not sure having a tree depth this large is in normal code.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117291
--- Comment #2 from Andrew Pinski ---
I am not sure if there is not much to be done.
The front-end is recusive here:
/* Binary operations evaluating both arguments (increment and
decrement are binary internally in GCC). */
13 matches
Mail list logo
