This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: RFC: Lazy __FUNCTION__ etc

Zack Weinberg wrote:
> This patch causes us to allocate the strings for __FUNCTION__,
> __PRETTY_FUNCTION__, and __func__ lazily.  At present they are

> We still get the semantics of __func__ wrong, but they are no more
> wrong than they were before.  I believe I know how to correct __func__
> within the new framework, and will attempt that after this patch goes in.
As you've observed for C++ we treat __func__ and __FUNCTION__ the same, and
in a C99 manner of
	static const char __func__[] = "foo";
I had thought C was doing the same, ho hum.

I think it would be a mistake for __FUNCTION__ and __func__ to have
(subtly) different semantics. Now that C99 has spoken, we should
treat them as array variables, not string constants.

> The patch is not quite ready for inclusion, because it somehow breaks
> C++'s ext/pretty3.C and ext/pretty4.C tests.  I believe pretty4 is in
> error: it wants __FUNCTION__ to be a different object from a string
> constant with the same contents, and a different object for two
> (overloaded) functions with the same base name.  This has never been
> true in the C compiler, but apparently used to be true for C++.  I
This naturally follows from the c99 definition of __func__.

> implicit specialization).  Formerly, __PRETTY_FUNCTION__ was not
> evaluated for template functions until they were specialized, so both
> of them came out like "f1(T) [with T = float]".  Now
> __PRETTY_FUNCTION__ is evaluated immediately, so the generic is just
> called "f1(T)".  This is undesired.  I do not know why it happened or
> how to put the semantics back the way they were - I do see some code
> aimed at evaluating _P_F_ at template specialization time, in pt.c,
> but I have no idea how we get there...
IIR, this was some pretty horrible subterfuge Mark (sorry) put in when I
fixed P_F etc to have the correct type inside template functions.

How about having __func__ __FUNCTION__ and _P_F_ as special grammar
rules which create the appropriate VAR_DECL, if it's not already
in existence? wouldn't that give the fewest changes elsewhere?


Dr Nathan Sidwell   ::   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?' : :

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]