On Sun, Oct 14, 2012 at 1:05 AM, thorsten <[email protected]> wrote:
> Hello all,
>
> this might be a noob Question but perhaps someone is so kind as to shed some
> light...
>
> using gcc-4.5.4 to build large files (as in wireshark or qemu) with
> Optimizations enabled (in my case -O2 -pipe -march=core2
> -fomit-frame-pointer) I get segmentation faults due to Stack limits, when
> using the standard stacksize on linux.
It is not a large file which is the problem but rather large functions
in this case that is the issue.
>> I figured out that ifcvt.c uses alloca to reserve mem on the stack. this is
> the point where the segmentation fault occurs.
It is also a regression from what I can tell too from 4.1.x.
It was introduced by:
commit 268de9b99fd9a7440549cf09781af0566ff076a1
Author: ian <ian@138bc75d-0d04-0410-961f-82ee72b054a4>
Date: Sun Jan 15 02:49:17 2006 +0000
./:
* ifcvt.c (noce_init_if_info): New static function, broken out of
noce_process_if_block.
(noce_process_if_block): Call noce_init_if_info.
(check_cond_move_block): New static function.
(cond_move_process_if_block): New static function.
(process_if_block): Call cond_move_process_if_block.
testsuite/:
* gcc.target/i386/cmov6.c: New test.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@109717
138bc75d-0d04-0410-961f-82ee72b054a4
Maybe Ian can mention why he used alloca there instead of xmalloc.
Thanks,
Andrew Pinski
>
> So beeing curious, I changed alloca to xmalloc to use the heap instead of
> the stack, thinking this is likely to cause a huge penalty in compile-speed.
> But comparing both the gcc-alloca and gcc-xmalloc the compiletimes do not
> differ significantly. And the gcc-xmalloc does not crash anymore due to
> limited stackspace.
>
> So here is my question: What is the reason for using alloca (Stack) instead
> of xmalloc (heap) in ifcvt.c? I have seen, that also gcc-4.7.2 still uses
> alloca.
>
> Thanks!
>
> Thorsten
