This stock will make profits for you: V N DB
"Shorters Started To Buy The Stock Back Making The Price Settle at low .02.
It's time to grow!"
To Keep In Mind
- The soon to be signed Hallmark(4Bill) contract is on its way!!!
- Their previous contractor now is currently traded at $1.80!
- Which i
So no one wastes time looking into this
On Wed, Aug 15, 2012 at 10:54 AM, Matt Davis wrote:
> Hello,
> In my compiler pass, I am inserting a new gimple call statement, and
> then replacing the next call. This usually works fine, and after I do
> this, the gimple dump looks as I expect. Howe
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,V,I) \
(VEC_safe_grow_cleared_1 (&(V), (int)
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
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, 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 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, 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, 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: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, 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, 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 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.
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 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
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
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 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
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
The default setting of -grecord-gcc-switches recently changed from 0 to 1:
2012-04-25 Jakub Jelinek
* common.opt (flag_debug_types_section): Default to 0.
...
(dwarf_record_gcc_switches): Default to 1.
Because of this, by default all objects in libraries built as p
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
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:
>>
On 08/15/2012 06:00 PM, Diego Novillo wrote:
> On the switch to C++ as the build language for GCC ...
Here are my results:
0:30 UTC - using C as the initial build language:
http://gcc.gnu.org/ml/gcc-testresults/2012-08/msg01329.html
and:
18:40 UTC - using C++ as the initial build language:
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 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.
>>
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
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 more productive to ensure that existing tools, like
valgrind, are effective with gcc?
--
Lawrence Crowl
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
29 matches
Mail list logo
