gcc and alloca

[jacob navia]

Some people here have started saying that "alloca"
is off topic, and they used the argument that the gcc
compiler doesn't recognize it.

They compile their code using the -ansi option, and
(off course) the aptly named "pedantic" option.

I am not related in anyway to the developers of the gcc
compiler but seeing the facts of their implementation
I can't imagine that they would take the effort of making
a BUILT-IN (__builtin) function if they did not want
people to use it.

The gcc compiler in its *default* setting supports alloca
even better than lcc-win32 since they made it a builtin.

And this since ages!

P.S.
Under windows, you have to make a small assembler loop
to touch the allocated pages as you walk down the stack.
This would lead to a slight code bloat and I prefered
the function call method.

 

[Ben Pfaff]

Some people here have started saying that "alloca"
is off topic, and they used the argument that the gcc
compiler doesn't recognize it.

They compile their code using the -ansi option, and
(off course) the aptly named "pedantic" option.

alloca() is not in the Standard. Therefore it is off-topic.

 

[E. Robert Tisdale]

Some people here have started saying that
"alloca" is off topic, and they used the argument that
the gcc compiler doesn't recognize it.

They compile their code using the -ansi option
and (of course) the aptly named "pedantic" option.

I am not related in anyway to the developers of the gcc
compiler but seeing the facts of their implementation
I can't imagine that they would take the effort
of making a BUILT-IN (__builtin) function
if they did not want people to use it.

The gcc compiler in its *default* setting supports alloca
even better than lcc-win32 since they made it a builtin.

And this since ages!

P.S.
Under windows, you have to make a small assembler loop
to touch the allocated pages as you walk down the stack.
This would lead to a slight code bloat and I prefered
the function call method.

Don't use alloca. It is obsolete.
Use "variable length arrays" and the -std=c99 option.

 

[Keith Thompson]

Don't use alloca. It is obsolete.
Use "variable length arrays" and the -std=c99 option.

ERT is correct. (For reasons I won't go into, this is worth pointing
out.)

 

[Gordon Burditt]

Some people here have started saying that "alloca"

is off topic, and they used the argument that the gcc
compiler doesn't recognize it.

They compile their code using the -ansi option, and
(off course) the aptly named "pedantic" option.

I am not related in anyway to the developers of the gcc
compiler but seeing the facts of their implementation
I can't imagine that they would take the effort of making
a BUILT-IN (__builtin) function if they did not want
people to use it.

I believe that alloca() is impossible to implement correctly without
making it a built-in and very difficult to either make work
unrestricted or describe the limits of where you can use it and
where you cannot even if it is a builtin. Early (e.g. a decade or
two ago) versions of GCC that had it as a builtin got it wrong.
Current versions may or may not handle it properly.

A particular problem is that if alloca() is used as a function
argument, arranging NOT to have the space end up somewhere in
the middle of the arguments of the called function.

Look at the generated code for this:

foo(
alloca(10),
alloca(20),
alloca(30),
alloca(40),
alloca(50),
alloca(60),
alloca(70),
alloca(80),
alloca(90),
alloca(100),
alloca(110),
alloca(120),
alloca(130),
alloca(140),
alloca(150),
alloca(160),
alloca(170),
alloca(180),
alloca(190)
);

and see if the arguments passed are 19 pointers and no part of an
uninitialized memory area. If it calls alloca(), pushes the result,
and repeats 19 times, it's going to get it wrong.

Gordon L. Burditt

 

[Richard Bos]

Some people here have started saying that "alloca"
is off topic, and they used the argument that the gcc
compiler doesn't recognize it.

Bullshit, and you know it, navia. alloca() is off-topic here because the
Standard doesn't recognise it. gcc is as immaterial as your own little
toy.

Richard

 

[jacob navia]

The code generated by gcc under linux seems to me 100%
correct. For the example you give, it will always save
the result of alloca and do all the pushes later on, pushing
the saved values.

If your only argument is that this builtin may have had a bug
around 10 years ago... well, I do not know what to say of such
an argumentation other than:

"There is no blinder man than the one that doesn't want to see"

 

[Christian Kandeler]

I am not related in anyway to the developers of the gcc
compiler but seeing the facts of their implementation
I can't imagine that they would take the effort of making
a BUILT-IN (__builtin) function if they did not want
people to use it.

"The alloca function is machine and compiler dependent. On many systems
its implementation is buggy. Its use is dis­couraged."
(from the alloca() man page on my SuSE sytem)

Doesn't sound all that encouraging, does it?


Christian

 

[Dan Pop]

ERT is correct. (For reasons I won't go into, this is worth pointing
out.)

OTOH, alloca is *far* more portable than VLAs... Fortunately, it can
be replaced by malloc and friends in most cases (the only excuse for using
alloca is when malloc and friends render the code too slow for its
intended purpose on its intended platform).

Dan

 

[Dan Pop]

A particular problem is that if alloca() is used as a function
argument, arranging NOT to have the space end up somewhere in
the middle of the arguments of the called function.

Look at the generated code for this:

foo(
alloca(10),
alloca(20),
alloca(30),
alloca(40),
alloca(50),
alloca(60),
alloca(70),
alloca(80),
alloca(90),
alloca(100),
alloca(110),
alloca(120),
alloca(130),
alloca(140),
alloca(150),
alloca(160),
alloca(170),
alloca(180),
alloca(190)
);

and see if the arguments passed are 19 pointers and no part of an
uninitialized memory area. If it calls alloca(), pushes the result,
and repeats 19 times, it's going to get it wrong.

OTOH, how often have you felt the need to use alloca this way?

Although I'm far from being an alloca advocate, I find this example
highly artificial and irrelevant for the typical use of alloca. Even if
the sizes are not constant, as in your trivial example.

Dan

 

[Richard Tobin]

(the only excuse for using
alloca is when malloc and friends render the code too slow for its
intended purpose on its intended platform).

Or too complicated: stack-allocated space has the advantage of being
automatically freed when the function returns, even if it "returns"
as the result of a longjmp.

-- Richard

 

[Villy Kruse]

I believe that alloca() is impossible to implement correctly without
making it a built-in and very difficult to either make work
unrestricted or describe the limits of where you can use it and
where you cannot even if it is a builtin. Early (e.g. a decade or
two ago) versions of GCC that had it as a builtin got it wrong.
Current versions may or may not handle it properly.

The gcc compiler itself uses or used to use alloca so it would be
hard to compile the gcc compiler without a working alloca. For the
bootstrap process there is a pseudo-alloca function including with
the gcc source so you can use alloca even when the native compiler
doesn't support it. I noticed this about a decade ago, so this may
no longer be true.

The various System V release 2 or 3 also had an alloca function hidden
somewhere in an obscure library. It was neither documented, nor working
properly on all platforms.

Villy

 

[Alan Balmer]

Some people here have started saying that "alloca"
is off topic, and they used the argument that the gcc
compiler doesn't recognize it.

No, they used the argument that "alloca" is not part of standard C.
Give it up, Jacob. Even most of our newbies eventually realize that
they are not going to change the declared topicality of this
newsgroup. You've been here long enough that it's getting really
annoying. You have a newsgroup of your own. Take this stuff over
there.

 

[Rob Thorpe]

The code generated by gcc under linux seems to me 100%
correct. For the example you give, it will always save
the result of alloca and do all the pushes later on, pushing
the saved values.

If your only argument is that this builtin may have had a bug
around 10 years ago... well, I do not know what to say of such
an argumentation other than:

"There is no blinder man than the one that doesn't want to see"

There are still outstanding problems with alloca in gcc, in particular
how its implementation interacts with variable length arrays.

I use it anyway.

 

[Emmanuel Delahaye]

Some people here have started saying that "alloca"
is off topic, and they used the argument that the gcc
compiler doesn't recognize it.

Lousy argument. The truth is that, according to international standards, it
doesn't belong to the definition of the C-language.

BTW, on many platform where it was implemented (according what standard, who
knows...) its usage is disencouraged (ranked obsolete or worst).

http://www.hmug.org/man/3/alloca.html
http://www.rt.com/man/alloca.3.html
http://www.neosoft.com/neosoft/man/alloca.3.html
etc.

Topicality is another debatable question.

 

[Dan Pop]

Or too complicated: stack-allocated space has the advantage of being
automatically freed when the function returns, even if it "returns"
as the result of a longjmp.

There is nothing preventing you from doing the cleanup *before* calling
longjmp. And if the code is carefully designed, the cleanup is always
trivial (just take care that each involved pointer is either null or
allocated and call free() on all of them).

Dan

 

[Dave Vandervies]

Some people here have started saying that "alloca"
is off topic, and they used the argument that the gcc
compiler doesn't recognize it.

They compile their code using the -ansi option, and
(off course) the aptly named "pedantic" option.

This looks to me a whole lot like:
"When you ask gcc to act like a C compiler, it doesn't recognize alloca.
Therefore, alloca should be considered topical in a newsgroup that
discusses C."

I think one of us has serious comprehension problems today. I'll refrain
from sharing my opinion about which one.


dave

 

[Dave Vandervies]

In <[email protected]> (e-mail address removed)
(Richard Tobin) writes:

There is nothing preventing you from doing the cleanup *before* calling
longjmp.

That only works if you're calling longjmp directly from that function,
and not from something that it calls.


dave

 

[Keith Thompson]

No, they used the argument that "alloca" is not part of standard C.
Give it up, Jacob. Even most of our newbies eventually realize that
they are not going to change the declared topicality of this
newsgroup. You've been here long enough that it's getting really
annoying. You have a newsgroup of your own. Take this stuff over
there.

Actually, he doesn't. comp.compilers.lcc is about the lcc compiler
<http://www.cs.princeton.edu/software/lcc/>, not just about lcc-win32
<http://www.cs.virginia.edu/~lcc-win32/>.

 

[Alan Balmer]

Actually, he doesn't. comp.compilers.lcc is about the lcc compiler
<http://www.cs.princeton.edu/software/lcc/>, not just about lcc-win32
<http://www.cs.virginia.edu/~lcc-win32/>.

Well, yeah, he doesn't own it ;-) I haven't monitored it, but if he
mentions his version as often there as he does here, it's probably
mostly his <G>.