Thread overview | |||||
---|---|---|---|---|---|
|
February 08, 2013 weird bug with nested functions: | ||||
---|---|---|---|---|
| ||||
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.) |
February 10, 2013 Re: weird bug with nested functions: | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johannes Pfau | 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.
|
February 11, 2013 Re: weird bug with nested functions: | ||||
---|---|---|---|---|
| ||||
Posted in reply to Johannes Pfau Attachments:
| 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'; |
Copyright © 1999-2021 by the D Language Foundation