-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of bin.cheng
Sent: Friday, September 27, 2013 1:07 PM
To: 'Richard Biener'
Cc: GCC Patches
Subject: RE: [PATCH]Fix computation of offset in ivopt
-Original
On Thu, Sep 26, 2013 at 9:35 PM, Aldy Hernandez al...@redhat.com wrote:
+ /* To distinguish from an OpenMP simd clone, Cilk Plus functions to
+ be cloned have a distinctive artificial label in addition to omp
+ declare simd. */
+ bool cilk_clone = flag_enable_cilkplus
+
On Fri, Sep 27, 2013 at 12:23 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
builtin_expect should be a NOP in size_estimation. Indeed, the call
stmt itself is 0 weight in size and time. But it may introduce
an extra relation expr which has non-zero size/time. The end result
is: for w/ and w/o
On Fri, Sep 27, 2013 at 7:07 AM, bin.cheng bin.ch...@arm.com wrote:
-Original Message-
From: Richard Biener [mailto:richard.guent...@gmail.com]
Sent: Tuesday, September 24, 2013 6:31 PM
To: Bin Cheng
Cc: GCC Patches
Subject: Re: [PATCH]Fix computation of offset in ivopt
On Tue,
Sure, but the modifier is not meant to force something into memory,
especially when it is already in an register. Remember, we are only
talking of structures here, and we only want to access one member.
It is more the other way round:
It says: You do not have to load the value in a
They don't need to be kept synchronised as such. It's fine for the index
to allow more than must_be_index_p. But if you're not keen on the current
structure, does the following look better? Tested on x86_64-linux-gnu.
Thanks,
Richard
gcc/
* rtlanal.c (must_be_base_p,
Thanks for the testing. It also passes bootstrap on x86_64-linux-gnu.
OK to install?
Yes, thanks.
--
Eric Botcazou
On Thu, Sep 26, 2013 at 6:07 PM, Andrew MacLeod amacl...@redhat.com wrote:
On 09/25/2013 04:49 AM, Richard Biener wrote:
On Tue, Sep 24, 2013 at 4:39 PM, Andrew MacLeod amacl...@redhat.com
wrote:
This larger patch moves all the immediate use and operand routines from
tree-flow.h into
below is a trivial patch, which makes both parts of test signed.
With this, bootstrap completes on powerpc-darwin9 - however, you might want
to check that it still does what you intended.
Please install under PR middle-end/58547 if not already done.
--
Eric Botcazou
Hi Mike,
I must say though, it seems wrong to have to provide a sign-extend pointer
pattern when pointers (on the MSP430) are unsigned.
Agreed. If we instead ask, is it sane for gcc to ever want to signed extend in
this case, the answer appears to be no. Why does it, ptr_mode is SImode,
Like the following.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
2013-09-26 Richard Biener rguent...@suse.de
* alias.h (component_uses_parent_alias_set): Rename to ...
(component_uses_parent_alias_set_from): ... this.
* alias.c
Let's CC Vladimir on this easy one.
Cheers.
Jan-Benedict Glaw jbg...@lug-owl.de a écrit:
On Fri, 2013-09-20 20:51:37 +0200, Jan-Benedict Glaw jbg...@lug-owl.de
wrote:
Hi!
With the VAX target, I see this warning:
g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions
Hi,
this is second part of the generic tuning changes sanityzing the tuning flags.
This patch again is supposed to deal with the obvious part only.
I will send separate patch for more changes.
The flags changed agree on all CPUs considered for generic (and their
optimization manuals) + amdfam10,
On 27 September 2013 03:15, Tim Shen wrote:
POSIX ERE says that escaping an ordinary char, say R\n is not
permitted, because 'n' is not a special char. However, they also say
that : Implementations are permitted to extend the language to allow
these. Conforming applications cannot use such
On 27 September 2013 05:17, Ed Smith-Rowland wrote:
The complex user-defined literals finally passed (n3779) with the resolution
to DR1473 allowing the suffix id to touch the quotes (Can't find it but I
put it in not too long ago).
I think it's been approved by the LWG and looks like it will
On Fri, Sep 27, 2013 at 01:48:36AM +0200, Jakub Jelinek wrote:
Perhaps. What if I do just minor cleanup (use flexible array members for
the reallocated vectors, and perhaps keep only the last out/inout task
in the hash table chains rather than all of them), retest, commit and then
we can
Gary Benson wrote:
Hi all,
This is a resubmission of my previous demangler fix [1] rewritten
to avoid using hashtables and other libiberty features.
From the above referenced email:
d_print_comp maintains a certain amount of scope across calls (namely
a stack of templates) which is
Hi,
this fixes the ICE during the build of the Ada runtime on the SPARC, a fallout
of the recent inliner changes:
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01033.html
The ICE is triggered because the ldd peephole merges an MEM with MEM_NOTRAP_P
and a contiguous MEM without MEM_NOTRAP_P,
On 9/27/13 4:34 AM, Jonathan Wakely wrote:
On 27 September 2013 03:15, Tim Shen wrote:
POSIX ERE says that escaping an ordinary char, say R\n is not
permitted, because 'n' is not a special char. However, they also say
that : Implementations are permitted to extend the language to allow
these.
On 09/27/13 03:18, Richard Biener wrote:
On Thu, Sep 26, 2013 at 9:35 PM, Aldy Hernandez al...@redhat.com wrote:
+ /* To distinguish from an OpenMP simd clone, Cilk Plus functions to
+ be cloned have a distinctive artificial label in addition to omp
+ declare simd. */
+ bool
On 27 September 2013 13:32, Paolo Carlini wrote:
On 9/27/13 4:34 AM, Jonathan Wakely wrote:
On 27 September 2013 03:15, Tim Shen wrote:
POSIX ERE says that escaping an ordinary char, say R\n is not
permitted, because 'n' is not a special char. However, they also say
that : Implementations
Hi!
I've committed the following fix to a regression introduced in 4.9
early loop construction. SESE regions, as documented above
move_sese_region_to_fn, are allowed to contain calls to noreturn functions
like abort/exit. But, basic blocks leading to noreturn functions aren't
actually placed in
PR libstdc++/57465
* include/std/functional
(_Function_base::_Base_manager::_M_not_empty_function): Fix overload
for pointers.
* testsuite/20_util/function/cons/57465.cc: New.
Tested x86_64-linux, committed to trunk. I'll apply it to the
branches after
Hi all,
I've recently submitted a bug report regarding invalid unpoisoning of
stack frame redzones
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58543). Could someone take
a look at proposed patch (a simple one-liner) and check whether it's ok
for commit?
Thanks!
-Yuri
diff --git
On Thu, Sep 26, 2013 at 3:02 PM, Jan Hubicka hubi...@ucw.cz wrote:
Why not just have probably_never_executed_bb_p return simply return
false bb-frequency is non-zero (right now it does the opposite -
We want to have frequencies guessed for functions that was not trained
in the profiling run
On Thu, Sep 26, 2013 at 02:31:33PM -0500, Aldy Hernandez wrote:
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -42806,6 +42806,43 @@ ix86_memmodel_check (unsigned HOST_WIDE_INT val)
return val;
}
+/* Return the default vector mangling ISA code when none is specified
+
On Fri, Sep 27, 2013 at 06:10:41PM +0400, Yury Gribov wrote:
Hi all,
I've recently submitted a bug report regarding invalid unpoisoning
of stack frame redzones
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58543). Could someone
take a look at proposed patch (a simple one-liner) and check
Hi,
this patch makes it possible to access value range info from setmem/movstr that
I plan to use in i386 memcpy/memset expansion code. It is all quite
straighforward except that I need to deal with cases where max size does not
fit in HOST_WIDE_INT where I use maximal value as a marker. It is
On Fri, Sep 27, 2013 at 1:56 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
this is second part of the generic tuning changes sanityzing the tuning flags.
This patch again is supposed to deal with the obvious part only.
I will send separate patch for more changes.
The flags changed agree on all
On 13-09-27 4:55 AM, Dodji Seketeli wrote:
Let's CC Vladimir on this easy one.
Cheers.
All targets I know have ELIMINABLE_REGS defined. Therefore it was not
caught before.
.
The patch is ok for me. Thanks.
Jan-Benedict Glaw jbg...@lug-owl.de a écrit:
On Fri, 2013-09-20 20:51:37 +0200,
On 09/27/2013 08:42 AM, James Greenhalgh wrote:
On Thu, Sep 26, 2013 at 04:26:35AM +0100, Jeff Law wrote:
Bootstrapped and regression tested on x86_64-unknown-linux-gnu.
Installed on trunk.
Hi Jeff,
This patch caused a regression on Arm and AArch64 in:
PASS-FAIL:
On Fri, Sep 27, 2013 at 1:56 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
this is second part of the generic tuning changes sanityzing the tuning
flags.
This patch again is supposed to deal with the obvious part only.
I will send separate patch for more changes.
The flags changed
Nice extension. Test cases would be great to have.
thanks,
David
On Fri, Sep 27, 2013 at 7:50 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
this patch makes it possible to access value range info from setmem/movstr
that
I plan to use in i386 memcpy/memset expansion code. It is all quite
On Fri, Sep 27, 2013 at 8:36 AM, Jan Hubicka hubi...@ucw.cz wrote:
On Fri, Sep 27, 2013 at 1:56 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
this is second part of the generic tuning changes sanityzing the tuning
flags.
This patch again is supposed to deal with the obvious part only.
I
On Thu, 2013-09-26 at 14:47 +0100, Marcus Shawcroft wrote:
I'm in two minds about whether further sticky tape of this form is the
right approach or whether the original patch should be reverted until a
proper fix that does not regress the tree can be found.
Thoughts?
2013-09-26 Marcus
The gimple builder no longer support normal form. The ssa_mode
enum is not needed now.
Committed to trunk.
* gimple.h (enum ssa_mode): Remove.
---
gcc/gimple.h | 9 -
1 file changed, 9 deletions(-)
diff --git a/gcc/gimple.h b/gcc/gimple.h
index 3047ab4..a031c8d 100644
---
Hi,
sorry it took me so long, but it also took me quite a while to chew
through. Please consider posting context diff in cases like this.
Nevertheless, most of the patch is a nice improvement.
On Wed, Sep 25, 2013 at 12:20:50PM +0200, Jan Hubicka wrote:
Hi,
this is updated version of
On Fri, Sep 27, 2013 at 04:32:10PM +0100, Jeff Law wrote:
If you could pass along a .i file it'd be helpful in case I want to look
at something under the debugger.
I've opened http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58553 to save
everyone's inboxes.
Let me know if I can do anything else
On 09/27/2013 10:48 AM, James Greenhalgh wrote:
On Fri, Sep 27, 2013 at 04:32:10PM +0100, Jeff Law wrote:
If you could pass along a .i file it'd be helpful in case I want to look
at something under the debugger.
I've opened http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58553 to save
everyone's
On Fri, Sep 27, 2013 at 1:20 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Fri, Sep 27, 2013 at 12:23 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
builtin_expect should be a NOP in size_estimation. Indeed, the call
stmt itself is 0 weight in size and time. But it may introduce
an
On 09/27/13 09:23, Jakub Jelinek wrote:
On Thu, Sep 26, 2013 at 02:31:33PM -0500, Aldy Hernandez wrote:
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -42806,6 +42806,43 @@ ix86_memmodel_check (unsigned HOST_WIDE_INT val)
return val;
}
+/* Return the default vector mangling
Please review the changes.html change and suggest better wordings if possible:
ndex: htdocs/gcc-4.9/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v
retrieving revision 1.26
diff -u -r1.26 changes.html
---
The Go standard library has an interesting function named
reflect.MakeFunc. It takes a Go function F that accepts and returns a
slice of reflect.Value, and a function type T, and returns a pointer to
a function of type T that converts its arguments to reflect.Value, calls
F, and converts the
On Thu, Sep 26, 2013 at 3:23 PM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
builtin_expect should be a NOP in size_estimation. Indeed, the call
stmt itself is 0 weight in size and time. But it may introduce
an extra relation expr which has non-zero size/time. The end result
is: for w/ and w/o
On Sep 27, 2013, at 1:48 AM, nick clifton ni...@redhat.com wrote:
OK by me, although I cannot approve that particular patch.
I know, the intent is for someone that can, to approve it.
But I ran into a very strange problem. With your PARTIAL_INT_MODE_NAME patch
applied GCC started
Can the sh people weigh in on this? Are the PSI and PDI precisions 32 and 64?
On Sep 17, 2013, at 10:24 AM, Mike Stump mikest...@comcast.net wrote:
On Sep 16, 2013, at 8:41 PM, DJ Delorie d...@redhat.com wrote:
m32c's PSImode is 24-bits, why does it have 32 in the macro?
/* 24-bit pointers,
David and Rong,
The following patch will disable -g/-gmlt when instrumenting for LIPO
since they will affect the recorded ggc_memory used in the module
grouping decision. Added -fripa-allow-debug to override this behavior.
Passes regression tests and simple tests on the new functionality.
Ok
On Fri, Sep 27, 2013 at 11:50 AM, Teresa Johnson tejohn...@google.com wrote:
David and Rong,
The following patch will disable -g/-gmlt when instrumenting for LIPO
since they will affect the recorded ggc_memory used in the module
grouping decision. Added -fripa-allow-debug to override this
Hi Tom,
On Mon, 23 Sep 2013, Tom Tromey wrote:
This adds the configury needed for automatic dependency tracking. It
also adds some bits to the Makefile so we can begin converting
(removing) explicit dependencies.
* Makefile.in (CCDEPMODE, DEPDIR, depcomp, COMPILE.base)
Hello,
a format string in the example for DATE_AND_TIME contained a syntax
error. Committed as obvious.
2013-09-27 Janne Blomqvist j...@gcc.gnu.org
* intrinsic.texi (DATE_AND_TIME): Fix example.
Index: intrinsic.texi
===
Jan Hubicka hubi...@ucw.cz writes:
I also added X86_TUNE_SSE_UNALIGNED_STORE_OPTIMAL to bobcat tuning, since it
seems like obvious omision (after double checking in optimization manual) and
droped X86_TUNE_FOUR_JUMP_LIMIT for buldozer cores.
When tuning for Intel SandyBridge+ it would be
On Fri, Sep 27, 2013 at 12:01 PM, Xinliang David Li davi...@google.com wrote:
On Fri, Sep 27, 2013 at 11:50 AM, Teresa Johnson tejohn...@google.com wrote:
David and Rong,
The following patch will disable -g/-gmlt when instrumenting for LIPO
since they will affect the recorded ggc_memory used
ok.
David
On Fri, Sep 27, 2013 at 1:03 PM, Teresa Johnson tejohn...@google.com wrote:
On Fri, Sep 27, 2013 at 12:01 PM, Xinliang David Li davi...@google.com
wrote:
On Fri, Sep 27, 2013 at 11:50 AM, Teresa Johnson tejohn...@google.com
wrote:
David and Rong,
The following patch will
I don't quite understand here. We use the profile-generate memory
consumption to estimate the profile use memory consumption.
we still have -g/-gmlt in profile-use compilation. Will this change
effectively under estimate the memory use in the use phrase?
-Rong
On Fri, Sep 27, 2013 at 11:50 AM,
On Fri, Sep 27, 2013 at 9:37 AM, Jonathan Wakely jwakely@gmail.com wrote:
Ah I see. I definitely agree it's good to accept that instead of
being unnecessarily strict, but other people will want the option of
strict conformance, so I think we can please everyone with something
like:
else
The issue is that building the instrumented binary with and without,
say, -gmlt, may result in different module grouping.
Teresa
On Fri, Sep 27, 2013 at 1:18 PM, Rong Xu x...@google.com wrote:
I don't quite understand here. We use the profile-generate memory
consumption to estimate the profile
The key is that grouping results should not dependent on the presence
of -g flags. The downside of the patch is that it may slightly
underestimate the memory pressure at profile-use time, but that should
not be a big problem.
David
On Fri, Sep 27, 2013 at 1:18 PM, Rong Xu x...@google.com wrote:
Gerald And looking at the code, I see
Gerald +COMPILE.base = $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS)
-o $@
[...]
Gerald Where does $(ALL_COMPILERFLAGS) compile from?
Look a little further down in the patch:
.cc.o .c.o:
- $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $
Hi
Tim Shen timshe...@gmail.com ha scritto:
Do I need to bootstrap again?
Nah, only double check that the testcase you are un-xfail-ing uses
-std=gnu++11, otherwise will not pass ;)
Paolo
On Thu, Sep 26, 2013 at 3:27 PM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
Current default probably for builtin_expect is 0.9996.
This makes the freq of unlikely bb very low (4), which
suppresses the inlining of any calls within those bb.
We used FDO data to measure the branch probably for
the
Following up on my earlier patch, this patch implements the
reflect.MakeFunc function for 386.
Tom Tromey pointed out to me that the libffi closure support can
probably be used for this. I was not aware of that support. It
supports a lot more processors, and I should probably start using it.
This patch increases comdat-sharing-probability to 80 under -Os. This
reduces the amount of inlining and helps internal benchmarks.
Unfortunately, this causes slight regression on spec 2006. Ok for
google branches if all tests pass?
- Easwaran
comdat_sharing.patch
Description: Binary data
I realized that in the amd64 implementation of MakeFunc I forgot that
it's not OK to just take the address of a value on the stack, since the
function might hang onto the address. The value needs to be copied onto
the heap first. This patch implements that. Bootstrapped and ran Go
testsuite on
I've merged revision 202996 from the GCC 4.8 branch to the gccgo branch.
Ian
Hi,
Current default probability for builtin_expect is 0.9996.
This makes the freq of unlikely bb very low (4), which
suppresses the inlining of any calls within those bb.
We used FDO data to measure the branch probably for
the branch annotated with builtin_expert.
For google internal
Hi,
builtin_expect should be a NOP in size_estimation. Indeed, the call
stmt itself is 0 weight in size and time. But it may introduce
an extra relation expr which has non-zero size/time. The end result
is: for w/ and w/o builtin_expect, we have different size/time estimation
for inlining.
This
d.growth -= (info-size
* (100 - PARAM_VALUE (PARAM_COMDAT_SHARING_PROBABILITY))
+ 50) / 100;
What is the purpose of '50' here?
The patch is fine for Google branch.
Other tunings to think about -- I think the sharing probability should
not be a fixed value -- but depending on the
On Fri, Sep 27, 2013 at 4:08 PM, Xinliang David Li davi...@google.com wrote:
d.growth -= (info-size
* (100 - PARAM_VALUE (PARAM_COMDAT_SHARING_PROBABILITY))
+ 50) / 100;
What is the purpose of '50' here?
Rounding after division by 100.
The patch is fine for Google branch.
Other
The current GCC vectorizer requires the following pattern as a simple
reduction computation:
loop_header:
a1 = phi a0, a2
a3 = ...
a2 = operation (a3, a1)
But a3 can also be defined outside of the loop. For example, the
following loop can benefit from vectorization but the
Here is the latest version of my -fstrict-volatile-bitfields patches.
I have gone ahead and committed part 1 of the previous version of this
patch series, which was approved back in mid-June. That part just
removes the warning about conflicts with packed structs (which everybody
seemed to
This patch fixes various -fstrict-volatile-bitfields wrong-code bugs,
including instances where bitfield values were being quietly truncated
as well as bugs relating to using the wrong width. The code changes are
identical to those in the previous version of this patch series
(originally
This patch makes -fstrict-volatile-bitfields not be the default on any
target. It is unchanged from part 4 of the previous version (v3) of
this patch set that I originally posted back in June and have been
re-pinging many times since then.
Some reviewers of my original patch series argued
72 matches
Mail list logo
