[Patch] Regex back-reference support
Nothing surprising here. Bootstrap passed and tested under x86_64 and i386 Linux. -- Tim Shen backref.patch Description: Binary data
Re: [Patch] Regex back-reference support
On Sat, Aug 10, 2013 at 4:37 PM, Tim Shen wrote: > Nothing surprising here. > > Bootstrap passed and tested under x86_64 and i386 Linux. Changelog. -- Tim Shen changelog Description: Binary data
Re: [Patch] Regex back-reference support
On 08/10/2013 10:37 AM, Tim Shen wrote: +regex_match(s, *(&s+1)-1, m, re); I don't like these *(&s+1)-1. Paolo.
Re: [Patch] Regex back-reference support
On Sat, Aug 10, 2013 at 4:58 PM, Paolo Carlini wrote: > On 08/10/2013 10:37 AM, Tim Shen wrote: >> >> +regex_match(s, *(&s+1)-1, m, re); > > I don't like these *(&s+1)-1. As you wish :) -- Tim Shen changelog Description: Binary data backref.patch Description: Binary data
Re: Speculative call support in the callgraph
> On Sat, Aug 10, 2013 at 02:25:21AM +0200, Andi Kleen wrote: > > On Sat, Aug 10, 2013 at 01:15:11AM +0200, Jan Hubicka wrote: > > > > Jan Hubicka writes: > > > > > > > > > Hi, > > > > > this patch adds support for speculative calls into callgraph. The > > > > > idea is that > > > > > any IPA optimization that believes it knows likely target of an > > > > > indirect call > > > > > (currently I use it for cross-module indirect call profiling, but I > > > > > expect > > > > > Martin J. can easily add support for ipa-cp and I hope to add > > > > > speculative > > > > > devirtualization in foreseeable future since it should make > > > > > difference for > > > > > Firefox). Speculative call replaces indirect call > > > > > > > > Patch appears to break boot strap on x86_64-linux > > > > (or maybe your other one) > > > > > > How do you bootstrap? This should not be used w/o lto+profiledbootstrap > > > and > > > that seems to work for me... > > > > Neither LTO nor profiled > > My tree bootstraps again when I revert > > * cgraphbuild.c (cgraph_rebuild_references): Rebuild only > * non-speculative >refs. > * cgraph.c (cgraph_update_edge_in_call_site_hash): New >* function. > > svn+ssh://gcc.gnu.org/svn/gcc/trunk@201632 > > (and also the later patch) This is really strange. The speculative edges should not be created here at all. So perhaps some uninitialized memory access crept in :( It would help if you try to track how the ->speculative bit appears for you in the loop in cgraph_rebuild_references. I will try to reproduce your setup now. Honza > > -Andi
Re: Speculative call support in the callgraph
Hi, also I just became aware that this patch hits the following bug of gold http://sourceware.org/bugzilla/show_bug.cgi?id=14342 It makes gcc.dg/tree-prof/crossmodule-indircall-1.c fail with the bogus diagnostic on TLS and non-TLS use of the same symbol. I attached the details into the PR. GNU-LD works. I am not sure if I can workaround this problem except for convincing users to always use -fno-lto with -fprofile-generate. Shall we fix it in mainline binutils + document that earlier binutils are broken with -fporfile-generate -flto? Honza
Re: [Patch] Regex back-reference support
Hi, Tim Shen ha scritto: >On Sat, Aug 10, 2013 at 4:58 PM, Paolo Carlini > wrote: >> On 08/10/2013 10:37 AM, Tim Shen wrote: >>> >>> +regex_match(s, *(&s+1)-1, m, re); >> >> I don't like these *(&s+1)-1. > >As you wish :) See wasn't that difficult, after all ;) Seriously, a modern c++ programmer doesn't necessarily use all the time pointers, and frankly would not be able to figure out both type and value of that expression in a split second (remember this test, for the future ;) More important: we are adding support for a non trivial feature and not a single comment in the new code refers to it. This is not ok, please add at least 2 or 3. Paolo
Re: Speculative call support in the callgraph
> This is really strange. The speculative edges should not be created here at > all. > So perhaps some uninitialized memory access crept in :( > It would help if you try to track how the ->speculative bit appears for you > in the loop in cgraph_rebuild_references. I will try to reproduce your setup > now. OK, it reproduced for me on one of the testers. I think the bug is that cgraph edges are not cleared upon allocation and I did not set the newly introduced flag: Index: cgraph.c === --- cgraph.c(revision 201640) +++ cgraph.c(working copy) @@ -873,6 +873,7 @@ cgraph_create_edge_1 (struct cgraph_node edge->indirect_info = NULL; edge->indirect_inlining_edge = 0; + edge->speculative = false; return edge; } I will commit this as obvious shortly. > > Honza > > > > -Andi
Re: RFC - Refactor tree.h
Mike Stump wrote: >On Aug 9, 2013, at 3:36 PM, Diego Novillo wrote: >> This patch is still WIP. It builds stage1, but I'm getting ICEs >> during stage 2. >> >> The patch splits tree.h into three files: >> >> - tree-core.h: All data structures, enums and typedefs from >> tree.h >> >> - tree-api.h: All extern function definitions from tree.h >> >> - tree-macros.h: All macro accessors, tree checks and other >> inline functions. > >I don't like this split. You focus in on the details and sort code by >detail. I think this is wrong. I want code sorted by the features and >functions it provides, and all like this, go into explainable >functional bins. One day, a function might be implemented by a data >structure, the next day, by a routine, or a macro, or an inline >function, the form of it doesn't matter. > >It is like sorting routines by the first character of the spelling of >the name of the routine. tree_to_int, goes into t.c, because tree >starts with a t. You rename the function, and suddenly it moves files? > Bad. > >Examine double_int. All macros for double int, go in double-int.h or >double-int.c. All function go in one or the other. All routines goes >in one or the other. All double-int code goes into this bin. What bin >is it? macros? No, the bin is double-int. > >Likewise vec.[ch]. You want tree.h smaller, pick the largest abstract >group that is contained in that file, and remove it to it's own file. >For example, fold. fold is fold, fold is special. fold can be in >fold.h. If you examine the nature of the code in tree.h: > >/* In fold-const.c */ > >/* Non-zero if we are folding constants inside an initializer; zero > > otherwise. */ >extern int folding_initializer; > >This is a dead giveaway. The second giveaway, fold-const.c exists. >That code isn't in tree.c. Now, maybe you call it fold-const.h, maybe >that's better, you get the idea. > >Look for isolatable hunks that can exist in their own group of some >sort. Look for "/* In ", this is a better way to sort. I mostly agree - tree-macros.h is a red herring. It should be tree-core.h and tree.h only. What does not belong there should go to other appropriate places, like fold-const.h for example. Thanks, Richard.
Re: [Patch] Regex back-reference support
On Sat, Aug 10, 2013 at 5:41 PM, Paolo Carlini wrote: > More important: we are adding support for a non trivial feature and not a > single comment in the new code refers to it. This is not ok, please add at > least 2 or 3. Here it is. Two pieces of code concerning implementation logic is commented. Add another testcase. I'll test it again before final commit. -- Tim Shen changelog Description: Binary data backref.patch Description: Binary data
Re: [C++ Patch / RFC] PR 46206
Hi Paolo, On 9 Aug 2013, at 16:47, Paolo Carlini wrote: > On 08/09/2013 05:22 PM, David Edelsohn wrote: >> Exactly. What is the common factor on AIX, Darwin and Solaris that is >> different from Linux? A difference in system types? How can we help? > Thanks David, all, for your kind offers. > > As I said the issue is weird, I think the only way in practice to make > progress is very serious debugging on AIX and either Darwin or Solaris. Note > that AIX and Darwin are already different: on the latter only the second new > subtest fails, that for Foo2, on AIX both. > > For the time being I decided to revert the patch, otherwise the issue only > makes me nervous. If somebody has insights, basing on my original analysis > here maybe: > >http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00239.html > > I would be glad to work again on the issue at a later time, in say a week or > two. At the moment my TODO list is already full. On Darwin, a couple more data points [current head, appears independent of build - i.e. stage1 built -O0 -g3 behaves the same as bootstrapped] we accept when ints < 3, we also accept when >= 4 (at least up to 15). I.E. ACAICT, the specific case triggering this is num-int == 3. If the name of the typedef is changed to Baz, we accept (maybe obvious, but checked anyway). Trying to think of things that could cause this... I wonder if this is some weird corner-case in name hashing? Iain
Re: Speculative call support in the callgraph
> Hi,
> also I just became aware that this patch hits the following bug of gold
> http://sourceware.org/bugzilla/show_bug.cgi?id=14342
> It makes gcc.dg/tree-prof/crossmodule-indircall-1.c fail with the bogus
> diagnostic on TLS and non-TLS use of the same symbol. I attached the
> details into the PR. GNU-LD works.
>
> I am not sure if I can workaround this problem except for convincing users to
> always use -fno-lto with -fprofile-generate. Shall we fix it in mainline
> binutils + document that earlier binutils are broken with -fporfile-generate
> -flto?
Hi,
it seems that the bug also appeared in later GNU-LDs. So I made the following
workaround that with -flto switches back to old API of indirect_call_profiler
and it makes new hidden variables in profiling code. This avoid mixing of
accesses of the TLS variable from LTO and non-LTO code.
Unless someone suggests me a better solution soon, I will go with this hack.
It ought to be essentially harmless just adding some extra overhead to -flto
-fprofile-generate (same as we had before patch). Things will also still break
if you produce fat LTO -fprofile-generate objects and link some with LTO and
others without. I do not think we need to support this with binutils bug.
Honza
Index: libgcc/Makefile.in
===
--- libgcc/Makefile.in (revision 201539)
+++ libgcc/Makefile.in (working copy)
@@ -857,7 +857,7 @@ LIBGCOV = _gcov _gcov_merge_add _gcov_me
_gcov_execv _gcov_execvp _gcov_execve _gcov_reset _gcov_dump \
_gcov_interval_profiler _gcov_pow2_profiler _gcov_one_value_profiler \
_gcov_indirect_call_profiler _gcov_average_profiler _gcov_ior_profiler \
-_gcov_merge_ior
+_gcov_merge_ior _gcov_indirect_call_profiler_v2
libgcov-objects = $(patsubst %,%$(objext),$(LIBGCOV))
Index: libgcc/libgcov.c
===
--- libgcc/libgcov.c(revision 201539)
+++ libgcc/libgcov.c(working copy)
@@ -1120,6 +1120,8 @@ __gcov_one_value_profiler (gcov_type *co
#endif
#ifdef L_gcov_indirect_call_profiler
+/* This function exist only for workaround of binutils bug 14342.
+ Once this compatibility hack is obsolette, it can be removed. */
/* By default, the C++ compiler will use function addresses in the
vtable entries. Setting TARGET_VTABLE_USES_DESCRIPTORS to nonzero
@@ -1141,18 +1143,90 @@ __gcov_one_value_profiler (gcov_type *co
/* Tries to determine the most common value among its inputs. */
void
__gcov_indirect_call_profiler (gcov_type* counter, gcov_type value,
- void* cur_func, void* callee_func)
+ void* cur_func, void* callee_func)
{
/* If the C++ virtual tables contain function descriptors then one
function may have multiple descriptors and we need to dereference
the descriptors to see if they point to the same function. */
if (cur_func == callee_func
|| (VTABLE_USES_DESCRIPTORS && callee_func
- && *(void **) cur_func == *(void **) callee_func))
+ && *(void **) cur_func == *(void **) callee_func))
__gcov_one_value_profiler_body (counter, value);
}
+
+#endif
+#ifdef L_gcov_indirect_call_profiler_v2
+
+/* These two variables are used to actually track caller and callee. Keep
+ them in TLS memory so races are not common (they are written to often).
+ The variables are set directly by GCC instrumented code, so declaration
+ here must match one in tree-profile.c */
+
+#ifdef HAVE_CC_TLS
+__thread
+#endif
+void * __gcov_indirect_call_callee;
+#ifdef HAVE_CC_TLS
+__thread
+#endif
+gcov_type * __gcov_indirect_call_counters;
+
+/* By default, the C++ compiler will use function addresses in the
+ vtable entries. Setting TARGET_VTABLE_USES_DESCRIPTORS to nonzero
+ tells the compiler to use function descriptors instead. The value
+ of this macro says how many words wide the descriptor is (normally 2),
+ but it may be dependent on target flags. Since we do not have access
+ to the target flags here we just check to see if it is set and use
+ that to set VTABLE_USES_DESCRIPTORS to 0 or 1.
+
+ It is assumed that the address of a function descriptor may be treated
+ as a pointer to a function. */
+
+#ifdef TARGET_VTABLE_USES_DESCRIPTORS
+#define VTABLE_USES_DESCRIPTORS 1
+#else
+#define VTABLE_USES_DESCRIPTORS 0
#endif
+/* Tries to determine the most common value among its inputs. */
+void
+__gcov_indirect_call_profiler_v2 (gcov_type value, void* cur_func)
+{
+ /* If the C++ virtual tables contain function descriptors then one
+ function may have multiple descriptors and we need to dereference
+ the descriptors to see if they point to the same function. */
+ if (cur_func == __gcov_indirect_call_callee
+ || (VTABLE_USES_DESCRIPTORS && __gcov_indirect_call_callee
+ && *(void **) cur_func == *(void **) __gcov_indirect_call_callee))
+__gcov_one_value_p
Re: Speculative call support in the callgraph
I can confirm that trunk bootstraps again. Thanks. Now if someone could please fix http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58090 too (bootstrap comparison failure with --enable-gather-detailed-mem-stats) -Andi -- a...@linux.intel.com -- Speaking for myself only.
Re: [Patch] Regex back-reference support
Hi, On 08/10/2013 12:50 PM, Tim Shen wrote: On Sat, Aug 10, 2013 at 5:41 PM, Paolo Carlini wrote: More important: we are adding support for a non trivial feature and not a single comment in the new code refers to it. This is not ok, please add at least 2 or 3. Here it is. Two pieces of code concerning implementation logic is commented. Add another testcase. I'll test it again before final commit. Thanks. Please also move out of line, to the *.tcc, _M_insert_backref, it's too big to be inline. Also, in the new comment, you refer to a "stack", but in the same patch you removed a std::stack and added a std::vector as data member, something seems inconsistent. Thanks, Paolo.
Re: [Patch] Regex back-reference support
On 08/10/2013 06:04 PM, Paolo Carlini wrote: Also, in the new comment, you refer to a "stack", but in the same patch you removed a std::stack and added a std::vector as data member, something seems inconsistent. I had having a closer look to this: if one looks at the code now, without knowing that a std::stack was there probably the comment makes perfect sense, doesn't appear confusing (after all you are just using push_back and pop_back, and std::vector is fine for that). Paolo.
Re: RFC - Refactor tree.h
On Aug 10, 2013, at 3:03 AM, Richard Biener wrote: > Mike Stump wrote: >> On Aug 9, 2013, at 3:36 PM, Diego Novillo wrote: >>> This patch is still WIP. It builds stage1, but I'm getting ICEs >>> during stage 2. >>> >>> The patch splits tree.h into three files: >>> >>> - tree-core.h: All data structures, enums and typedefs from >>> tree.h >>> >>> - tree-api.h: All extern function definitions from tree.h >>> >>> - tree-macros.h: All macro accessors, tree checks and other >>> inline functions. >> >> I don't like this split. You focus in on the details and sort code by >> detail. I think this is wrong. > I mostly agree - tree-macros.h is a red herring. It should be tree-core.h and > tree.h only. I disagree. core isn't a concept that should be binned into. control flow, call graph, register, arm, alias, allocation, attribute, builtin, type, eval, jit, symbol, file, floating point, pass, block, stack, constant, hash, map, range, memory, debug, dump, elf, dwarf, operator, value, vector, declarations, int, statements, object, storage, expressions, frame, error, values, mapping, the list is endless. core is like a bin for important, functions that begin with a, functions I wrote, big functions, functions implemented with templates, trivial functions, hard to grasp concepts, simple things, things added in the last year, old things, fun things, extra things, useful thing, unsorted things, often used things, and so on… core goes in exactly the wrong long term direction.
[PATCH] Add -fno-instrument-function v2
From: Andi Kleen
[I posted this originally quite some time ago.
This version fixes all review problems, particularly
it works for C++ too and the test case really works.]
This adds a new C/C++ option to force
__attribute__((no_instrument_function)) on every function compiled.
This is useful together with LTO. You may want to have the whole
program compiled with -pg and have to specify that in the LTO
link, but want to disable it for some specific files. As the
option works on the frontend level it is already passed through
properly by LTO.
Without LTO it is equivalent to not specifing -pg or -mfentry.
This fixes some missing functionality in the Linux kernel LTO port.
Passed bootstrap and test suite on x86_64-linux. Ok?
gcc/:
2013-08-10 Andi Kleen
* c.opt (fno-instrument-function): Document.
gcc/c:
2013-08-10 Andi Kleen
* c-decl.c (start_function): Handle force_no_instrument_function
gcc/cp:
2013-08-10 Andi Kleen
* decl.c (start_preparsed_function): Handle
force_no_instrument_function
gcc/testsuite:
2013-08-10 Andi Kleen
* g++.dg/fno-instrument-function.C: Add.
* gcc.dg/fno-instrument-function.c: Add.
---
gcc/c-family/c.opt | 4
gcc/c/c-decl.c | 3 +++
gcc/cp/decl.c | 3 +++
gcc/doc/invoke.texi| 8 +++-
gcc/testsuite/g++.dg/fno-instrument-function.C | 18 ++
gcc/testsuite/gcc.dg/fno-instrument-function.c | 24
6 files changed, 59 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/g++.dg/fno-instrument-function.C
create mode 100644 gcc/testsuite/gcc.dg/fno-instrument-function.c
diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index 10ae84d..2159f89 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1014,6 +1014,10 @@ fnil-receivers
ObjC ObjC++ Var(flag_nil_receivers) Init(1)
Assume that receivers of Objective-C messages may be nil
+fno-instrument-function
+C C++ ObjC ObjC++ RejectNegative Report Var(force_no_instrument_function)
+Force __attribute__((no_instrument_function)) for all functions in translation
unit.
+
fnonansi-builtins
C++ ObjC++ Var(flag_no_nonansi_builtin, 0)
diff --git a/gcc/c/c-decl.c b/gcc/c/c-decl.c
index d9bbf5c..15717a9 100644
--- a/gcc/c/c-decl.c
+++ b/gcc/c/c-decl.c
@@ -7876,6 +7876,9 @@ start_function (struct c_declspecs *declspecs, struct
c_declarator *declarator,
if (current_scope == file_scope)
maybe_apply_pragma_weak (decl1);
+ if (force_no_instrument_function)
+DECL_NO_INSTRUMENT_FUNCTION_ENTRY_EXIT (decl1) = 1;
+
/* Warn for unlikely, improbable, or stupid declarations of `main'. */
if (warn_main && MAIN_NAME_P (DECL_NAME (decl1)))
{
diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index 01804d2..103188b 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -13023,6 +13023,9 @@ start_preparsed_function (tree decl1, tree attrs, int
flags)
&& lookup_attribute ("noinline", attrs))
warning (0, "inline function %q+D given attribute noinline", decl1);
+ if (force_no_instrument_function)
+DECL_NO_INSTRUMENT_FUNCTION_ENTRY_EXIT (decl1) = 1;
+
/* Handle gnu_inline attribute. */
if (GNU_INLINE_P (decl1))
{
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 782b569..bc20a77 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -169,7 +169,7 @@ in the following sections.
-aux-info @var{filename} -fallow-parameterless-variadic-functions @gol
-fno-asm -fno-builtin -fno-builtin-@var{function} @gol
-fhosted -ffreestanding -fopenmp -fms-extensions -fplan9-extensions @gol
--trigraphs -traditional -traditional-cpp @gol
+-trigraphs -traditional -traditional-cpp -fno-instrument-function @gol
-fallow-single-precision -fcond-mismatch -flax-vector-conversions @gol
-fsigned-bitfields -fsigned-char @gol
-funsigned-bitfields -funsigned-char}
@@ -1868,6 +1868,12 @@ Allow implicit conversions between vectors with
differing numbers of
elements and/or incompatible element types. This option should not be
used for new code.
+@item -fno-instrument-function
+@opindex fno-instrument-function
+Override @option{-pg} for this translation unit. This is useful with
+Link Time Optimization (LTO) to override the effects of -pg for a
+specific source file.
+
@item -funsigned-char
@opindex funsigned-char
Let the type @code{char} be unsigned, like @code{unsigned char}.
diff --git a/gcc/testsuite/g++.dg/fno-instrument-function.C
b/gcc/testsuite/g++.dg/fno-instrument-function.C
new file mode 100644
index 000..e2f6518
--- /dev/null
+++ b/gcc/testsuite/g++.dg/fno-instrument-function.C
@@ -0,0 +1,18 @@
+/* Test -fno-instrument-function */
+/* { dg-do compile } */
+/* { dg-options "-pg -fno-instrument-function" } */
+/* { dg-final { scan-assembler-not "mcount" } } */
+/* Origin: Andi Kleen */
+extern void foobar(const char *);
+
+void func(void)
Re: [PATCH 2/2] Fix HLE example in manual
On Thu, Jun 20, 2013 at 11:05:15AM -0700, Richard Henderson wrote: > On 06/20/2013 06:20 AM, Andi Kleen wrote: > > gcc/: > > 2013-06-13 Andi Kleen > > > > * doc/extend.texi: Dont use __atomic_clear in HLE > > example. Fix typo. > > Ok. I would like to to backport this to 4.8. Ok too? -Andi -- a...@linux.intel.com -- Speaking for myself only.
Re: [PATCH] Handle target specific memory models in C frontend
On Fri, Nov 09, 2012 at 07:08:07AM -0800, Richard Henderson wrote: > On 2012-11-09 07:03, Andi Kleen wrote: > > PR55139 > > * c-common.c (get_atomic_generic_size): Mask with > > MEMMODEL_MASK > > Ok. I would like to backport this patch to 4.8. Ok? -Andi -- a...@linux.intel.com -- Speaking for myself only.
[PATCH] Update MAINTAINERS file
I would like to make the following changes to the MAINTAINERS file. May I commit this? -- Caroline Tice cmt...@google.com 2013-08-10 Caroline Tice * MAINTAINERS: Add myself as libvtv maintainer. Correct my email address in the Write After Approval section. maintainers.patch Description: Binary data
Re: Speculative call support in the callgraph
> > Hi,
> > also I just became aware that this patch hits the following bug of gold
> > http://sourceware.org/bugzilla/show_bug.cgi?id=14342
> > It makes gcc.dg/tree-prof/crossmodule-indircall-1.c fail with the bogus
> > diagnostic on TLS and non-TLS use of the same symbol. I attached the
> > details into the PR. GNU-LD works.
> >
> > I am not sure if I can workaround this problem except for convincing users
> > to
> > always use -fno-lto with -fprofile-generate. Shall we fix it in mainline
> > binutils + document that earlier binutils are broken with -fporfile-generate
> > -flto?
> Hi,
> it seems that the bug also appeared in later GNU-LDs. So I made the following
> workaround that with -flto switches back to old API of indirect_call_profiler
> and it makes new hidden variables in profiling code. This avoid mixing of
> accesses of the TLS variable from LTO and non-LTO code.
>
> Unless someone suggests me a better solution soon, I will go with this hack.
> It ought to be essentially harmless just adding some extra overhead to -flto
> -fprofile-generate (same as we had before patch). Things will also still
> break
> if you produce fat LTO -fprofile-generate objects and link some with LTO and
> others without. I do not think we need to support this with binutils bug.
>
> Honza
Hi,
this is what I commited after lto & profiled bootstrap with gold +
regular testing on x86_64-linux
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (revision 201646)
+++ gcc/ChangeLog (working copy)
@@ -1,3 +1,10 @@
+2013-08-10 Jan Hubicka
+
+ Workaround binutils PR14342
+ * tree-profile.c (init_ic_make_global_vars): Add LTO path.
+ (gimple_init_edge_profiler): Likewise.
+ (gimple_gen_ic_func_profiler): Likewise.
+
2013-08-09 Jan Hubicka
* cgraph.c (cgraph_create_edge_1): Clear speculative flag.
Index: gcc/tree-profile.c
===
--- gcc/tree-profile.c (revision 201646)
+++ gcc/tree-profile.c (working copy)
@@ -67,13 +67,28 @@ init_ic_make_global_vars (void)
ptr_void = build_pointer_type (void_type_node);
- ic_void_ptr_var
-= build_decl (UNKNOWN_LOCATION, VAR_DECL,
- get_identifier ("__gcov_indirect_call_callee"),
- ptr_void);
+ /* Workaround for binutils bug 14342. Once it is fixed, remove lto path. */
+ if (flag_lto)
+{
+ ic_void_ptr_var
+ = build_decl (UNKNOWN_LOCATION, VAR_DECL,
+ get_identifier ("__gcov_indirect_call_callee_ltopriv"),
+ ptr_void);
+ TREE_PUBLIC (ic_void_ptr_var) = 1;
+ DECL_COMMON (ic_void_ptr_var) = 1;
+ DECL_VISIBILITY (ic_void_ptr_var) = VISIBILITY_HIDDEN;
+ DECL_VISIBILITY_SPECIFIED (ic_void_ptr_var) = true;
+}
+ else
+{
+ ic_void_ptr_var
+ = build_decl (UNKNOWN_LOCATION, VAR_DECL,
+ get_identifier ("__gcov_indirect_call_callee"),
+ ptr_void);
+ TREE_PUBLIC (ic_void_ptr_var) = 1;
+ DECL_EXTERNAL (ic_void_ptr_var) = 1;
+}
TREE_STATIC (ic_void_ptr_var) = 1;
- TREE_PUBLIC (ic_void_ptr_var) = 1;
- DECL_EXTERNAL (ic_void_ptr_var) = 1;
DECL_ARTIFICIAL (ic_void_ptr_var) = 1;
DECL_INITIAL (ic_void_ptr_var) = NULL;
if (targetm.have_tls)
@@ -83,13 +98,28 @@ init_ic_make_global_vars (void)
varpool_finalize_decl (ic_void_ptr_var);
gcov_type_ptr = build_pointer_type (get_gcov_type ());
- ic_gcov_type_ptr_var
-= build_decl (UNKNOWN_LOCATION, VAR_DECL,
- get_identifier ("__gcov_indirect_call_counters"),
- gcov_type_ptr);
+ /* Workaround for binutils bug 14342. Once it is fixed, remove lto path. */
+ if (flag_lto)
+{
+ ic_gcov_type_ptr_var
+ = build_decl (UNKNOWN_LOCATION, VAR_DECL,
+ get_identifier ("__gcov_indirect_call_counters_ltopriv"),
+ gcov_type_ptr);
+ TREE_PUBLIC (ic_gcov_type_ptr_var) = 1;
+ DECL_COMMON (ic_gcov_type_ptr_var) = 1;
+ DECL_VISIBILITY (ic_gcov_type_ptr_var) = VISIBILITY_HIDDEN;
+ DECL_VISIBILITY_SPECIFIED (ic_gcov_type_ptr_var) = true;
+}
+ else
+{
+ ic_gcov_type_ptr_var
+ = build_decl (UNKNOWN_LOCATION, VAR_DECL,
+ get_identifier ("__gcov_indirect_call_counters"),
+ gcov_type_ptr);
+ TREE_PUBLIC (ic_gcov_type_ptr_var) = 1;
+ DECL_EXTERNAL (ic_gcov_type_ptr_var) = 1;
+}
TREE_STATIC (ic_gcov_type_ptr_var) = 1;
- TREE_PUBLIC (ic_gcov_type_ptr_var) = 1;
- DECL_EXTERNAL (ic_gcov_type_ptr_var) = 1;
DECL_ARTIFICIAL (ic_gcov_type_ptr_var) = 1;
DECL_INITIAL (ic_gcov_type_ptr_var) = NULL;
if (targetm.have_tls)
@@ -157,15 +187,31 @@ gimple_init_edge_profiler (void)
init_ic_make_global_vars ();
- /* void (*) (gcov_type, void *) */
- ic_profiler_fn_type
- = build_function_type
Re: [PATCH, vtv update] Fix /tmp directory issues in libvtv
OK, I have removed the attempt to use $HOME for the logs; they will
now either go into the directory specified by the environment variable
VTV_LOGS_DIR, or they will go into the current directory. I also
added code to use secure_getenv, rather than getenv, if it is
available. Is this patch ok to commit?
-- Caroline Tice
cmt...@google.com
2013-08-10 Caroline Tice
* configure.ac: Add check for __secure_getenv and secure_getenv.
* configure: Regenerate.
* vtv_utils.cc : Include stdlib.h
(HAVE_SECURE_GETENV): Add checks and definitions for secure_getenv.
(log_dirs): Remove file static constant.
(__vtv_open_log): Increase size of log file name. Add the user
and process ids to the file name. Do not put the log files in /tmp.
Instead try to get the directory name from an environment variable; if
that fails use the current directory. Add O_NOFOLLOW to the flags
for 'open'. Update function comment.
On Fri, Aug 9, 2013 at 12:06 AM, Florian Weimer wrote:
> On 08/09/2013 12:09 AM, Caroline Tice wrote:
>>
>> + logs_dir = getenv ("VTV_LOGS_DIR");
>
>
> This needs to use __secure_getenv or secure_getenv, depending on the glibc
> version, so that it doesn't wreak havoc in SUID/SGID binaries (or after
> other kinds of privilege transitions).
>
> Relevant autoconf checks are described here:
>
>
>
> --
> Florian Weimer / Red Hat Product Security Team
vtv-update-tmpdir.patch
Description: Binary data
Re: [Patch] Regex back-reference support
On Sun, Aug 11, 2013 at 2:12 AM, Paolo Carlini wrote: > On 08/10/2013 06:04 PM, Paolo Carlini wrote: >> >> Also, in the new comment, you refer to a "stack", but in the same patch >> you removed a std::stack and added a std::vector as data member, something >> seems inconsistent. > > I had having a closer look to this: if one looks at the code now, without > knowing that a std::stack was there probably the comment makes perfect > sense, doesn't appear confusing (after all you are just using push_back and > pop_back, and std::vector is fine for that). I have to use a vector, because I need to iterate it while manipulating it as a stack. -- Tim Shen backref.patch Description: Binary data
[PATCH] x86-64 gcc generate wrong assembly instruction movabs for intel syntax
When compiles below testcase with gcc -masm=intel -O2
--cut here--
int test(){
long *ptr = (long*)0x8000;
*ptr = -1;
return 0;
}
--cut here--
movabs is incorrectly translated into "mov [rax], -1", and causes
compile error "Error: ambiguous operand size for `mov' ".
It should be "mov QWORD PTR [rax], -1"
Bootstrap passed. Regression tested on x86_64-unknown-linux-gnu (pc).
2013-08-10 Perez Read
* config/i386/i386.md (*movabs_1) : Add PTR before
operand 0 for intel asm alternative.
* testsuite/gcc.target/i386/movabs-1.c : New test.
Index: gcc/config/i386/i386.md
===
--- gcc/config/i386/i386.md (revision 201646)
+++ gcc/config/i386/i386.md (working copy)
@@ -2255,7 +2255,7 @@
"TARGET_LP64 && ix86_check_movabs (insn, 0)"
"@
movabs{}\t{%1, %P0|[%P0], %1}
- mov{}\t{%1, %a0|%a0, %1}"
+ mov{}\t{%1, %a0| PTR %a0, %1}"
[(set_attr "type" "imov")
(set_attr "modrm" "0,*")
(set_attr "length_address" "8,0")
Index: gcc/testsuite/gcc.target/i386/movabs-1.c
===
--- gcc/testsuite/gcc.target/i386/movabs-1.c(revision 0)
+++ gcc/testsuite/gcc.target/i386/movabs-1.c(working copy)
@@ -0,0 +1,10 @@
+/* { dg-do assemble } */
+/* { dg-options "-O2 -masm=intel" } */
+/* { dg-require-effective-target lp64 } */
+/* { dg-require-effective-target masm_intel } */
+
+void
+foo (void)
+{
+ *(volatile long*)0x8000 = -1;
+}
