On 10/29/18 9:37 AM, Jason Merrill wrote:
> On Fri, Oct 26, 2018 at 3:14 AM Martin Liška <mliska@suse.cz> wrote:
>> On 10/24/18 7:24 PM, Jason Merrill wrote:
>>> On Tue, Oct 23, 2018 at 4:59 AM Martin Liška <mliska@suse.cz> wrote:
>>>> However, I still see some minor ICEs, it's probably related to decay_conversion in cp_fname_init:
>>>>
>>>> 1) ./xg++ -B. /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-__func__2.C
>>>>
>>>> /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-__func__2.C:6:17: internal compiler error: Segmentation fault
>>>> 6 |     [] { return __func__; }();
>>>>    |                 ^~~~~~~~
>>>> 0x1344568 crash_signal
>>>>          /home/marxin/Programming/gcc/gcc/toplev.c:325
>>>> 0x7ffff6bc310f ???
>>>>          /usr/src/debug/glibc-2.27-6.1.x86_64/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
>>>> 0x9db134 is_capture_proxy(tree_node*)
>>
>> Hi.
>>
>>>
>>> The problem in both tests is that is_capture_proxy thinks your
>>> __func__ VAR_DECL with DECL_VALUE_EXPR is a capture proxy, since it is
>>> neither an anonymous union proxy nor a structured binding.
>>
>> I see, however I'm a rookie in area of C++ FE. Would it be solvable this problem
>> with lambdas?
>>
>>>
>>> The standard says,
>>>
>>> The function-local predefined variable __func__ is defined as if a
>>> definition of the form
>>>     static const char __func__[] = "function-name ";
>>> had been provided, where function-name is an implementation-defined
>>> string. It is unspecified whether such a variable has an address
>>> distinct from that of any other object in the program.
>>>
>>> So changing the type of __func__ (from array to pointer) still breaks
>>> conformance.  And we need to keep the type checks from pretty4.C, even
>>> though the checks for strings being distinct need to go.
>>
>> I added following patch which puts back type to const char[] (instead of char *)
>> and I made the variable static. Now I see pretty4.C testcase passing again.
>> To be honest I'm not convinced about the FE changes, so a help would
>> be appreciated.
> 
> OK, I'll poke at it.

This further patch teaches is_capture_proxy about function-name 
variables, and changes the handling of __PRETTY_FUNCTION__ in template 
instantiations to create new variables rather than instantiations.

The C++ changes are OK with this.