This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



------- 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]