[Bug middle-end/41001] New: alloca broken for -fno-builtin

[Bug middle-end/41001] New: alloca broken for -fno-builtin

[ktietz at gcc dot gnu dot org]

The function alloca (for cygwin/mingw target _alloca) is broken or not
available (for linux64), when using option -fno-builtin.

The linux and win32 targets the symbol alloca isn't present. For windows
targets there is an implementation (_alloca) in gcc/config/i386/cygwin.asm
present. But when using this, the stack layout is broken after calling alloca.

The attached example shows the failure for i?86 and x86_64 windows targets
pretty well.


-- 
           Summary: alloca broken for -fno-builtin
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: ktietz at gcc dot gnu dot org
  GCC host triplet: x86_64-pc-linux
GCC target triplet: x86_64-*-* i686-*-*


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41001

[Bug middle-end/41001] alloca broken for -fno-builtin

[ktietz at gcc dot gnu dot org]

------- Comment #1 from ktietz at gcc dot gnu dot org  2009-08-07 15:38 -------
Created an attachment (id=18324)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18324&action=view)
Testcase for alloca/_alloca

to be compiled with option -fno-builtins


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41001

[Bug middle-end/41001] alloca broken for -fno-builtin

[joseph at codesourcery dot com]

------- Comment #2 from joseph at codesourcery dot com  2009-08-07 17:24 -------
Subject: Re:   New: alloca broken for -fno-builtin

On Fri, 7 Aug 2009, ktietz at gcc dot gnu dot org wrote:

> The function alloca (for cygwin/mingw target _alloca) is broken or not
> available (for linux64), when using option -fno-builtin.

It is in the nature of alloca that it needs to be built in to the compiler 
for an effective implementation, and the lack of a library emulation 
(using malloc) is nothing to do with the compiler.  Why do you think there 
is a bug here?

> The linux and win32 targets the symbol alloca isn't present. For windows
> targets there is an implementation (_alloca) in gcc/config/i386/cygwin.asm
> present. But when using this, the stack layout is broken after calling alloca.

I do not believe _alloca is meant to be an implementation of the C alloca 
function; if it was, it would be alloca not _alloca.  Do you have any 
reason to believe _alloca does not follow its specification of making 
stack space available when called implicitly by the compiler (*not* an 
explicit C function call - it has its own special ABI so you can't call it 
explicitly from C)?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41001

[Bug middle-end/41001] alloca broken for -fno-builtin

[ktietz at gcc dot gnu dot org]

------- Comment #3 from ktietz at gcc dot gnu dot org  2009-08-07 21:05 -------
(In reply to comment #2)
> Subject: Re:   New: alloca broken for -fno-builtin
> 
> On Fri, 7 Aug 2009, ktietz at gcc dot gnu dot org wrote:
> 
> > The function alloca (for cygwin/mingw target _alloca) is broken or not
> > available (for linux64), when using option -fno-builtin.
> 
> It is in the nature of alloca that it needs to be built in to the compiler 
> for an effective implementation, and the lack of a library emulation 
> (using malloc) is nothing to do with the compiler.  Why do you think there 
> is a bug here?
> 
> > The linux and win32 targets the symbol alloca isn't present. For windows
> > targets there is an implementation (_alloca) in gcc/config/i386/cygwin.asm
> > present. But when using this, the stack layout is broken after calling alloca.
> 
> I do not believe _alloca is meant to be an implementation of the C alloca 
> function; if it was, it would be alloca not _alloca.  Do you have any 
> reason to believe _alloca does not follow its specification of making 
> stack space available when called implicitly by the compiler (*not* an 
> explicit C function call - it has its own special ABI so you can't call it 
> explicitly from C)?
> 

Well, if so. It makes no sense that -fno-builtins tries to call a function
which isn't present. But for other compilers, alloca can be invoked as
function, too. The compiler builtin part in all cases is, to be aware that
stack frame changes (hot-region, call save-area, and co are adjusted after
calling it).
IIRC it is even mentioned as function in K&R, but well I could mix-up here
something.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41001

[Bug middle-end/41001] alloca broken for -fno-builtin

[joseph at codesourcery dot com]

------- Comment #4 from joseph at codesourcery dot com  2009-08-07 22:36 -------
Subject: Re:  alloca broken for -fno-builtin

On Fri, 7 Aug 2009, ktietz at gcc dot gnu dot org wrote:

> Well, if so. It makes no sense that -fno-builtins tries to call a function
> which isn't present. But for other compilers, alloca can be invoked as
> function, too. The compiler builtin part in all cases is, to be aware that
> stack frame changes (hot-region, call save-area, and co are adjusted after
> calling it).

-fno-builtin means more or less exactly that the compiler *should not* 
assume anything special about a function from its name (unless the name 
starts __builtin or some similar reserved-namespace cases such as __sync) 
- that is, you declare alloca and because of -fno-builtin the compiler 
assumes this is your own function with no special semantics whatever.  By 
-fno-builtin you are declaring that alloca, and all other normally 
built-in functions, are normal functions with no special semantics the 
compiler needs to know about.  So of course it generates a call like it 
would to any other random function you might have defined in another 
translation unit.

If you want to use alloca with its traditional memory allocation semantics 
with -fno-builtin, you'll need to use a malloc-based emulation such as 
that in libiberty, not something that uses the stack.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41001

[Bug middle-end/41001] alloca broken for -fno-builtin

[ktietz at gcc dot gnu dot org]

------- Comment #5 from ktietz at gcc dot gnu dot org  2009-08-08 08:43 -------
(In reply to comment #4)
> -fno-builtin means more or less exactly that the compiler *should not* 
> assume anything special about a function from its name (unless the name 
> starts __builtin or some similar reserved-namespace cases such as __sync) 
> - that is, you declare alloca and because of -fno-builtin the compiler 
> assumes this is your own function with no special semantics whatever.  By 
> -fno-builtin you are declaring that alloca, and all other normally 
> built-in functions, are normal functions with no special semantics the 
> compiler needs to know about.  So of course it generates a call like it 
> would to any other random function you might have defined in another 
> translation unit.
> 
> If you want to use alloca with its traditional memory allocation semantics 
> with -fno-builtin, you'll need to use a malloc-based emulation such as 
> that in libiberty, not something that uses the stack.
> 

Well, IMHO it is the same for alloca, as for setjmp, or longjmp. Even some code
for detecting alloca semanices is present (in a slightly broken way), see
calls.c (special_function_p).
So, if it is really the intention that by -fno-builtin all function have
standard calling convention, then this special cases in calls.c would be a bug.
But well, I assume it isn't. I think the best thing to do here is, as written
within this function commment, to have a function-declaration attribute, which
indicated alloca behavior.
Or, do I mis-read here something.

Kai


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41001

[Bug middle-end/41001] alloca broken for -fno-builtin

[rguenth at gcc dot gnu dot org]

------- Comment #6 from rguenth at gcc dot gnu dot org  2009-08-08 10:31 -------
The special_function thing is to make us not miss special side-effects of those
functions even when we didn't recognize them as builtins.  alloca doesn't have
one apart from the likeliness to blow up the stack if we do some crazy
inlining like into loops.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41001

[Bug middle-end/41001] alloca broken for -fno-builtin

[joseph at codesourcery dot com]

------- Comment #7 from joseph at codesourcery dot com  2009-08-08 10:37 -------
Subject: Re:  alloca broken for -fno-builtin

On Sat, 8 Aug 2009, ktietz at gcc dot gnu dot org wrote:

> Well, IMHO it is the same for alloca, as for setjmp, or longjmp. Even some code
> for detecting alloca semanices is present (in a slightly broken way), see
> calls.c (special_function_p).
> So, if it is really the intention that by -fno-builtin all function have
> standard calling convention, then this special cases in calls.c would be a bug.

I consider that those cases should be handled through attributes on 
built-in functions and in standard headers (added where necessary to those 
headers through fixincludes), rather than in special_function_p (which 
should go away); see at the bottom of 
<http://gcc.gnu.org/projects/beginner.html>.  (It is not valid to use 
setjmp/longjmp without including the standard header, so failing if it is 
not included and -fno-builtin is used would be fine.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41001