This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/41001] alloca broken for -fno-builtin
- From: "ktietz at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 8 Aug 2009 08:43:10 -0000
- Subject: [Bug middle-end/41001] alloca broken for -fno-builtin
- References: <bug-41001-15155@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla 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