This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Make __FUNCTION__ a mergeable string and do not generate symbol entry.
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Martin Liška <mliska at suse dot cz>, Pedro Alves <palves at redhat dot com>, Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: GCC Patches <gcc-patches at gcc dot gnu dot org>, Jason Merrill <jason at redhat dot com>, Segher Boessenkool <segher at kernel dot crashing dot org>
- Date: Tue, 25 Apr 2017 13:58:27 +0200
- Subject: Re: [PATCH] Make __FUNCTION__ a mergeable string and do not generate symbol entry.
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx04.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx04.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jakub at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com AA8368047A
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com AA8368047A
- References: <e506fecb-c2b2-ccd8-12dc-4300a481bf04@suse.cz>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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 <mliska@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 <jason@redhat.com>
> Martin Liska <mliska@suse.cz>
> Segher Boessenkool <segher@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?
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.
Jakub