On Thu, Mar 31, 2011 at 9:14 AM, Paolo Bonzini <bonz...@gnu.org> wrote: > On 03/31/2011 03:22 AM, Michael Matz wrote: >> >> this came up when looking into why the static ctors contain useless trees >> (like casts). We can simply canonicalize them while varpool analyzes >> pending decls. It'll look at initialzers once, where we can "gimplify" >> them. This requires making canonicalize_constructor_val be able to be >> called outside of functions. And it requires the java frontend not >> leaving a dangling function decl as current (for the static ctor function >> it generates). > > canonicalize_constructor_val may be doing useful things on ADDR_EXPR too, > but you don't call it in that case because you only added your code in the > default case. You only reach it when the ADDR_EXPR is wrapped in a cast. > > Any reason why you didn't add it (possibly wrapped in a loop) _before_ the > switch statement?
Indeed. This comment needs adjustment, too: /* We never have the chance to fixup types in global initializers during gimplification. Do so here. */ if (TREE_TYPE (TREE_TYPE (cval)) != TREE_TYPE (TREE_OPERAND (cval, 0))) cval = build_fold_addr_expr (TREE_OPERAND (cval, 0)); as we now sort-of do this. In fact it looks like all existing canonicalize_constructor_val calls are subsumed by the lowering, so, eventually remove those and move this function to a local place next to its sole caller. Richard. > Paolo >