On 3 January 2013 16:12, Johannes Pfau <nos...@example.com> wrote: > Then there's the question why the outer function has to be a template > as well for this to happen: It's because if it's not a template, gdc > uses a completely different code path: There's a > "!gen.functionNeedsChain (f)" check in outputFunction which is false > for the failing case. (cgraph_finalize_function marks the function as > reachable) > > That might be just it then...
BTW: I think that this isn't happening in gcc-4.8 is pure luck. Most of > the cgraph_analyze* functions have been rewritten in gcc-4.8. But I > think this specific case is still bogus (we tell the backend that > we can access percolateDown from outside the unit even though it > requires access to a function which is only valid in a limited scope) > I have been rolling round my head to remove the notion of functions nested in functions within the D codegen. Having only RECORD and UNION types set in DECL_CONTEXT. So all public functions are TREE_PUBLIC=1 (unless there's some overriding attribute), and all nested functions are TREE_PUBLIC=0. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
