The below patch adds a new preprocessor define for the device name
(__AVR_DEVICE_NAME__) that was passed to the compiler.
While the device name macro (say __AVR_ATmega128__) can be used to
check for a specific device, there is no way right now for code
to get the device name it is being compiled
Darn, had forgotten to attach the patch...
On 16/07/14 12:30, Kyrill Tkachov wrote:
Hi all,
This fixes the PR mentioned in the subject. When expanding
atomic_test_and_set we try the corresponding sync optabs and if none
exist, like for pre-SMP ARM architectures (-march=armv6 and earlier) the
c
Ping.
On 16/07/14 10:46, Kyrill Tkachov wrote:
On 16/07/14 09:25, James Greenhalgh wrote:
On Wed, Jul 16, 2014 at 09:05:22AM +0100, Kyrill Tkachov wrote:
Hi all,
I noticed we don't document the clrsb2 optab but it does exist.
The proposed description is based on the clrsb RTL code documentati
On 07/22/2014 07:17 PM, Alexander Monakov wrote:
On Tue, 22 Jul 2014, Alexander Monakov wrote:
I'd like to push this topic forward a bit. I've bootstrapped and regtested a
version of the patch based on the initial proposal to check DECL_WEAK. The
approach with decl_replaceable_p looks not that
On Tue, Jul 22, 2014 at 5:17 PM, Jan Hubicka wrote:
>> I don't see why
>>
>> long x[1024];
>>
>> Q *q = new (x) Q;
>> q->~Q ();
>> new (x) T;
>>
>> would be invalid. I also don't see why
>>
>> Q q;
>> q.~Q ();
>> new (&q) T;
>>
>> would be. Object lifetime is precisely specified and I don't see
Roman Gareev writes:
> I've attached the patch, which contains generation of Gimple code from
> isl_ast_node_block. Is it fine for trunk?
2014-07-22 Roman Gareev
gcc/
* graphite-isl-ast-to-gimple.c:
(translate_isl_ast_node_block): New function.
(translate_isl_
On Wed, Jul 23, 2014 at 12:12 AM, Prathamesh Kulkarni
wrote:
> Would it be a good idea to allow multiple match_and_simplify within for ?
I see no good reason to disallow it.
Thus I have installed the patch.
Thanks,
Richard.
> * genmatch.c (parse_for): Adjust to parse multiple patterns.
>
> Tha
On Wed, Jul 23, 2014 at 12:27 AM, Prathamesh Kulkarni
wrote:
> I was displaying pattern = for debugging some issue related to
> implementing for-pattern, not meant for dumping with -v
> Removed accordingly.
>
> * genmatch.c (main): Remove unnecessary debug information.
Thanks - installed.
Richa
On Wed, Jul 23, 2014 at 2:09 AM, Prathamesh Kulkarni
wrote:
> This patch changes syntax of inner-if to be parenthesized - (if (cond))
>
> * genmatch.c (parse_match_and_simplify): Adjust to parse parenthesized if.
> (peek_ident): New function.
>
> * match.pd: Adjust patterns having if-expr to
On Wed, Jul 23, 2014 at 2:39 AM, Pengfei Yuan <0xcool...@gmail.com> wrote:
> In the experiment, about 60% (1019/1699) profile data files are empty
> (all counters are zero).
Well, but you are globally overriding options even for the parts with
profile. The whole point of profile-feedback is to ge
On 22/07/14 17:29, Ramana Radhakrishnan wrote:
On Mon, Jul 14, 2014 at 11:11 AM, Jiong Wang wrote:
currently the following testcases are disabled for arm target,
gcc.dg/ira-shrinkwrap-prep-1.c
gcc.dg/ira-shrinkwrap-prep-2.c
gcc.dg/pr10474.c
the reason is on arm target, register r3 is caller-
On 23/07/2014 11:13, Rainer Orth wrote:
Roman Gareev writes:
I've attached the patch, which contains generation of Gimple code from
isl_ast_node_block. Is it fine for trunk?
2014-07-22 Roman Gareev
gcc/
* graphite-isl-ast-to-gimple.c:
(translate_isl_ast_node_block
On Fri, Jul 18, 2014 at 3:08 AM, Trevor Saunders wrote:
> On Thu, Jul 17, 2014 at 06:36:31AM +0200, Andi Kleen wrote:
>> On Wed, Jul 16, 2014 at 10:40:53PM -0400, Trevor Saunders wrote:
>> >
>> > > + public:
>> > > +
>> > > + /* Start incremential hashing, optionally with SEED. */
>> > > + void
On Fri, Jul 18, 2014 at 5:39 PM, Horst Schirmeier wrote:
> Hi,
>
> when reading the gcc/opts.c sources, I noticed that the docs don't
> mention -ftree-loop-distribute-patterns along the other switches enabled
> with -O3.
>
> This documentation was missing since this option's introduction in SVN
>
On Mon, Jul 21, 2014 at 7:06 PM, Wei Mi wrote:
> Hi,
>
> This patch is to fix:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61776
>
> It records func decls whose const/pure flags are reset during
> instrumentation. After the loop resetting const/pure flags, find out
> stmts calling those recorde
On Sat, 12 Jul 2014, Ulrich Drepper wrote:
Ed's submission of the logistic regression distribution caused problems
for me because, like Ed, I have changes to the header in my
tree for a long time. Time to submit them.
This first one is a new distribution. It generates coordinates for
random
On 07/22/2014 01:53 PM, Ed Smith-Rowland wrote:
+ if (cxx_dialect < cxx1z)
+ {
+ /* Look for the `class' keyword. */
+ cp_parser_require_keyword (parser, RID_CLASS, RT_CLASS);
+ }
+ else
+ {
+ /* Look for the `class' or 'typename'
I have a release on file with the FSF, but don't have SVN write access.
Problem description:
asm_fprintf allows platforms to add support for new format specifiers by
using the ASM_FPRINTF_EXTENSIONS macro. ARM uses this to add support
for %@ and %r specifiers.
However, it isn't enough to add
On 23/07/14 11:58 +0200, Marc Glisse wrote:
* can't we end up dividing by 0 if all values of the normal
distribution happen to be 0?
As an aside, we already have divide-by-zero bugs in , it
would be nice if someone could look at that.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60037
On 07/22/2014 02:34 PM, Richard Biener wrote:
As discussed during the Cauldron keeping some builtin doesn't help because
you are not forced to access the newly created object via the pointer returned
by the placement new. That is,
template
struct Storage {
char x[sizeof(T)];
St
On 15/07/14 13:03 +0100, Jonathan Wakely wrote:
On 14/07/14 20:31 +0100, Jonathan Wakely wrote:
This adds printers for the types in the std::experimental namespace.
This should fix the test failures that Paolo and HJ are seeing, older
versions of GDB didn't have the gdb.Type.name attribute.
(
I guess some optimizations are controlled only by "optimize_size", not
by the profile.
Other optimizations are controlled by the profile.
So this patch does not have very much effectiveness (only 0.9% size reduction).
2014-07-23 17:26 GMT+08:00 Richard Biener :
> On Wed, Jul 23, 2014 at 2:39 AM, P
On Wed, Jul 23, 2014 at 12:44 PM, Jason Merrill wrote:
> On 07/22/2014 02:34 PM, Richard Biener wrote:
>>
>> As discussed during the Cauldron keeping some builtin doesn't help because
>>
>> you are not forced to access the newly created object via the pointer
>> returned
>> by the placement new.
On Wed, Jul 23, 2014 at 1:04 PM, Pengfei Yuan <0xcool...@gmail.com> wrote:
> I guess some optimizations are controlled only by "optimize_size", not
> by the profile.
I only see tree-inline.c:estimate_move_cost which we should indeed fix,
it could make a significant difference.
One other use in tr
Ping?
> Hello,
>
> in testing the rs6000 ABI patches I noted a weird effect: usually, the
> -Wpsabi warning notes are ignored in the compat test suites, so we get
> a clean test run anyway.
>
> However, when running the C++ version of the struct-layout-1.exp case
> *alone* (using RUNTESTFLAGS=s
The following patch makes us use profile-guided size/speed metrics
for MOVE_RATIO in estimate_move_cost. The estimate_num_insn
user update is obvious but the rest not exactly - I've choosen
size metrics everywhere but in ipa-cp.c:estimate_local_effects
(because there the result is used in some ti
Hi,
On Wed, Jul 23, 2014 at 11:51:37AM +0200, Richard Biener wrote:
> On Mon, Jul 21, 2014 at 7:06 PM, Wei Mi wrote:
> > Hi,
> >
> > This patch is to fix:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61776
> >
> > It records func decls whose const/pure flags are reset during
> > instrumentati
Hi,
>
> The following patch makes us use profile-guided size/speed metrics
> for MOVE_RATIO in estimate_move_cost. The estimate_num_insn
> user update is obvious but the rest not exactly - I've choosen
> size metrics everywhere but in ipa-cp.c:estimate_local_effects
> (because there the result is
> On Wed, Jul 23, 2014 at 2:39 AM, Pengfei Yuan <0xcool...@gmail.com> wrote:
> > In the experiment, about 60% (1019/1699) profile data files are empty
> > (all counters are zero).
>
> Well, but you are globally overriding options even for the parts with
> profile. The whole point of profile-feedb
Ping.
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00616.html
On 06/06/2014 05:07 PM, Bernd Schmidt wrote:
There's a problem when offloading from a compiler for one target machine
to another: the machine specific options don't necessarily match. This
patch tries to address this.
The idea is
> I guess some optimizations are controlled only by "optimize_size", not
> by the profile.
> Other optimizations are controlled by the profile.
> So this patch does not have very much effectiveness (only 0.9% size
> reduction).
0.9% size reduction counts as very much in compiler developers perspe
Hi!
In context of adding support for OpenACC, next to the existing
GIMPLE_OMP_TARGET (quoting from gcc/gimple.def and gcc/gimple.h):
DEFGSCODE(GIMPLE_OMP_TARGET, "gimple_omp_target", GSS_OMP_PARALLEL_LAYOUT)
/* GIMPLE_OMP_TARGET */
struct GTY((tag("GSS_OMP_PARALLEL_LAYOUT")))
g
Bultin macros like __FILE__, __DATE__, etc. had wrong locus - always
column 1. This patch fixes it by giving those macros location
of the expansion point, i.e, the location, where builtin macro is used.
It now also does the correct thing if we do e.g.
#define F __FILE__.
Bootstrapped/regtested on
Jakub reported to me that bounds-2.c test fails with
-fstack-protector-strong -Os. The following hack fixes it.
Tested x86_64-linux, applying to trunk as obvious.
2014-07-23 Marek Polacek
* c-c++-common/ubsan/bounds-2.c (fn4): Adjust to check the array size
in the structure.
Hi all!
This is a friendly reminder message.
On 07/17/2014 03:22 PM, Marat Zakirov wrote:
On 07/16/2014 01:32 PM, Kyrill Tkachov wrote:
On 16/07/14 10:22, Marat Zakirov wrote:
Christophe,
Please look at a new patch. Draft tests are OK.
I'll ask your commit approval when full regression (A
On 03/26/14 17:44, Teresa Johnson wrote:
Recently I discovered that the profile updates being performed by jump
threading were incorrect in many cases, particularly in the case where
the threading path contains a joiner. Some of the duplicated
blocks/edges were not getting any counts, leading to
On 07/16/14 12:41, Yi Yang wrote:
There are a few if statements in cfgrtl.c that are very fragile in the
sense that introducing an irrelevant edge flag breaks things.
This patch rewrites them to avoid such breakage.
--
2014-07-16 Yi Yang
gcc:
* cfgrtl.c (rtl_verify_edges, purge_dead_e
On 07/16/14 14:32, Xinliang David Li wrote:
Instrumentation based FDO is designed to work when the source files
that are used to generate the instr binary match exactly with the
sources in profile-use compile. It is known historically that using
stale profile (due to source changes, not gcda form
On 04/16/14 08:03, Ilya Enkovich wrote:
Hi,
This patch introduces changes in call graph for Pointer Bounds Checker.
New fields instrumented_version, instrumentation_clone and orig_decl are added
for cgraph_node:
- instrumentation_clone field is 1 for nodes created for instrumented version
o
On 07/21/14 09:47, Chen Gang wrote:
'asm_out_file' may be 'stdout', so need check this case before close it.
Or 'stdout' may be closed -- since need not open 'stdout', either need
not close it.
ChangLog:
* topleve.c (finalize): Avoid to close 'asm_out_file' when it is
'stdout'.
What exact
On 07/15/14 23:31, Andi Kleen wrote:
From: Andi Kleen
Again should not really change any behavior (except
for some minor differences with empty types)
gcc/:
2014-07-10 Andi Kleen
* tree.c (build_type_attribute_qual_variant): Use inchash.
(type_hash_list): Dito.
(at
On 07/15/14 23:31, Andi Kleen wrote:
From: Andi Kleen
Some files in gcc, like lto or tree, do large scale incremential hashing.
The current jhash implementation of this could be likely improved
by using an incremential hash that does not do a full rehashing
for every new value added.
This patc
On 07/15/14 23:31, Andi Kleen wrote:
From: Andi Kleen
Should not really change any behavior, it's just a more abstract
interface, but uses the same underlying hash functions.
lto/:
2014-07-10 Andi Kleen
* lto.c (hash_canonical_type): Convert to inchash.
(iterative_hash_can
On 07/15/14 23:31, Andi Kleen wrote:
From: Andi Kleen
No substantial changes, although the hash values will be slightly
different.
gcc/:
2014-07-10 Andi Kleen
* lto-streamer-out.c (hash_tree): Convert to inchash.
(add_flag): New macro.
So my question here, does this make a
On Wed, Jul 23, 2014 at 2:11 PM, Martin Jambor wrote:
> Hi,
>
> On Wed, Jul 23, 2014 at 11:51:37AM +0200, Richard Biener wrote:
>> On Mon, Jul 21, 2014 at 7:06 PM, Wei Mi wrote:
>> > Hi,
>> >
>> > This patch is to fix:
>> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61776
>> >
>> > It records f
On 07/07/2014 04:50 PM, Ilya Verbin wrote:
On 27 Jun 09:32, Bernd Schmidt wrote:
Sorry for the delayed reply, I was travelling. There seem to be some
thinkos in the configure script and Makefile; can you try the
following (don't forget to regenerate configure)? It seems to work
for ptx (with som
On Mon, Jul 14, 2014 at 4:57 AM, Kugan
wrote:
> On 11/07/14 22:47, Richard Biener wrote:
>> On Fri, Jul 11, 2014 at 1:52 PM, Kugan
>> wrote:
>>> Thanks foe the review and suggestions.
>>>
>>> On 10/07/14 22:15, Richard Biener wrote:
On Mon, Jul 7, 2014 at 8:55 AM, Kugan
wrote:
>>>
>>>
On Wed, Jul 23, 2014 at 5:40 AM, Jeff Law wrote:
> On 07/15/14 23:31, Andi Kleen wrote:
>>
>> From: Andi Kleen
>>
>> No substantial changes, although the hash values will be slightly
>> different.
>>
>> gcc/:
>>
>> 2014-07-10 Andi Kleen
>>
>> * lto-streamer-out.c (hash_tree): Convert t
Hi there!
I made a patch which fixes regressions on ARM platforms with disabled
unaligned accesses. The problem is that 'arm_vect_no_misalign' predicate
do not check 'unaligned_access' global variable to determine whether
unaligned access to vector are allowed. This leads to spurious vect.exp
> Btw, what will be the way to plug in an alternative hash function?
> That is, there doesn't seem to be a separation of interface
> and implementation in your patch (like with a template or a base-class
> you inherit from).
Just change the inchash.h include file. The point was to only
change a si
Braden,
Great work on this. In addition to helping with constraints there is at
least one new library feature that depends on constexpr variable templates.
For my two cents it would be good to get just the constexpr variable
templates, aka n3651, in now as a first stage - it's quite usable.
On 07/18/2014 05:38 PM, Jakub Jelinek wrote:
Do you error out on -fsanitize=thread -fsanitize=kernel-address ?
Perhaps -fsanitize=kernel-address -fsanitize=address should be invalid too?
Yes, all these combinations are invalid.
But you don't error out on that.
Ok, fixed.
Then in sanitize_
On Tue, Jul 22, 2014 at 09:40:15PM -0600, Jeff Law wrote:
> On 07/15/14 23:31, Andi Kleen wrote:
> >From: Andi Kleen
> >
> >No substantial changes, although the hash values will be slightly
> >different.
> >
> >gcc/:
> >
> >2014-07-10 Andi Kleen
> >
> > * lto-streamer-out.c (hash_tree): Con
On 23 Jul 16:16, Bernd Schmidt wrote:
> Here's the latest version, which fixes some more issues and removes
> things that are now unnecessary. Configure scripts and toplevel
> autogenned stuff is left out and must be regenerated.
>
> Are you OK with me installing this on gomp-4_0-branch? If there'
On 07/22/2014 12:27 PM, Yury Gribov wrote:
Attached patch delays generation of Asan memory checking
code until sanopt pass.
Here is an updated patch based on Jakub's review.
Bootstrapped and regtested on x64.
Yet another version with ASAN_CHECK changed to builtin function
(instead of internal
> On Tue, Jul 22, 2014 at 5:17 PM, Jan Hubicka wrote:
> >> I don't see why
> >>
> >> long x[1024];
> >>
> >> Q *q = new (x) Q;
> >> q->~Q ();
> >> new (x) T;
> >>
> >> would be invalid. I also don't see why
> >>
> >> Q q;
> >> q.~Q ();
> >> new (&q) T;
> >>
> >> would be. Object lifetime is prec
> But someday we'll want non-constexpr too. I have only seen a sentence
> somewhere stating that non-constexpr variable templates are allowed but have
> seen no paper or wording anywhere. Does anyone know where such exists?
When variable templates were proposed, EWG decided they wanted
non-conste
> On 07/15/14 23:31, Andi Kleen wrote:
> >From: Andi Kleen
> >
> >No substantial changes, although the hash values will be slightly
> >different.
> >
> >gcc/:
> >
> >2014-07-10 Andi Kleen
> >
> > * lto-streamer-out.c (hash_tree): Convert to inchash.
> > (add_flag): New macro.
> So my qu
I've attached the patch, which adds handling of isl_ast_op_pdiv_q and
isl_ast_op_pdiv_r. It also contains a corresponding test case, which
generates the following ISL AST:
{
for (int c1 = 0; c1 < -((-k.0 + i + 4294967296) % 4294967296) +
4294967296; c1 += 1)
S_4(c1);
S_6();
}
Is it fine f
If we try to generate code from the following ISL AST:
{
for (int c1 = 0; c1 < k.3; c1 += 1) {
S_21(c1);
S_21(c1);
S_4(c1);
for (int c3 = 0; c3 < pretmp; c3 += 1)
S_5(c1, c3);
S_7(c1);
S_26(c1);
S_8(c1);
S_8(c1);
S_9(c1);
for (int c3 = 0; c3 < pretmp
> gcc/
> * graphite-isl-ast-to-gimple.c:
> (translate_isl_ast_node_block): New function.
> (translate_isl_ast): Add calling of translate_isl_ast_node_block.
>
> gcc/testsuite/gcc.dg/graphite/
> * isl-ast-gen-blocks-1.c: New testcase.
> * isl-a
On 23 Jul 14:51, Bernd Schmidt wrote:
> Ping.
> https://gcc.gnu.org/ml/gcc-patches/2014-06/msg00616.html
>
> On 06/06/2014 05:07 PM, Bernd Schmidt wrote:
> >There's a problem when offloading from a compiler for one target machine
> >to another: the machine specific options don't necessarily matc
> I think we managed to
> stay bytecode compatible for 4.8 release series. (Richi knows better)
Nope, fortran options broke it at some point.
-Andi
--
a...@linux.intel.com -- Speaking for myself only.
On 23/07/2014 16:55, Roman Gareev wrote:
I've attached the patch, which adds handling of isl_ast_op_pdiv_q and
isl_ast_op_pdiv_r. It also contains a corresponding test case, which
generates the following ISL AST:
{
for (int c1 = 0; c1 < -((-k.0 + i + 4294967296) % 4294967296) +
4294967296; c1
On 23/07/2014 16:55, Roman Gareev wrote:
If we try to generate code from the following ISL AST:
{
for (int c1 = 0; c1 < k.3; c1 += 1) {
S_21(c1);
S_21(c1);
S_4(c1);
for (int c3 = 0; c3 < pretmp; c3 += 1)
S_5(c1, c3);
S_7(c1);
S_26(c1);
S_8(c1);
S
CCing Dodji, please, can you have a look? (I don't believe it is
caused by yours
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01063.html though,
this was wrong even in 4.8 and maybe earlier.)
On Wed, Jul 23, 2014 at 03:15:53PM +0200, Marek Polacek wrote:
> Bultin macros like __FILE__, __DATE__,
[Though Dodji is on a vacation for next two weeks, so if anyone else
can review this patch, it would be appreciated.]
On Wed, Jul 23, 2014 at 05:39:51PM +0200, Marek Polacek wrote:
> CCing Dodji, please, can you have a look? (I don't believe it is
> caused by yours
> https://gcc.gnu.org/ml/gcc-pa
On 22 July 2014 15:49, Jiong Wang wrote:
> gcc/
> * config/aarch64/aarch64.c (aarch64_save_or_restore_fprs): GNU-Stylize
> code.
> (aarch64_save_or_restore_callee_save_registers): Likewise.
> (aarch64_expand_prologue): Likewise
OK and applied.
/Marcus
On 22 July 2014 15:49, Jiong Wang wrote:
> gcc/
> * config/aarch64/aarch64.c (aarch64_save_or_restore_fprs): Change type to
> HOST_WIDE_INT.
OK and applied.
/Marcus
On 22 July 2014 15:49, Jiong Wang wrote:
> gcc/
> * config/aarch64/aarch64.c
> (aarch64_save_or_restore_callee_save_registers): Rename
> 'offset' to 'start_offset'. Remove local variable 'start_offset'.
OK and applied.
/Marcus
On July 23, 2014 5:15:53 PM CEST, Andi Kleen wrote:
>> I think we managed to
>> stay bytecode compatible for 4.8 release series. (Richi knows better)
>
>Nope, fortran options broke it at some point.
We try hard to not break things on branches or at least should bump the version
if we do. Maybe
> > I think we managed to
> > stay bytecode compatible for 4.8 release series. (Richi knows better)
>
> Nope, fortran options broke it at some point.
Duh, option streaming sucks, another things that ought to be fixed this release
cycle...
Honza
On Wed, Jul 23, 2014 at 06:00:35PM +0200, Richard Biener wrote:
> On July 23, 2014 5:15:53 PM CEST, Andi Kleen wrote:
> >> I think we managed to
> >> stay bytecode compatible for 4.8 release series. (Richi knows better)
> >
> >Nope, fortran options broke it at some point.
>
> We try hard to not b
On 22 July 2014 15:50, Jiong Wang wrote:
> gcc/
> * config/aarch64/aarch64.c (aarch64_save_or_restore_fprs): Remove
> base_rtx.
> (aarch64_save_or_restore_callee_save_registers): Likewise.
OK and applied.
/Marcus
On 22 July 2014 15:51, Jiong Wang wrote:
> gcc/
> * config/aarch64/aarch64.c (aarch64_save_or_restore_fprs): Use register
> offset in
> cfun->machine->frame.reg_offset.
> (aarch64_save_or_restore_callee_save_registers): Likewise.
OK and applied.
/Marcus
On 22 July 2014 15:51, Jiong Wang wrote:
> gcc/
> * config/aarch64/aarch64.c (aarch64_save_or_restore_fprs): Remove
> "increment".
> (aarch64_save_or_restore_callee_save_registers): Likewise.
OK and applied.
/Marcus
On 22 July 2014 15:51, Jiong Wang wrote:
> gcc/
> * config/aarch64/aarch64.c (aarch64_save_or_restore_fprs): Hoist
> calculation
> of register rtx.
> (aarch64_save_or_restore_callee_save_registers): Likewise.
OK and applied.
/Marcus
On 22 July 2014 15:51, Jiong Wang wrote:
> gcc/
> * config/aarch64/aarch64.c (aarch64_next_callee_save): New function.
> (aarch64_save_or_restore_fprs): Use aarch64_next_callee_save.
> (aarch64_save_or_restore_callee_save_registers): Likewise.
OK and applied.
/Marcus
On 22 July 2014 15:51, Jiong Wang wrote:
> * config/aarch64/aarch64.c (aarch64_gen_store_pair): New helper function.
> (aarch64_gen_load_pair): Likewise.
> (aarch64_save_or_restore_fprs): Use new helper functions.
> (aarch64_save_or_restore_callee_save_registers): Likewise.
OK and applie
On 22 July 2014 15:51, Jiong Wang wrote:
> * config/aarch64/aarch64.c (aarch64_save_or_restore_fprs): Deleted.
> (aarch64_save_callee_saves): New function to handle reg save
> for both core and vectore regs.
OK and applied
/Marcus
On 22 July 2014 15:51, Jiong Wang wrote:
> * config/aarch64/aarch64.md: (aarch64_save_or_restore_callee_saves):
> Rename to aarch64_save_callee_saves, remove restore code.
> (aarch64_restore_callee_saves): New function.
OK and applied.
/Marcus
On July 23, 2014 4:42:22 PM CEST, Jan Hubicka wrote:
>> On Tue, Jul 22, 2014 at 5:17 PM, Jan Hubicka wrote:
>> >> I don't see why
>> >>
>> >> long x[1024];
>> >>
>> >> Q *q = new (x) Q;
>> >> q->~Q ();
>> >> new (x) T;
>> >>
>> >> would be invalid. I also don't see why
>> >>
>> >> Q q;
>> >> q.~
On 22 July 2014 15:51, Jiong Wang wrote:
> This patch simplify aarch64_expand_prologue using our new
> helper functions. All ad-hoc code for saving FP/LR are removed.
>
> *no functional change*
I think you mean no change in generated code rather than no functional change...
> gcc/
> * config/
> On July 23, 2014 4:42:22 PM CEST, Jan Hubicka wrote:
> >> On Tue, Jul 22, 2014 at 5:17 PM, Jan Hubicka wrote:
> >> >> I don't see why
> >> >>
> >> >> long x[1024];
> >> >>
> >> >> Q *q = new (x) Q;
> >> >> q->~Q ();
> >> >> new (x) T;
> >> >>
> >> >> would be invalid. I also don't see why
> >>
On 22 July 2014 15:51, Jiong Wang wrote:
> gcc/
> * config/aarch64/aarch64.c (aarch64_gen_loadwb_pair): New helper function.
> (aarch64_popwb_pair_reg): Likewise.
> (aarch64_expand_epilogue): Simplify code using new helper functions.
ChangeLog entry is missing the .md file hunk. Otherwise
On Wed, Jul 23, 2014 at 04:21:59PM +0200, Richard Biener wrote:
> On Wed, Jul 23, 2014 at 5:40 AM, Jeff Law wrote:
> > On 07/15/14 23:31, Andi Kleen wrote:
> >>
> >> From: Andi Kleen
> >>
> >> No substantial changes, although the hash values will be slightly
> >> different.
> >>
> >> gcc/:
> >>
>
On Tue, Jul 22, 2014 at 8:14 PM, Jeff Law wrote:
> On 07/16/14 14:32, Xinliang David Li wrote:
>>
>> Instrumentation based FDO is designed to work when the source files
>> that are used to generate the instr binary match exactly with the
>> sources in profile-use compile. It is known historically
On Thu, Jul 17, 2014 at 02:40:27AM -0600, Jeff Law wrote:
> I was really hoping someone could add tests from the old (2004?) thread
> between DJ and Per to ensure we weren't regressing any of those cases while
> fixing 57653. In fact, I think I'd pre-approved with those tests added ;-)
All I coul
yes -- I am thinking about this and other better hash functions.
Changing it to 64bit will cause profile format change and increase in
profile data size.
David
On Wed, Jul 23, 2014 at 10:52 AM, Yi Yang wrote:
> It's worth noting that merely changing the hash function from crc32 to
> something th
On July 23, 2014 4:27:43 PM CEST, Andi Kleen wrote:
>> Btw, what will be the way to plug in an alternative hash function?
>> That is, there doesn't seem to be a separation of interface
>> and implementation in your patch (like with a template or a
>base-class
>> you inherit from).
>
>Just change t
It's worth noting that merely changing the hash function from crc32 to
something that's 64 bit long is enough to make sure collisions does
not happen. Maybe it's worth the trouble?
On Wed, Jul 23, 2014 at 10:42 AM, Xinliang David Li wrote:
>
> On Tue, Jul 22, 2014 at 8:14 PM, Jeff Law wrote:
> >
>
> I don't think existing profile data matter.
>
> For perfect fresh profile, using external id has the chance of
> collision. I have tested with a C++ symbol file with about 750k unique
> symbol names, using crc32 based id yields 71 collisions --- the rate
> is ~0.009%.
init_node_map will reso
> So there will be at most one hash implementation?
One per binary I expect. Modern hash functions are pretty good,
so it's unlikely that someone needs to come up with special
purpose hashes.
I found Bob Jenkins' spooky is rather good for this case (very
large incremential keys), but it is only
> > Why didn't you replace the tree.c uses BTW?
>
> Patches were already quite big, but I'll add it.
Actually I handled them all in tree.c. Did you
mean something else?
I didn't convert all of tree-ssa-* and dwarf* so far,
and a few other places. This can be done step by step.
-Andi
On Wed, 2014-07-16 at 11:23 +0200, Jakub Jelinek wrote:
> On Wed, Jul 16, 2014 at 05:18:06AM -0400, David Edelsohn wrote:
> > This seems weird. Why wasn't this file included before or whenever it
> > was added for other *-linux targets? This seems to define SPECs that
> > should have been necessa
On Tue, Jul 22, 2014 at 04:20:04PM +0200, Richard Biener wrote:
> On Tue, Jul 22, 2014 at 4:15 PM, Yury Gribov wrote:
> > On 07/22/2014 05:57 PM, Richard Biener wrote:
> >>>
> >>> I probably could
> >>> provide fnspec with (EAF_DIRECT | EAF_NOCLOBBER | EAF_NOESCAPE) or
> >>> even EAF_UNUSED for th
On 27/06/2014 21:48, Paolo Carlini wrote:
Hi,
On 06/27/2014 07:33 PM, Jonathan Wakely wrote:
I didn't see an obvious fix (I'm not sure if the templated constructor
can deduce its argument since the change) but have been out all day
and not had a chance to look into it.
Ok, thanks. I'm revertin
AFDO invokes cgraph_node_for_asm during VPT to get the cgraph node for
a callee. Use the resolved node so we don't add a reference to the
un-resolved node after LIPO fixup.
Passes regression tests and internal test. Ok for google/4_9?
Thanks,
Teresa
2014-07-23 Teresa Johnson
Google r
ok.
David
On Wed, Jul 23, 2014 at 1:46 PM, Teresa Johnson wrote:
> AFDO invokes cgraph_node_for_asm during VPT to get the cgraph node for
> a callee. Use the resolved node so we don't add a reference to the
> un-resolved node after LIPO fixup.
>
> Passes regression tests and internal test. Ok fo
On Tue, Jul 22, 2014 at 7:29 PM, Jeff Law wrote:
> On 03/26/14 17:44, Teresa Johnson wrote:
>>
>> Recently I discovered that the profile updates being performed by jump
>> threading were incorrect in many cases, particularly in the case where
>> the threading path contains a joiner. Some of the du
1 - 100 of 119 matches
Mail list logo
