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
=
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
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:
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
> 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 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
> 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
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
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 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)
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
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
(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
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
> -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
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
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
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
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 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
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
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
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
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
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
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
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 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, 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, 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
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
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
> ===
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
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
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 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
* 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-
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.
> >
> >
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 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
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 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
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
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.
+ /* 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
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
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
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 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 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 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
> > 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
>
> 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 ear
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,
>
> 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 wrote:
>> Hi,
>>
>> Current default probably for builtin_expect is 0.9996.
>> This makes the freq of unlike
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)
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;
>
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 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 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 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
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
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
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
> -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
70 matches
Mail list logo
