• Johannes Pfau (21/21) Feb 08 2013 https://gist.github.com/jpf91/4738922
• Johannes Pfau (16/18) Feb 10 2013 OK, found it and found a fix. As a result functions in nested structs
• Iain Buclaw (6/24) Feb 11 2013 This code logic was from gcc-3.4 times, other changes around that may ha...

Johannes Pfau <nospam example.com> writes:

https://gist.github.com/jpf91/4738922

/tmp/cc8D6NeD.o:(.rodata._D6nested10__T5f7965Z5f7965FNaNbNfZC6nested10__T5f7965Z5f79656Result6Result6__vtblZ[_D6nested10__T5f7965Z5f7965FNaNbNfZC6nested10__T5f7965Z5f79656Result6Result6__vtblZ]+0x30):
undefined reference to
`_D6nested10__T5f7965Z5f7965FNaNbNfZC6nested10__T5f7965Z5f79656Result6Result1gMFZv'

This is currently not detected as needing a closure, it tries to use
the gcc nested function mechanism. I guess the gcc mechanism can't
handle function->class->function chains as it was developed for c
nested functions which can only be nested in functions AFAIK.

Background info: We don't call cgraph_finalize_function for GCC nested
functions (ObjectFile::outputFunction). This is correct, as
cgraph_finalize_function is called by the GCC middle / backend. But I
think in this case we're passing something to the backend which it can't
handle. Therefore cgraph_finalize_function is never called and the
function is not put out.

Uncommenting the /*a = 42;*/ makes everything work as we use the D
closure code path in that case. Marking the Result class as static also
works.

Do you know how we could force the D closure codepath in such cases or
how we should solve this?

(I actually found a fix for that verify_callgraph problem. But it
triggered some regressions which are actually caused by this bug.)

Johannes Pfau <nospam example.com> writes:

Am Fri, 8 Feb 2013 14:05:24 +0100
schrieb Johannes Pfau <nospam example.com>:

 https://gist.github.com/jpf91/4738922
 

OK, found it and found a fix. As a result functions in nested structs
can now also have static chains.

With my changes it's possible that a function in a template instance
has a static chain. So we can have functions which are nested, but
for which we still need to call make_decl_one_only.

There's a small problem: makeDeclOneOnly has this comment:

      /* Weak definitions have to be public.  Nested functions may or
	 may not be emitted as public even if TREE_PUBLIC is set.
	 There is no way to tell if the back end implements
	 make_decl_one_only with DECL_WEAK, so this check is
	 done first.  */

and therefore it doesn't mark nested functions as one-only.

Do you know if that statement is still true for recent gcc versions? I
removed that check and there were no regressions.

Iain Buclaw <ibuclaw ubuntu.com> writes:

On 10 February 2013 09:05, Johannes Pfau <nospam example.com> wrote:

 Am Fri, 8 Feb 2013 14:05:24 +0100
 schrieb Johannes Pfau <nospam example.com>:

 https://gist.github.com/jpf91/4738922

 OK, found it and found a fix. As a result functions in nested structs
 can now also have static chains.

 With my changes it's possible that a function in a template instance
 has a static chain. So we can have functions which are nested, but
 for which we still need to call make_decl_one_only.

 There's a small problem: makeDeclOneOnly has this comment:

       /* Weak definitions have to be public.  Nested functions may or
          may not be emitted as public even if TREE_PUBLIC is set.
          There is no way to tell if the back end implements
          make_decl_one_only with DECL_WEAK, so this check is
          done first.  */

 and therefore it doesn't mark nested functions as one-only.

 Do you know if that statement is still true for recent gcc versions? I
 removed that check and there were no regressions.

This code logic was from gcc-3.4 times, other changes around that may have
made it work by now.  Can you pull so I can review?

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';