<div dir="ltr"><div class="gmail_extra"><br><br><div class="gmail_quote">On 3 January 2013 16:12, Johannes Pfau <span dir="ltr"><<a href="mailto:nospam@example.com" target="_blank">nospam@example.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id=":22i">Then there's the question why the outer function has to be a template<br>
as well for this to happen: It's because if it's not a template, gdc<br>
uses a completely different code path: There's a<br>
"!gen.functionNeedsChain (f)" check in outputFunction which is false<br>
for the failing case. (cgraph_finalize_function marks the function as<br>
reachable)<br>
<br></div></blockquote><div><br></div><div>That might be just it then...<br></div><div> <br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div id=":22i">


BTW: I think that this isn't happening in gcc-4.8 is pure luck. Most of<br>
the cgraph_analyze* functions have been rewritten in gcc-4.8. But I<br>
think this specific case is still bogus (we tell the backend that<br>
we can access percolateDown from outside the unit even though it<br>
requires access to a function which is only valid in a limited scope)</div></blockquote></div><br></div><div class="gmail_extra">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.<br>
</div><div class="gmail_extra"><br clear="all"></div><div class="gmail_extra"><br>-- <br>Iain Buclaw<br><br>*(p < e ? p++ : p) = (c & 0x0f) + '0';
</div></div>