The first part is obsolete since r91570 at least, for the second part about
MEM_KEEP_ALIAS_SET_P it's more recent.
Tested on x86_64-suse-linux, applied on the mainline.
2013-09-26 Eric Botcazou ebotca...@adacore.com
* expr.c (expand_assignment): Remove obsolete comment.
--
Eric
Hi,
This is the updated patch for expanding gimple stmts without zer/sign
extensions when it is safe to do that. This is based on the
latest changes to propagating value range information to SSA_NAMEs
and addresses review comments from Eric.
Bootstrapped and regtested on
Hi,
On Wed, 25 Sep 2013 16:01:02, Martin Jambor wrote:
Hi,
On Wed, Sep 25, 2013 at 11:05:21AM +0200, Richard Biener wrote:
On Tue, Sep 24, 2013 at 8:06 PM, Martin Jambor mjam...@suse.cz wrote:
Hi,
On Tue, Sep 24, 2013 at 12:02:17PM +0200, Richard Biener wrote:
On Tue, Sep 24, 2013 at 4:52
On 24/09/13 10:03, Yvan Roux wrote:
Hi,
The following patch switch LRA on for AArch64. The patch introduces
an undocumented option -mlra to use LRA instead of reload, for a
testing purpose. Please notice that this patch is dependent on the
one submitted in the thread below:
Eric, the current way component_uses_parent_alias_set is called from
get_alias_set causes the reference tree chain to be walked O(n^2)
in case there is any DECL_NONADDRESSABLE_P or TYPE_NONALIASED_COMPONENT
reference in the tree chain. Also the comment above
component_uses_parent_alias_set
On Wed, 25 Sep 2013 21:00:33, Tobias Burnus wrote:
Bernd Edlinger wrote:
this test case fails very often, and the reason is not in GCC but
in a missing glibc rounding support for strtod.
This patch fixes the test case, to first determine if the
rounding support is available. This is often
So I still think my patch does the right thing.
The rationale is:
= expand_expr (tem,
(TREE_CODE (TREE_TYPE (tem)) == UNION_TYPE
COMPLETE_TYPE_P (TREE_TYPE (tem))
(TREE_CODE (TYPE_SIZE (TREE_TYPE
Hi Guys,
I am checking in the attached patch in order to fix some code
generation problems exposed by running the GCC testsuite for the
MSP430.
The patch basically adds a definition of TARGET_PRINT_OPERAND_ADDRESS
as some asm() statements needs this. It also adds a sign extending
On Thu, 26 Sep 2013, Eric Botcazou wrote:
Eric, the current way component_uses_parent_alias_set is called from
get_alias_set causes the reference tree chain to be walked O(n^2)
in case there is any DECL_NONADDRESSABLE_P or TYPE_NONALIASED_COMPONENT
reference in the tree chain. Also the
Hi Yvan,
On 24 Sep 2013, at 09:29, Yvan Roux wrote:
On 11 September 2013 21:08, Yvan Roux yvan.r...@linaro.org wrote:
Here is the new patch discussed in the other thread.
Thanks
Yvan
2013-09-11 Yvan Roux yvan.r...@linaro.org
Vladimir Makarov vmaka...@redhat.com
The vectorizer does not honor the fact that debug statements
do not participate in loop-closed-SSA construction and thus
a SSA name can have outside loop uses that are not in the
loop-closed PHI node but in a debug statement.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
On Wed, 25 Sep 2013, Steven Bosscher wrote:
On Wednesday, September 25, 2013, Richard Biener rguent...@suse.de wrote:
On Wed, 25 Sep 2013, Richard Biener wrote:
This loosens the restriction of only coalescing SSA names with
the same base variable by ignoring that restriction for
(Added Eric and Richard)
Sorry for the inconvenience Iain, It's ok for my side.
Thanks,
Yvan
On 26 September 2013 13:18, Iain Sandoe i...@codesourcery.com wrote:
Hi Yvan,
On 24 Sep 2013, at 09:29, Yvan Roux wrote:
On 11 September 2013 21:08, Yvan Roux yvan.r...@linaro.org wrote:
Here is
Hi,
On Thu, 26 Sep 2013 11:34:02, Eric Botcazou wrote:
So I still think my patch does the right thing.
The rationale is:
= expand_expr (tem,
(TREE_CODE (TREE_TYPE (tem)) == UNION_TYPE
COMPLETE_TYPE_P (TREE_TYPE (tem))
(TREE_CODE (TYPE_SIZE (TREE_TYPE (tem)))
!= INTEGER_CST)
modifier
-Original Message-
From: Richard Biener [mailto:richard.guent...@gmail.com]
Sent: Tuesday, September 24, 2013 7:58 PM
To: Bin.Cheng
Cc: Bin Cheng; GCC Patches; Richard Earnshaw
Subject: Re: [PATCH]Construct canonical scaled address expression in IVOPT
On Tue, Sep 24, 2013 at
Sorry for missing the patch.
Thanks.
bin
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of bin.cheng
Sent: Thursday, September 26, 2013 8:05 PM
To: 'Richard Biener'; Bin.Cheng
Cc: GCC Patches; Richard Earnshaw
Subject: RE:
On 26/09/13 09:50, Zhenqiang Chen wrote:
-Original Message-
From: Richard Earnshaw
Sent: Monday, September 23, 2013 11:11 PM
To: Zhenqiang Chen
Cc: Yufeng Zhang; gcc-patches@gcc.gnu.org
Subject: Re: [PATCH, ARM] Fix PR target/58423
On 23/09/13 09:11, Zhenqiang Chen wrote:
On Thu, 26 Sep 2013, Richard Biener wrote:
On Thu, 26 Sep 2013, Eric Botcazou wrote:
Eric, the current way component_uses_parent_alias_set is called from
get_alias_set causes the reference tree chain to be walked O(n^2)
in case there is any DECL_NONADDRESSABLE_P or
All of the rs6000-specific dependencies are included and discovered
automatically.
Bootstrapped on powerpc-ibm-aix7.1.0.0.
David
* config/rs6000/t-rs6000 (rs6000.o): Remove.
(rs6000-c.o): Use COMPILE and POSTCOMPILE.
Index: config/rs6000/t-rs6000
On Thu, Sep 26, 2013 at 2:10 PM, bin.cheng bin.ch...@arm.com wrote:
Sorry for missing the patch.
Thanks.
bin
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of bin.cheng
Sent: Thursday, September 26, 2013 8:05 PM
To:
This patch:
http://gcc.gnu.org/ml/fortran/2013-06/msg00038.html
... breaks libgfortran configure against newlib.
The solution implemented hard wires an assumption in
libgfortran/configure.ac that newlib provides strtold(). This
assumption is not correct, newlib only provides an
After much thinking I settled on removing the restriction from
forwprop that avoids propagating non-invariant addresses into
loops. As forwprop is mainly seen as a way to canonicalize the IL
and simplify it for further passes this seems like the correct thing
to do. LIM and IVOPTs should undo
On Tue, Sep 24, 2013 at 12:00:48PM +0100, Richard Biener wrote:
2013-09-24 Richard Biener rguent...@suse.de
* g++.dg/vect/pr58513.cc: New testcase.
Hi,
This testcase fails for arm and aarch64 targets when using -fPIC.
As discussed on IRC this can be fixed by making op static.
Hi,
On Wed, 25 Sep 2013, Jeff Law wrote:
I was going to bring it up at some point too. My preference is
strongly to simply eliminate the space on methods...
Which wouldn't be so weird: in the libstdc++-v3 code we do it all the time.
Yea. I actually reviewed the libstdc++ guidelines to
It turns out we are pretty conservative on the set of SSA names
we make anonymous. In particular all named temporaries
created by gimplification and lowering passes were left alone.
The following patch makes all SSA names anonymous that we will
not generate debug information for and transitions
On Thu, Sep 26, 2013 at 4:15 PM, Michael Matz m...@suse.de wrote:
Hi,
On Wed, 25 Sep 2013, Jeff Law wrote:
I was going to bring it up at some point too. My preference is
strongly to simply eliminate the space on methods...
Which wouldn't be so weird: in the libstdc++-v3 code we do it
On Thu, Sep 26, 2013 at 1:10 AM, Xinliang David Li davi...@google.com wrote:
I took the liberty to pick up Richard's original fvect-cost-model
patch and made some modification.
What has not changed:
1) option -ftree-vect-loop-version is removed;
2) three cost models are introduced: cheap,
On Thu, Sep 26, 2013 at 03:54:19PM +0200, Richard Biener wrote:
After much thinking I settled on removing the restriction from
forwprop that avoids propagating non-invariant addresses into
loops. As forwprop is mainly seen as a way to canonicalize the IL
and simplify it for further passes
On Thu, 26 Sep 2013, Jakub Jelinek wrote:
On Thu, Sep 26, 2013 at 03:54:19PM +0200, Richard Biener wrote:
After much thinking I settled on removing the restriction from
forwprop that avoids propagating non-invariant addresses into
loops. As forwprop is mainly seen as a way to
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
This patch fix the bug when setting max-lipo-group in AutoFDO:
Bootstrapped and passed regression test.
OK for google branches?
Thanks,
Dehao
Index: gcc/auto-profile.c
===
--- gcc/auto-profile.c (revision 202926)
+++
Looks ok.
David
On Thu, Sep 26, 2013 at 9:00 AM, Dehao Chen de...@google.com wrote:
This patch fix the bug when setting max-lipo-group in AutoFDO:
Bootstrapped and passed regression test.
OK for google branches?
Thanks,
Dehao
Index: gcc/auto-profile.c
Eric Botcazou ebotca...@adacore.com writes:
So in the set_* routines it isn't about whether the value is definitely
a base or a definitely an index. It's just about drilling down through
what we've already decided is a base or index to get the inner reg or mem,
and knowing which XEXPs to look
Steve Ellcey sell...@mips.com writes:
On Tue, 2013-09-24 at 21:07 +0200, Andreas Schwab wrote:
Richard Sandiford rdsandif...@googlemail.com writes:
Sorry for the breakage. I think we need to handle INT_LIST in the same way
as INSN_LIST though, and eliminate in XEXP (x, 1).
How about
This fixes an ICE when lipo_cmp_type handles NULL_PTR_TYPE.
Bootstrapped and regression test on going?
OK for google branches?
Thanks,
Dehao
Index: gcc/l-ipo.c
===
--- gcc/l-ipo.c (revision 202926)
+++ gcc/l-ipo.c (working copy)
yes.
David
On Thu, Sep 26, 2013 at 9:26 AM, Dehao Chen de...@google.com wrote:
This fixes an ICE when lipo_cmp_type handles NULL_PTR_TYPE.
Bootstrapped and regression test on going?
OK for google branches?
Thanks,
Dehao
Index: gcc/l-ipo.c
As preapproved by Richard Biener. Bootstrapped on
x86_64-debian-linux-gnu.
2013-09-26 Florian Weimer f...@deneb.enyo.de
* tree-ssa.h (walk_use_def_chains_fn, walk_use_def_chains): Delete.
* tree-ssa.c (walk_use_def_chains_1, walk_use_def_chains): Delete.
*
On 25 Sep 15:48, Richard Biener wrote:
On Wed, Sep 25, 2013 at 3:29 PM, Ilya Tocar tocarip.in...@gmail.com wrote:
On 24 Sep 11:02, Richard Biener wrote:
On Mon, Sep 23, 2013 at 3:29 PM, Ilya Tocar tocarip.in...@gmail.com
wrote:
thus consider assigning the section
name in a different
On 19 Sep 11:23, Jakub Jelinek wrote:
that. Another complication is dependent shared libraries.
Consider
liba.c:
#pragma omp declare target
int i;
int foo (void)
{
return ++i;
}
#pragma omp end declare target
main.c:
#pragma omp declare target
extern int i;
extern int foo (void);
On Thu, Sep 26, 2013 at 7:37 AM, Richard Biener
richard.guent...@gmail.com wrote:
On Thu, Sep 26, 2013 at 1:10 AM, Xinliang David Li davi...@google.com wrote:
I took the liberty to pick up Richard's original fvect-cost-model
patch and made some modification.
What has not changed:
1) option
Hi!
This patch adds depend clause support.
In GOMP_task, before queueing the task, if task has any depend clauses
we look up the addresses in a hash table (in the parent task, because
only sibling tasks are ordered through depend clause), and if there
are any dependencies on the earlier started
On 19 January 2013 23:43, Jonathan Wakely wrote:
PR libstdc++/55861
* include/std/future (_State_base::_S_check(const shared_ptrT)):
Fix return type.
(__basic_future::_M_get_result()): Const qualify.
(shared_future::get()): Likewise.
*
On Tue, Sep 24, 2013 at 5:31 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hi Honza,
I am finally getting back to working on this after a few weeks of
working on some other priorities.
I am also trying to return to this, so good timming ;)
Martin has got smaller C++ programs (Inkscape) to not touch
Hi folks.
Both OMP4 and Cilk Plus provide mechanisms for simd function cloning.
In OMP4 it's #pragma omp declare simd and in Cilk Plus they are
elemental functions (or simd-enabled functions in their Intel's
latest nomenclature). For lack of a better term, I'll call them simd
clones.
We
+ /* 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
+ lookup_attribute (cilk plus elemental,
+DECL_ATTRIBUTES
I discovered that I was setting the wv/wu constraints incorrectly to
ALTIVEC_REGS, which leads to reload failures in some cases.
Is this patch ok to apply along with the previous patch assuming it bootstraps
and has no regressions with make check? It builds the programs that had
failures with
Just to be clear, I was only asking about the change in rs6000.c. The other
two changes (rs6000-builtins.def, rs6000.h) will be part of the next patch
set.
--
Michael Meissner, IBM
IBM, M/S 2506R, 550 King Street, Littleton, MA 01460, USA
email: meiss...@linux.vnet.ibm.com, phone: +1 (978)
On Tue, Sep 17, 2013 at 10:41 AM, Ilya Enkovich enkovich@gmail.com wrote:
The x86 part looks mostly OK (I have a couple of comments bellow), but
please first get target-independent changes reviewed and committed.
Do you mean I should move bound type and mode declaration into a
Just follow the standard :)
Booted and tested under -m32, -m64.
Thank you!
--
Tim Shen
a.patch
Description: Binary data
On 26 September 2013 22:28, Tim Shen wrote:
Just follow the standard :)
Booted and tested under -m32, -m64.
The ChangeLog entry says stanard, with that fixed this is OK to
commit, thanks!
On Thu, Sep 26, 2013 at 5:37 PM, Jonathan Wakely jwakely@gmail.com wrote:
The ChangeLog entry says stanard, with that fixed this is OK to
commit, thanks!
Committed.
--
Tim Shen
On 09/26/2013 10:21 AM, Richard Biener wrote:
On Thu, Sep 26, 2013 at 4:15 PM, Michael Matz m...@suse.de wrote:
Hi,
On Wed, 25 Sep 2013, Jeff Law wrote:
I was going to bring it up at some point too. My preference is
strongly to simply eliminate the space on methods...
Which wouldn't be so
As for COMDAT merging, i would like to see the patch. I am experimenting
now with a patch to also privatize COMDATs during -fprofile-generate to
avoid problems with lost profiles mentioned above.
Do you mean you privatize every COMDAT function in the profile-generate?
We discussed
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 (that was patch I posted earlier that I think did not
go in, yet).
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 early inlining.
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 branch annotated with builtin_expert.
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 early
On Thu, Sep 26, 2013 at 2:54 PM, Jan Hubicka hubi...@ucw.cz wrote:
As for COMDAT merging, i would like to see the patch. I am experimenting
now with a patch to also privatize COMDATs during -fprofile-generate to
avoid problems with lost profiles mentioned above.
Do you mean you
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 branch annotated with builtin_expert.
This patch improves linux kernel performance with a large workload, so
it is good to first submit this to trunk and backport it.
thanks,
David
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
it might worth extend __builtin_expect to take more parameters:
1) argument to specify actual probability: __builtin_expect (x, 10, 0.6)
2) a more general way of doing this is to allow specifying multiple
values, and the probability is determined by # of occurances:
__builtin_expect (x, 10, 10,
On 09/26/2013 11:36 AM, Jakub Jelinek wrote:
+struct gomp_task;
struct gomp_taskgroup;
+struct htab;
+
+struct gomp_task_depend_entry
+{
+ void *addr;
+ struct gomp_task_depend_entry *next;
+ struct gomp_task_depend_entry *prev;
+ struct gomp_task *task;
+ bool is_in;
+ bool
On Thu, Sep 26, 2013 at 4:51 PM, Michael Meissner
meiss...@linux.vnet.ibm.com wrote:
I discovered that I was setting the wv/wu constraints incorrectly to
ALTIVEC_REGS, which leads to reload failures in some cases.
Is this patch ok to apply along with the previous patch assuming it bootstraps
On Thu, Sep 26, 2013 at 06:56:37PM -0400, David Edelsohn wrote:
On Thu, Sep 26, 2013 at 4:51 PM, Michael Meissner
meiss...@linux.vnet.ibm.com wrote:
I discovered that I was setting the wv/wu constraints incorrectly to
ALTIVEC_REGS, which leads to reload failures in some cases.
Is this
On Thu, Sep 26, 2013 at 03:54:09PM -0700, Richard Henderson wrote:
On 09/26/2013 11:36 AM, Jakub Jelinek wrote:
+struct gomp_task;
struct gomp_taskgroup;
+struct htab;
+
+struct gomp_task_depend_entry
+{
+ void *addr;
+ struct gomp_task_depend_entry *next;
+ struct
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
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual
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 constructs.
So let's support it not to make users
Greetings,
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).
(http://wiki.edg.com/twiki/pub/Wg21chicago2013/LibraryWorkingGroup/N3779-complex_literals.pdf)
On 09/26/2013 08:15 AM, Michael Matz wrote:
Hi,
On Wed, 25 Sep 2013, Jeff Law wrote:
I was going to bring it up at some point too. My preference is
strongly to simply eliminate the space on methods...
Which wouldn't be so weird: in the libstdc++-v3 code we do it all the time.
Yea. I
-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, Sep 24, 2013 at 11:13 AM, bin.cheng bin.ch...@arm.com wrote:
+
70 matches
Mail list logo
