ok.
David
On Fri, Aug 14, 2015 at 11:13 PM, Teresa Johnson wrote:
> This patch resets the lambda scope based sequence numbering used to assign
> numbers to lambdas during parsing when we pop a module scope. This resets
> the numbering for subsequent modules imported during LIPO compilation.
>
>
on is not in trunk.
>
> It's ok to submit to google/gcc-4_9 branch.
>
> Thanks,
>
> -Rong
>
> On Wed, Sep 2, 2015 at 10:01 AM, Matt Deeds wrote:
>>
>> Hello, Honza. David Li said you might be able to help me get this
>> patch into GCC trunk. I sent mai
The fix is already in upstream gcc-4.9 branch? If yes, we just need a merge.
David
On Tue, Dec 16, 2014 at 11:30 AM, Carrot Wei wrote:
> Hi
>
> In Google application we hit the same problem as
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63341, so we also need
> the patch r215585 for Google/4.
ok.
David
On Tue, Dec 16, 2014 at 2:15 PM, Dehao Chen wrote:
> This patch syncs google-4_9 autofdo implementation to trunk (as much
> as possible).
>
> Bootstrapped and passed regression test and performance test.
>
> OK for google-4_9?
>
> Thanks,
> Dehao
Does it paper over the real bug?
David
On Tue, Dec 16, 2014 at 2:38 PM, Dehao Chen wrote:
> This patch fixes the bug for undefined symbol in AutoFDO build.
>
> Testing on going. OK for google-4_9 branch?
>
> Thanks,
> Dehao
>
> Index: gcc/auto-profile.c
>
lem, but is also reasonable because
> if callee's definition is not available, we should not promote the
> indirect call anyway.
>
It depends. If there is a wrong DFE before the promotion, we will end
up missing opportunities.
David
> Dehao
>
> On Tue, Dec 16, 2014 at 2
Ok (perhaps merge DECL_EXTERNAL and cgraph_is_aux_decl_external
checks together).
David
On Mon, Dec 22, 2014 at 4:57 PM, Teresa Johnson wrote:
> Ping.
> Teresa
>
> On Fri, Dec 19, 2014 at 5:40 PM, Teresa Johnson wrote:
>> Passes regression tests, ok for google 4_9?
>>
>> Thanks,
>> Teresa
>>
>
ok.
David
On Fri, Jan 2, 2015 at 10:19 PM, Teresa Johnson wrote:
> Fixes a problem caused by my recent change to allow aux functions to
> be removed. They need to be kept until after LIPO linking/static
> promotion, since they affect the promoted names of any static
> variables defined within th
ichard Biener
wrote:
> On Wed, Oct 31, 2012 at 12:57 AM, Xinliang David Li
> 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 ac
> --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 -fno-mat
On Wed, Oct 31, 2012 at 4:10 PM, Jakub Jelinek 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
>
> If Dmitry wrote parts of the patch, it would be nice to mention
> him in the ChangeLog too.
>
On Wed, Oct 31, 2012 at 11:27 PM, Jakub Jelinek wrote:
> On Wed, Oct 31, 2012 at 11:00:17PM -0700, Xinliang David Li wrote:
>> > + /* Below are things we do not instrument
>> > + (no possibility of races or not implemented yet). */
>> > + if (/* Compile
On Thu, Nov 1, 2012 at 10:06 AM, Dmitry Vyukov wrote:
> On Thu, Nov 1, 2012 at 7:47 PM, Xinliang David Li
> wrote:
>>
>> On Wed, Oct 31, 2012 at 11:27 PM, Jakub Jelinek 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 wrote:
> On Thu, Nov 1, 2012 at 10:14 PM, Dmitry Vyukov wrote:
>>>
>>> >> > On Wed, Oct 31, 2012 at 11:00:17PM -0700, Xinliang David Li wrote:
>>> >> >> > + /* Below are things we do not instru
x27;? If yes, then it is not
the same as address taken.
David
On Thu, Nov 1, 2012 at 11:24 AM, Jakub Jelinek 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.
>
.
David
On Thu, Nov 1, 2012 at 11:49 AM, Jakub Jelinek 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]
>> ...
On Thu, Nov 1, 2012 at 12:16 PM, Jakub Jelinek 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 m
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 wrote:
> patch.part2.txt.bz2 and patch.part3.txt.bz2 are still too big.
>
> Divide patch.part2.txt.bz2 into two parts:
>
that sounds good to me.
David
On Thu, Nov 1, 2012 at 1:31 PM, Jakub Jelinek 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 d
On Thu, Nov 1, 2012 at 1:47 PM, Jakub Jelinek 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 wrote:
>> > On Thu, Nov 01, 2012 at 11:57:21AM -0700, Xinliang David Li wrote:
>> >> That is
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 wrote:
> On Thu, Nov 01, 2012 at 01:57:40PM -0700, Xinliang David Li wrote:
>> I looked at it prett
; Thanks,
> Wei.
>
> On Thu, Nov 1, 2012 at 1:34 PM, Xinliang David Li wrote:
>> that sounds good to me.
>>
>> David
>>
>> On Thu, Nov 1, 2012 at 1:31 PM, Jakub Jelinek wrote:
>>> On Thu, Nov 01, 2012 at 01:19:42PM -0700, Xinliang David Li wrote:
>
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 wrote:
> On Thu, Nov 01, 2012 at 02:19:43PM -0700, Xinliang David Li wrote:
>> Right -- I found the same thing, it is
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 wrote:
> Instead of planning this change for the branch
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 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
>>
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 planned svn commands will be:
>>
>> svn mv libasan libsanitizer
>> svn add libsanitizer/asan
>> svn add
On Thu, Nov 1, 2012 at 3:57 PM, Ian Lance Taylor wrote:
> On Thu, Nov 1, 2012 at 10:00 AM, Dehao Chen 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 gdb behavior (it's als
On Thu, Nov 1, 2012 at 4:16 PM, Dehao Chen wrote:
> On Thu, Nov 1, 2012 at 4:07 PM, Xinliang David Li wrote:
>> On Thu, Nov 1, 2012 at 3:57 PM, Ian Lance Taylor wrote:
>>> On Thu, Nov 1, 2012 at 10:00 AM, Dehao Chen wrote:
>>>>
>>>> I see your poin
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
wrote:
>
>
> On Thu, Nov 1, 201
Thanks, good to know that.
David
On Fri, Nov 2, 2012 at 6:31 AM, Martin Jambor 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
Yes, agree. For now using the !(TREE_ADDRESSABLE (decl) ||
is_global_var (decl)) can be used to skip instrumentation if the
points-to interface is not available for use.
David
On Fri, Nov 2, 2012 at 8:58 AM, Jakub Jelinek wrote:
> On Fri, Nov 02, 2012 at 08:54:42AM -0700, Xinliang David
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 wrote:
> Adding function attributes: 'always_patch_for_instrumentati
On Sun, Nov 4, 2012 at 8:07 AM, Richard Biener
wrote:
> On Wed, Oct 31, 2012 at 8:02 PM, Xinliang David Li wrote:
>> Dehao's patch will make the debugging of the following code (-g -O2)
>> less jumpy. After the testing of x > 0, it should go to line 'a++'.
&
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 wrote:
> We have been developing a new security hardening feature for GCC that
> i
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 wrote:
> Thanks David for the review. My comments are inline.
>
>
> On Sat, Nov 3, 2012 at 12:38 PM, Xinliang David Li wrote:
>>
>> Harshit, Nov 5 is the gcc48 cutoff date. If you want to have the x-ray
>> instrumenta
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, 2
gt; 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 wrote:
>> It does not hurt to submit the patch for review -- you need to provide
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. */
>
>
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 wrote:
> On Fri, Nov 09, 2012 at 02:14:04PM +0100, Tobias Burnus wrote:
>> Dodji Seketeli wrote:
>> >This patch imports the initial state of asan as i
On Mon, Nov 12, 2012 at 12:45 AM, Jakub Jelinek 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 depenencies), adding a
On Tue, Nov 13, 2012 at 8:40 AM, Jakub Jelinek 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 cleanly becau
On Tue, Nov 13, 2012 at 9:36 AM, Jakub Jelinek 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
>>
On Tue, Nov 13, 2012 at 3:20 AM, Dodji Seketeli wrote:
> Diego Novillo 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 (Jakub, Dodji, are they there?
On Tue, Nov 13, 2012 at 3:42 AM, Jakub Jelinek 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 wrote:
>> > Diego Novillo a écrit:
>> >
>> >> Patches to libsanitizer should be sent upstream. We should only
>> >> contain a copy
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 fa
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 wrote:
>> The randomness here means that if we set UNKNOWN_LOCATION to insn, it
>> can
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 wrote:
> Hi,
>
> This patch is to change -faddress-saniti
On Mon, Nov 19, 2012 at 10:57 AM, Jakub Jelinek 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 automatically implem
Nov 19, 2012 at 10:31 PM, Xinliang David Li
> 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.
>
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 wrote:
> Hi,
>
> A dummy script to help merging asan from upstream.
> Not 100% complete, but sh
is script from libsanitizer dir"
>
>
> +rm -rf upstream
>
>
>
>
>
> On Wed, Nov 21, 2012 at 10:49 PM, Xinliang David Li
> wrote:
>> Suggestions:
>>
>> 1) make sure current local dir is libsanitizer -- exit if it is not
>> 2) clean up the upstream
d_p use_p)
else 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
* 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 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
> + (FIELD_DE
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
>> wrote:
>>> How about also documenting this in README.gcc?
>>>
>>> D
On Fri, Nov 23, 2012 at 8:39 AM, Jakub Jelinek 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, tsan uses
On Sun, Nov 25, 2012 at 4:40 AM, Richard Biener
wrote:
> On Thu, Nov 15, 2012 at 5:46 PM, Eric Botcazou wrote:
>>> But UNKNOWN_LOCATION is effectively wrong as well. If other
>>> optimizations move the statements above the inserted instruction, then
>>> the new instruction ends up inheriting wha
On Mon, Nov 26, 2012 at 12:35 AM, Jakub Jelinek 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 wrote:
>> >>> Ok. A slight problem then is that where the tsan pass sits right now,
>> >>> there
>> >>> is no easy way to fi
*/
- ~(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
* config/i386/i386.c: Allow sign extend instructions (cltd etc)
on modern CPUs
Fixed.
thanks,
David
On Sat, Dec 1, 2012 at 4:08 PM, Steven Bosscher wrote:
> On Sat, Dec 1, 2012 at 6:50 AM, Xinliang David Li wrote:
>> 2010-11-30 Xinliang David Li <>
>>
>> * config/i386/i386.c: Allow sign extend instructions (cltd etc)
>>
.
>
> 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();
>>
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, wrote:
> Reviewers: davidxl, xur,
>
> Message:
> When I backported this patch to google/gcc-4.6, I forgot to do it for
>
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 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 t
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
wrote:
> On Wed, Dec 5, 2012 at 3:39 PM, Jakub Jelinek wrote:
>> Hi!
>>
>> Another problem from the compiler side when working on the asan testsuite
>> i
Ok. Tail/head merging optimization also happens after PRE. Though it
happens before asan instrumentation, in theory it can trigger similar
bogus loc problem, but less likely.
David
On Wed, Dec 5, 2012 at 8:35 AM, Jakub Jelinek wrote:
> On Wed, Dec 05, 2012 at 08:24:59AM -0800, Xinliang David
It (a trunk backport) is not needed for google/main.
David
On Wed, Dec 5, 2012 at 1:46 PM, 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/
| m_ATHLON_K8,
/* X86_TUNE_SHIFT1 */
~m_486,
2012-12-08 Xinliang David Li
* config/i386/i386.c: Eanble push/pop in pro/epilogue for
moderen CPUs.
, push/pop is implemented using 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
>>&
ok.
David
On Mon, Dec 10, 2012 at 9:23 PM, Dehao Chen 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
> TREE_BLOC
ok.
David
On Thu, Apr 25, 2013 at 4:37 PM, Dehao Chen wrote:
> The ported patch:
>
> r188371 | dehao | 2012-06-09 18:44:58 -0700 (Sat, 09 Jun 2012) | 13 lines
>
> 2012-06-10 Dehao Chen
>
> Backport r188303 from google-4_7
> * gcc/cgraph.c (cgraph_node): Add attribute to function decl.
> * gcc
Ok.
David
On Fri, Apr 26, 2013 at 6:42 PM, Dehao Chen wrote:
> Bootstrapped and passed regression tests.
>
> Okay for google-4_7 and google-4_7 branches?
>
> Thanks,
> Dehao
>
> 2012-03-09 Rong Xu
>
> * opts-global.c (lipo_save_cl_args): save -std option.
> Google ref b/61179
ok with benchmark testing.
Need to be in all google branches (47, 48 and main)
David
On Fri, Apr 26, 2013 at 7:57 PM, Dehao Chen wrote:
> This patch forbids modules to be imported as aux module if its --std
> is different with the primary module.
>
> Bootstrapped and passed regression test.
>
>
ok.
David
On Tue, Apr 30, 2013 at 1:34 PM, Harshit Chopra wrote:
> Adding function name to the function_patch_* sections when
> -ffunction-sections is provided. Helps in garbage collecting dead functions
> with the help of linker.
>
> Tested:
> Tested using 'make -k check-gcc RUNTESTFLAGS="i
On Tue, Apr 30, 2013 at 4:10 PM, Dehao Chen wrote:
> This patch changes to use context function name to replace function
> id, which is not available in AutoFDO builds.
Why isn't func_id not available in autofdo builds? The func-id for the
the same function should remain the same regardless wheth
I suggest submitting the refactoring part of the changes to GCC trunk first.
thanks,
David
On Thu, May 2, 2013 at 11:06 AM, Carrot Wei wrote:
> This patch fixes google bug 8397853 and targets google 4.7 branch.
>
> In LIPO mode, when coverage_obj_init is called, cgraph_state is
> CGRAPH_STATE_F
in aux module is not the same (off by
>> 1). This is when -fexception is specified. I had not looked into why
>> though. I'll find out why it is off-by-1
>>
>> Dehao
>>
>> On Wed, May 1, 2013 at 9:57 AM, Xinliang David Li wrote:
>>> On Tue, Apr 30
Please do what Richard suggested. gcov_info_type can be obtained from
gcov_info_var decl.
David
On Fri, May 3, 2013 at 11:31 AM, Carrot Wei wrote:
> On Fri, May 3, 2013 at 1:03 AM, Richard Biener
> wrote:
>> On Thu, May 2, 2013 at 10:41 PM, Carrot Wei wrote:
>>> This patch outline the constru
CL_INITIAL (gcov_info_var)
> = build_info (TREE_TYPE (gcov_info_var), fn_info_ary);
> +
> + build_init_ctor (TREE_TYPE (gcov_info_var));
> +
>varpool_finalize_decl (gcov_info_var);
> }
>
>
>
> On Thu, May 2, 2013 at 11:15 AM, Xinliang David Li wrote:
>> I sugg
ok.
David
On Tue, May 7, 2013 at 7:27 PM, Dehao Chen wrote:
> This patch updated the unittest and doc for the new
> -frecord-compilation-info-in-elf flag.
>
> Bootstrapped and passed regression test.
>
> OK for google-4_7 branch?
>
> Thanks,
> Dehao
>
> Index: gcc/testsuite/gcc.dg/record-gcc-swi
This is not correct. current_module_id is used only in FE parsing.
The real question is why the decl is created, neither static nor external?
David
On Thu, May 9, 2013 at 11:39 AM, Carrot Wei wrote:
> This patch fixed google bug entry 6124850.
>
> The usage of varpool_node has some restrictions
On Thu, May 9, 2013 at 3:40 PM, Steven Bosscher wrote:
> On Thu, May 9, 2013 at 11:42 PM, Diego Novillo wrote:
>> On 2013-05-08 01:13 , Teresa Johnson wrote:
>>> -static void
>>> +void
>>> emit_barrier_after_bb (basic_block bb)
>>> {
>>>rtx barrier = emit_barrier_after (BB_END (bb));
>>> -
On Thu, May 9, 2013 at 4:46 PM, Carrot Wei wrote:
> On Thu, May 9, 2013 at 12:53 PM, Xinliang David Li wrote:
>> This is not correct. current_module_id is used only in FE parsing.
>>
> Suppose the var decl has correct flags and varpool_node can accept it,
> a new varpool_nod
ok. Would be nicer if there is a way to tell this from other error cases though.
David
On Fri, May 10, 2013 at 11:00 AM, Dehao Chen wrote:
> On Fri, May 10, 2013 at 10:47 AM, Teresa Johnson wrote:
>> Is it only auto fdo that doesn't store the module info if the module
>> is not exported or has
Looks good.
David
On Sat, May 11, 2013 at 3:53 PM, Dehao Chen wrote:
> In AutoFDO, we early-inline callsites that was inlined in profiling
> runs regardless of the size limit. With this change, the existing
> ipa-inline tunings for AutoFDO is unnecessary: it's fine to just use
> the traditional
The MV testing support includes 3 logical parts:
1) runtime APIs to check mocked CPU types and features
(__builtin_mock_cpu_supports ..)
2) runtime APIs to do CPU mocking;
3) compile time option to do lazy dispatching (instead of using IFUNC).
3) can be used to also support target without IFUNC s
Looks ok to me in general.
1) the parameter name is not ideal -- it is not callonce.
2) it might be better to extend the callonce parameter into
-ftest-coverage option such as -ftest-coverage=exec_once?
3) need documentation in invoke.texi
4) watch out for long lines.
cc Teresa.
David
On Tue, Ma
On Fri, May 24, 2013 at 4:26 PM, Rong Xu wrote:
> This patch fixes a bug in exposed in LIPO build (ICE in copy tree node).
>
> Tested with bookstrap and google internal benchmarks.
>
> -Rong
>
> 2013-05-24 Rong Xu
> Google ref b/8963414.
> * gcc/tree-inline.c (add_local_variable
On Fri, May 24, 2013 at 2:32 PM, Sharad Singhai wrote:
>if (flag_gcov_file)
> {
> - char *gcov_file_name
> -= make_gcov_file_name (file_name, src->coverage.name);
> + if (flag_intermediate_format)
> +/* Output the intermediate format without requiring source
> +
The early inlining part is ok. The tracer optimization should be
revisited -- we should have more fine grain control on it (for
instance, based on FDO summary -- but that should be common to
FDO/LIPO).
David
On Wed, May 29, 2013 at 9:39 AM, Dehao Chen wrote:
> In gcc4-8, the max einline iteratio
ok.
David
On Wed, May 29, 2013 at 5:18 PM, Carrot Wei wrote:
> Hi
>
> Since b/8397853 has been fixed, the related tests now passed, so we can remove
> them from powerpc64-grtev3-linux-gnu.xfail now.
>
> Tested with ./buildit --run_tests.
>
> OK for google 4.7 branch?
>
> thanks
> Carrot
>
>
> 20
On Thu, May 30, 2013 at 3:47 PM, Dehao Chen wrote:
> This patch makes more strict check of call args to make sure the
> number of args match.
>
> Bootstrapped and passed regression tests.
>
> OK for google branches?
>
> Thanks,
> Dehao
>
> Index: gcc/gimple-low.c
>
Ok. I think this is a useful patch for trunk too.
Thanks,
David
On Thu, May 30, 2013 at 7:03 PM, Teresa Johnson wrote:
> Testing passed. I forgot to include the documentation change in the first
> patch:
>
> Index: doc/invoke.texi
> =
Those cases you mentioned may lead to problems in inlining, indirect
target promotion transformations etc too, so it is better to use the
new guard against them.
David
On Fri, May 31, 2013 at 1:15 AM, Duncan Sands wrote:
> Hi Dehao,
>
>
> On 31/05/13 00:47, Dehao Chen wrote:
>>
>> This patch mak
ok.
David
On Sat, Jun 1, 2013 at 9:05 PM, Dehao Chen wrote:
> This patch fixes an uninitialized memory error and a hashtable
> comparison bug in AutoFDO.
>
> Bootstrapped and passed regression test.
>
> OK for google branches?
>
> Thanks,
> Dehao
>
> Index: gcc/auto-profile.c
> =
LIKELY_EXECUTED))
>
> Performance testing on-going...
>
> Dehao
>
> On Wed, May 29, 2013 at 3:44 PM, Dehao Chen wrote:
>> OK, I'll commit the early inline part.
>>
>> Dehao
>>
>> On Wed, May 29, 2013 at 10:00 AM, Xinliang David Li
>> wrot
If the purpose of the fix is to filter early inlinings with code
growth in autoFDO, the proposed fix is the wrong way to do -- it
changes the meaning of cgraph_maybe_hot_edge_p.
David
On Sun, Jun 2, 2013 at 7:25 PM, Dehao Chen wrote:
> On Sun, Jun 2, 2013 at 7:14 PM, Xinliang David Li wr
; + xstrdup (cgraph_node_name (e->caller)), e->caller->uid,
> + xstrdup (cgraph_node_name (callee)), callee->uid,
> + growth);
> +want_inline = false;
> + }
>else if (!cgraph_maybe_hot_edge_p (e))
> {
>if (dump_file)
>
> Thanks,
Richard's question is that inlining should deal with extra arguments
just fine -- those paths (the insane profile case) won't be executed
anyway. Do you have a case showing otherwise (i.e., the mismatch
upsets the compiler?)
David
On Tue, Jun 4, 2013 at 8:07 AM, Dehao Chen wrote:
> On Tue, Jun
ok.
David
On Tue, Jun 4, 2013 at 9:51 AM, Dehao Chen wrote:
> Patch updated to set the iteration threshold to 10 for AutoFDO.
> Performance test shows ok.
>
> OK for google-4_8 branch?
>
> Thanks,
> Dehao
>
> Index: gcc/ipa-inline.c
> =
301 - 400 of 1051 matches
Mail list logo
