http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50678
Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2011-10-11
Component|ada |tree-optimization
Ever Confirmed|0 |1
--- Comment #6 from Eric Botcazou <ebotcazou at gcc dot gnu.org> 2011-10-11
06:19:39 UTC ---
> 2011-10-07 Tom de Vries <t...@codesourcery.com>
>
> PR middle-end/50527
> * tree.c (build_common_builtin_nodes): Add local_define_builtin for
> * builtins.c (expand_builtin_alloca): Handle BUILT_IN_ALLOCA_WITH_ALIGN
> * tree-ssa-ccp.c (evaluate_stmt): Set align for
> * builtins.def (BUILT_IN_ALLOCA_WITH_ALIGN): Declare using
> * ipa-pure-const.c (special_builtin_state): Handle
> * tree-ssa-alias.c (ref_maybe_used_by_call_p_1)
> * function.c (gimplify_parameters): Lower vla to
> * gimplify.c (gimplify_vla_decl): Same.
> * cfgexpand.c (expand_call_stmt): Handle BUILT_IN_ALLOCA_WITH_ALIGN.
> * tree-mudflap.c (mf_xform_statements): Same.
> * tree-ssa-dce.c (mark_stmt_if_obviously_necessary)
> * varasm.c (incorporeal_function_p): Same.
> * tree-object-size.c (alloc_object_size): Same.
> * gimple.c (gimple_build_call_from_tree): Same.
OK, I didn't realize that things were still ongoing on this front. Frankly,
this alloca folding seems to introduce far too much complication for what it's
worth.
Tom, did you consider reverting the whole thing and doing things differently?
If your canonical example is something like:
const int n = 5;
int array[n];
it's very easy to fold this in the front-end into:
const int n = 5;
int array[5];
As a matter of fact, that's what we do in Ada, which is by far the biggest user
of alloca in the compiler.
