Bug 41001 - alloca broken for -fno-builtin
Summary: alloca broken for -fno-builtin
Status: UNCONFIRMED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.5.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2009-08-07 15:36 UTC by Kai Tietz
Modified: 2009-08-08 10:31 UTC (History)
1 user (show)

See Also:
Host: x86_64-pc-linux
Target: x86_64-*-* i686-*-*
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments
Testcase for alloca/_alloca (395 bytes, text/plain)
2009-08-07 15:38 UTC, Kai Tietz
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kai Tietz 2009-08-07 15:36:19 UTC
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.
Comment 1 Kai Tietz 2009-08-07 15:38:12 UTC
Created attachment 18324 [details]
Testcase for alloca/_alloca

to be compiled with option -fno-builtins
Comment 2 joseph@codesourcery.com 2009-08-07 17:24:33 UTC
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)?

Comment 3 Kai Tietz 2009-08-07 21:05:49 UTC
(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.
Comment 4 joseph@codesourcery.com 2009-08-07 22:36:27 UTC
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.

Comment 5 Kai Tietz 2009-08-08 08:43:09 UTC
(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
Comment 6 Richard Biener 2009-08-08 10:31:34 UTC
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.
Comment 7 joseph@codesourcery.com 2009-08-08 10:37:45 UTC
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.)