Hi,
On Fri, 24 Aug 2012, Diego Novillo wrote:
> > 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)?
>
> I really like this idea.
>
> Couldn't we make it ev
> "Diego" == Diego Novillo writes:
Diego> The compiler will then always add 'file', 'function' and 'line' to the
Diego> argument list, which can then be retrieved via builtins or special
Diego> argument names (I think builtins may be safer).
Diego> This would allow us to handle operators. I
On Fri, Aug 24, 2012 at 10:01 AM, Diego Novillo 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
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_cal
On 12-08-16 04:29 , Richard Guenther wrote:
May it not suggest it applies "very lazy", like after inlining for
example? Anyway, sofar I'd side with Michas suggestion of using
__builtin_FILE, etc. if people agree on adding _lazy that's fine
for me, too.
So far two votes for __builtin_FILE, one
On Wed, 15 Aug 2012, Gabriel Dos Reis wrote:
> On Wed, Aug 15, 2012 at 7:34 PM, Lawrence Crowl wrote:
> > Would it be more productive to ensure that existing tools, like
> > valgrind, are effective with gcc?
>
> Indeed. Richard's patch strikes me as the way to go with
> the issue he raised.
It
On Wed, 15 Aug 2012, Lawrence Crowl wrote:
> On 8/15/12, Gabriel Dos Reis wrote:
> > On Aug 15, 2012 Richard Guenther wrote:
> > > On Wed, 15 Aug 2012, Michael Matz wrote:
> > > > On Wed, 15 Aug 2012, Richard Guenther wrote:
> > > > > Prototype below - fire away on bikeshedding names.
> > > > Ma
On Wed, 15 Aug 2012, Tobias Burnus wrote:
> Am 15.08.2012 18:26, schrieb Gabriel Dos Reis:
> > On Wed, Aug 15, 2012 at 11:21 AM, Tobias Burnus wrote:
> > > Gabriel Dos Reis wrote:
> > > > A few points to consider:
> > > > * relation of __builtin_function_location to C99 (and C++11)
> > > >
On Wed, Aug 15, 2012 at 7:34 PM, Lawrence Crowl wrote:
> Would it be more productive to ensure that existing tools, like
> valgrind, are effective with gcc?
Indeed. Richard's patch strikes me as the way to go with
the issue he raised.
-- Gaby
Would it be more productive to ensure that existing tools, like
valgrind, are effective with gcc?
--
Lawrence Crowl
Or no explicit parameters at all ...
void do_something (T1 t1, T2 t2) __attribute__ ((caller_info));
All this will do (with appropriate compilation switches
and/or pre-defined macros) is pass one/more hidden
arguments, which in turn can be accessed in the
function body via a built-in function.
#
Would it be possible to define a new function
attribute that transparently adds two parameters
for file name and line number? Or that etablishes
a binding between this information and existing
parameter names? This might be useful for regular
"C" programs as well.
void do_something (T1 t1, T2 t
On Wed, Aug 15, 2012 at 5:15 PM, Lawrence Crowl wrote:
> On 8/15/12, Gabriel Dos Reis wrote:
>> On Aug 15, 2012 Richard Guenther wrote:
>> > On Wed, 15 Aug 2012, Michael Matz wrote:
>> > > On Wed, 15 Aug 2012, Richard Guenther wrote:
>> > > > Prototype below - fire away on bikeshedding names.
>>
On 8/15/12, Gabriel Dos Reis wrote:
> On Aug 15, 2012 Richard Guenther wrote:
> > On Wed, 15 Aug 2012, Michael Matz wrote:
> > > On Wed, 15 Aug 2012, Richard Guenther wrote:
> > > > Prototype below - fire away on bikeshedding names.
> > > Make it mirror the preprocessor names that people are used
On Wed, Aug 15, 2012 at 12:03 PM, Georg-Johann Lay wrote:
> Gabriel Dos Reis schrieb:
>
>> Richard Guenther wrote:
>>>
>>> Hm, well. The following includes documentation and the old new names,
>>> __builtin_file_location, etc.
>>
>>
>> This looks good too me.
>>
>> A few points to consider:
>>
Gabriel Dos Reis schrieb:
Richard Guenther wrote:
Hm, well. The following includes documentation and the old new names,
__builtin_file_location, etc.
This looks good too me.
A few points to consider:
* relation of __builtin_function_location to C99 (and C++11) __func__
* Do we want
Am 15.08.2012 18:26, schrieb Gabriel Dos Reis:
On Wed, Aug 15, 2012 at 11:21 AM, Tobias Burnus wrote:
Gabriel Dos Reis wrote:
A few points to consider:
* relation of __builtin_function_location to C99 (and C++11) __func__
* Do we want to update libcpp to systematically expand __FI
On Wed, Aug 15, 2012 at 11:21 AM, Tobias Burnus wrote:
> Gabriel Dos Reis wrote:
>>
>> A few points to consider:
>> * relation of __builtin_function_location to C99 (and C++11) __func__
>>
>> * Do we want to update libcpp to systematically expand __FILE__ to
>>__builtin_file_loca
Gabriel Dos Reis wrote:
A few points to consider:
* relation of __builtin_function_location to C99 (and C++11) __func__
* Do we want to update libcpp to systematically expand __FILE__ to
__builtin_file_location, etc?
If you do so, please make sure that you don't break Fortran,
On Wed, Aug 15, 2012 at 7:52 AM, Richard Guenther wrote:
> On Wed, 15 Aug 2012, Michael Matz wrote:
>
>> Hi,
>>
>> On Wed, 15 Aug 2012, Richard Guenther wrote:
>>
>> > Prototype below - fire away on bikeshedding names.
>>
>> Make it mirror the preprocessor names that people are used to, and do awa
On Wed, 15 Aug 2012, Michael Matz wrote:
> Hi,
>
> On Wed, 15 Aug 2012, Richard Guenther wrote:
>
> > Prototype below - fire away on bikeshedding names.
>
> Make it mirror the preprocessor names that people are used to, and do away
> with the _loc_: __builtin_FILE, __builtin_FUNCTION, __builti
Hi,
On Wed, 15 Aug 2012, Richard Guenther wrote:
> Prototype below - fire away on bikeshedding names.
Make it mirror the preprocessor names that people are used to, and do away
with the _loc_: __builtin_FILE, __builtin_FUNCTION, __builtin_LINE.
Ciao,
Michael.
On 12-08-15 07:26 , Richard Guenther wrote:
Prototype below - fire away on bikeshedding names.
*_loc instead of loc_*? So it reads as 'file location', 'function
location', etc.
Other than that, looks fine to me.
Diego.
On Wed, 15 Aug 2012, Gabriel Dos Reis wrote:
> On Wed, Aug 15, 2012 at 6:01 AM, Richard Guenther wrote:
> > On Wed, 15 Aug 2012, Gabriel Dos Reis wrote:
> >
> >> On Wed, Aug 15, 2012 at 5:11 AM, Florian Weimer wrote:
> >> > On 08/15/2012 12:07 PM, Gabriel Dos Reis wrote:
> >> >
> >> >> You might
On Wed, Aug 15, 2012 at 6:01 AM, Richard Guenther wrote:
> On Wed, 15 Aug 2012, Gabriel Dos Reis wrote:
>
>> On Wed, Aug 15, 2012 at 5:11 AM, Florian Weimer wrote:
>> > On 08/15/2012 12:07 PM, Gabriel Dos Reis wrote:
>> >
>> >> You might try to encode/package information with the
>> >> parameters
On Wed, Aug 15, 2012 at 5:10 AM, 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 direc
On Wed, 15 Aug 2012, Gabriel Dos Reis wrote:
> On Wed, Aug 15, 2012 at 5:11 AM, Florian Weimer 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__
On Wed, Aug 15, 2012 at 5:11 AM, Florian Weimer 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
On Wed, 15 Aug 2012, Richard Guenther wrote:
How would you deal with removing the ops3 variant here:
-#define gimple_build_assign_with_ops(c,o1,o2,o3) \
- gimple_build_assign_with_ops_stat (c, o1, o2, o3, NULL_TREE
MEM_STAT_INFO)
-#define gimple_build_assign_with_ops3(c,o
On Wed, 15 Aug 2012, Gabriel Dos Reis wrote:
> On Wed, Aug 15, 2012 at 4:37 AM, Richard Guenther wrote:
> >
> > I face an issue with replacing macros with C++ functions and the
> > way we implement gather-detailed-mem-stats. Currently the
> > mem-stat info is passed at the call site of functions
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. When they
are
On Wed, Aug 15, 2012 at 4:37 AM, Richard Guenther wrote:
>
> I face an issue with replacing macros with C++ functions and the
> way we implement gather-detailed-mem-stats. Currently the
> mem-stat info is passed at the call site of functions via macros
> like
>
> #define VEC_safe_grow_cleared(T,A
32 matches
Mail list logo
