On 04/25/2017 01:58 PM, Jakub Jelinek wrote:
> On Tue, Apr 25, 2017 at 01:48:05PM +0200, Martin Liška wrote:
>> Hello.
>>
>> This is patch that was originally installed by Jason and later reverted due
>> to PR70422.
>> In the later PR Richi suggested a fix for that and Segher verified that it
>> helped him
>> to survive regression tests. That's reason why I'm resending that.
>>
>> Patch can bootstrap on ppc64le-redhat-linux and survives regression tests.
>>
>> Ready to be installed?
>> Martin
>
>> >From a34ce0ef37ae00609c9f3ff98a9cb0b7db6a8bd0 Mon Sep 17 00:00:00 2001
>> From: marxin <mli...@suse.cz>
>> Date: Thu, 20 Apr 2017 14:56:30 +0200
>> Subject: [PATCH] Make __FUNCTION__ a mergeable string and do not generate
>> symbol entry.
>>
>> gcc/cp/ChangeLog:
>>
>> 2017-04-20 Jason Merrill <ja...@redhat.com>
>> Martin Liska <mli...@suse.cz>
>> Segher Boessenkool <seg...@kernel.crashing.org>
>>
>> PR c++/64266
>> PR c++/70353
>> PR bootstrap/70422
>> Core issue 1962
>> * decl.c (cp_fname_init): Decay the initializer to pointer.
>> (cp_make_fname_decl): Set DECL_DECLARED_CONSTEXPR_P,
>> * pt.c (tsubst_expr) [DECL_EXPR]: Set DECL_VALUE_EXPR,
>> DECL_INITIALIZED_BY_CONSTANT_EXPRESSION_P and
>> DECL_IGNORED_P. Don't call cp_finish_decl.
>
> If we don't emit those into the debug info, will the debugger be
> able to handle __FUNCTION__ etc. properly?
No, debugger with the patch can't handled these. Similar to how clang
behaves currently. Maybe it can be conditionally enabled with -g3, or -g?
> Admittedly, right now we emit it into debug info only if those decls
> are actually used, say on:
> const char * foo () { return __FUNCTION__; }
> const char * bar () { return ""; }
> we'd emit foo::__FUNCTION__, but not bar::__FUNCTION__, so the debugger
> has to have some handling of it anyway. But while in functions
> that don't refer to __FUNCTION__ it is always the debugger that needs
> to synthetize those and thus they will be always pointer-equal,
> if there are some uses of it and for other uses the debugger would
> synthetize it, there is the possibility that the debugger synthetized
> string will not be the same object as actually used in the function.
You're right, currently one has to use a special function to be able to
print it in debugger. I believe we've already discussed that, according
to spec, the strings don't have to point to a same string.
Suggestions what we should do with the patch?
Thanks,
Martin
>
> Jakub
>
