This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: alloca() called when i do not want it to be called


On Tuesday, September 2, 2003, at 09:30 PM, Manik, Raina (IE10) wrote:
I use cygwin gcc 2.9x (and 3.2 sometimes) on x86
or the pe executable format and i have a quick
question about alloca().

1. If i support a new OS, i need to support alloca()
in libgcc.a for the new OS runtime.

Is this a question? Assuming that this was meant as a question, the answer is usually no. On most systems, alloca is always inline. One a few rare and very odd systems, it isn't. So, you question is, is an OS I am thinking of odd, well, that depends upon the OS now, doesn't it. Anything from Microsoft, is odd, the rest are usually not.


2. Is there a way i prevent the compiler from generating assembly code which calls alloca () ?

Yes, but not without changing the compiler. Just fix up i386.md to inline the code from cygwin.asm, though, this isn't beneficial, as it then will bloat the size of function. Just search for alloca and you will find the relevant hunks. If you preprobe lots of stack (lots == 16 or 32 MBs worth of stack) during program startup, you should be able to remove the dynamic probing. I'd recommend that solution I think.


Basically, i want gcc to substitute inline the assembly which would do
what alloca() does without making a call to the function. I tried -fno-builtin which prevents alloca() from being defined even though it's called.

Why would you want to do this? Size wise, it isn't a win. And performance wise, it can kick things out of the cache that would otherwise fit in the cache, causing code to be slower.


This whole issue should probably be discussed on the cygwin mailing list, not this list, as the people there are experts at this sort of system specific detail.

3. Is it true that if one declares a large array on stack,
gcc attempts to satisfy that memory requirement from the
.data section instead of the stack ?

I don't think gcc normally does this.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]