[cfe-dev] Additional instantiations of anonymous enum inside a template

[Richard Smith]

On Tue, Oct 14, 2014 at 3:18 PM, Pavel Morozkin <pavel.morozkin at gmail.com>
wrote:

> On 13 October 2014 23:51, Richard Smith <richard at metafoo.co.uk> wrote:
>
>> On Mon, Oct 13, 2014 at 12:48 PM, Richard Smith <richard at metafoo.co.uk>
>> wrote:
>>
>>> On Mon, Oct 13, 2014 at 12:02 PM, András Kucsma <r0maikx02b at gmail.com>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I'm one of the developers of Metashell (
>>>> https://github.com/sabel83/metashell), more specifically the developer
>>>> of metadebugger, which was used to reproduce this issue.
>>>>
>>>> Metashell uses Templight (http://plc.inf.elte.hu/templight/) to gather
>>>> information about the template instantiations.
>>>>
>>>> I put together a small test which reproduces the issue without
>>>> Metashell, using only a clang patched with Templight:
>>>> https://gist.github.com/r0mai/4d90fdc8007af96c2dd1
>>>>
>>>
>>> I don't see any Clang bug here. Templight is not reporting template
>>> instantiations; you're misinterpreting its output. 129 of the 130 instances
>>> are of kind "Memoization", which is Templight's way of saying "Clang
>>> checked whether the type was complete". There are no additional
>>> instantiations here.
>>>
>>
>> Sorry, I missed one; there are two TemplateInstantiations in that log,
>> not one. One for fib<2> and one for int_<1>.
>>
>
> Thanks for the explanation. Could you briefly explain what Clang
> understands under term «type completeness» regarding enum and why the
> compiler does such amount of checks?
>

Any time the compiler examines a case where the completeness of a type
might affect program semantics, it will check whether the type is complete
(and trigger the Templight message you're seeing). Any of these cases
/could/ trigger an instantiation, if they happen to be the first such
check. If you want to understand why all of these are happening, you could
set a breakpoint on the code added by Templight and have a look at the
backtraces (and if you want a spoiler, see PR21280).

You can find the trace that Templight produced in the gist as well.
>>>> Memoization events of ENUM appear 130 times while instantiating
>>>> int_<fib<2>::value>.
>>>>
>>>> I CC-ed in two guys (Zoltán Porkoláb and Zoltán Borók-Nagy). They will
>>>> be able to help with Templight related questions.
>>>>
>>>> Regards,
>>>> András
>>>>
>>>> On Mon, Oct 13, 2014 at 6:02 PM, Richard Smith <richard at metafoo.co.uk>
>>>> wrote:
>>>>
>>>>>
>>>>> On 13 Oct 2014 01:06, "Pavel Morozkin" <pavel.morozkin at gmail.com>
>>>>> wrote:
>>>>> >
>>>>> > On 13 October 2014 03:53, Richard Smith <richard at metafoo.co.uk>
>>>>> wrote:
>>>>> >>
>>>>> >> On Sun, Oct 12, 2014 at 3:29 AM, Pavel Morozkin <
>>>>> pavel.morozkin at gmail.com> wrote:
>>>>> >>>
>>>>> >>> Hello cfe-dev group,
>>>>> >>>
>>>>> >>> Consider this template metaprogram:
>>>>> >>> template <unsigned N> struct fib { enum { value = fib<N-1>::value
>>>>> + fib<N-2>::value}; };
>>>>> >>> template <> struct fib<1> { enum { value = 1 }; };
>>>>> >>> template <> struct fib<0> { enum { value = 0 }; };
>>>>> >>>
>>>>> >>> During compilation of 'fib<2>::value' (after finally getting
>>>>> memoized result of instantiation of struct fib<0>) Clang «instantiates the
>>>>> anonymous enum inside fib<0> and fib<1>» 129 times in sum.
>>>>> >>
>>>>> >>
>>>>> >> That sounds like a bug. How are you observing it?
>>>>> >
>>>>> >
>>>>> > I debugged the metaprogram with use of Metashell tool.
>>>>>
>>>>> Possibly this is a bug in metashell? How does it get this information?
>>>>>
>>>>> >>> In case, when we use 'constexpr static auto' instead of 'enum', no
>>>>> additional instantiations occurs. Why Clang performs additional
>>>>> instantiations in the first case?
>>>>> >>>
>>>>> >>> Thank you,
>>>>> >>> Pavel
>>>>> >>>
>>>>> >>> _______________________________________________
>>>>> >>> cfe-dev mailing list
>>>>> >>> cfe-dev at cs.uiuc.edu
>>>>> >>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>>>> >>>
>>>>> >>
>>>>> >
>>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141014/0bbfe88c/attachment.html>