On Mon, Oct 15, 2012 at 11:12 PM, Jakub Jelinek ja...@redhat.com 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
of scope
...@redhat.com 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 you at CLOBBER protect the var
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
On Tue, Oct 16, 2012 at 7:58 AM, Jakub Jelinek ja...@redhat.com 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))
On Tue, Oct 16, 2012 at 3:03 PM, Jakub Jelinek ja...@redhat.com 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;
+
+ if (TREE_CODE (decl) != VAR_DECL
On Tue, Oct 16, 2012 at 2:52 PM, Jakub Jelinek ja...@redhat.com 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, the redzone var
On Tue, Oct 16, 2012 at 4:02 PM, Jakub Jelinek ja...@redhat.com 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 a big
, 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 davi...@google.com wrote:
On Fri, Oct 12, 2012 at 12:15 AM, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Oct 11, 2012
On Fri, Oct 12, 2012 at 12:15 AM, Jakub Jelinek ja...@redhat.com 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.
On Fri, Oct 12, 2012 at 9:32 AM, Jakub Jelinek ja...@redhat.com 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 if he has time
On Fri, Oct 12, 2012 at 12:26 AM, Jakub Jelinek ja...@redhat.com 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 + required_for_alignment];
} global
On Fri, Oct 12, 2012 at 9:27 AM, Jakub Jelinek ja...@redhat.com 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
On Fri, Oct 12, 2012 at 11:10 AM, Jakub Jelinek ja...@redhat.com 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
that would
On Fri, Oct 12, 2012 at 1:22 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Thu, Oct 11, 2012 at 10:39 PM, Xinliang David Li davi...@google.com
wrote:
On Thu, Oct 11, 2012 at 1:23 PM, Lawrence Crowl cr...@googlers.com wrote:
On 10/10/12, Xinliang David Li davi...@google.com wrote
On Wed, Oct 10, 2012 at 6:52 PM, Easwaran Raman era...@google.com 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.
On Thu, Oct 11, 2012 at 6:16 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Thu, Oct 11, 2012 at 3:52 AM, Easwaran Raman era...@google.com wrote:
Hi,
In the expression reassociation pass, statements might get moved
downwards to ensure that dependences are not violated after
On Thu, Oct 11, 2012 at 9:38 AM, Jakub Jelinek ja...@redhat.com 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
On Thu, Oct 11, 2012 at 11:12 AM, Jakub Jelinek ja...@redhat.com 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)
+
Does it belong here ? -- looks
On Thu, Oct 11, 2012 at 1:23 PM, Lawrence Crowl cr...@googlers.com wrote:
On 10/10/12, Xinliang David Li davi...@google.com wrote:
In a different thread, I proposed the following alternative to 'try_xxx':
templatetypename T T* symbol::cast_to(symbol* p) {
if (p-isT())
return
ok.
thanks,
David
On Thu, Oct 11, 2012 at 1:21 PM, Easwaran Raman era...@google.com 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
Is there an agreed way for file naming?
David
On Wed, Oct 10, 2012 at 1:48 PM, Steven Bosscher stevenb@gmail.com 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
On Wed, Oct 10, 2012 at 2:08 PM, Steven Bosscher stevenb@gmail.com 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 time
In a different thread, I proposed the following alternative to 'try_xxx':
templatetypename T T* symbol::cast_to(symbol* p) {
if (p-isT())
return static_castT*(p);
return 0;
}
cast:
templatetypename T T symbol:as(symbol* p) {
assert(p-isT())
return static_castT(*p);
}
David
On Wed, Sep 19, 2012 at 11:39 AM, Lawrence Crowl cr...@googlers.com wrote:
On 9/19/12, Gabriel Dos Reis g...@integrable-solutions.net wrote:
On Sep 19, 2012 Richard Guenther richard.guent...@gmail.com wrote:
Indeed. Btw, can we not provide a specialization for
dynamic_cast ? This -try_...
On Fri, Oct 5, 2012 at 1:49 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Thu, Oct 4, 2012 at 8:16 PM, Diego Novillo dnovi...@google.com wrote:
On Thu, Oct 4, 2012 at 2:14 PM, Lawrence Crowl cr...@googlers.com wrote:
So, Jan Hubicka requested and approved the current spelling.
xray feature is not in trunk yet.
David
On Fri, Oct 5, 2012 at 3:53 PM, Diego Novillo dnovi...@google.com 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 hars...@google.com
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 hars...@google.com wrote:
commit fc3a55ccec9bc770c79f8a221f5abd397befc8f6
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 tmsri...@google.com wrote:
Ping.
On Fri, Aug 24,
thanks. That will be helpful.
David
On Fri, Oct 5, 2012 at 2:09 PM, Dehao Chen de...@google.com 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 davi...@google.com wrote:
Dehao, the file auto-profile.c has some high
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 era...@google.com wrote:
Hi,
thanks for the update!
David
On Wed, Oct 3, 2012 at 10:37 AM, Steven Bosscher stevenb@gmail.com wrote:
On Wed, Oct 3, 2012 at 6:12 PM, Xinliang David Li davi...@google.com wrote:
What is the status of switch expansion GIMPLE rewrite? If it is not
planned for 4.8, It will be desirable
On Mon, Oct 1, 2012 at 2:37 PM, Michael Meissner
meiss...@linux.vnet.ibm.com 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
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 davi...@google.com wrote:
On Mon, Oct 1, 2012 at 2:37 PM, Michael Meissner
meiss...@linux.vnet.ibm.com wrote:
I tracked down some of the other code
ok (for google-47 and google/main)
thanks,
David
On Fri, Sep 28, 2012 at 10:22 AM, Rong Xu x...@google.com wrote:
Comments are inlined.
Attached is the new patch.
Thanks,
-Rong
On Tue, Sep 25, 2012 at 2:25 PM, Xinliang David Li davi...@google.com wrote:
On Mon, Sep 24, 2012 at 2:42 PM
On Thu, Sep 27, 2012 at 4:35 AM, Sharad Singhai sing...@google.com 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.
*
ok.
David
On Mon, Sep 24, 2012 at 2:40 PM, Rong Xu x...@google.com 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 x...@google.com
*
Ok.
David
On Mon, Sep 24, 2012 at 2:41 PM, Rong Xu x...@google.com 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
On Tue, Sep 18, 2012 at 1:48 AM, Sharad Singhai sing...@google.com 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
Yes. The google/main update will happen next quarter.
David
On Fri, Sep 14, 2012 at 1:17 PM, Teresa Johnson tejohn...@google.com wrote:
On Fri, Sep 14, 2012 at 1:10 PM, Diego Novillo dnovi...@google.com wrote:
On Fri, Sep 14, 2012 at 4:09 PM, Teresa Johnson tejohn...@google.com wrote:
yes.
thanks,
David
On Fri, Sep 14, 2012 at 1:20 PM, Teresa Johnson tejohn...@google.com wrote:
On Fri, Sep 14, 2012 at 1:19 PM, Diego Novillo dnovi...@google.com 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.
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 de...@adacore.com wrote:
On 9/13/2012 8:00 AM, Richard
Yes, indeed.
thanks,
David
On Thu, Sep 13, 2012 at 4:08 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, Sep 12, 2012 at 6:46 PM, Xinliang David Li davi...@google.com wrote:
On Wed, Sep 12, 2012 at 3:30 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, Sep 12
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
On Wed, Sep 12, 2012 at 2:13 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, Sep 12, 2012 at 7:06 AM, Dehao Chen de...@google.com 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
On Thu, Sep 13, 2012 at 1:18 AM, Xinliang David Li davi...@google.com wrote:
On Wed, Sep 12, 2012 at 10:05 AM, Dehao Chen de...@google.com wrote:
There are two parts that needs memory management:
1. The BLOCK structure. This is managed by GC. I originally thought
that removing blocks from
.
Thanks,
Sharad
On Thu, Jun 7, 2012 at 12:19 AM, Xinliang David Li
davi...@google.com wrote:
On Wed, Jun 6, 2012 at 10:58 PM, Sharad Singhai
sing...@google.com wrote:
Sorry about the delay. I have finally incorporated all the
suggestions
and reorganized the dump
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 de...@google.com wrote:
Now I think we
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 cm...@google.com wrote:
Also, what did you mean by there being missing string table management code?
On Fri, Aug 24, 2012 at 2:23 PM, cm...@google.com wrote:
Ok, I
On Fri, Aug 24, 2012 at 3:56 PM, cm...@google.com 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
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 davi...@google.com wrote:
Index: coverage.c
===
On Thu, Aug 23, 2012 at 2:01 PM, Teresa Johnson tejohn...@google.com 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.
Ok for now but some follow up may be needed.
thanks,
David
On Thu, Aug 23, 2012 at 4:21 PM, Teresa Johnson tejohn...@google.com wrote:
On Thu, Aug 23, 2012 at 3:33 PM, Xinliang David Li davi...@google.com wrote:
On Thu, Aug 23, 2012 at 2:01 PM, Teresa Johnson tejohn...@google.com wrote
On Mon, Aug 20, 2012 at 10:29 PM, Jan Hubicka hubi...@ucw.cz wrote:
On Mon, Aug 20, 2012 at 6:27 PM, Jan Hubicka hubi...@ucw.cz wrote:
Xinliang David Li davi...@google.com writes:
Process level synchronization problems can happen when two processes
(running the instrumented binary
On Mon, Aug 20, 2012 at 11:33 PM, Jan Hubicka hubi...@ucw.cz 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
On Tue, Aug 21, 2012 at 12:34 AM, Jan Hubicka hubi...@ucw.cz 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
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
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
:
Xinliang David Li davi...@google.com writes:
Process level synchronization problems can happen when two processes
(running the instrumented binary) exit at the same time. The
updated/merged counters from one process may be overwritten by another
process -- this is true for both counter data
On Sun, Aug 19, 2012 at 9:59 PM, Teresa Johnson tejohn...@google.com wrote:
On Sat, Aug 18, 2012 at 1:19 AM, Jan Hubicka hubi...@ucw.cz 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 ja...@redhat.com 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 thinking to defer a detailed code
Ping ..
On Wed, Jul 4, 2012 at 8:01 AM, Xinliang David Li davi...@google.com wrote:
Comment?
David
On Mon, Jul 2, 2012 at 4:30 PM, Xinliang David Li davi...@google.com wrote:
I extended the patch a little so that the option can be used to set
multiple stack reuse levels: -fstack-reuse=[all
Ok. Do you have specific comments on the patch?
thanks,
David
On Sun, Jul 8, 2012 at 4:20 AM, Jason Merrill ja...@redhat.com 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
affect the signature
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 de...@google.com wrote:
During function inlining, a lexical block is added for each cloned
callee, and source info is attached to this block
On Fri, Jul 6, 2012 at 11:05 PM, Jason Merrill ja...@redhat.com 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
Comment?
David
On Mon, Jul 2, 2012 at 4:30 PM, Xinliang David Li davi...@google.com 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 davi...@google.com 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
the
clobber stmt.
thanks,
David
On Tue, Jun 26, 2012 at 1:28 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Mon, Jun 25, 2012 at 6:25 PM, Xinliang David Li davi...@google.com wrote:
Are there any more concerns about this patch? If not, I'd like to check it
in.
No - the fact
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 davi...@google.com wrote:
On Fri, Jun 22, 2012 at 2:39 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Fri, Jun 22, 2012 at 11:29 AM
thanks for the fix. It works fine for me.
David
On Sat, Jun 23, 2012 at 11:00 AM, Nathan Sidwell nat...@acm.org 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
On Fri, Jun 22, 2012 at 2:39 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Fri, Jun 22, 2012 at 11:29 AM, Jason Merrill ja...@redhat.com 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
On Thu, Jun 21, 2012 at 2:21 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Thu, Jun 21, 2012 at 7:28 AM, Xinliang David Li davi...@google.com wrote:
I modified the documentation and it now looks like this:
@item -ftemp-stack-reuse
@opindex ftemp_stack_reuse
This option enables
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 davi...@google.com
* common.opt: -ftemp-reuse
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
It looks reasonable to move it after DCE which exposes more opportunities.
David
On Thu, Jun 14, 2012 at 6:38 PM, Easwaran Raman era...@google.com wrote:
The conditional dead call elimination pass shrink wraps certain dead
calls to math functions. It doesn't handle case like this:
. Does it look okay?
Thanks,
Sharad
On Mon, May 14, 2012 at 12:26 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Sat, May 12, 2012 at 6:39 PM, Xinliang David Li davi...@google.com
wrote:
On Sat, May 12, 2012 at 9:26 AM, Gabriel Dos Reis
g...@integrable-solutions.net wrote
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 tejohn...@google.com wrote:
On Tue, Jun 5, 2012 at 11:46 AM, davi...@google.com wrote:
On Wed, Jun 6, 2012 at 2:02 PM, Teresa Johnson tejohn...@google.com wrote:
On Tue, Jun 5, 2012 at 11:46 AM, davi...@google.com 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
On Wed, Jun 6, 2012 at 2:02 PM, Teresa Johnson tejohn...@google.com wrote:
On Tue, Jun 5, 2012 at 11:46 AM, davi...@google.com 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
Please document it in doc/invoke.texi with examples.
thanks,
David
On Tue, Jun 5, 2012 at 7:28 PM, Dehao Chen de...@google.com wrote:
Patch updated: using regex to match the function name:
http://codereview.appspot.com/6281047
Thanks,
Dehao
2012-06-01 Dehao Chen de...@google.com
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 davi...@google.com wrote:
Please document it in doc/invoke.texi with examples.
thanks,
David
On Tue, Jun 5, 2012 at 7:28 PM, Dehao Chen de...@google.com wrote
On Mon, Jun 4, 2012 at 12:49 AM, Nathan Sidwell nat...@acm.org wrote:
On 06/03/12 21:40, Xinliang David Li wrote:
Can you explain this more -- what exactly are trying to do? Are you
trying
to rebuild multiple times with the same coverage data,
yes -- for instance, in the context
such always_inline.
2. change to use deferred option.
Thanks,
Dehao
On Sun, Jun 3, 2012 at 12:40 PM, Xinliang David Li davi...@google.com
wrote:
On Sat, Jun 2, 2012 at 11:11 AM, Jan Hubicka hubi...@ucw.cz wrote:
Actually Dehao also plans to teach the static predictor to understand
standard
On Mon, Jun 4, 2012 at 6:24 AM, Jan Hubicka hubi...@ucw.cz wrote:
On Sat, Jun 2, 2012 at 11:11 AM, Jan Hubicka hubi...@ucw.cz 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
to use deferred option.
Thanks,
Dehao
On Sun, Jun 3, 2012 at 12:40 PM, Xinliang David Li davi...@google.com wrote:
On Sat, Jun 2, 2012 at 11:11 AM, Jan Hubicka hubi...@ucw.cz wrote:
Actually Dehao also plans to teach the static predictor to understand
standard library functions more (e.g IO
On Sun, Jun 3, 2012 at 6:10 AM, Nathan Sidwell nat...@acm.org wrote:
On 06/03/12 05:51, Xinliang David Li wrote:
On Fri, Dec 30, 2011 at 10:25 AM, Nathan Sidwellnat...@acm.org wrote:
I've committed this patch to fix and improve coverage reporting:
1) the time stamp local_tick will be -1
On Sun, Jun 3, 2012 at 10:24 AM, Nathan Sidwell nat...@acm.org wrote:
On 06/03/12 17:16, Xinliang David Li wrote:
Basically it makes it very difficult to rebuild the file with the
profile data --- which makes problem triaging impossible. What is
Can you explain this more -- what exactly
On Sat, Jun 2, 2012 at 2:36 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
This patch adds 4 flags to enable user to type in a list of name
patterns. Compiler will match the function name with the given
patterns, and add hot, cold, likely_hot, likely_cold
attributes to function declaration. The
On Sat, Jun 2, 2012 at 3:06 AM, Jan Hubicka hubi...@ucw.cz wrote:
On Sat, Jun 2, 2012 at 2:36 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
This patch adds 4 flags to enable user to type in a list of name
patterns. Compiler will match the function name with the given
patterns, and add hot,
Based on Honza's feedback, I think it is bettre to add command line
interface such as this:
-ffunction-attribute-list=attribute_name:function_pattern_list
or
-ffunction-attribute-filelist=attribute_name:function_pattern_list_filename
e.g,
-ffunction-attribute-list=code:foo1,foo2,bar_*,blah
It
On Sat, Jun 2, 2012 at 11:11 AM, Jan Hubicka hubi...@ucw.cz 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 annotating the library?
I find them more suitable to be compiler
On Fri, Dec 30, 2011 at 10:25 AM, Nathan Sidwell nat...@acm.org wrote:
I've committed this patch to fix and improve coverage reporting:
1) the time stamp local_tick will be -1 if the user overrides the random
seed. In such cases the gcov data file should be deleted, just as it would
if the
ok.
thanks,
David
On Fri, Jun 1, 2012 at 2:26 PM, Teresa Johnson tejohn...@google.com wrote:
Renamed to __gcov_dummy_ref1 and __gcov_dummy_ref2. I'd prefer that
approach for now to keep the differences with trunk to a minimum.
Thanks,
Teresa
On Fri, Jun 1, 2012 at 2:18 PM,
Ok.
David
On Thu, May 24, 2012 at 11:38 AM, Rong Xu x...@google.com wrote:
Hi,
This is for google branches only.
It changes the format of the temp function name so that they
can be demangled.
Tested with regression tests.
Google ref b/5733865.
Thanks,
2012-05-24 Rong Xu
ok for google-4_7 branch. This should also be pushed to trunk.
Thanks,
David
On Wed, May 16, 2012 at 6:56 PM, Sriraman Tallam tmsri...@google.com wrote:
Patch too large to be attached, rejected by gcc-patches. Please see:
http://codereview.appspot.com/download/issue6195099_1.diff
Thanks,
Looks good.
thanks,
David
On Mon, May 14, 2012 at 7:18 PM, Teresa Johnson tejohn...@google.com wrote:
Two cleanup items for the sampling instrumentation interfaces. First,
rename variables from *rate* to *period*, since what is being specified
is a sampling period (time between recorded
Sounds good.
On Sat, May 12, 2012 at 3:31 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Fri, May 11, 2012 at 8:11 PM, Xinliang David Li davi...@google.com wrote:
To be more specific, does the following match what your envisioned?
1) when multiple streams are specified for dumping
On Sat, May 12, 2012 at 9:26 AM, Gabriel Dos Reis
g...@integrable-solutions.net wrote:
On Sat, May 12, 2012 at 11:05 AM, Xinliang David Li davi...@google.com
wrote:
The downside is that the dump file format will look different from the
stderr output which is less than ideal.
BTW, why do
On Fri, May 11, 2012 at 1:49 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Thu, May 10, 2012 at 6:28 PM, Xinliang David Li davi...@google.com wrote:
I like your suggestion and support the end goal you have. I don't
like the -fopt-info behavior to interfere with regular -fdump-xxx
-fopt-info=N, and take -ftree-vectorizer-verbose as the
first guinea pig to use the new dumping interfaces.
After the infrastructure is ready, gradually deprecate the use of the
original dumper interfaces.
what do you think?
thanks,
David
On Fri, May 11, 2012 at 9:06 AM, Xinliang David Li davi
, Xinliang David Li davi...@google.com wrote:
Bummer. I was thinking to reserve '=' for selective dumping:
-fdump-tree-pre=func_list_regexp
I guess this can be achieved via @
-fdump-tree-pre@func_list
-fdump-tree-pre=file_name@func_list
Another issue -- I don't think the current precedence
601 - 700 of 970 matches
Mail list logo
