On Fri, Aug 24, 2012 at 10:01 AM, Diego Novillo <dnovi...@google.com> wrote:
> On 2012-08-15 06:10 , Richard Guenther wrote:
>
>> Maybe have a GNU C++ builtin type
>>
>> struct __Gcc_call_location_pack {
>> const char *file;
>> const char *function;
>> unsigned line;
>> };
>>
>> and an attribute
>>
>> void foo (int bar) __attribute__((add_location_pack));
>>
>> that directs GNU C++ to add a __Gcc_call_location_pack typed
>> argument at each call site (properly constructed of course)?
>>
>> Or more explicitely:
>>
>> void foo (int bar,
>> __Gcc_call_location_pack pack = __Gcc_create_location_pack ());
>>
>> ? I'd be willing to pay the price that only GCC can build itself
>> with mem-stat support.
>
>
> I really like this idea.
>
> Couldn't we make it even more transparent? If a function is marked with
> __attribute__((add_location_pack)) (or some other attribute name), the
> callers will always pass file, function and line as hidden arguments (in the
> same way that 'this' is passed as a hidden argument).
If we go with this approach, then it must be made transparent
(there is no point in adding such a facility in the compiler if its
usage is a painpoint :-)
>
> The compiler will then always add 'file', 'function' and 'line' to the
> argument list, which can then be retrieved via builtins or special argument
> names (I think builtins may be safer).
>
> This would allow us to handle operators. I don't think it would be a big
> deal if this introduces ABI incompatibilities.
I think we still have ABI issue to resolve.
So far, implicit arguments such as `this' as are still fully
spelled out in function elaborations. E.g. a non-static
member function of arity n is elaborated as a function
of arity n+1. A binary operator is always elaborated as
a binary function whether it is defined as a member or a free function.
-- Gaby
