This is the mail archive of the gcc@gcc.gnu.org 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]
Other format: [Raw text]

Re: C++ and gather-detailed-mem-stats


On Wed, Aug 15, 2012 at 6:01 AM, Richard Guenther <rguenther@suse.de> wrote:
> On Wed, 15 Aug 2012, Gabriel Dos Reis wrote:
>
>> On Wed, Aug 15, 2012 at 5:11 AM, Florian Weimer <fweimer@redhat.com> wrote:
>> > On 08/15/2012 12:07 PM, Gabriel Dos Reis wrote:
>> >
>> >> You might try to encode/package information with the
>> >> parameters T and A, but essentially you will hit the wall
>> >> that __FILE__, __LINE__, and __FUNCTION__ are CPP artifacts.
>> >
>> >
>> > GNAT has built-in functions which return this information.
>>
>> This is a very sensible thing to do.
>>
>> > When they are
>> > used in default argument expressions and these arguments are omitted, the
>> > functions are evaluated in the context of the caller and return the file
>> > position at that point.  Perhaps that would be an approach for C++ as well?
>>
>> C++ already has the rule that default arguments are evaluated at the call
>> site, so this is definitely something to consider for stage 2 and higher builds.
>> For stage 1 builds, I suppose one would have to fake it and leave
>> with the imprecision that is bothering Richard?
>>
>> > (This assumes that gather-detailed-mem-stats is not needed in the first
>> > stage compiler.)
>>
>> it is built into stage 1 compiler, but I doubt that stage 1 compiler is
>> really useful to the kind of detailed statistics that would require this.
>
> The configury for --enable-gather-detailed-mem-stats is re-done for
> each stage, so if we add a proper feature check we can simply disable
> it in stage1 when the host compiler does not support this feature.

Yes, agreed.

>
> We can add __builtin__FILE__ and friends in generic code, for example
> "folding" them during gimplification using location information on
> the CALL_EXPR and the current function context.  I think at least
> __FUNCTION__ is already sort-of a "builtin" as the preprocessor
> has no way of expanding it.

Yes, you are right.
(We already have to treat __PRETTY_FUNCTION__ as a special case
so that it works reliably for template instances and reports template
arguments properly.)

-- Gaby


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