https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87589
--- Comment #14 from GCC Commits ---
The master branch has been updated by Rainer Orth :
https://gcc.gnu.org/g:9ab90fc627301b1701cf19bf4ca220f02a93d894
commit r15-1091-g9ab90fc627301b1701cf19bf4ca220f02a93d894
Author: Rainer Orth
Date: Fri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87589
--- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #12 from Ian Lance Taylor ---
> Sure, we can do that patch for now. Thanks. unsupported is fine too.
I've posted the patch now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87589
--- Comment #12 from Ian Lance Taylor ---
Sure, we can do that patch for now. Thanks. unsupported is fine too.
Let's not close the bug, though. The real fix is to not put very large objects
on the stack--we don't want to do that for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87589
--- Comment #11 from Rainer Orth ---
Created attachment 58357
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58357=edit
Proposed patch
Wouldn't the attached patch be TRT then?
Btw., ISTM that this should be unsupported instead of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87589
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #9 from Ian Lance Taylor ---
> It does work for me on x86_64 GNU/Linux. The big stack allocation is handled
> by the split-stack support.
I think I see what's happening
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87589
--- Comment #9 from Ian Lance Taylor ---
It does work for me on x86_64 GNU/Linux. The big stack allocation is handled
by the split-stack support.
This of course leaves the question of why it is making such a large stack
allocation to begin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87589
--- Comment #8 from Rainer Orth ---
Something is still very wrong with this test: it FAILs not only on Solaris/x86,
but also Solaris/SPARC and Linux/x86_64, always with a SEGV.
Looking closer, I checked the 32-bit Solaris/x86 test, which SEGVs
