> -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 wrote:
>
> + fiel
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 actual
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)
Actuall
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 use
On Fri, 2013-09-20 20:51:37 +0200, Jan-Benedict Glaw 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 -Wmissing-form
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;
> > +
On Thu, Sep 26, 2013 at 06:56:37PM -0400, David Edelsohn wrote:
> On Thu, Sep 26, 2013 at 4:51 PM, Michael Meissner
> 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 al
On Thu, Sep 26, 2013 at 4:51 PM, Michael Meissner
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
> and has no regressions
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;
>
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, 20)
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 wrote:
>> Hi,
>>
>> Current default probably for builtin_expect is 0.9996.
>> This makes the freq of unlike
> 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.
>
On Thu, Sep 26, 2013 at 2:54 PM, Jan Hubicka 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 privati
> 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 ear
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 inlining.
>
> 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)
> > 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 dis
On 09/26/2013 10:21 AM, Richard Biener wrote:
On Thu, Sep 26, 2013 at 4:15 PM, 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
On Thu, Sep 26, 2013 at 5:37 PM, Jonathan Wakely wrote:
> The ChangeLog entry says "stanard", with that fixed this is OK to
> commit, thanks!
Committed.
--
Tim Shen
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!
Just follow the standard :)
Booted and tested under -m32, -m64.
Thank you!
--
Tim Shen
a.patch
Description: Binary data
On Tue, Sep 17, 2013 at 10:41 AM, Ilya Enkovich 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 separate
>> > p
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) 899-4
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 the
+ /* 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_ATTRIBUTE
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.
On Tue, Sep 24, 2013 at 5:31 AM, Jan Hubicka 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 col
On 19 January 2013 23:43, Jonathan Wakely wrote:
> PR libstdc++/55861
> * include/std/future (_State_base::_S_check(const shared_ptr&)):
> Fix return type.
> (__basic_future::_M_get_result()): Const qualify.
> (shared_future::get()): Likewise.
> * tes
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 ta
On Thu, Sep 26, 2013 at 7:37 AM, Richard Biener
wrote:
> On Thu, Sep 26, 2013 at 1:10 AM, Xinliang David Li 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
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
On 25 Sep 15:48, Richard Biener wrote:
> On Wed, Sep 25, 2013 at 3:29 PM, Ilya Tocar wrote:
> > On 24 Sep 11:02, Richard Biener wrote:
> >> On Mon, Sep 23, 2013 at 3:29 PM, Ilya Tocar
> >> wrote:
> >> thus consider assigning the section
> >> name in a different place.
> >>
> >> Richard.
> >
> >
As preapproved by Richard Biener. Bootstrapped on
x86_64-debian-linux-gnu.
2013-09-26 Florian Weimer
* 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.
* doc/tree-ssa.texi (Walking use-
yes.
David
On Thu, Sep 26, 2013 at 9:26 AM, Dehao Chen 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
>
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)
@@
Steve Ellcey writes:
> On Tue, 2013-09-24 at 21:07 +0200, Andreas Schwab wrote:
>> Richard Sandiford 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 the attached? Testing in p
Eric Botcazou 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 at. We could
Looks ok.
David
On Thu, Sep 26, 2013 at 9:00 AM, Dehao Chen 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
> ===
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)
+++ gcc/auto-profi
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
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 c
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 pass
On Thu, Sep 26, 2013 at 1:10 AM, Xinliang David Li 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, dynamic, and un
On Thu, Sep 26, 2013 at 4:15 PM, 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 i
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 t
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++ guide
On Tue, Sep 24, 2013 at 12:00:48PM +0100, Richard Biener wrote:
> 2013-09-24 Richard Biener
>
> * 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.
After asking Rich
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 an
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 implementatio
On Thu, Sep 26, 2013 at 2:10 PM, bin.cheng 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: 'Richard
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, 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 TYPE_NONA
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
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
> -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
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)))
>> != I
(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 wrote:
> Hi Yvan,
>
> On 24 Sep 2013, at 09:29, Yvan Roux wrote:
>
>>> On 11 September 2013 21:08, Yvan Roux wrote:
Here is the new patch discussed in the o
On Wed, 25 Sep 2013, Steven Bosscher wrote:
> On Wednesday, September 25, 2013, Richard Biener 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 DECL_INGOR
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.
Richard
Hi Yvan,
On 24 Sep 2013, at 09:29, Yvan Roux wrote:
>> On 11 September 2013 21:08, Yvan Roux wrote:
>>> Here is the new patch discussed in the other thread.
>>>
>>> Thanks
>>> Yvan
>>>
>>> 2013-09-11 Yvan Roux
>>>Vladimir Makarov
>>>
>>>* rtlanal.c (lsb_bitfield_op_p)
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. Als
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
PSI
> 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 (TR
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
> 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_s
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:
>
> htt
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 wrote:
>>> Hi,
>>>
>>> On Tue, Sep 24, 2013 at 12:02:17PM +0200, Richard Biener wrote:
On Tue, Sep 24, 2013 at 4:
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 x86_64-unknown-linux-gnu
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
* expr.c (expand_assignment): Remove obsolete comment.
--
Eric BotcazouIndex: expr.c
=
70 matches
Mail list logo
