ession ok on x86_64-linux-gnu. ok for
trunk?
2013-09-03 Wei Mi
* haifa-sched.c (move_insns): New function.
(adjust_for_macro_fusion): Ditto.
(schedule_block): Call adjust_for_macro_fusion before commit schedule.
* doc/tm.texi.in: Generated.
* doc/tm.texi:
Thanks for the suggestions! I take a look at adjust_priority, and find
it may not guarantee to schedule cmp and jmp together. The priority is
used to choose a candidate from ready list. If cmp is the only insn in
ready list and there is another insn-A in queued set (insn-A's
dependence has been res
SCHED_GROUP works after I add chain_to_prev_insn after
add_branch_dependences, in order to chain control dependences to prev
insn for sched group. Here is the new patch. Testing is going on.
Thanks,
Wei Mi.
2013-09-06 Wei Mi
* config/i386/i386.c (ix86_macro_fusion_p): New function
Add a testcase. bootstrap and regression ok for the patch in last mail.
2013-09-09 Wei Mi
* gcc/testsuite/gcc.dg/macro-fusion-1.c: New.
Index: gcc/testsuite/gcc.dg/macro-fusion-1.c
===
--- gcc/testsuite/gcc.dg/macro
still be scheduled apart since they will not be
put in ready list at the same time.
On Tue, Sep 10, 2013 at 4:44 AM, Alexander Monakov wrote:
>
>
> On Fri, 6 Sep 2013, Wei Mi wrote:
>
>> SCHED_GROUP works after I add chain_to_prev_insn after
>> add_branch_dependences, i
I tried that and it caused some regressions, so I choosed to do
chain_to_prev_insn another time in add_branch_dependences. There could
be some dependence between those two functions.
On Wed, Sep 11, 2013 at 2:58 AM, Alexander Monakov wrote:
>
>
> On Tue, 10 Sep 2013, Wei Mi wrote:
>
Taking the same issue slot is not enough for x86. The compare and
branch need to be consecutive in binary to be macro-fused on x86.
Thanks,
Wei Mi.
On Wed, Sep 11, 2013 at 10:45 AM, Andrew Pinski wrote:
> On Wed, Sep 4, 2013 at 12:33 PM, Alexander Monakov wrote:
>> On Wed, Sep 4, 201
tial reg stall (similar as what r201308
does for cvtsi2ss/cvtsi2sd). bootstrap and regression pass. ok for
trunk?
Thanks,
Wei Mi.
2013-09-11 Wei Mi
* config/i386/x86-tune.def (DEF_TUNE): Remove
m_CORE_ALL.
* config/i386/i386.md: Add define_peephole2 to
break par
is used to check for which kind of cmp and branch pair
macro-fusion is supported on target platform. But I am not sure if it
is proper to put those two hooks under TARGET_SCHED hook vector.
Thanks,
Wei Mi.
updated patch:
Index: doc/
> Your new implementation is not efficient: when looping over BBs, you need to
> look only at the last insn of each basic block.
>
Thanks, fixed. New patch attached.
patch
Description: Binary data
o review and respond to). Please
> mention if the updated patch passes bootstrap and regtest.
Thanks! Here is the new patch. bootstrap and regression pass. ok for trunk?
2013-09-13 Wei Mi
* sched-rgn.c (add_branch_dependences): Keep insns in
a SCHED_GROUP at the end of bb
for now because I don't have those machines for testing.
Thanks,
Wei Mi.
On Fri, Sep 13, 2013 at 12:09 PM, H.J. Lu wrote:
> On Fri, Sep 13, 2013 at 11:28 AM, Wei Mi wrote:
>>> Checking corei7/corei7-avx explicitly isn't a good idea.
>>> It is also useful for Ivy Bridge and Haswell. I think you
>>> should use a
On Fri, Sep 13, 2013 at 1:45 PM, Wei Mi wrote:
> On Fri, Sep 13, 2013 at 12:09 PM, H.J. Lu wrote:
>> On Fri, Sep 13, 2013 at 11:28 AM, Wei Mi wrote:
>>>> Checking corei7/corei7-avx explicitly isn't a good idea.
>>>> It is also useful for Ivy Bridge and H
ell support branch checking Sign and Overflow flags.
X86_TUNE_FUSE_ALU_AND_BRANCH: COREI7 doesn't support macrofusion for
alu + branch. COREI7_AVX and Haswell support it.
bootstrap and regression ok for the two patches.
Thanks,
Wei Mi.
Patch1:
2013-09-16 Wei Mi
* gcc/conf
Ping.
> -Original Message-
> From: Wei Mi [mailto:w...@google.com]
> Sent: Thursday, September 12, 2013 2:51 AM
> To: GCC Patches
> Cc: David Li; Zamyatin, Igor
> Subject: [PATCH] disable use_vector_fp_converts for m_CORE_ALL
>
> For the following testcase 1.c, on
t; && peep2_reg_dead_p (0, operands[0])
> test. Reg has to be dead since it is full destination of the operation.
Ok, I see. I will delete it.
>
> Lets wait few days before commit so we know effect of
> individual changes. I will test it on AMD hardware and we can decide on
> generic tuning then.
>
> Honza
Ok, thanks.
Wei Mi.
ks for checking it. Agner's guide also mentions this constraint
for sandybridge, ivybridge I missed it because Intel optimization
reference manual doesn't mention it. I did some experiment just now
and verified the constraint for sandybridge existed. Will add the
predicate.
Thanks,
Wei Mi.
mediate operand. I simplify
choose to use the more stringent constraint here (m_CORE_ALL's
constraint).
2. Add Budozer back and merge TARGET_FUSE_CMP_AND_BRANCH_64 and
TARGET_FUSE_CMP_AND_BRANCH_32.
bootstrap and regression pass. ok for trunk?
2013-09-24 Wei Mi
* gc
accurate either).
> Better to break it out to a common predicate and perhaps unify with what
> ix86_print_operand_address is doing.
>
> Honza
>>
>>
>> --
>> H.J.
Thanks. How about this one. bootstrap and regression are going on.
2013-09-24 Wei Mi
hardreg which
couldn't find a pair register.
No test is added because I cannot create a small testcase to reproduce
the problem on trunk, the difficulty of which was described in the
above post.
bootstrap and regression pass. ok for trunk?
Thanks,
Wei Mi.
2013-09-24 Wei Mi
ny case,
> the solution for the problem will be not that easy as in the patch.
To fix it in IRA, it looks like we want a live range splitting pass
for pseudos used in paradoxical subreg here. Is the potential
compilation slow down you mention here caused by more allocnos
introduced by the live range splitting, or something else?
Thanks,
Wei Mi.
(re-)allocation (although it is worse than in
> IRA).
>
When you get an idea how to fix it in LRA, if you are still busy, I
would be happy to do the implementation if you could brief your idea.
Thanks,
Wei Mi.
rd registers will be allocated to reg180 to save TImode
operand in LRA_assign.
Thanks,
Wei Mi.
2013-09-30 Wei Mi
* lra-constraints.c (insert_move_for_subreg): New function.
(simplify_operand_subreg): Add re
applications.
Thanks,
Wei Mi.
> Hi Wei Mi,
>
> Have you checked in your patch?
>
> --
> H.J.
No, I havn't. Honza wants me to wait for his testing on AMD hardware.
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01603.html
On Tue, Oct 1, 2013 at 3:50 PM, Jan Hubicka wrote:
>> > Hi Wei Mi,
>> >
>> > Have you checked in your patch?
>> >
>> > --
>> > H.J.
>>
>> No, I havn't. Honza wants me to wait for his testing on AMD hardware.
>> http://gc
Hi Diego,
>> /* Build
>> - (base_addr >> ASAN_SHADOW_SHIFT) | targetm.asan_shadow_offset ().
>> */
>> + (base_addr >> ASAN_SHADOW_SHIFT) + targetm.asan_shadow_offset ().
>> */
>
>
> Hm, I wonder if this is a documentation problem or we're generating bad
> runtime code. Wei, you tested
Hi,
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]. llvm regression tests for gcc-asan: 18 failures in 123 for tests
written in google test and 24 failures in 28 for tests writ
>
> This is a good start. Can you send a patch out without including
> libasan so at least the toplevel parts can be reviewed easier?
> Also the changelog entry for gcc.c go under the gcc/ChangeLog rather
> than the toplevel one.
>
> Thanks,
> Andrew Pinski
Sure, I attach it. Thanks for pointing
On Thu, Oct 18, 2012 at 11:16 AM, Jakub Jelinek wrote:
> On Thu, Oct 18, 2012 at 09:46:36AM -0700, Wei Mi wrote:
>> --- gcc/gcc.c (revision 192567)
>> +++ gcc/gcc.c (working copy)
>> @@ -679,6 +679,7 @@ proper position among the other output f
>> %{fgnu-tm:%:inc
red 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 bugs can always be found and fixed
> later.
>
> thanks,
>
> David
>
>
>
Hi,
A small patch to remove the bogus error reports exposed in the
spec2000 testing. In varasm.c, asan_protected should be equivalent
with asan_protect_global (decl) all the time, or else compiler will
not insert redzones for some globals planned to be protected.
gcc/ChangeLog:
2012-10-25 Wei
Hi,
Thanks for all the comments. Fixed. Ok to checkin?
2012-10-25 Wei Mi
* varasm.c (assemble_variable): Set asan_protected even
for decls that are already ASAN_RED_ZONE_SIZE or more
bytes aligned.
Index: varasm.c
I try to migrate it to trunk. Ok for trunk?
gcc/ChangeLog:
2012-10-31 Wei Mi
* Makefile.in (tsan.o): New
* passes.c (init_optimization_passes): Add tsan passes
* tree-pass.h (register_pass_info): Ditto
* cfghooks.h (GCC_CFGHOOKS_H): Avoid including duplicate
view! Patch fixed according to your
comments and committed as r203169.
Regards,
Wei Mi.
On Tue, Sep 24, 2013 at 4:32 PM, Wei Mi wrote:
>>> It doesn't look right. IP relative address is only possible
>>> with TARGET_64BIT and
>>>
>>> 1. base == pc. Or
>>> 2. UUNSPEC_PCREL, UNSPEC_GOTPCREL, and
>>> NSPEC_GOTNTPOFF.
>&g
Thanks for the comments. One question inlined. Preparing another patch
addressing the comments.
Regards,
Wei Mi.
On Tue, Oct 15, 2013 at 1:35 PM, Jeff Law wrote:
> On 10/03/13 12:24, Wei Mi wrote:
>>
>> Thanks,
>> Wei Mi.
>>
>> 2013-10-03 Wei Mi
>&g
> Go ahead and consider that pre-approved. Just send it to the list with a
> note that I approved it in this thread.
>
> Jeff
Thanks! The new patch addressed Jeff's comments.
Is it ok for x86 maintainer?
Thanks,
Wei Mi.
2013-10-16 Wei Mi
* gcc/c
On Thu, Oct 17, 2013 at 12:35 AM, Marek Polacek wrote:
> On Wed, Oct 16, 2013 at 04:25:58PM -0700, Wei Mi wrote:
>> +/* Return true if target platform supports macro-fusion. */
>> +
>> +static bool
>> +ix86_macro_fusion_p ()
>> +{
>> + if (TARGET_F
Ping. Is it ok for x86 maintainer?
Thanks,
Wei Mi.
On Wed, Oct 16, 2013 at 4:25 PM, Wei Mi wrote:
>> Go ahead and consider that pre-approved. Just send it to the list with a
>> note that I approved it in this thread.
>>
>> Jeff
>
> Thanks! The new patch addressed
. However there is no subreg generated for
target cris-axis-elf, so REG_EQUIV should be allowed.
Is it ok for trunk and gcc-4.8 branch?
Thanks,
Wei Mi.
2013-11-04 Wei Mi
PR regression/58985
* testsuite/gcc.dg/pr57518.c: Add subreg in regexp pattern.
Index: testsuite/gcc.dg/pr57518.c
Thanks! The three patches are commited as r204367, r204369 and r204371.
Regards,
Wei Mi.
On Sun, Nov 3, 2013 at 5:18 PM, Jan Hubicka wrote:
>> Ping. Is it ok for x86 maintainer?
>
> I tought I already approved the x86 bits.
>>
>> Thanks,
>> Wei Mi.
>>
>&g
On Tue, Nov 26, 2013 at 9:34 PM, Jeff Law wrote:
> On 11/26/13 12:33, Wei Mi wrote:
>>
>> On Mon, Nov 25, 2013 at 2:12 PM, Jeff Law wrote:
>>>
>>>
>>>>
>>>> Doing the cleanup at the end of BB could ensure all the groups
>>>> i
de sched_analyze.
> I am trying this method...
>
> Thanks,
> Wei.
Here is the patch. The patch does the SCHED_GROUP_P cleanup in
sched_analyze before deps_analyze_insn set SCHED_GROUP_P and chain the
insn with prev insns. And it move try_group_insn for macrofusion from
sched_init to s
Ping.
Thanks,
wei.
On Sat, Nov 23, 2013 at 10:46 AM, Wei Mi wrote:
> bootstrap and regression of the updated patch pass.
>
> On Sat, Nov 23, 2013 at 12:05 AM, Wei Mi wrote:
>> On Thu, Nov 21, 2013 at 12:19 AM, Zdenek Dvorak
>> wrote:
>>> Hi,
>>>
>&
Ping.
Thanks,
Wei.
On Mon, Dec 9, 2013 at 9:54 PM, Wei Mi wrote:
> Ping.
>
> Thanks,
> wei.
>
> On Sat, Nov 23, 2013 at 10:46 AM, Wei Mi wrote:
>> bootstrap and regression of the updated patch pass.
>>
>> On Sat, Nov 23, 2013 at 12:05 AM, Wei Mi wrote:
arked as may_be_spilled_p.
The patch changes it.
Test:
Gcc unit tests ok.
Minor improvement for google internal benchmarks.
Thanks,
Wei.
gcc/ChangeLog:
2015-12-10 Wei Mi
* ira-color.c (restore_costs_from_conflicts): Don't record the
cost change.
(update_conflict_har
Yes, that is intentional. It is to avoid assiging a discriminator for
the first call in the group of calls with the same source lineno.
Starting from the second call in the group, it will get a different
discriminator with previous call in the same group.
Thanks,
Wei.
On Thu, Aug 7, 2014 at 12:17
wrote:
> Is this
>
> [1.cc : 179:64] Reader::~Reader (&version);
>
> from an inline instance?
>
> David
>
> On Wed, Aug 6, 2014 at 10:18 AM, Wei Mi wrote:
>> We saw bb like this in the IR dump after pass_build_cfg:
>>
>> :
>> [1.cc : 205:45
On Thu, Aug 7, 2014 at 2:40 PM, Xinliang David Li wrote:
> On Thu, Aug 7, 2014 at 2:20 PM, Wei Mi wrote:
>> No, it is not. This IR is dumped before early inline -- just after
>> pass_build_cfg. The line number of the deconstructor is marked
>> according to where its c
Ping.
On Sun, Jul 27, 2014 at 11:08 PM, Wei Mi wrote:
>> But fact is that it is _not_ necessary to split the block because there
>> are no outgoing abnormal edges from it.
>>
>> The verifier failure is an artifact from using the same predicates during
>> CFG build
possible to turn all these into a single flag,
> GF_CALL_CTRL_ALTERING? That is, cover everything
> that is_ctrl_altering_stmt covers? I suggest we initialize it at
> CFG build time and only ever clear it later.
Good idea!
ChangeLog:
2014-08-19 Martin Jambor
Wei Mi
ine, a new discriminator will be used everytime. The new
patch is attached. Internal perf test and regression test are ok. Is
it ok for google-4_9?
Thanks,
Wei.
On Thu, Aug 7, 2014 at 2:10 PM, Wei Mi wrote:
> Yes, that is intentional. It is to avoid assiging a discriminator for
> the first call
Hi Cary,
Is the new patch ok for google-4_9?
Thanks,
Wei.
On Sun, Aug 24, 2014 at 8:53 PM, Wei Mi wrote:
> To avoid the unused new discriminator value, I added a map
> "found_call_this_line" to track whether a call is the first call in a
> source line seen when assigning
Thanks, that is ellegant. Will paste a new patch in this way soon.
Wei.
On Fri, Aug 29, 2014 at 10:11 AM, Cary Coutant wrote:
>> To avoid the unused new discriminator value, I added a map
>> "found_call_this_line" to track whether a call is the first call in a
>> source line seen when assigning
t;> else
>> (*slot)->needs_increment = true;
>> return (*slot)->discriminator;
>> }
>>
>> -cary
Here is the new patch (attached). Regression test passes. Cary, is it ok?
Thanks,
Wei.
ChangeLog:
2014-08-29 Wei Mi
* tree-cfg.c (struct lo
+Release manager.
Thanks, committed to trunk as r204438. Ok for 4.8 branch?
On Tue, Nov 5, 2013 at 11:19 AM, Jeff Law wrote:
> On 11/04/13 12:07, Wei Mi wrote:
>>
>> Hi,
>>
>> This is to fix testcase error reported in PR58985.
>>
>> The intention of
4-linux-gnu. ok for trunk?
Thanks,
Wei.
2013-11-20 Wei Mi
* expr.c (expand_expr_addr_expr_1): Not to split TMR.
(expand_expr_real_1): Ditto.
* targhooks.c (default_builtin_has_mem_ref_p): Default
builtin.
* tree-ssa-loop-ivopts.c (struct iv)
> So what you are doing is basically not only rewriting memory references
> to possibly use TARGET_MEM_REF but also address uses to use
> &TARGET_MEM_REF. I think this is a good thing in general
> (given instructions like x86 lea) and I would not bother distinguishing
> the different kind of uses.
On Thu, Nov 21, 2013 at 1:01 PM, Richard Biener
wrote:
> Wei Mi wrote:
>>On Thu, Nov 21, 2013 at 11:36 AM, Richard Biener
>> wrote:
>>> Wei Mi wrote:
>>>>> So what you are doing is basically not only rewriting memory
>>>>references
>>&g
On Thu, Nov 21, 2013 at 11:36 AM, Richard Biener
wrote:
> Wei Mi wrote:
>>> So what you are doing is basically not only rewriting memory
>>references
>>> to possibly use TARGET_MEM_REF but also address uses to use
>>> &TARGET_MEM_REF. I think th
On Thu, Nov 21, 2013 at 12:19 AM, Zdenek Dvorak
wrote:
> Hi,
>
>> This patch works on the intrinsic calls handling issue in IVOPT mentioned
>> here:
>> http://gcc.gnu.org/ml/gcc-patches/2010-10/msg01295.html
>>
>> In find_interesting_uses_stmt, it changes
>>
>> arg = expr
>> __builtin_xxx (arg)
>
Thanks for the comments.
Regards,
Wei.
On Thu, Nov 21, 2013 at 12:48 AM, Bin.Cheng wrote:
> I don't know very much about the problem but willing to study since I
> am looking into IVO recently :)
>
>> --- tree-ssa-loop-ivopts.c (revision 204792)
>> +++ tree-ssa-loop-ivopts.c (working c
On Fri, Nov 22, 2013 at 6:11 AM, Zdenek Dvorak wrote:
> Hi,
>
>> >> > If a pointer typed use is plainly value passed to a func call, it is
>> >> > not an address use, right? But as you said, x86 lea may help here.
>> >>
>> >> But that's what you are matching ... (well, for builtins you know
>> >>
> I think the problem can be showed by below example:
> struct tag
> {
> int a[10];
> int b;
> };
> struct tag s;
> int foo(int len)
> {
> int i = 0;
> int sum = 0;
> for (i = 0; i < len; i++)
> sum += barr (&s.a[i]);
>
> return sum;
> }
> The dump before IVOPT is like:
>
> :
>
On Fri, Nov 22, 2013 at 9:21 AM, Wei Mi wrote:
>> I think the problem can be showed by below example:
>> struct tag
>> {
>> int a[10];
>> int b;
>> };
>> struct tag s;
>> int foo(int len)
>> {
>> int i = 0;
>> int
as USE_ADDRESS and do the rewriting in
> rewrite_use_address.
>
> Zdenek
I updated the patch. The gimple changing part is now moved to
rewrite_use_address. Add support for plain address expr in addition to
reference expr in find_interesting_uses_address.
bootstrap
bootstrap and regression of the updated patch pass.
On Sat, Nov 23, 2013 at 12:05 AM, Wei Mi wrote:
> On Thu, Nov 21, 2013 at 12:19 AM, Zdenek Dvorak
> wrote:
>> Hi,
>>
>>> This patch works on the intrinsic calls handling issue in IVOPT mentioned
>>> here:
&
ssion test is going on. Is it ok if regression passes?
Thanks,
Wei.
2013-11-23 Wei Mi
PR rtl-optimization/59020
* haifa-sched.c (cleanup_sched_group): New function.
(sched_finish): Call cleanup_sched_group to cleanup SCHED_GROUP_P.
2013-11-23 Wei Mi
P
On Mon, Nov 25, 2013 at 2:08 AM, Alexander Monakov wrote:
> On Sat, 23 Nov 2013, Wei Mi wrote:
>> For the failed testcase, it was compiled using -fmodulo-sched.
>> modulo-sched phase set SCHED_GROUP_P of a jump insn to be true, which
>> means the jump insn should be schedule
On Mon, Nov 25, 2013 at 10:36 AM, Jeff Law wrote:
> On 11/24/13 00:30, Wei Mi wrote:
>>
>> Sorry about the problem.
>>
>> For the failed testcase, it was compiled using -fmodulo-sched.
>> modulo-sched phase set SCHED_GROUP_P of a jump insn to be true, which
On Mon, Nov 25, 2013 at 11:25 AM, Jeff Law wrote:
> On 11/25/13 12:16, Wei Mi wrote:
>>>
>>>
>>> I'll note you're doing an extra pass over all the RTL here. Is there
>>> any
>>> clean way you can clean SCHED_GROUP_P without that extra
On Mon, Nov 25, 2013 at 2:12 PM, Jeff Law wrote:
>
>>
>> Doing the cleanup at the end of BB could ensure all the groups
>> inserted for macrofusion will be cleaned. For groups not at the end of
>> a block, no matter whether they are cleaned up or not, nothing will
>> happen because other passes wi
+
offset). With the fix, find_base_term can always get the base of the
original addr.
bootstrap and regression test on x86_64-linux-gnu are ok. regression
tests on aarch64-linux-gnu and powerpc64-linux-gnu are also ok. Is it
ok for trunk?
Thanks,
Wei.
gcc/ChangeLog:
2015-01-21 Wei Mi
Thanks for the review. Comments addressed and patch committed. The
problem exists on gcc-4_9 too. Is it ok for gcc-4_9-branch? Will wait
another day to commit it to gcc-4_9 if it is ok.
Thanks,
Wei.
On Thu, Jan 22, 2015 at 9:39 AM, Jeff Law wrote:
> On 01/21/15 15:32, Wei Mi wrote:
>&
?
2012-11-1 Wei Mi
* configure.ac: Change target-libasan to target-libsanitizer.
* configure.in: Regenerate.
* Makefile.def: Change libasan module to libsanitizer.
* Makefile.in: Regenerate.
* libsanitizer: Change libasan to libsanitizer and add
> On Thu, Nov 1, 2012 at 1:17 PM, Wei Mi wrote:
>> patch.part2.txt.bz2 and patch.part3.txt.bz2 are still too big.
>>
>> Divide patch.part2.txt.bz2 into two parts:
>> patch.part2-1.txt.bz2 + patch.part2-2.txt.bz2
>>
>> Divide patch.part3.txt.bz2 into two p
Ok, I will check in the patch.
Thanks,
Wei.
On Thu, Nov 1, 2012 at 3:03 PM, Xinliang David Li wrote:
> On Thu, Nov 1, 2012 at 2:23 PM, Xinliang David Li wrote:
>> On Thu, Nov 1, 2012 at 2:17 PM, Wei Mi wrote:
>>> Thanks for the suggestion!
>>>
>>> The plann
The patch has been checked in.
Committed revision 193074.
Thanks,
Wei.
On Thu, Nov 1, 2012 at 3:16 PM, Wei Mi wrote:
> Ok, I will check in the patch.
>
> Thanks,
> Wei.
>
> On Thu, Nov 1, 2012 at 3:03 PM, Xinliang David Li wrote:
>> On Thu, Nov 1, 2012 at 2:23 PM,
Hi,
Thanks for so many useful comments! I update the file according to the
comments. The major changes include adding sanitizer.def and
generating gimple directly. New patch file is attached.
> On Wed, Oct 31, 2012 at 11:34:10AM -0700, Wei Mi wrote:
>> gcc/ChangeLog:
>> 201
Sorry, I attached an incorrect patch.txt yesterday. This is the correct one.
Thanks,
Wei.
On Fri, Nov 2, 2012 at 6:31 PM, Wei Mi wrote:
> Hi,
>
> Thanks for so many useful comments! I update the file according to the
> comments. The major changes include adding sanitizer.def and
te_ssa, so I kept it.
>> +| TODO_update_address_taken /* todo_flags_finish */
>
> And why this?
>
If we generate tsan_read(&a) for a non-address taken static variable
a, we need to change a to be address taken, right?
On Sat, Nov 3, 2012 at 11:39 AM, Jakub Jelinek wrote:
> On Sat, Nov
> Other issues:
>
> * libasan does not seem to be a multilib, at least I only find the 64bit
> version on x86-64-gnu-linux such that "-m32" compilation fails.
>
That is because originally configure file is shared between asan and
tsan (tsan doesn't support 32 bit). Diego has suggested me to split
>
>>
>> > 2. Large Gtest-based unittest. This is a set of c++ files that should
>> > be built with the asan switch, depends on gtest
>> > (http://code.google.com/p/googletest/).
>> >
>> > http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/asan/tests/asan_test.cc?revision=166104&view=markup
>
On Fri, Nov 9, 2012 at 11:13 AM, Jakub Jelinek wrote:
> On Fri, Nov 09, 2012 at 11:05:37AM -0800, Wei Mi wrote:
>> gtest integrate multiple tests into the same file with each test being
>> a single line check. I cannot think out a method to migrate it to
>> dejagnu withou
ed flag is set. That is why I will get assertion when
I remove TODO_update_ssa flag.
Is it ok to keep TODO_update_ssa and TODO_update_address_taken?
Thanks,
Wei.
On Mon, Nov 5, 2012 at 4:37 PM, Wei Mi wrote:
> Hi Jakub,
>
> Thanks for the comments. I fix most of them except the setting
>> > 3. Full output tests (a .cc file should be build with asan switch,
>> > executable should be run and the stderr is compared with the expected
>> > output)
>> > Example:
>> > http://llvm.org/viewvc/llvm-project/compiler-rt/trunk/lib/asan/lit_tests/stack-overflow.cc?revision=165391&view=markup
>
> Will this run the test in all mode (O0 vs O2 and -m32 vs -m64)?
>
>
> --kcc
Yes, it runs in all modes. O0/O1/O2/O3 + -m32/-m64, which is specified
in asan.exp.
Thanks,
Wei.
Sure, I can add the support. To run -mx32 test, we need to add x32
multilib support for libasan first, right?
Thanks,
Wei.
On Tue, Nov 13, 2012 at 2:14 PM, H.J. Lu wrote:
> On Tue, Nov 13, 2012 at 1:49 PM, Wei Mi wrote:
>>> Will this run the test in all mode (O0 vs O2 and
Thanks for catching this. I update the patch.
Regards,
Wei.
On Tue, Nov 13, 2012 at 4:54 PM, Richard Henderson wrote:
> On 11/13/2012 04:08 PM, Wei Mi wrote:
>> +extern void tsan_finish_file (void);
>> +
>> +#endif /* TREE_TSAN */
>> +/* ThreadSanitizer, a data race
Hi,
Is it ok for the trunk?
Thanks,
Wei.
On Tue, Nov 13, 2012 at 5:06 PM, Wei Mi wrote:
> Thanks for catching this. I update the patch.
>
> Regards,
> Wei.
>
> On Tue, Nov 13, 2012 at 4:54 PM, Richard Henderson wrote:
>> On 11/13/2012 04:08 PM, Wei Mi wrote:
>>&
Hi,
This patch is to change -faddress-sanitizer to -fsanitize=address. Ok for trunk?
2012-11-19 Wei Mi
* cfgexpand.c (partition_stack_vars): Change flag_asan to
flag_sanitize.
(expand_stack_vars): Likewise.
(defer_stack_allocation): Likewise
t; 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 wrote:
>> Hi,
>>
>> This patch is to change -faddress-sanitizer to -fsanitize=address. Ok for
>> trun
I rewrite the patch according to Jakub's suggestion -- add the
following option in common.opt and keep flag_asan. The patch is
attached. Ok to checkin?
fsanitize=address
Common Report Var(flag_asan)
Enable AddressSanitizer, a memory error detector
2012-11-21 Wei Mi
* commo
Thanks! Done.
Committed revision 193702.
Regards,
Wei.
On Tue, Nov 20, 2012 at 11:57 PM, Jakub Jelinek wrote:
> On Tue, Nov 20, 2012 at 11:14:27PM -0800, Wei Mi wrote:
>> 2012-11-21 Wei Mi
>>
>> * common.opt: Change faddress-sanitizer to fsanitize=address.
;> > + && tcode != MEM_REF)
>> > +return false;
>> >
>>
>> The listed cases are handled.
>>
>> David
>>
>> >
>> >
>> > On Thu, Nov 22, 2012 at 11:29 AM, Dmitry Vyukov
>> > wrote:
>
Thanks. I checked in the code.
Committed revision 193736.
Committed revision 193737.
Wei.
On Thu, Nov 22, 2012 at 1:54 AM, Jakub Jelinek wrote:
> On Wed, Nov 21, 2012 at 11:22:51PM -0800, Wei Mi wrote:
>> I update the tsan patch against trunk, and create libtsan patch.
>> Please
, Nov 22, 2012 at 3:18 PM, Jack Howarth wrote:
> On Thu, Nov 22, 2012 at 02:08:07PM -0800, Wei Mi wrote:
>> Thanks. I checked in the code.
>> Committed revision 193736.
>> Committed revision 193737.
>>
>> Wei.
>
> Wei,
>Unlike libasan, we seem to have issu
s that host or build) delete).
> But of course if you could eyeball the rest and comment, I'd be even happier.
>
> On Fri, Nov 30, 2012 at 12:35:35PM -0800, Wei Mi wrote:
>> Thanks for the comments! Here is the second version patch. Please see
>> if it is ok.
>> (-Wno-attr
1 - 100 of 154 matches
Mail list logo
