Further observations regarding alloca on i586-pc-linux-gnu

Further observations regarding alloca on i586-pc-linux-gnu

[Joerg Pommnitz]

While the following code dies with a segmentation violation
---
include <cstdlib>
#include <iostream>

class xx {
public:
        char *xy (char *c = alloca (18)) {
                strcpy (c, "Hello World!");
                return c;
        }
};

int
main ()
{
        xx x;
        cout << x.xy () << endl;
}  
---

this one works fine:

#include <cstdlib>
#include <iostream>

class xx {
public:
    char *xy (char *c = alloca (18)) {
	strcpy (c, "Hello World!");
	return c;
    }
};

int
main ()
{
    xx x;
    char *c = alloca (18);

    cout << x.xy (c) << endl;
}

Is this a bug? I think yes, but I'm not sure whether case #1
is supposed to work. Since alloca is a compiler builtin 
function this relates to egcs development and should either be
fixed or documented.

-- 
Regards
       Joerg
GMD-IPSI, Dolivostr. 15, Zimmer 120, D-64293 Darmstadt
+49-6151-869-786 (Phone), -818 (FAX)

Re: Further observations regarding alloca on i586-pc-linux-gnu

[Noel Yap]

Joerg Pommnitz wrote:
> 
> While the following code dies with a segmentation violation
> ---
> include <cstdlib>
> #include <iostream>
> 
> class xx {
> public:
>         char *xy (char *c = alloca (18)) {
>                 strcpy (c, "Hello World!");
>                 return c;
>         }
> };
> 
> int
> main ()
> {
>         xx x;
>         cout << x.xy () << endl;
> }
> ---
> 
> this one works fine:
> 
> #include <cstdlib>
> #include <iostream>
> 
> class xx {
> public:
>     char *xy (char *c = alloca (18)) {
>         strcpy (c, "Hello World!");
>         return c;
>     }
> };
> 
> int
> main ()
> {
>     xx x;
>     char *c = alloca (18);
> 
>     cout << x.xy (c) << endl;
> }
> 
> Is this a bug? I think yes, but I'm not sure whether case #1
> is supposed to work. Since alloca is a compiler builtin
> function this relates to egcs development and should either be
> fixed or documented.

Whose stack does will xy's alloca() call execute in?  It should _not_
be executed in main() regardless of whether xy() is inlined or not.
Function behaviour should not change based on its inline status,
otherwise different inlining heuristics would produce different
executables.

Noel

Re: Further observations regarding alloca on i586-pc-linux-gnu

[Alexandre Oliva]

Joerg Pommnitz <pommnitz@darmstadt.gmd.de> writes:

> While the following code dies with a segmentation violation

> #include <cstdlib>
> #include <iostream>
> class xx { public: char *xy (char *c = alloca (18)) {
>                 strcpy (c, "Hello World!"); return c; } };
> int main () { xx x; cout << x.xy () << endl; }

> Is this a bug? I think yes, but I'm not sure whether case #1
> is supposed to work.

IMO, it should work on x86, as it does on sparc and alpha.  The
problem is that the stack pointer is moved after pushing default
arguments onto the stack.

Unfortunately, I don't have the (time required to develop) skills
needed to fix it, so I'll leave this for someone else.

Anyway, next time you report a problem, please clearly state on which
platform you have encountered it, and which compiler options you have
used.  It took me some time to find out the problem would only occur
on x86 without optimization!

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: Further observations regarding alloca on i586-pc-linux-gnu

[Carlo Wood]

| Joerg Pommnitz <pommnitz@darmstadt.gmd.de> writes:
| 
| > While the following code dies with a segmentation violation
| 
| > #include <cstdlib>
| > #include <iostream>
| > class xx { public: char *xy (char *c = alloca (18)) {
| >                 strcpy (c, "Hello World!"); return c; } };
| > int main () { xx x; cout << x.xy () << endl; }
| 
| > Is this a bug? I think yes, but I'm not sure whether case #1
| > is supposed to work.
| 
| IMO, it should work on x86, as it does on sparc and alpha.  The
| problem is that the stack pointer is moved after pushing default
| arguments onto the stack.
| 
| Unfortunately, I don't have the (time required to develop) skills
| needed to fix it, so I'll leave this for someone else.
| 
| Anyway, next time you report a problem, please clearly state on which
| platform you have encountered it, and which compiler options you have
| used.  It took me some time to find out the problem would only occur
| on x86 without optimization!

After a little bit of experimenting, I found what is happening:

  cout << alloca (20) << '\n';

becomes:

???     pushl $10		# put '\n' on the stack
        addl $-20,%esp		# allocate 20 bytes on the stack
        movl %esp,%eax
        pushl %eax		# write the result of alloca() to cout
        pushl $cout
.LCFI2:
        call __ls__7ostreamPCv
        addl $8,%esp		# correct last two pushes.
        movl %eax,%eax		# put return value `cout' on the stack:
        pushl %eax
        call __ls__7ostreamc	# Try to write '\n' (fails, stack pointer wrong).
        addl $8,%esp		# "correct" wrongly stack for push $10 and last push.


Correct would be:

        addl $-20,%esp		# allocate 20 bytes on the stack
        movl %esp,%eax
!!!     pushl $10		# put '\n' on the stack
        pushl %eax		# write the result of alloca() to cout
..etc

In other words: This is a bug.

-- 
 Carlo Wood  <carlo@runaway.xs4all.nl>

Re: Further observations regarding alloca on i586-pc-linux-gnu

[Richard Henderson]

On Sat, Aug 22, 1998 at 07:24:11PM +0200, Carlo Wood wrote:
> ???     pushl $10		# put '\n' on the stack
>         addl $-20,%esp		# allocate 20 bytes on the stack
[...]
> In other words: This is a bug.

This is well known.  What is not clear to me though, is whether
it is a bug in the compiler or in the test. 

The test is effectively relying on the order in which arguments
are evaluated, which is wrong.  Note that the exact same effect
would happen if alloca was not a builtin.  Note that if you mind
sequence points like you ought, you get correct results.


r~

Re: Further observations regarding alloca on i586-pc-linux-gnu

[Martin von Loewis]

> This is well known.  What is not clear to me though, is whether
> it is a bug in the compiler or in the test. 

I've tried to find documentation on the semantics of alloca in gcc,
but didn't found much. The portable alloca.c says

>>  allocate automatically reclaimed memory

and this is how most users probably see it. extend.texi says that the
memory is available until the end of the function.

> The test is effectively relying on the order in which arguments are
> evaluated, which is wrong.

No, it doesn't. It requests memory reclaimed at the end of the
function. As it turns out, the compiler might overwrite the memory
allocated.

> Note that the exact same effect would happen if alloca was not a
> builtin.

No, it wouldn't. The portable alloca would not reclaim the memory
until the next alloca call, and then only if the previous call was
deeper on stack.

> Note that if you mind sequence points like you ought, you get
> correct results.

The original example was using alloca as a default argument. It seems
that g++ currently does not support that, an alloca call must occur as
a full expression in itself, not inside a full expression.

So it seems g++ should either detect this violation in alloca usage,
or be fixed to support alloca in subexpressions.

Regards,
Martin

Re: Further observations regarding alloca on i586-pc-linux-gnu

[Richard Henderson]

On Sun, Aug 23, 1998 at 08:20:05PM +0200, Martin von Loewis wrote:
> > Note that the exact same effect would happen if alloca was not a
> > builtin.
> 
> No, it wouldn't. The portable alloca would not reclaim the memory
> until the next alloca call, and then only if the previous call was
> deeper on stack.

No no, I meant the olde tyme non-portable alloca.  You know:

	alloca: popl	%edx
		subl	%eax, %esp
		movl	%esp, %eax
		jmp	*%edx

> > Note that if you mind sequence points like you ought, you get
> > correct results.
> 
> The original example was using alloca as a default argument. It seems
> that g++ currently does not support that, an alloca call must occur as
> a full expression in itself, not inside a full expression.

"Full expression" isn't a term I'm familiar with.  Besides,

	(tmp = alloca(n), foo(tmp, blah));

works just fine.  It seems that alloca must be the first thing
after a sequence point.  How to enforce or even warn about this
I have absolutely no idea.


r~

Re: Further observations regarding alloca on i586-pc-linux-gnu

[Martin von Loewis]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 789 bytes --]

> "Full expression" isn't a term I'm familiar with.  

This is a term from the ISO C++ standard, 1.8 [intro.execution]/12

>> A <em>full­expression</em> is an expression that is not a
>> subexpression of another expression. If a language construct is
>> defined to produce an implicit call of a function, a use of the
>> language construct is considered to be an expression for the
>> purposes of this definition.

> It seems that alloca must be the first thing after a sequence point.
> How to enforce or even warn about this I have absolutely no idea.

Yes, it would be tricky to explain under what circumstances it works
and when it doesn't. If we'd enforce a rule, it would probably outlaw
cases that do work right now. So it seems more reasonable to support
it everywhere.

Martin

Re: Further observations regarding alloca on i586-pc-linux-gnu

[Jeffrey A Law]

  In message < 199808231820.UAA00204@mira.isdn.cs.tu-berlin.de >you write:
  > > This is well known.  What is not clear to me though, is whether
  > > it is a bug in the compiler or in the test. 
  > 
  > I've tried to find documentation on the semantics of alloca in gcc,
  > but didn't found much. The portable alloca.c says
I don't think alloca's behavior is defined by GCC.  You'll probably
need to look at an ANSI or POSIX standard.

I don't happen to have either handy, but I did find this blurb on
my HPUX system:

           alloca()         Allocates space from the stack of the caller for
                            a block of at least size bytes, but does not
                            initialize the space.  The space is
                            automatically freed when the calling routine
                            exits.

                            Memory returned by alloca() is not related to
                            memory allocated by other memory allocation
                            functions.  Behavior of addresses returned by
                            alloca() as parameters to other memory functions
                            is undefined.

                            The implementation of this routine is system
                            dependent and its use is discouraged.



jeff

Re: Further observations regarding alloca on i586-pc-linux-gnu

[Martin von Loewis]

> I don't think alloca's behavior is defined by GCC.  You'll probably
> need to look at an ANSI or POSIX standard.

Looking at Single Unix as found at
http://www.UNIX-systems.org/apis/0.r.html

I cannot see a definition of alloca. I don't think it is covered by
any international or industry standard. It seems the HP definition is
pretty good: It's system dependant (sp?), so all systems that provide
it should document the implementation and possible limitations.

Martin

Re: Further observations regarding alloca on i586-pc-linux-gnu

[Joerg Pommnitz]

I just tried the test on MS Visual C++ 5.0 with SP3 installed.
It crashes the compiler (fatal error C1001: INTERNAL COMPILER ERROR).
So, egcs just silently generates bad code while VC++ crashes. Both
not exactly the right thing, but I actually prefer the VC++ crash.

I really think the test is valid. There are no documented constraints
on the usage of alloca. An option "-fno-inline-alloca" and the generic
alloca emulation included in glibc would provide a useable work around.

Richard Henderson wrote:
> 
> On Sat, Aug 22, 1998 at 07:24:11PM +0200, Carlo Wood wrote:
> > ???     pushl $10             # put '\n' on the stack
> >         addl $-20,%esp                # allocate 20 bytes on the stack
> [...]
> > In other words: This is a bug.
> 
> This is well known.  What is not clear to me though, is whether
> it is a bug in the compiler or in the test.
> 
> The test is effectively relying on the order in which arguments
> are evaluated, which is wrong.  Note that the exact same effect
> would happen if alloca was not a builtin.  Note that if you mind
> sequence points like you ought, you get correct results.
> 
> r~

-- 
Regards
	Joerg
-- 
GMD-IPSI, Dolivostr. 15, Zimmer 120, D-64293 Darmstadt
+49-6151-869-786 (Phone), -818 (FAX)

Re: Further observations regarding alloca on i586-pc-linux-gnu

[Martin von Loewis]

> I really think the test is valid. There are no documented
> constraints on the usage of alloca.

This is a weak point :-) There is no alloca documentation, period.
It's not an ANSI C or ISO C++ function, so you code is certainly not
valid standard C++.

> An option "-fno-inline-alloca" and the generic alloca emulation
> included in glibc would provide a useable work around.

Well, this is easy to provide. Please check out -fno-builtin. Be aware
of alloca.h, which just knows we support __builtin_alloca.

Regards,
Martin

Re: Further observations regarding alloca on i586-pc-linux-gnu

[Joerg Pommnitz]

Martin von Loewis wrote:
> 
> > I really think the test is valid. There are no documented
> > constraints on the usage of alloca.
> 
> This is a weak point :-) There is no alloca documentation, period.
> It's not an ANSI C or ISO C++ function, so you code is certainly not
> valid standard C++.
> 

I know it is not ISO C++, however it would be very convenient. Without
alloca there are basically three ways to return a pointer:

a) allocate heap memory inside the function. Disadvantage: needs
   explicite release.
b) return a pointer to static memory. Disadvantage: not thread safe
   and code like
   a (xx(), xx();
   can give unexpected results.
c) pass a local array. closest to alloca, but requires more typing.

> > An option "-fno-inline-alloca" and the generic alloca emulation
> > included in glibc would provide a useable work around.
> 
> Well, this is easy to provide. Please check out -fno-builtin. Be aware
> of alloca.h, which just knows we support __builtin_alloca.
> 

Will do. Does it kill every built in function or is it possible to
target
a specific one?

> Regards,
> Martin

Regards
	Joerg

Re: Further observations regarding alloca on i586-pc-linux-gnu

[Martin von Loewis]

> a) allocate heap memory inside the function. Disadvantage: needs
>    explicite release.

I'd say auto_ptrs are there for you, no? Somebody correct me, but it
seems that

void f(char * = std::auto_ptr<char*>(new char[20]));

is valid C++, and gives you memory that will live slightly longer than
the call to f, and will then be automatically deallocated.

You did not say how long you need the memory: If you need automatic
deallocation when the caller of f returns, you can return an auto_ptr
from f.

> Will do. Does it kill every built in function or is it possible to
> target a specific one?

Have a look at the manual. It will consider no function builtin,
unless you explicitly invoke, say, __builtin_memcpy.

Regards,
Martin

signal 11 generating problem, was: Further observations regarding alloca on i586-pc-linux-gnu

[Joerg Pommnitz]

Martin von Loewis wrote:
> 
> > a) allocate heap memory inside the function. Disadvantage: needs
> >    explicite release.
> 
> I'd say auto_ptrs are there for you, no? Somebody correct me, but it
> seems that
> 
> void f(char * = std::auto_ptr<char*>(new char[20]));
> 
> is valid C++, and gives you memory that will live slightly longer than
> the call to f, and will then be automatically deallocated.
> 
> You did not say how long you need the memory: If you need automatic
> deallocation when the caller of f returns, you can return an auto_ptr
> from f.
> 

I had thought about auto_ptr before, but the SGI STL in egcs-1.0.x
disables <memory>. Alloca seemed to be a much easier solution.

Returning an auto_ptr is not really an option. According to Stroustrup, 
"The C++ Programming Language" 3rd Edition page 368, auto_ptr does not 
contain a cast operator to its element type.

However, the following program does what I want:

#include <sgimemory>
#include <cstdlib>
#include <iostream>

char *
xx (const auto_ptr<char> &c = auto_ptr<char>(new char[20]))
{
    return strncpy (c.get (), "Hello World!", 20);
}

int
main ()
{
    cout << xx () << endl;
}

<sgimemory> is the <memory> include file provided by the current
SGI STL implementation (don't know the exact version number, but
it was current as of 1 week ago).

Now the reason this has been sent to egcs-bugs, too. My original version
of the above program looks like this:

#include <sgimemory>
#include <cstdlib>
#include <iostream>

template <int i = 20> char *
xx (const auto_ptr<char> &c = auto_ptr<char>(new char[i]))
{
    return strncpy (c.get (), "Hello World!", i);
}

int
main ()
{
    cout << xx () << endl;
}

This version crashes gcc version egcs-2.90.27 980315 (egcs-1.0.2
release)
with g++: Internal compiler error: program cc1plus got fatal signal 11

Can somebody test this with egcs-1.1, please?

-- 
Regards
       Joerg
GMD-IPSI, Dolivostr. 15, Zimmer 120, D-64293 Darmstadt
+49-6151-869-786 (Phone), -818 (FAX)

Re: signal 11 generating problem, was: Further observations regarding alloca on i586-pc-linux-gnu

[Alexandre Oliva]

Joerg Pommnitz <pommnitz@darmstadt.gmd.de> writes:

> Martin von Loewis wrote:

>> I'd say auto_ptrs are there for you, no? Somebody correct me, but it
>> seems that
>> 
>> void f(char * = std::auto_ptr<char*>(new char[20]));

>> is valid C++, and gives you memory that will live slightly longer than
>> the call to f, and will then be automatically deallocated.

Yup, it's syntactically valid C++, but it is wrong because auto_ptr
will delete the pointer to the array as if it were a pointer to a
single object.  You should write auto_ptr_array instead.

> Returning an auto_ptr is not really an option. According to Stroustrup, 
> "The C++ Programming Language" 3rd Edition page 368, auto_ptr does not 
> contain a cast operator to its element type.

But it provides a get() method, that you could use to obtain the
pointer to the contained object.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: signal 11 generating problem, was: Further observations regarding alloca on i586-pc-linux-gnu

[Joerg Pommnitz]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 693 bytes --]

Alexandre Oliva wrote:
> 
> Yup, it's syntactically valid C++, but it is wrong because auto_ptr
> will delete the pointer to the array as if it were a pointer to a
> single object.  You should write auto_ptr_array instead.
> 

Where does auto_ptr_array come from? It´s not in SGI´s STL and I have
not
seen it in the Stroustrup either.

> > Returning an auto_ptr is not really an option. According to Stroustrup,
> > "The C++ Programming Language" 3rd Edition page 368, auto_ptr does not
> > contain a cast operator to its element type.
> 
> But it provides a get() method, that you could use to obtain the
> pointer to the contained object.
> 

That´s what I use now.

Regards
	Joerg

Re: signal 11 generating problem, was: Further observations regarding alloca on i586-pc-linux-gnu

[Martin von Loewis]

> Yup, it's syntactically valid C++, but it is wrong because auto_ptr
> will delete the pointer to the array as if it were a pointer to a
> single object.  You should write auto_ptr_array instead.

Is auto_ptr_array a standard template? If so, where is it defined?

Martin

Re: signal 11 generating problem, was: Further observations regarding alloca on i586-pc-linux-gnu

[Joe Buck]

> > Yup, it's syntactically valid C++, but it is wrong because auto_ptr
> > will delete the pointer to the array as if it were a pointer to a
> > single object.  You should write auto_ptr_array instead.
> 
> Is auto_ptr_array a standard template? If so, where is it defined?

No, there is no standard template by that name.  It has been proposed
by many people to be analogous to auto_ptr, except that it would contain a
pointer to an array on the heap (e.g. "new MyClass[5]") and would do
"delete []" rather than "delete" in the destructor.

The committee's response to such proposals has been to try to get people
to just use vector, which is OK as long as you aren't trying to interface
to C code that wants a genuine C array.

Re: Further observations regarding alloca on i586-pc-linux-gnu

[Noel Yap]

Martin von Loewis wrote:
> 
> > a) allocate heap memory inside the function. Disadvantage: needs
> >    explicite release.
> 
> I'd say auto_ptrs are there for you, no? Somebody correct me, but it
> seems that
> 
> void f(char * = std::auto_ptr<char*>(new char[20]));
> 
> is valid C++, and gives you memory that will live slightly longer than
> the call to f, and will then be automatically deallocated.
> 
> You did not say how long you need the memory: If you need automatic
> deallocation when the caller of f returns, you can return an auto_ptr
> from f.

How does it know when to deallocate the memory?

Noel

Re: Further observations regarding alloca on i586-pc-linux-gnu

[Joe Buck]

> > You did not say how long you need the memory: If you need automatic
> > deallocation when the caller of f returns, you can return an auto_ptr
> > from f.
> 
> How does it know when to deallocate the memory?

The destructor deallocates the memory.

Re: Further observations regarding alloca on i586-pc-linux-gnu

[Andreas Schwab]

Joerg Pommnitz <pommnitz@darmstadt.gmd.de> writes:

|> Martin von Loewis wrote:
|> > 
|> > > I really think the test is valid. There are no documented
|> > > constraints on the usage of alloca.
|> > 
|> > This is a weak point :-) There is no alloca documentation, period.
|> > It's not an ANSI C or ISO C++ function, so you code is certainly not
|> > valid standard C++.
|> > 
|> 
|> I know it is not ISO C++, however it would be very convenient.

C9x will have VLA (variable length arrays), which are about the same
thing, but safer.

-- 
Andreas Schwab                                      "And now for something
schwab@issan.informatik.uni-dortmund.de              completely different"
schwab@gnu.org

Re: Further observations regarding alloca on i586-pc-linux-gnu

[Oleg Zabluda]

In article < 199808250624.IAA00271@mira.isdn.cs.tu-berlin.de > you wrote:
: > a) allocate heap memory inside the function. Disadvantage: needs
: >    explicite release.

: I'd say auto_ptrs are there for you, no? Somebody correct me, but it
: seems that

: void f(char * = std::auto_ptr<char*>(new char[20]));

: is valid C++, and gives you memory that will live slightly longer than
: the call to f, and will then be automatically deallocated.

This needs some modifications:

1. auto_ptr<>'s destructor deallocates the memory with
   operator delete, while you will need operator delete[].
   So you'll have to use your own auto_array<> or something,
   with the correct destructor.

2. My understanding is that the default arguments have static
   storage duration. This is not what was intended.

3. You can not initialize ``char*'' with std::auto_ptr<char*>.
   I think this is a typo. You meant something similar to
   void f( char* = std::auto_ptr<void*>(::operator new(20)).get() );

Oleg.

Re: Further observations regarding alloca on i586-pc-linux-gnu

[Alexandre Oliva]

Oleg Zabluda <zabluda@math.psu.edu> writes:

> In article < 199808250624.IAA00271@mira.isdn.cs.tu-berlin.de > you wrote:

> : void f(char * = std::auto_ptr<char*>(new char[20]));

> 2. My understanding is that the default arguments have static
>    storage duration. This is not what was intended.

The Standard says [dcl.fct.default]

9 Default arguments are evaluated each time the function is called.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: Further observations regarding alloca on i586-pc-linux-gnu

[Richard Henderson]

On Mon, Aug 24, 1998 at 05:38:38PM +0200, Joerg Pommnitz wrote:
> I really think the test is valid. There are no documented constraints
> on the usage of alloca. An option "-fno-inline-alloca" and the generic
> alloca emulation included in glibc would provide a useable work around.

As discussed elsewhere on this thread, no it wouldn't.  You'll
get _exactly_ the same results from the alloca in glibc.

With the malloc-based c alloca in gcc, it would work, but that
is rather different.


r~