Question about memory allocation in ifcvt.c
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. I figured out that ifcvt.c uses alloca to reserve mem on the stack. this is the point where the segmentation fault occurs. 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
Re: Question about memory allocation in ifcvt.c
On Sun, Oct 14, 2012 at 1:05 AM, thorsten 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 Date: Sun Jan 15 02:49:17 2006 + ./: * 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
Re: Question about memory allocation in ifcvt.c
Andrew Pinski Wrote: >> 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. And one that's fixed for GCC 4.8. See http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00270.html If it's a regression then perhaps the patch could be back-ported to open release branches. Ciao! Steven
Re: thumb2 support
On 11 October 2012 17:58, Grant wrote: >>> Hello, I'm working with the BeagleBone and gcc-4.5.4 on Gentoo. If I >>> try to compile the 3.6 kernel with CONFIG_THUMB2_KERNEL, I get: >>> >>> arch/arm/boot/compressed/head.S:127: Error: selected processor does >>> not support requested special purpose register -- `mrs r2,cpsr' >>> arch/arm/boot/compressed/head.S:134: Error: selected processor does >>> not support requested special purpose register -- `mrs r2,cpsr' >>> arch/arm/boot/compressed/head.S:136: Error: selected processor does >>> not support requested special purpose register -- `msr cpsr_c,r2' >>> >>> This post indicates that mainline gcc does not currently support thumb2: >>> >>> https://groups.google.com/d/msg/beagleboard/P52fgMDzp8A/vupzuh71vdYJ >>> >>> However, this indicates that thumb2 has been supported since 4.3: >>> >>> http://gcc.gnu.org/gcc-4.3/changes.html >>> >>> Can anyone clear this up? >> >> The errors are coming from an assembler file that is not part of the >> GCC sources. Are those instructions valid for Thumb2? I don't know. >> If they are valid, then the issue is with the assembler, which is not >> part of GCC; check the version of the GNU binutils that you have >> installed. If those instructions are not valid, then you need to >> change your source. > > Thanks Ian. I'm using binutils-2.22-r1. Do you happen to know which > version of binutils should support thumb2? Hi Grant. I'm pretty sure this was fixed by: commit c0d796cf810a84f10703c0390f7b1c5887b837c9 Author: Nick Clifton Date: Wed Jun 13 14:18:59 2012 + PR gas/12698 * config/tc-arm.c (do_t_mrs): Do not require an m-profile architecure when assembling for all archiectures. (do_t_msr): Likewise. which will be in the upcoming binutils 2.23. Debian/Ubuntu carry this as a patch on top of their 2.22. -- Michael
gcc-4.8-20121014 is now available
Snapshot gcc-4.8-20121014 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20121014/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.8 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 192442 You'll find: gcc-4.8-20121014.tar.bz2 Complete GCC MD5=1a25042c66ca8be7da25e165771386e8 SHA1=d168e91e5096bf71c16d285c2d814d6a696c7214 Diffs from 4.8-20121007 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.8 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Question about memory allocation in ifcvt.c
On Sun, Oct 14, 2012 at 1:40 AM, Andrew Pinski wrote: > > Maybe Ian can mention why he used alloca there instead of xmalloc. It was a long time ago, but I expect it was just because alloca is usually fine for memory that has to live for just a single function. As a single-threaded program, GCC doesn't normally have severe limits on stack size. This can't have been too big a problem, as I added the code in GCC 4.2 and this is the first complaint I've seen. In any case, as Steven points out, this has been fixed in mainline. Ian
Re: Question about memory allocation in ifcvt.c
On Sun, Oct 14, 2012 at 1:40 AM, Andrew Pinski wrote: Maybe Ian can mention why he used alloca there instead of xmalloc. It was a long time ago, but I expect it was just because alloca is usually fine for memory that has to live for just a single function. As a single-threaded program, GCC doesn't normally have severe limits on stack size. This can't have been too big a problem, as I added the code in GCC 4.2 and this is the first complaint I've seen. In any case, as Steven points out, this has been fixed in mainline. Ian Thanks for the hints, I will try to backport the fix to 4.5 thorsten
