Ping. Original message was here:
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01267.html
Richard Sandiford writes:
> My patch to reduce the amount of rtx garbage created:
>
> 2014-05-17 Richard Sandiford
>
> * emit-rtl.h (replace_equiv_address, replace_equiv_address_nv): Add an
>
Ping. Originaly message was here:
https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01113.html
Richard Sandiford writes:
> Richard Sandiford writes:
>> Jan Hubicka writes:
>>> Hi,
>>
>>> IRA initialization shows high in profiles even when building lto
>>> objects. This patch simply delays RTL
This second patch cleans up some more global names. the three functions should
not be visible to the user. I'm not sure if they're attempting to export an
interface to the user but they're (a) undocumented and (b) don't follow existing
gcov naming.
I'm a little confused as to why the gcov li
Hi!
On Thu, 24 Jul 2014 01:47:09 +0200, Bernd Schmidt
wrote:
> (git doesn't seem to produce something
> nice for the renames unfortunately)
Are you maybe looking for the the -M or -C options to certain commands
(diff, show, ...)?
Grüße,
Thomas
pgpmCctHzScdm.pgp
Description: PGP signature
On 07/24/2014 12:09 AM, Jakub Jelinek wrote:
Ah internal fns. Those cannot have attributes indeed (technical
limitation).
Martin was working on putting those flags elsewhere (cgraph, though internal
functions don't have cgraph nodes either ...). Maybe it was a bad idea to use
internal funct
On Wed, Jul 23, 2014 at 9:10 PM, Hongxu Jia wrote:
> 1. How to reproduce the issue:
>
> 1) manually modify gcc/Makefile.in to delay the generation of config.h:
> ...
> diff --git gcc-4.9.0/gcc/Makefile.in gcc-4.9.0/gcc/Makefile.in
> --- gcc-4.9.0/gcc/Makefile.in
> +++ gcc-4.9.0/gcc/Makefile.in
> @
1. How to reproduce the issue:
1) manually modify gcc/Makefile.in to delay the generation of config.h:
...
diff --git gcc-4.9.0/gcc/Makefile.in gcc-4.9.0/gcc/Makefile.in
--- gcc-4.9.0/gcc/Makefile.in
+++ gcc-4.9.0/gcc/Makefile.in
@@ -1622,9 +1622,12 @@ tm.h: cs-tm.h ; @true
tm_p.h: cs-tm_p.h ; @t
On 07/23/2014 06:05 AM, Jason Merrill wrote:
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
There are more.
In toplev.c:
/* One region RA really helps to decrease the code size. */
if (flag_ira_region == IRA_REGION_AUTODETECT)
flag_ira_region
= optimize_size || !optimize ? IRA_REGION_ONE : IRA_REGION_MIXED;
In config/i386/i386.c:
* Assignment of ix86_cost
* Decision o
On Thu, Jul 24, 2014 at 02:00:24AM +0200, Oleg Endo wrote:
> On Wed, 2014-07-23 at 11:37 +0200, Richard Biener wrote:
> > 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,
On 07/11/2014 03:29 AM, Jakub Jelinek wrote:
> On Fri, Jul 11, 2014 at 12:11:10PM +0200, Thomas Schwinge wrote:
>> To avoid duplication of work: with Jakub's Fortran OpenMP 4 target
>> changes recently committed to trunk, and now merged into gomp-4_0-branch,
>> I have trimmed down Ilmir's patch to
On Tue, 2014-07-22 16:40:31 -0400, Hans-Peter Nilsson wrote:
> In the name of "dealing with the fallout": with the patch below
> (don't forget to re-generate configure) I get build errors in
> generic code r212915 for *both* x86_64 "gcc version 4.7.2
> 20120921 (Red Hat 4.7.2-2) (GCC)" for mmix-kn
On Wed, 2014-07-23 at 11:37 +0200, Richard Biener wrote:
> 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:
> >> > > +
> >> > >
On Wed, Jul 23, 2014 at 4:47 PM, Bernd Schmidt wrote:
> This is an idea I discussed with a few folks at the Cauldron, and since they
> made supportive noises, I decided to work on it. The problem I'm trying to
> solve is that for ptx, I'll have to mark a lot of testcases as unsupported
> (uses of
This is an idea I discussed with a few folks at the Cauldron, and since
they made supportive noises, I decided to work on it. The problem I'm
trying to solve is that for ptx, I'll have to mark a lot of testcases as
unsupported (uses of things such as indirect jumps, alloca, and
sometimes K&R-st
On Mon, Mar 24, 2014 at 12:32 PM, Jonathan Wakely wrote:
> On 24/03/14 20:20 +0100, Jakub Jelinek wrote:
>>
>> Hi!
>>
>> This patch updates baseline_symbols.txt to what I've grabbed from trunk
>> builds as of today on various targets. Verified the additions are the
>> same (just sizes of some obj
On 07/23/2014 11:44 AM, Jeff Law wrote:
> 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
On Jul 23, 2014, at 4:42 AM, Ulrich Weigand wrote:
> Ping?
Ok.
>> 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++ versio
On Wed, Jul 23, 2014 at 11:06 AM, Jan Hubicka 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 coll
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
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
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
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
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 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
> > 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
> 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
>
> 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
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:
> >
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
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 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
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 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 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 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:
> 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
>> >>
>> >> Q q;
>> >> q.~
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 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.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:
> 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:
> 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_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): 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: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 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
> > 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 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
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 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_fprs): GNU-Stylize
> code.
> (aarch64_save_or_restore_callee_save_registers): Likewise.
> (aarch64_expand_prologue): Likewise
OK and applied.
/Marcus
[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
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__,
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
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
> 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 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
> 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
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
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
> 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
> 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 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
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 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 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 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_
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.
> 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
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
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
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 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 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/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 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
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
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/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 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/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 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 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
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
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.
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
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
> 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
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
> 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
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
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
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
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
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
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.
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 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.
(
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
1 - 100 of 119 matches
Mail list logo
