It depends on the value distribution .
David
On Thu, Dec 20, 2012 at 11:30 AM, Rong Xu x...@google.com wrote:
On Wed, Dec 19, 2012 at 5:22 PM, Rong Xu x...@google.com wrote:
On Wed, Dec 19, 2012 at 5:04 PM, davi...@google.com wrote:
The change in gcov-io.h is from a different patch.
This looks good to me for google branches. Useful for trunk too.
David
On Wed, Dec 19, 2012 at 12:08 PM, Rong Xu x...@google.com wrote:
Hi,
This patch adds the supprot of atomic update the profile counters.
Tested with google internal benchmarks and fdo kernel build.
Thanks,
-Rong
A couple of comments:
1) please dump with source location if possible. What is the use of
the information if there is no line number
2) Please do not use the existing dump report -- Loop 1,2,3 etc means
nothing to user
3) The optimization report should be standardized with some template
(similar
On Wed, Dec 12, 2012 at 8:37 AM, Jan Hubicka hubi...@ucw.cz wrote:
I noticed in prologue/epilogue, GCC prefers to use MOVs followed by a
SP adjustment instead of a sequence of pushes/pops. The preference to
the MOVs are good for old CPU micro-architectures (before pentium-4,
K10), because it
Honza, can you explain each change and point to the reference?
thanks,
David
On Wed, Dec 12, 2012 at 8:37 AM, Jan Hubicka hubi...@ucw.cz wrote:
I noticed in prologue/epilogue, GCC prefers to use MOVs followed by a
SP adjustment instead of a sequence of pushes/pops. The preference to
the MOVs
On Wed, Dec 12, 2012 at 10:30 AM, Jan Hubicka hubi...@ucw.cz wrote:
Concerning 1push per cycle, I think it is same as K7 hardware did, so move
prologue should be a win.
Index: config/i386/i386.c
===
--- config/i386/i386.c
On Wed, Dec 12, 2012 at 4:16 PM, Xinliang David Li davi...@google.com wrote:
On Wed, Dec 12, 2012 at 10:30 AM, Jan Hubicka hubi...@ucw.cz wrote:
Concerning 1push per cycle, I think it is same as K7 hardware did, so move
prologue should be a win.
Index: config/i386/i386.c
On Wed, Dec 12, 2012 at 5:19 PM, Jan Hubicka hubi...@ucw.cz wrote:
libcall is not faster up to 8KB to rep sequence that is better for
regalloc/code
cache than fully blowin function call.
Be careful with this. My recollection is that REP sequence is good for
any size -- for smaller size,
:
On Wed, Dec 12, 2012 at 10:09:14PM -0800, Xinliang David Li wrote:
On Wed, Dec 12, 2012 at 5:19 PM, Jan Hubicka hubi...@ucw.cz wrote:
libcall is not faster up to 8KB to rep sequence that is better for
regalloc/code
cache than fully blowin function call.
Be careful with this. My
52340 618545
delta -1.5% 15.5% -0.006%
parser-move 81244 15788 334003
parser-push 80684 16332 333987
delta -0.7% 3.4% -0.005%
On Tue, Dec 11, 2012 at 9:14 AM, Xinliang David Li davi...@google.com wrote:
On Tue, Dec 11, 2012 at 1:49 AM, Richard Biener
richard.guent...@gmail.com
Some SPEC2k performance number (with 3 runs on core2):
Push wins over move on 3 benchmarks. Others are noises.
perlbmk : ~+1.9%
gap: ~+1.4%
vortex:~ +0.7%
David
On Tue, Dec 11, 2012 at 2:53 PM, Xinliang David Li davi...@google.com wrote:
The following the O2 size data from SPEC2k
a mechanism called
stack engine. The data dependency is removed by the hardware, and
push/pop becomes very cheap (1 uOp, 1 cycle latency), and they are
smaller. There is no longer the need to avoid using them. This is
also what ICC does.
2012-12-08 Xinliang David Li davi...@google.com
ok.
David
On Mon, Dec 10, 2012 at 9:23 PM, Dehao Chen de...@google.com wrote:
Hi,
The location_block patch has failed lto-bootstrap. This is fixed by a
bunch of fixes in trunk. But we would rather not spend too much effort
to back-port those fixes. So for now, we would disable streaming out
| m_ATHLON_K8,
/* X86_TUNE_SHIFT1 */
~m_486,
2012-12-08 Xinliang David Li davi...@google.com
* config/i386/i386.c: Eanble push/pop in pro/epilogue for
moderen CPUs.
Can the report builtins be marked with certain attribute such as
'no-return' etc?
David
On Wed, Dec 5, 2012 at 3:48 AM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
On Wed, Dec 5, 2012 at 3:39 PM, Jakub Jelinek ja...@redhat.com wrote:
Hi!
Another problem from the compiler
, Xinliang David Li wrote:
Can the report builtins be marked with certain attribute such as
'no-return' etc?
They are marked as noreturn obviously (and leaf, nothrow etc.).
But noreturn isn't attribute that prevents cross-jumping. It is fine
to cross-jump noreturn calls.
On IRC Richard agreed
It (a trunk backport) is not needed for google/main.
David
On Wed, Dec 5, 2012 at 1:46 PM, x...@google.com wrote:
Look good to me. Please check with David if google-main branch is
currently opened for check-in.
-Rong
https://codereview.appspot.com/6878045/
Nice. We used to just do post-processing of the dumps with -blocks option.
I assume the graph dump does not support multiple function dump (I
noticed that the previous function's dump gets overwritten). This
reminds me that I need to resurrect my per-function dump support, and
dump-before/after
On Tue, Dec 4, 2012 at 12:47 PM, Steven Bosscher stevenb@gmail.com wrote:
On Tue, Dec 4, 2012 at 9:14 PM, Xinliang David Li wrote:
I assume the graph dump does not support multiple function dump (I
noticed that the previous function's dump gets overwritten). This
reminds me that I need
Looks good for gcc-4_7* branches. There is no need to port any trunk
changes to google/main (it will be synced to trunk at some point).
David
On Mon, Dec 3, 2012 at 4:50 PM, asha...@chromium.org wrote:
Reviewers: davidxl, xur,
Message:
When I backported this patch to google/gcc-4.6, I
, but...
On 21/06/12 00:50, Xinliang David Li wrote:
One of the most common runtime errors we have seen in gcc-4_7 is
caused by dangling references to temporaries whole life time have
ended
e.g,
const A a = foo();
or
foo (A());// where temp's address is saved and used after foo.
Of course
*/
- ~(m_PENT | m_CORE2I7 | m_ATOM | m_K6 | m_GENERIC),
+ ~(m_PENT | m_ATOM | m_K6),
/* X86_TUNE_USE_XCHGB: Use xchgb %rh,%rl instead of rolw/rorw $8,rx. */
m_PENT4,
2010-11-30 Xinliang David Li davi...@google.com
* config/i386/i386.c: Allow sign extend instructions (cltd etc
On Mon, Nov 26, 2012 at 12:35 AM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Nov 26, 2012 at 12:17:44PM +0400, Dmitry Vyukov wrote:
On Sat, Nov 24, 2012 at 12:58 PM, Dmitry Vyukov dvyu...@google.com wrote:
Ok. A slight problem then is that where the tsan pass sits right now,
there
is
On Fri, Nov 23, 2012 at 8:39 AM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Nov 23, 2012 at 08:10:39PM +0400, Dmitry Vyukov wrote:
This patch attempts to instrument __atomic_* and __sync_* builtins.
Unfortunately for none of the builtins there is 1:1 mapping to the tsan
replacements,
be done with the aid of the merge.sh script;
it will also update the file MERGE to contain the upstream revision
we merged with.
On Wed, Nov 21, 2012 at 11:03 PM, Xinliang David Li davi...@google.com
wrote:
How about also documenting this in README.gcc?
David
On Wed, Nov 21, 2012 at 10:56 AM
Suggestions:
1) make sure current local dir is libsanitizer -- exit if it is not
2) clean up the upstream directory after the merge is done.
David
On Wed, Nov 21, 2012 at 10:25 AM, Kostya Serebryany k...@google.com wrote:
Hi,
A dummy script to help merging asan from upstream.
Not 100%
On Wed, Nov 21, 2012 at 10:49 PM, Xinliang David Li davi...@google.com
wrote:
Suggestions:
1) make sure current local dir is libsanitizer -- exit if it is not
2) clean up the upstream directory after the merge is done.
David
On Wed, Nov 21, 2012 at 10:25 AM, Kostya Serebryany k...@google.com
if (is_old_name (use))
rdef = get_reaching_def (use);
- if (rdef rdef != use)
+ if (rdef)
SET_USE (use_p, rdef);
}
2012-11-21 Xinliang David Li davi...@google.com
* tree-into-ssa.c (make_replace_use): force use replacement
in SSA update.
David
On Wed, Nov 21, 2012 at 11:35 PM, Dmitry Vyukov dvyu...@google.com wrote:
What percent of the memory accesses the following can skip?
I just don't know what exactly they mean. ADDR_EXPR/COMPONENT_REF look like
it can skip a lot.
It does not skip a lot.
+ /* TODO: handle other cases
+
Questions: are -fsanitize=thread -fsanitize=address mutually exclusive
here? If yes, that will be wrong.
How about -fsanitize=all option?
As kcc mentioned, the -fno-.. form is not handled.
David
On Mon, Nov 19, 2012 at 10:14 AM, Wei Mi w...@google.com wrote:
Hi,
This patch is to change
On Mon, Nov 19, 2012 at 10:57 AM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Nov 19, 2012 at 10:26:26PM +0400, Konstantin Serebryany wrote:
FYI
Clang also supports the no- form (-fno-sanitize=address).
We probably want it here too, but preferably as a separate patch.
(or is it
...@gmail.com wrote:
On Mon, Nov 19, 2012 at 10:31 PM, Xinliang David Li davi...@google.com
wrote:
Questions: are -fsanitize=thread -fsanitize=address mutually exclusive
here? If yes, that will be wrong.
How about -fsanitize=all option?
asan and tsan can not coexist in the same process
I am sensing some optimization here :) Is it really important to
collect the full stack trace for the allocation context? You care
about actual site where the allocation happens -- which might usually
be the calls to the malloc like wrappers. The distance from there to
the leaf should not he too
I probably made too general statement in this topic. However for the
PRE case, I believe the choice of not using UNKNOWN location is still
better.
thanks,
David
On Thu, Nov 15, 2012 at 9:23 AM, Eric Botcazou ebotca...@adacore.com wrote:
The randomness here means that if we set UNKNOWN_LOCATION
On Tue, Nov 13, 2012 at 8:40 AM, Jakub Jelinek ja...@redhat.com wrote:
On Mon, Nov 05, 2012 at 04:37:41PM -0800, Wei Mi wrote:
Thanks for the comments. I fix most of them except the setting of
TODO_ The new patch.txt is attached.
Please update the patch against trunk, it doesn't apply
On Tue, Nov 13, 2012 at 9:36 AM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Nov 13, 2012 at 09:25:36AM -0800, Xinliang David Li wrote:
That is complete misunderstanding of what update_address_taken does.
It removes TREE_ADDRESSABLE from addressables that are no longer
addressable, rather
On Tue, Nov 13, 2012 at 3:20 AM, Dodji Seketeli do...@redhat.com wrote:
Diego Novillo dnovi...@google.com a écrit:
Patches to libsanitizer should be sent upstream. We should only
contain a copy of the master in the LLVM repository. There should be
instructions in libsanitizer/README.gcc
On Tue, Nov 13, 2012 at 3:42 AM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Nov 13, 2012 at 03:31:21AM -0800, H.J. Lu wrote:
On Tue, Nov 13, 2012 at 3:20 AM, Dodji Seketeli do...@redhat.com wrote:
Diego Novillo dnovi...@google.com a écrit:
Patches to libsanitizer should be sent
On Mon, Nov 12, 2012 at 12:45 AM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Nov 09, 2012 at 12:03:09PM -0800, Kostya Serebryany wrote:
Why depending on gtest is bad?
Because gcc already has way too many dependencies (starting from gmp, mpfr,
libmpc, graphite dependencies, java
It seems that my one line fix in asan branch (r192605) is not included
in Dodji's patch set.
David
On Fri, Nov 9, 2012 at 5:58 AM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Nov 09, 2012 at 02:14:04PM +0100, Tobias Burnus wrote:
Dodji Seketeli wrote:
This patch imports the initial state
it
to google_4-7 and adds to the already existing functionality of
-mpatch-function-for-instrumentation.
Thanks,
Harshit
On Mon, Nov 5, 2012 at 12:29 PM, Xinliang David Li davi...@google.com wrote:
It does not hurt to submit the patch for review -- you need to provide
more background
See some random comments below. Some test cases should also be added.
It should be easy to fake the attack by using placement new with
incompatible type ..
David
/* Start the process of running a particular set of global constructors
or destructors. Subroutine of do_[cd]tors. */
As asan/tsan functionality is getting into trunk, we need to set up
testings as soon as possible to avoid bitrot.
Kostya can probably shed some lights on the test case requirements,
and we can continue discussions on how to extend dejagnu to import
those tests.
thanks,
David
On Fri, Oct 12,
For the example I listed, the new statement is generated for source
construct at program point (2). However unlike simple code motion, (2)
is not going away after PRE. How would setting the location of the new
statement at the insertion point break coverage? Besides, the new
statement won't create
On Mon, Nov 5, 2012 at 12:20 PM, Harshit Chopra hars...@google.com wrote:
Thanks David for the review. My comments are inline.
On Sat, Nov 3, 2012 at 12:38 PM, Xinliang David Li davi...@google.com wrote:
Harshit, Nov 5 is the gcc48 cutoff date. If you want to have the x-ray
instrumentation
Can you split the patch into two parts? One for runtime and and one
for GCC ? Please also use -up option in the diff command to generate
the patch file.
thanks,
David
On Thu, Nov 1, 2012 at 1:07 PM, Caroline Tice cmt...@google.com wrote:
We have been developing a new security hardening feature
Harshit, Nov 5 is the gcc48 cutoff date. If you want to have the x-ray
instrumentation feature into this release, you will need to port your
patch and submit for trunk review now.
On Tue, Oct 30, 2012 at 5:15 PM, Harshit Chopra hars...@google.com wrote:
Adding function attributes:
Thanks, good to know that.
David
On Fri, Nov 2, 2012 at 6:31 AM, Martin Jambor mjam...@suse.cz wrote:
Hi,
On Thu, Nov 01, 2012 at 11:11:13AM -0700, Xinliang David Li wrote:
...
The TREE_ADDRESSABLE check seems redundant -- if the var_decl (instead
of ssa name) appears in the assignment
, Xinliang David Li wrote:
Thanks, good to know that.
But note that such vars, even when accessed only partially, don't
need to be tracked by tsan just because of that.
TREE_ADDRESSABLE (decl) || is_global_var (decl) is really a conservative
check for what needs to be tracked, and perhaps less
--fno-default-inline @gol
+-fmove-loop-invariants -fmudflap -fmudflapir -fmudflapth
-fno-branch-count-reg @gol
+-ftsan -ftsan-ignore -fno-default-inline @gol
Change -ftsan to -fthread-sanitizer
-fno-defer-pop -fno-function-cse -fno-guess-branch-probability @gol
-fno-inline
On Wed, Oct 31, 2012 at 4:10 PM, Jakub Jelinek ja...@redhat.com wrote:
Hi!
Just a couple of random comments:
On Wed, Oct 31, 2012 at 11:34:10AM -0700, Wei Mi wrote:
gcc/ChangeLog:
2012-10-31 Wei Mi w...@gmail.com
If Dmitry wrote parts of the patch, it would be nice to mention
him in
On Thu, Nov 1, 2012 at 10:06 AM, Dmitry Vyukov dvyu...@google.com wrote:
On Thu, Nov 1, 2012 at 7:47 PM, Xinliang David Li davi...@google.com
wrote:
On Wed, Oct 31, 2012 at 11:27 PM, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Oct 31, 2012 at 11:00:17PM -0700, Xinliang David Li wrote
On Thu, Nov 1, 2012 at 11:16 AM, Dmitry Vyukov dvyu...@google.com wrote:
On Thu, Nov 1, 2012 at 10:14 PM, Dmitry Vyukov dvyu...@google.com wrote:
On Wed, Oct 31, 2012 at 11:00:17PM -0700, Xinliang David Li wrote:
+ /* Below are things we do not instrument
+ (no possibility
, then it is not
the same as address taken.
David
On Thu, Nov 1, 2012 at 11:24 AM, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Nov 01, 2012 at 11:11:13AM -0700, Xinliang David Li wrote:
But it skips those globals without static storage and marked as not
addressable.
It seems to me you want to skip all stack
at 11:49 AM, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Nov 01, 2012 at 11:32:01AM -0700, Xinliang David Li wrote:
For the following case:
int foo()
{
int a[100];
// use 'a' as a[i]
...
}
Assuming there is no assignment of the form p = a[i] in the source,
variable 'a' still
On Thu, Nov 1, 2012 at 12:16 PM, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Nov 01, 2012 at 11:57:21AM -0700, Xinliang David Li wrote:
That is exactly related to tsan -- it should skip local variable that
is not address taken (though still addressable, which by addressable,
it means
Will it be easier if you just rolled back your previous libasan
library changes, and resubmit it with the restructured directory?
David
On Thu, Nov 1, 2012 at 1:17 PM, Wei Mi w...@google.com wrote:
patch.part2.txt.bz2 and patch.part3.txt.bz2 are still too big.
Divide patch.part2.txt.bz2 into
that sounds good to me.
David
On Thu, Nov 1, 2012 at 1:31 PM, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Nov 01, 2012 at 01:19:42PM -0700, Xinliang David Li wrote:
Will it be easier if you just rolled back your previous libasan
library changes, and resubmit it with the restructured
On Thu, Nov 1, 2012 at 1:47 PM, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Nov 01, 2012 at 12:34:54PM -0700, Xinliang David Li wrote:
On Thu, Nov 1, 2012 at 12:16 PM, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Nov 01, 2012 at 11:57:21AM -0700, Xinliang David Li wrote:
That is exactly
Right -- I found the same thing, it is the ivopt that resets it -- the
IV opt pass should have a TODO_update_address_taken.
thanks,
David
On Thu, Nov 1, 2012 at 2:07 PM, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Nov 01, 2012 at 01:57:40PM -0700, Xinliang David Li wrote:
I looked
, Xinliang David Li davi...@google.com wrote:
that sounds good to me.
David
On Thu, Nov 1, 2012 at 1:31 PM, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Nov 01, 2012 at 01:19:42PM -0700, Xinliang David Li wrote:
Will it be easier if you just rolled back your previous libasan
library changes
It is not always true though -- only when the array address is picked
by the pass to be the induction variable.
David
On Thu, Nov 1, 2012 at 2:24 PM, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Nov 01, 2012 at 02:19:43PM -0700, Xinliang David Li wrote:
Right -- I found the same thing
I think it is better to apply this patch to asan first to avoid extra
thread. You probably just need to retrieve your runtime part of the
trunk patch and resend it. Make sense?
thanks,
David
On Thu, Nov 1, 2012 at 2:47 PM, Dodji Seketeli do...@redhat.com wrote:
Instead of planning this
Yes, there is no need to repeat the error made in asan branch in trunk.
David
On Thu, Nov 1, 2012 at 2:55 PM, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Nov 01, 2012 at 02:52:52PM -0700, Xinliang David Li wrote:
I think it is better to apply this patch to asan first to avoid extra
thread
On Thu, Nov 1, 2012 at 2:23 PM, Xinliang David Li davi...@google.com wrote:
On Thu, Nov 1, 2012 at 2:17 PM, Wei Mi w...@google.com wrote:
Thanks for the suggestion!
The planned svn commands will be:
svn mv libasan libsanitizer
svn add libsanitizer/asan
svn add libsanitizer/tsan
Probably
On Thu, Nov 1, 2012 at 3:57 PM, Ian Lance Taylor i...@google.com wrote:
On Thu, Nov 1, 2012 at 10:00 AM, Dehao Chen de...@google.com wrote:
I see your point. How about we guard these changes with a flag, say
-gless-jumpy, so that people can always choose between better coverage
and less jumpy
On Thu, Nov 1, 2012 at 4:16 PM, Dehao Chen de...@google.com wrote:
On Thu, Nov 1, 2012 at 4:07 PM, Xinliang David Li davi...@google.com wrote:
On Thu, Nov 1, 2012 at 3:57 PM, Ian Lance Taylor i...@google.com wrote:
On Thu, Nov 1, 2012 at 10:00 AM, Dehao Chen de...@google.com wrote:
I see your
Changing the option is part of the plan.
Dodji, can you make the option change part of one the patches (e.g,
the first one that introduces it) -- there seems no need for a
separate patch for it.
thanks,
David
On Thu, Nov 1, 2012 at 9:12 PM, Konstantin Serebryany
...@gmail.com wrote:
On Wed, Oct 31, 2012 at 12:57 AM, Xinliang David Li davi...@google.com
wrote:
It will make the location info for the newly synthesized stmt more
deterministic, I think.
Maybe, but it will increase the jumpiness in the debugger without actually
being accurate, no? For example
On Tue, Oct 30, 2012 at 1:21 AM, Sharad Singhai sing...@google.com wrote:
As per discussion in http://gcc.gnu.org/ml/gcc/2012-10/msg00225.html,
I have added the -fopt-info pass filtering in the attached patch.
The basic idea is that there are optimization pass groups and a user
can
On Tue, Oct 30, 2012 at 8:28 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Tue, Oct 30, 2012 at 9:21 AM, Sharad Singhai sing...@google.com wrote:
As per discussion in http://gcc.gnu.org/ml/gcc/2012-10/msg00225.html,
I have added the -fopt-info pass filtering in the attached patch.
On Tue, Oct 30, 2012 at 12:25 PM, Steven Bosscher stevenb@gmail.com wrote:
On Tue, Oct 30, 2012 at 5:59 PM, Teresa Johnson wrote:
I will try testing your patch on top of mine with our fdo benchmarks.
Thanks. But you should expect a lot of errors, hopefully you can make
something out of it
Good cleanup! Simple and consistent interfaces are usually
self-documenting, and this one is a good step forward.
thanks,
David
On Tue, Oct 30, 2012 at 2:09 PM, Lawrence Crowl cr...@googlers.com wrote:
On 10/30/12, Diego Novillo dnovi...@google.com wrote:
On Tue, Oct 30, 2012 at 4:53 PM,
There are not many -- see gcc/testsuite/gcc.dg/tree-prof directory.
Under that, 5 cases explicitly set the option.
David
On Tue, Oct 30, 2012 at 2:31 PM, Teresa Johnson tejohn...@google.com wrote:
On Tue, Oct 30, 2012 at 12:33 PM, Xinliang David Li davi...@google.com
wrote:
On Tue, Oct 30
It will make the location info for the newly synthesized stmt more
deterministic, I think.
David
On Tue, Oct 30, 2012 at 4:38 PM, Steven Bosscher stevenb@gmail.com wrote:
On Wed, Oct 31, 2012 at 12:00 AM, Dehao Chen wrote:
This patch aims to improve debugging of optimized code. It ensures
Yes.
David
On Fri, Oct 26, 2012 at 5:35 AM, Diego Novillo dnovi...@google.com wrote:
On Fri, Oct 26, 2012 at 4:40 AM, Kostya Serebryany k...@google.com wrote:
One thing I overlooked before.
In the gcc patch we are using -fasan flag name, while clang uses
-f[no-]address-sanitizer
(it used to
yes -- there is no need to change any developer only internal names.
David
On Fri, Oct 26, 2012 at 8:49 AM, Jakub Jelinek ja...@redhat.com wrote:
On Fri, Oct 26, 2012 at 08:48:10AM -0700, Xinliang David Li wrote:
Yes.
On Fri, Oct 26, 2012 at 5:35 AM, Diego Novillo dnovi...@google.com wrote
On Fri, Oct 26, 2012 at 8:54 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
sorry for jumping in late, for too long I did not had chnce to look at my
TODO.
I have two comments...
Index: gcc/cgraphbuild.c
===
--- gcc/cgraphbuild.c
be that specific.
Thanks,
Wei.
On Fri, Oct 19, 2012 at 12:52 PM, Xinliang David Li davi...@google.com
wrote:
The library builds fine with the following diff. The file acinclude.m4
is cloned from libmudflap.
David
index 485d169..3e847f1 100644
--- a/libasan/aclocal.m4
+++ b/libasan/aclocal.m4
On Thu, Oct 25, 2012 at 9:39 AM, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Oct 25, 2012 at 09:24:51AM -0700, Xinliang David Li wrote:
To accommodate tsan (and msan in the future), the directory structure
needs to be changed. The top level directory can be called something
like librt
On Thu, Oct 25, 2012 at 9:52 AM, Diego Novillo dnovi...@google.com wrote:
On Thu, Oct 25, 2012 at 12:48 PM, Xinliang David Li davi...@google.com
wrote:
On Thu, Oct 25, 2012 at 9:39 AM, Jakub Jelinek ja...@redhat.com wrote:
librt is a very bad name, that clashes with glibc librt, would only
On Thu, Oct 25, 2012 at 9:55 AM, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Oct 25, 2012 at 09:48:54AM -0700, Xinliang David Li wrote:
Why should be libasan linked statically by default?
There are a couple of reasons:
1) it makes running sanitized binary on remote machines which does
On Thu, Oct 25, 2012 at 10:19 AM, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Oct 25, 2012 at 10:00:03AM -0700, Xinliang David Li wrote:
How about statically linking just for executables, not shared library buid?
That is IMHO still a bad idea.
I don't know why you think so (It seems
Should the alignment check be moved into 'asan_protect_global' method?
David
On Thu, Oct 25, 2012 at 2:32 PM, Wei Mi w...@google.com wrote:
Hi,
A small patch to remove the bogus error reports exposed in the
spec2000 testing. In varasm.c, asan_protected should be equivalent
with
Why not relaxing the check even more to allow for instance 128 byte
alignment which may be common?
David
On Thu, Oct 25, 2012 at 2:51 PM, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Oct 25, 2012 at 05:46:47PM -0400, Diego Novillo wrote:
The change looks fine to me, but why not just move the
On Tue, Oct 23, 2012 at 6:11 AM, Dodji Seketeli do...@redhat.com 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
On Tue, Oct 23, 2012 at 8:58 AM, Jakub Jelinek ja...@redhat.com wrote:
On Tue, Oct 23, 2012 at 08:47:48AM -0700, Xinliang David Li wrote:
+ /* The builtin below cannot be safely instrumented as their
+ length parameter is just a mere limit.
+
Why can't the following
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
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 davi...@google.com
wrote:
I tried it, and this version works
On Thu, Oct 18, 2012 at 3:36 PM, Easwaran Raman era...@google.com 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
On Thu, Oct 18, 2012 at 5:58 AM, Jakub Jelinek ja...@redhat.com 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,
On Tue, Oct 16, 2012 at 12:27 AM, Jakub Jelinek ja...@redhat.com 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
On Thu, Oct 18, 2012 at 11:22 AM, Jakub Jelinek ja...@redhat.com 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 @@ target_modules = { module= libstdc++-v3
+ 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 davi...@google.com wrote:
On Thu, Oct 18, 2012 at 11:22 AM, Jakub Jelinek ja...@redhat.com wrote:
On Thu, Oct 18, 2012
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
discussed this yesterday).
--kcc
On Thu, Oct 18, 2012 at 11:29 PM, Xinliang David Li davi...@google.com
wrote:
+ 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 davi
On Tue, Oct 16, 2012 at 11:51 PM, Jakub Jelinek ja...@redhat.com 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.
Besides if ABI
Looks ok to me for the branch.
thanks,
David
On Wed, Oct 17, 2012 at 2:35 AM, Jakub Jelinek ja...@redhat.com 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 correctly, the redzone
Yes, I think it is good for the branch.
thanks,
David
On Wed, Oct 17, 2012 at 4:11 AM, Jakub Jelinek ja...@redhat.com 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 ja...@redhat.com wrote:
Why the above two condition
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
501 - 600 of 970 matches
Mail list logo
