OK for google/main with the nits below.
http://codereview.appspot.com/5272048/diff/42003/ChangeLog.google-main
File ChangeLog.google-main (right):
http://codereview.appspot.com/5272048/diff/42003/ChangeLog.google-main#newcode1
ChangeLog.google-main:1: 2011-11-02 Kostya Serebryany
1 2011-
The invoke.texi change looks fine. The ChangeLog entry needs some work.
http://codereview.appspot.com/5272048/diff/41001/ChangeLog.google-main
File ChangeLog.google-main (right):
http://codereview.appspot.com/5272048/diff/41001/ChangeLog.google-main#newcode6
ChangeLog.google-main:6:
1 2011-11
Ok for google/main when the option is documented in doc/invoke.texi
and a Changlog file is provided.
David
On Tue, Nov 1, 2011 at 5:24 PM, wrote:
> So, do you have any other suggestions before the first commit?
>
> http://codereview.appspot.com/5272048/
>
On Tue, Nov 1, 2011 at 12:41 PM, Diego Novillo wrote:
> On 11-11-01 15:34 , Xinliang David Li wrote:
>
>>> Right before pass_expand? In init_optimization_passes(), look for
>>> NEXT_PASS
>>> (pass_expand). That's RTL generation. Somewhere before that.
>>>
>>
>> Why?
>
> The idea was to experime
On 11-11-01 15:34 , Xinliang David Li wrote:
Right before pass_expand? In init_optimization_passes(), look for NEXT_PASS
(pass_expand). That's RTL generation. Somewhere before that.
Why?
The idea was to experiment where to best place ASAN to avoid
instrumenting too much. If we schedule
On Tue, Nov 1, 2011 at 12:16 PM, Diego Novillo wrote:
> On 11-11-01 15:11 , konstantin.s.serebry...@gmail.com wrote:
>>
>> Diego mentioned that we can move the asan pass somewhere to the very
>> end, just before lowering to RTL.
>> Where would be this blessed place?
>> Does it still have TARGET_ME
On 11-11-01 15:11 , konstantin.s.serebry...@gmail.com wrote:
Diego mentioned that we can move the asan pass somewhere to the very
end, just before lowering to RTL.
Where would be this blessed place?
Does it still have TARGET_MEM_REF?
Right before pass_expand? In init_optimization_passes(), loo
First round of comments.
I think we should add this to google/main. It's in sufficiently good
shape for it. You can keep improving it in the branch.
It is now too late for 4.7's stage 1, so I think a reasonable way to
proceed is to keep it in google/main and then present it for trunk
inclusion
what kind of failures?
David
On Wed, Oct 19, 2011 at 2:04 PM, wrote:
> On 2011/10/19 20:38:35, kcc wrote:
>>
>> Added code to avoid bitfields.
>
> Is there anything I should know about splitting basic blocks in the
> presence of EH?
> Currently, asan fails on 483.xalancbmk, 453.povray and 450.s
On Wed, Oct 19, 2011 at 12:02 PM, wrote:
> Minimized the crash to this:
>
> struct Foo {
> unsigned bf1:1;
> unsigned bf2:1;
> unsigned bf3:1;
> };
>
> void foo (struct Foo *ob) {
> ob->bf2 = 1;
> }
>
>
>
> D.2731_4 = &ob_1(D)->bf2;
> __asan_base_addr.2 = (long unsigned int) D.2731_4;
> D.273
On Tue, Oct 18, 2011 at 19:31, Xinliang David Li wrote:
> It will be weird to put the instrumentation pass inside loop opt,
> besides memory loads which are loop invariants and redundant stores in
> loop should be handled by pre/pde.
>
> +cc Richard Guenther
>
> You may want to ask the middle-end
It will be weird to put the instrumentation pass inside loop opt,
besides memory loads which are loop invariants and redundant stores in
loop should be handled by pre/pde.
+cc Richard Guenther
You may want to ask the middle-end maintainer to review your code at
this point if you want it to be in
On Tue, Oct 18, 2011 at 3:56 PM, wrote:
> On 2011/10/18 22:52:33, davidxl wrote:
>>
>> http://codereview.appspot.com/5272048/diff/18001/tree-asan.c
>> File tree-asan.c (right):
>
>
> http://codereview.appspot.com/5272048/diff/18001/tree-asan.c#newcode325
>>
>> tree-asan.c:325: base = build_addr (
http://codereview.appspot.com/5272048/diff/18001/tree-asan.c
File tree-asan.c (right):
http://codereview.appspot.com/5272048/diff/18001/tree-asan.c#newcode325
tree-asan.c:325: base = build_addr (t, current_function_decl);
There are issues with creating address expressions from TARGET_MEM_REF
in
http://codereview.appspot.com/5272048/diff/18001/tree-asan.c
File tree-asan.c (right):
http://codereview.appspot.com/5272048/diff/18001/tree-asan.c#newcode325
tree-asan.c:325: base = build_addr (t, current_function_decl);
You need to create a temp var and build as gimple assignment. See
init_tmp
There must be a style lint for gcc -- but I have not used it ..
http://codereview.appspot.com/5272048/diff/2001/tree-asan.c
File tree-asan.c (right):
http://codereview.appspot.com/5272048/diff/2001/tree-asan.c#newcode79
tree-asan.c:79: (All I need is to traverse *all* memory accesses and
instru
http://codereview.appspot.com/5272048/diff/2001/tree-asan.c
File tree-asan.c (right):
http://codereview.appspot.com/5272048/diff/2001/tree-asan.c#newcode79
tree-asan.c:79: (All I need is to traverse *all* memory accesses and
instrument them).
Discard 2) -- it is not correct. What Asan needs is
fasan option also needs to be documented in doc/invoke.texi.
http://codereview.appspot.com/5272048/diff/2001/tree-asan.c
File tree-asan.c (right):
http://codereview.appspot.com/5272048/diff/2001/tree-asan.c#newcode54
tree-asan.c:54: ShadowValue = (char*)ShadowAddr;
*(char*) ShadowAddr;
http://
18 matches
Mail list logo
