On Tue, Oct 23, 2012 at 6:11 AM, Dodji Seketeli wrote:
> This patch instruments many memory access patterns through builtins.
>
> Basically, for a call like:
>
> __builtin_memset (from, 0, n_bytes);
>
> the patch would only instrument the accesses at the beginning and at
> the end of the memo
On Thu, Oct 18, 2012 at 3:36 PM, Easwaran Raman wrote:
> Hi,
>
> During expression reassociation, statements are conservatively moved
> downwards to ensure that dependences are correctly satisfied after
> reassocation. This could lead to lengthening of live ranges. This
> patch moves statements on
erated under
> $topbuilddir/x86_64-unknown-linux-gnu/libasan you met yesterday
> appeared. That is why I had to generate the new libtool m4 files and
> ltmain.sh using libtoolize.
>
> Thanks,
> Wei.
>
> On Fri, Oct 19, 2012 at 10:16 AM, Xinliang David Li
> wrote:
>&
I tried it, and this version works for me.
Your probably do not need to add the m4 subdir under libasan. The
required m4 files are either in .. or ../config dir. See how
libmudflap does it.
Other than that, if there are no other comments, the change is good to
check into the branch. Remaining bu
nate this include completely
> (we've just discussed this yesterday).
>
>
> --kcc
>
> On Thu, Oct 18, 2012 at 11:29 PM, Xinliang David Li
> wrote:
>>
>> + kcc the author of the libasan library.
>>
>> Koystya, does libasan build (need to ) depend on C++ l
The following is small bug fix caught during testing. The shadow value
for redzone can be negative, so the shadow type must be signed for the
check to succeed.
Ok for the branch?
thanks,
David
Index: asan.c
===
--- asan.c (re
+ kcc the author of the libasan library.
Koystya, does libasan build (need to ) depend on C++ library ?
thanks,
David
On Thu, Oct 18, 2012 at 12:26 PM, Xinliang David Li wrote:
> On Thu, Oct 18, 2012 at 11:22 AM, Jakub Jelinek wrote:
>> On Thu, Oct 18, 2012 at 11:15:33AM -0700,
On Thu, Oct 18, 2012 at 11:22 AM, Jakub Jelinek wrote:
> On Thu, Oct 18, 2012 at 11:15:33AM -0700, Xinliang David Li wrote:
>> >> --- Makefile.def (revision 192487)
>> >> +++ Makefile.def (working copy)
>> >> @@ -119,6 +119,7 @@
On Tue, Oct 16, 2012 at 12:27 AM, Jakub Jelinek wrote:
> On Mon, Oct 15, 2012 at 11:39:52PM -0700, Wei Mi wrote:
>> --- gcc/gcc.c (revision 192487)
>> +++ gcc/gcc.c (working copy)
>> @@ -679,6 +679,7 @@ proper position among the other output f
>> %{fgnu-tm:%:include(libitm.spec)%(link_itm)}\
On Thu, Oct 18, 2012 at 5:58 AM, Jakub Jelinek wrote:
> Hi!
>
> Dodji reported to me an ICE about NOTE_INSN_BASIC_BLOCK in a middle
> of a bb. The following patch (cfgexpand.c hunk) fixes that.
> I then run asan cc1/cc1plus with -O2 -fasan on a portion of cc1files
> and got other ICEs, which is t
Yes, I think it is good for the branch.
thanks,
David
On Wed, Oct 17, 2012 at 4:11 AM, Jakub Jelinek wrote:
> On Tue, Oct 16, 2012 at 02:41:42PM -0700, Xinliang David Li wrote:
>> On Tue, Oct 16, 2012 at 7:58 AM, Jakub Jelinek wrote:
>> Why the above two condition? If the l
Looks ok to me for the branch.
thanks,
David
On Wed, Oct 17, 2012 at 2:35 AM, Jakub Jelinek wrote:
> On Tue, Oct 16, 2012 at 03:56:31PM -0700, Xinliang David Li wrote:
>> >> 1) I am not sure if the stack slot sharing is handled correctly. If I
>> >> read the code
On Tue, Oct 16, 2012 at 11:51 PM, Jakub Jelinek wrote:
> On Tue, Oct 16, 2012 at 04:19:09PM -0700, Xinliang David Li wrote:
>> I am not sure -- fasan is an error detecting feature -- the goal is to
>> find bugs -- missing handling of commons etc. are not desirable.
>> Be
On Tue, Oct 16, 2012 at 4:02 PM, Jakub Jelinek wrote:
> On Tue, Oct 16, 2012 at 03:50:27PM -0700, Xinliang David Li wrote:
>> Does that mean that all globals defined in shared libraries can not be
>> protected as long as they are not protected or hidden? This sounds
>> like
On Tue, Oct 16, 2012 at 2:52 PM, Jakub Jelinek wrote:
> On Tue, Oct 16, 2012 at 01:56:46PM -0700, Xinliang David Li wrote:
>> Looks good except for the following:
>>
>> 1) I am not sure if the stack slot sharing is handled correctly. If I
>> read the code correctly, t
On Tue, Oct 16, 2012 at 3:03 PM, Jakub Jelinek wrote:
> On Tue, Oct 16, 2012 at 02:41:42PM -0700, Xinliang David Li wrote:
>> > +bool
>> > +asan_protect_global (tree decl)
>> > +{
>> > + rtx rtl, symbol;
>> > + section *sect;
On Tue, Oct 16, 2012 at 7:58 AM, Jakub Jelinek wrote:
> Hi!
>
> This is a WIP patch for globals protection.
> I'm not filling names yet and has_dynamic_init is always
> false (wonder how to figure it has_dynamic_init out, especially
> with LTO, TYPE_ADDRESSABLE (TREE_TYPE (decl)) probably isn't it
Looks good except for the following:
1) I am not sure if the stack slot sharing is handled correctly. If I
read the code correctly, the redzone var will be only created for the
representative variable in a partition -- will this lead to false
negatives? As I asked before, should stack slot sharing
On Tue, Oct 16, 2012 at 10:40 AM, Jakub Jelinek wrote:
> On Tue, Oct 16, 2012 at 09:48:28AM -0700, Xinliang David Li wrote:
>> The way to do this is not to use the shadow memory, but to clobber
>> directly the variable itself with specified byte pattern -- though
>> error di
wrote:
> On Tue, Oct 16, 2012 at 09:06:22AM -0700, Xinliang David Li wrote:
>> I don't get it. Clobber marks the end of lifetime of a variable so it
>> is safe to emit code to really clobber its value -- otherwise how
>> would clobber based slot sharing work?
>
> If
On Mon, Oct 15, 2012 at 11:12 PM, Jakub Jelinek wrote:
> On Mon, Oct 15, 2012 at 10:48:13PM -0700, Xinliang David Li wrote:
>> Another error checking feature is to poison stack vars on entry and
>> exit of the lexical scope to catch uninit variable reference and out
>>
The change to remove mode check looks good to me.
Not directly related to this bug but somehow related: the REE has
obvious conservativeness regarding partial redundancy (i.e., not all
reaching def has the bits properly extended). However, there are bugs
preventing elimination even with full redu
, it is in the wishlist:
http://code.google.com/p/address-sanitizer/issues/detail?id=83
Might be good consider this feature.
David
On Fri, Oct 12, 2012 at 9:30 AM, Xinliang David Li wrote:
> On Fri, Oct 12, 2012 at 12:15 AM, Jakub Jelinek wrote:
>> On Thu, Oct 11, 2012 at 04:19:18PM
On Fri, Oct 12, 2012 at 1:22 AM, Richard Biener
wrote:
> On Thu, Oct 11, 2012 at 10:39 PM, Xinliang David Li
> wrote:
>> On Thu, Oct 11, 2012 at 1:23 PM, Lawrence Crowl wrote:
>>> On 10/10/12, Xinliang David Li wrote:
>>>> In a different thread, I prop
On Fri, Oct 12, 2012 at 11:10 AM, Jakub Jelinek wrote:
> On Fri, Oct 12, 2012 at 10:52:04AM -0700, Xinliang David Li wrote:
>> This is related to the way how you implement it. Emitting the stack
>> shadow initialization code in GIMPLE would solve the problem. I think
>>
On Fri, Oct 12, 2012 at 9:27 AM, Jakub Jelinek wrote:
> Hi!
>
> This is not finished completely yet, but roughly implements protection
> of stack variables. As testcase I was using:
> extern void *malloc (__SIZE_TYPE__);
>
> int
> main ()
> {
> char buf1[16];
> char buf2[256];
> char buf3[3
On Fri, Oct 12, 2012 at 12:26 AM, Jakub Jelinek wrote:
> On Thu, Oct 11, 2012 at 10:05:54PM -0700, Xinliang David Li wrote:
>> Was:
>> Type global;
>> Now:
>> struct { // at least 32-byte aligned
>>Type orig;
>>char redzone[32 + r
On Fri, Oct 12, 2012 at 9:32 AM, Jakub Jelinek wrote:
> On Fri, Oct 12, 2012 at 09:30:33AM -0700, Xinliang David Li wrote:
>> > Yeah, I think the stack check shouldn't be that hard and can hack it up,
>> > I'll perhaps leave the global vars stuff to Dodji or others
On Fri, Oct 12, 2012 at 12:15 AM, Jakub Jelinek wrote:
> On Thu, Oct 11, 2012 at 04:19:18PM -0700, Wei Mi wrote:
>> Here is the initial test results of gcc asan patch, and it shows us
>> some missing features in gcc but existing in llvm.
>> [1]. gcc regression test for gcc-asan passes.
>> [2]. llv
ok.
thanks,
David
On Thu, Oct 11, 2012 at 1:21 PM, Easwaran Raman wrote:
> This patch moves the two argument delete operator into its own file.
> When a program provides its own definition of operator delete (void
> *), but not operator delete (void *, size_t), we could end up linking
> two fil
On Thu, Oct 11, 2012 at 1:23 PM, Lawrence Crowl wrote:
> On 10/10/12, Xinliang David Li wrote:
>> In a different thread, I proposed the following alternative to 'try_xxx':
>>
>> template T* symbol::cast_to(symbol* p) {
>>if (p->is())
>&g
On Thu, Oct 11, 2012 at 11:12 AM, Jakub Jelinek wrote:
> On Thu, Oct 11, 2012 at 10:31:58AM -0700, Xinliang David Li wrote:
>> > +#define PROB_VERY_UNLIKELY (REG_BR_PROB_BASE / 2000 - 1)
>> > +#define PROB_ALWAYS(REG_BR_PROB_BASE)
>> > +
>>
On Thu, Oct 11, 2012 at 9:38 AM, Jakub Jelinek wrote:
> Hi!
>
> Building trees, then gimplifying it, is unnecessarily expensive.
> This patch changes build_check_stmt to emit GIMPLE directly, and
> a couple of small cleanups here and there. Also, I'm using a different
> alias set for the shadow m
On Thu, Oct 11, 2012 at 6:16 AM, Richard Biener
wrote:
> On Thu, Oct 11, 2012 at 3:52 AM, Easwaran Raman wrote:
>> Hi,
>> In the expression reassociation pass, statements might get moved
>> downwards to ensure that dependences are not violated after
>> reassociation. This can increase the live r
On Wed, Oct 10, 2012 at 6:52 PM, Easwaran Raman wrote:
> Hi,
> In the expression reassociation pass, statements might get moved
> downwards to ensure that dependences are not violated after
> reassociation. This can increase the live range and, in a tight loop,
> result in spills. This patch sim
On Fri, Oct 5, 2012 at 1:49 AM, Richard Guenther
wrote:
> On Thu, Oct 4, 2012 at 8:16 PM, Diego Novillo wrote:
>> On Thu, Oct 4, 2012 at 2:14 PM, Lawrence Crowl wrote:
>>
>>> So, Jan Hubicka requested and approved the current spelling.
>>> What now?
>>
>> I don't think we should hold this up. T
On Wed, Sep 19, 2012 at 11:39 AM, Lawrence Crowl wrote:
> On 9/19/12, Gabriel Dos Reis wrote:
>> On Sep 19, 2012 Richard Guenther wrote:
>> > Indeed. Btw, can we not provide a specialization for
>> > dynamic_cast <>? This ->try_... looks awkward to me compared
>> > to the more familiar
>> >
>>
In a different thread, I proposed the following alternative to 'try_xxx':
template T* symbol::cast_to(symbol* p) {
if (p->is())
return static_cast(p);
return 0;
}
cast:
template T& symbol:as(symbol* p) {
assert(p->is())
return static_cast(*p);
}
David
On Wed, Sep 19, 2012
On Wed, Oct 10, 2012 at 2:08 PM, Steven Bosscher wrote:
> On Wed, Oct 10, 2012 at 11:00 PM, Xinliang David Li wrote:
>> Is there an agreed way for file naming?
>
> It was not my intent to start a bike shed discussion. This was just
> something I've been wondering for some
Is there an agreed way for file naming?
David
On Wed, Oct 10, 2012 at 1:48 PM, Steven Bosscher wrote:
> On Wed, Oct 10, 2012 at 10:20 PM, Diego Novillo wrote:
>> * tree-asan.c: New file.
>> * tree-asan.h: New file.
>
> Nit: do we still need the "tree-" prefix? IMHO not.
>
> Ciao!
Ok for google branches.
Please consider resend the original xray patch to trunk (gcc-4_8) You
need to make the runtime bits available publicly though.
thanks,
David
On Fri, Sep 28, 2012 at 2:24 AM, Harshit Chopra wrote:
> commit fc3a55ccec9bc770c79f8a221f5abd397befc8f6
> Author: Harshit Chopra
xray feature is not in trunk yet.
David
On Fri, Oct 5, 2012 at 3:53 PM, Diego Novillo wrote:
> Harshit, why didn't you propose this patch for trunk? Why should we
> make it a google-local patch?
>
>
> Diego.
>
> On Fri, Sep 28, 2012 at 5:24 AM, Harshit Chopra wrote:
>> commit fc3a55ccec9bc770c
thanks. That will be helpful.
David
On Fri, Oct 5, 2012 at 2:09 PM, Dehao Chen wrote:
> Sure, I'll add a detailed documentation in a gcc wiki page.
>
> Dehao
>
> On Fri, Oct 5, 2012 at 2:01 PM, Xinliang David Li wrote:
>> Dehao, the file auto-profile.c has some
Hi Jason, Sri has addressed the comments you had on FE part. Can you
take a look if it is ok? Stage-1 is going to be closed soon, and we
hope to get this major feature in 4.8.
thanks,
David
On Tue, Sep 18, 2012 at 9:29 AM, Sriraman Tallam wrote:
> Ping.
>
> On Fri, Aug 24, 2012 at 5:34 PM,
thanks for the update!
David
On Wed, Oct 3, 2012 at 10:37 AM, Steven Bosscher wrote:
> On Wed, Oct 3, 2012 at 6:12 PM, Xinliang David Li wrote:
>> What is the status of switch expansion GIMPLE rewrite? If it is not
>> planned for 4.8, It will be desirable to include this fix in
What is the status of switch expansion GIMPLE rewrite? If it is not
planned for 4.8, It will be desirable to include this fix into trunk.
It also helps set up a good base line to test against regression.
thanks,
David
On Tue, Oct 2, 2012 at 6:09 PM, Easwaran Raman wrote:
> Hi,
> This patch pr
sier to read/maintain.
>
I find it confusing to be honest. The redundant check serves no purpose.
David
> Sharad
> Sharad
>
>
> On Mon, Oct 1, 2012 at 3:45 PM, Xinliang David Li wrote:
>> On Mon, Oct 1, 2012 at 2:37 PM, Michael Meissner
>> wrote:
>>> I tracked
On Mon, Oct 1, 2012 at 2:37 PM, Michael Meissner
wrote:
> I tracked down some of the other code that previously used REPORT_DETAILS, and
> MSG_NOTE is the new way to do the same thing. This bootstraps and no
> unexpected errors occur during make check. Is it ok to install?
>
> 2012-10-01 Michae
ok (for google-47 and google/main)
thanks,
David
On Fri, Sep 28, 2012 at 10:22 AM, Rong Xu wrote:
> Comments are inlined.
> Attached is the new patch.
>
> Thanks,
>
> -Rong
>
> On Tue, Sep 25, 2012 at 2:25 PM, Xinliang David Li wrote:
>> On Mon, Sep 24, 2012 at 2
On Thu, Sep 27, 2012 at 4:35 AM, Sharad Singhai wrote:
> Thanks for the review. A couple of comments inline:
>
>> Some minor issues:
>>
>> * c/c-decl.c (c_write_global_declarations): Use different method to
>> determine if the dump has ben initialized.
>> * cp/decl2.c (cp_w
The following patch fixes a mis-fired error on extern alias
(same-body). The assembler hash related code needs rework to avoid
patches like this. (The bug was found during a large grouping stress
test).
David
extern_alias.p
Description: Binary data
On Mon, Sep 24, 2012 at 2:42 PM, Rong Xu wrote:
> Hi,
>
> This is for google branches only.
> It fix the lino number checksum mismatch during LIPO-use build.
>
> Tested with SPEC and google internal banchmarks.
>
> Thanks,
>
> -Rong
>
> 2012-09-24 Rong Xu
>
> * gcc/coverage.c (coverage_
Ok.
David
On Mon, Sep 24, 2012 at 2:41 PM, Rong Xu wrote:
> Hi,
>
> This patch is for google branches only.
> It prohibits the grouping of modules with diffent flag_rtti value.
> otherwise it may cause profile mismatch, undefined symbols and some other
> internal errors.
>
> Tested with google i
ok.
David
On Mon, Sep 24, 2012 at 2:40 PM, Rong Xu wrote:
> Hi,
>
> This patch is for google branches only.
> It fixes the unsatified symbol in lipo-use build.
> Tested with SPEC and google internal benchmarks.
>
> Thanks,
>
> -Rong
>
>
> 2012-09-24 Rong Xu
>
> * gcc/l-ipo.c (cgraph_i
On Tue, Sep 18, 2012 at 1:48 AM, Sharad Singhai wrote:
> In response to the recent comments, I have updated the patch to do the
> following:
>
> - Remove pass handling from -fopt-info
> - Support additional flags in regular dumps
>
> I have massaged the options so that they have the following (hop
yes.
thanks,
David
On Fri, Sep 14, 2012 at 1:20 PM, Teresa Johnson wrote:
> On Fri, Sep 14, 2012 at 1:19 PM, Diego Novillo wrote:
>> On Fri Sep 14 16:17:25 2012, Teresa Johnson wrote:
>>
>>> Should I just put it onto ggogle/4_7 and 4_6 directly then?
>>
>>
>> Yeah. Not sure it's really needed
Yes. The google/main update will happen next quarter.
David
On Fri, Sep 14, 2012 at 1:17 PM, Teresa Johnson wrote:
> On Fri, Sep 14, 2012 at 1:10 PM, Diego Novillo wrote:
>> On Fri, Sep 14, 2012 at 4:09 PM, Teresa Johnson wrote:
>>> Backport from trunk r190952 to add counter histogram to gcov
The following patch fixes a problem exposed in LIPO random stress
testing with large module groups -- the error is that multiple copies
compiler generated static functions (ctor of class in anonymous
namespace) get emitted.
David
Index: cgraphunit.c
=
Yes, indeed.
thanks,
David
On Thu, Sep 13, 2012 at 4:08 AM, Richard Guenther
wrote:
> On Wed, Sep 12, 2012 at 6:46 PM, Xinliang David Li wrote:
>> On Wed, Sep 12, 2012 at 3:30 AM, Richard Guenther
>> wrote:
>>> On Wed, Sep 12, 2012 at 10:12 AM, Sharad Singhai wro
It is very important to make sure -g does not affect code gen ---
people do release build with -g with optimization, and strip the
binary before sending it to production machines ..
David
On Thu, Sep 13, 2012 at 6:33 AM, Robert Dewar wrote:
> On 9/13/2012 8:00 AM, Richard Guenther wrote:
>
>> Be
ehao
>
> On Thu, Sep 13, 2012 at 1:18 AM, Xinliang David Li wrote:
>> On Wed, Sep 12, 2012 at 10:05 AM, Dehao Chen wrote:
>>> There are two parts that needs memory management:
>>>
>>> 1. The BLOCK structure. This is managed by GC. I originally thought
>&
ck is in the map, it can still be
> GCed as soon as it's not reachable from DECL_INITIAL.
>
> I've tested this on some very large C++ files (each one takes more
> than 10s to build), the memory consumption does not see noticeable
> increase/decrease.
>
> Thanks,
> Deh
On Wed, Sep 12, 2012 at 2:13 AM, Richard Guenther
wrote:
> On Wed, Sep 12, 2012 at 7:06 AM, Dehao Chen wrote:
>> Now I think we are facing a more complex problem. The data structure
>> we use to store the location_adhoc_data are file-static in linemap.c
>> in libcpp. These data structures are not
Can you make definition of location_adhoc_data available in both
libcpp and gcc? In gcc side, the data structure will be annotated
with GTY(). The root global variables should also be visible in gcc
side.
David
On Tue, Sep 11, 2012 at 10:06 PM, Dehao Chen wrote:
> Now I think we are facing a mo
89,11 @@ slpeel_make_loop_iterate_ntimes (struct loop
>>> >>>>> *loop
>>> >>>>> gsi_remove (&loop_cond_gsi, true);
>>> >>>>>
>>> >>>>> loop_loc = find_loop_location (loop);
>>> >>>&
On Fri, Aug 24, 2012 at 3:56 PM, wrote:
>
> http://codereview.appspot.com/6427063/diff/11002/gcc/gcov-io.h
> File gcc/gcov-io.h (right):
>
> http://codereview.appspot.com/6427063/diff/11002/gcc/gcov-io.h#newcode688
> gcc/gcov-io.h:688: gcov_unsigned_t index; /* The corresponding string
> table
I don't see any code where a string table is declared nor created ...
David
On Fri, Aug 24, 2012 at 2:26 PM, Chris Manghane wrote:
> Also, what did you mean by there being missing string table management code?
>
>
> On Fri, Aug 24, 2012 at 2:23 PM, wrote:
>>
>>
>> Ok, I fixed most of the probl
Ok for now but some follow up may be needed.
thanks,
David
On Thu, Aug 23, 2012 at 4:21 PM, Teresa Johnson wrote:
> On Thu, Aug 23, 2012 at 3:33 PM, Xinliang David Li wrote:
>> On Thu, Aug 23, 2012 at 2:01 PM, Teresa Johnson wrote:
>>> This patch is for google branches onl
On Thu, Aug 23, 2012 at 2:01 PM, Teresa Johnson wrote:
> This patch is for google branches only.
>
> This is the patch I plan to apply after reverting an earlier set of
> patches ported over from trunk that addressed the same problem but
> were causing some performance regressions. This is a narro
The patch is needed to handle more options that will causes invalid
LIPO module grouping. The new option handled is -fsized-delete.
David
On Thu, Aug 23, 2012 at 11:32 AM, David Li wrote:
> Index: coverage.c
> ===
> --- coverage.c
On Tue, Aug 21, 2012 at 12:34 AM, Jan Hubicka wrote:
>> Teresa has done some tunings for the unroller so far. The inliner
>> tuning is the next step.
>>
>> >
>> > What concerns me that it is greatly inaccurate - you have no idea how many
>> > instructions given counter is guarding and it can diffe
On Mon, Aug 20, 2012 at 11:33 PM, Jan Hubicka wrote:
>>
>> This is useful for large applications with a long tail. The
>> instruction working set for those applications are very large, and
>> inliner and unroller need to be aware of that and good heuristics can
>> be developed to throttle aggressi
On Mon, Aug 20, 2012 at 10:29 PM, Jan Hubicka wrote:
>> On Mon, Aug 20, 2012 at 6:27 PM, Jan Hubicka wrote:
>> >> Xinliang David Li writes:
>> >> >
>> >> > Process level synchronization problems can happen when two processes
>> >> &g
I was mistaken here -- gcov_open actually uses locking via fcntl
interface -- so we do need to find a way to solve the summary update
synchronization problem when it is separate out of the per-file update
loop.
David
On Mon, Aug 20, 2012 at 12:03 PM, Andi Kleen wrote:
> Xinliang David
> If this approach seems like it is feasible, then we could stick with
> the current approach of emitting the working set array in the summary,
> mitigating it somewhat by doing the sum_all based scaling of the
> counter values, then in a follow on patch restructure the merging code
> to delay the
>
> So I definitely preffer 2 or 3 over 1. David has experience with 3. How well
> does
> it work for LIPO?
>
This (lack of locking, races) is not a new problem. There is no
synchronization in libgcov for profile update/merge at both thread and
process level. Thread level data races leads to inco
On Sun, Aug 19, 2012 at 9:59 PM, Teresa Johnson wrote:
> On Sat, Aug 18, 2012 at 1:19 AM, Jan Hubicka wrote:
>>
>> > +{
>> > + cs_prg->num = cs_tprg->num;
>> > + /* Allocate the working set array for the merged
>> > summary. */
>> > +
On Tue, Jul 10, 2012 at 2:46 AM, Jason Merrill wrote:
> On 07/09/2012 11:27 PM, Xinliang David Li wrote:
>>
>> Ok. Do you have specific comments on the patch?
>
>
> My comment is "Perhaps we want to implement this using a more generic
> mechanism." I was thi
Is this related to the problem described in
http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01511.html ?
David
On Mon, Jun 25, 2012 at 4:43 AM, Dehao Chen wrote:
> During function inlining, a lexical block is added for each cloned
> callee, and source info is attached to this block for addr2line to
Ok. Do you have specific comments on the patch?
thanks,
David
On Sun, Jul 8, 2012 at 4:20 AM, Jason Merrill wrote:
> On 07/07/2012 08:38 PM, Xinliang David Li wrote:
>>>
>>> It seems to me that what you have here are target-specific attributes
>>> that
>>
Ping ..
On Wed, Jul 4, 2012 at 8:01 AM, Xinliang David Li wrote:
> Comment?
>
> David
>
> On Mon, Jul 2, 2012 at 4:30 PM, Xinliang David Li wrote:
>> I extended the patch a little so that the option can be used to set
>> multiple stack reuse levels: -fstack-reuse=[al
On Fri, Jul 6, 2012 at 11:05 PM, Jason Merrill wrote:
> On 06/14/2012 04:13 PM, Sriraman Tallam wrote:
>>
>> C++ Frontend maintainers, Could you please take a look at the
>> front-end part when you find the time?
>
>
> It seems to me that what you have here are target-specific attributes that
Comment?
David
On Mon, Jul 2, 2012 at 4:30 PM, Xinliang David Li wrote:
> I extended the patch a little so that the option can be used to set
> multiple stack reuse levels: -fstack-reuse=[all|name_vars|none]
>
> all: enable stack reuse for all local vars (named vars and compiler
will be updated when the patch is agreed upon.
thanks,
David
On Thu, Jun 28, 2012 at 10:43 PM, Xinliang David Li wrote:
> (re-post in plain text)
>
> Moving this to cfgexpand time is simple and it can also be extended to
> handle scoped variables. However Jakub raised a good poin
the
clobber stmt.
thanks,
David
On Tue, Jun 26, 2012 at 1:28 AM, Richard Guenther
wrote:
> On Mon, Jun 25, 2012 at 6:25 PM, Xinliang David Li wrote:
>> Are there any more concerns about this patch? If not, I'd like to check it
>> in.
>
> No - the fact that the f
Are there any more concerns about this patch? If not, I'd like to check it in.
thanks,
David
On Fri, Jun 22, 2012 at 8:51 AM, Xinliang David Li wrote:
> On Fri, Jun 22, 2012 at 2:39 AM, Richard Guenther
> wrote:
>> On Fri, Jun 22, 2012 at 11:29 AM, Jason Merrill wrote:
>
thanks for the fix. It works fine for me.
David
On Sat, Jun 23, 2012 at 11:00 AM, Nathan Sidwell wrote:
> This patch changes the coverage unlinking to be less aggressive. As David
> pointed out, when experimenting with random optimization options along side
> -fuse-coverage and -frandom-seed, i
On Fri, Jun 22, 2012 at 2:39 AM, Richard Guenther
wrote:
> On Fri, Jun 22, 2012 at 11:29 AM, Jason Merrill wrote:
>> On 06/22/2012 01:30 AM, Richard Guenther wrote:
What other issues? It enables more potential code motion, but on the
other hand, causes more conservative stack reuse
On Thu, Jun 21, 2012 at 2:21 AM, Richard Guenther
wrote:
> On Thu, Jun 21, 2012 at 7:28 AM, Xinliang David Li wrote:
>> I modified the documentation and it now looks like this:
>>
>> @item -ftemp-stack-reuse
>> @opindex ftemp_stack_reuse
>> This option enables
I modified the documentation and it now looks like this:
@item -ftemp-stack-reuse
@opindex ftemp_stack_reuse
This option enables stack space reuse for temporaries. The default is on.
The lifetime of a compiler generated temporary is well defined by the C++
standard. When a lifetime of a temporary
triaging of
bugs like this is pretty time consuming to triage. This patch tries to
introduce an option to disable stack reuse for temporaries, which can
be used to debugging purpose.
Is this good for trunk?
thanks,
David
2012-06-20 Xinliang David Li
* common.opt: -ftemp-reuse-sta
It looks reasonable to move it after DCE which exposes more opportunities.
David
On Thu, Jun 14, 2012 at 6:38 PM, Easwaran Raman wrote:
> The conditional dead call elimination pass shrink wraps certain dead
> calls to math functions. It doesn't handle case like this:
>
> D.142420_139 = powD.549
...);
> This will output to dump file(s) only when dump_flag is enabled for a
> given pass.
>
> I have bootstrapped and tested it on x86_64. Does it look okay?
>
> Thanks,
> Sharad
>
>
> On Mon, May 14, 2012 at 12:26 AM, Richard Guenther
> wrote:
>> On Sat,
On Wed, Jun 6, 2012 at 2:02 PM, Teresa Johnson wrote:
> On Tue, Jun 5, 2012 at 11:46 AM, wrote:
>>
>> http://codereview.appspot.com/6282045/diff/1/gcc/gcov-io.h
>> File gcc/gcov-io.h (right):
>>
>> http://codereview.appspot.com/6282045/diff/1/gcc/gcov-io.h#newcode544
>> gcc/gcov-io.h:544: gcov_u
On Wed, Jun 6, 2012 at 2:02 PM, Teresa Johnson wrote:
> On Tue, Jun 5, 2012 at 11:46 AM, wrote:
>>
>> http://codereview.appspot.com/6282045/diff/1/gcc/gcov-io.h
>> File gcc/gcov-io.h (right):
>>
>> http://codereview.appspot.com/6282045/diff/1/gcc/gcov-io.h#newcode544
>> gcc/gcov-io.h:544: gcov_u
The patch looks like 4_7 based which can be different from 4_6 based
one. Do you have the latter one for review?
David
On Wed, Jun 6, 2012 at 2:02 PM, Teresa Johnson wrote:
> On Tue, Jun 5, 2012 at 11:46 AM, wrote:
>>
>> http://codereview.appspot.com/6282045/diff/1/gcc/gcov-io.h
>> File gcc/gc
Also needs to get the attribute spec and call the attribute handler ..
David
On Tue, Jun 5, 2012 at 9:28 PM, Xinliang David Li wrote:
> Please document it in doc/invoke.texi with examples.
>
> thanks,
>
> David
>
> On Tue, Jun 5, 2012 at 7:28 PM, Dehao Chen wrote:
&g
Please document it in doc/invoke.texi with examples.
thanks,
David
On Tue, Jun 5, 2012 at 7:28 PM, Dehao Chen wrote:
> Patch updated: using regex to match the function name:
>
> http://codereview.appspot.com/6281047
>
> Thanks,
> Dehao
>
> 2012-06-01 Dehao Chen
>
> * gcc/cgraph.c (cgr
On Mon, Jun 4, 2012 at 6:24 AM, Jan Hubicka wrote:
>> On Sat, Jun 2, 2012 at 11:11 AM, Jan Hubicka wrote:
>> >> Actually Dehao also plans to teach the static predictor to understand
>> >> standard library functions more (e.g IO functions) and add more naming
>> >
>> > How this differ from annotat
attribute_pair_p) xmalloc (sizeof (attribute_pair));
> + p->name = token_start;
> + p->attribute = attribute;
> + VEC_safe_push (attribute_pair_p, heap, vec, p);
> + }
> +
> + *pvec = vec;
> +}
> +
> /* Complain that switch DECODED does not apply to
601 - 700 of 1034 matches
Mail list logo
