Ping.
On Wed, Sep 25, 2013 at 01:08:38PM +0200, Marek Polacek wrote:
> The following testcase ICEd because complete_ctor_at_level_p got
> a union with two initializers - and didn't like that. I think we can
> get away with splicing when sorting the initializers: we already gave
> an error and the
On Tue, Oct 01, 2013 at 07:12:54PM -0700, Cong Hou wrote:
> --- gcc/tree-vect-loop-manip.c (revision 202662)
> +++ gcc/tree-vect-loop-manip.c (working copy)
Your mailer ate all the tabs, so the formatting of the whole patch
can't be checked.
> @@ -19,6 +19,10 @@ You should have received a copy of
On Tue, Oct 01, 2013 at 04:22:38PM -0600, Jeff Law wrote:
> >>- The Copyright years should be 2013 in every new file. Or has this
> >>port been released before?
> >
> >The port has been available via git for quite a while:
> >https://github.com/foss-for-synopsys-dwc-arc-processors/gcc
> Right. Wa
Hi, libstdc++-v3 is ready for releasing.
Is it Ok to apply? By the way, do we need a News entry for this improvement?
Thanks!
Index: htdocs/gcc-4.9/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v
retrievin
> On Oct 1, 2013, at 7:12 PM, Cong Hou wrote:
>
> When alias exists between data refs in a loop, to vectorize it GCC
> does loop versioning and adds runtime alias checks. Basically for each
> pair of data refs with possible data dependence, there will be two
> comparisons generated to make sure
When alias exists between data refs in a loop, to vectorize it GCC
does loop versioning and adds runtime alias checks. Basically for each
pair of data refs with possible data dependence, there will be two
comparisons generated to make sure there is no aliasing between them
in each iteration of the
On Tue, 2013-10-01 at 23:57 +0100, Yufeng Zhang wrote:
> On 10/01/13 20:55, Bill Schmidt wrote:
> >
> >
> > On Tue, 2013-10-01 at 11:56 -0500, Bill Schmidt wrote:
> >> OK, thanks. The problem that you've encountered is that you are
> >> attempting to do something illegal. ;) (Bin's original patch
On 10/02/2013 02:00 AM, Tim Shen wrote:
On Tue, Oct 1, 2013 at 7:49 PM, Paolo Carlini wrote:
Thanks. But then the function actually *is* implemented, saying 'not
implemented' is misleading. Please change the xml to something like 'isn't
correctly implemented', or more informally, 'needs work',
On Tue, Oct 1, 2013 at 7:49 PM, Paolo Carlini wrote:
> Thanks. But then the function actually *is* implemented, saying 'not
> implemented' is misleading. Please change the xml to something like 'isn't
> correctly implemented', or more informally, 'needs work', up to you, but
> please adjust it.
C
On 10/02/2013 01:45 AM, Tim Shen wrote:
On Tue, Oct 1, 2013 at 6:41 PM, Paolo Carlini wrote:
Ok, thus just say that transform_primary is unimplented. Please also add a comment inline
in the code explaining the issue, but don't word it in term of , because
is just what it is per C++11, and do
On Tue, Oct 1, 2013 at 6:41 PM, Paolo Carlini wrote:
> Ok, thus just say that transform_primary is unimplented. Please also add a
> comment inline in the code explaining the issue, but don't word it in term of
> , because is just what it is per C++11, and doesn't directly
> provide what we nee
On Tue, Oct 1, 2013 at 3:50 PM, Jan Hubicka wrote:
>> > Hi Wei Mi,
>> >
>> > Have you checked in your patch?
>> >
>> > --
>> > H.J.
>>
>> No, I havn't. Honza wants me to wait for his testing on AMD hardware.
>> http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01603.html
> I only wanted to separate it
On Tue, Oct 1, 2013 at 1:52 PM, Michael Meissner
wrote:
> This patch moves most of the VSX DFmode operations from vsx.md to rs6000.md to
> use the traditional floating point instructions (f*) instead of the VSX scalar
> instructions (xs*) if all of the registers come from the traditional floating
On 10/01/13 20:55, Bill Schmidt wrote:
On Tue, 2013-10-01 at 11:56 -0500, Bill Schmidt wrote:
OK, thanks. The problem that you've encountered is that you are
attempting to do something illegal. ;) (Bin's original patch is
actually to blame for that, as well as me for not catching it then.)
> > Hi Wei Mi,
> >
> > Have you checked in your patch?
> >
> > --
> > H.J.
>
> No, I havn't. Honza wants me to wait for his testing on AMD hardware.
> http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01603.html
I only wanted to separate it from the changes in generic so the regular testers
can pick it
This patch fixes an issue where expansion of an ORIF expression arbitrarily
applied the probability that the entire condition was true to just the
first condition. When the ORIF true probability was 100%, this resulted
in the second condition's jump being given a count of zero (since the
first cond
Hi,
> Il giorno 02/ott/2013, alle ore 00:21, Tim Shen ha
> scritto:
>
>> On Tue, Oct 1, 2013 at 6:08 PM, Paolo Carlini
>> wrote:
>> What do you mean by "not well defined"? Non confoming? Why?
>
> I don't know if the word 'define' is appropriate, maybe I should just
> use 'implement'.
>
> It
On Tue, Oct 1, 2013 at 5:50 PM, Joern Rennecke
wrote:
> Quoting Diego Novillo :
>
>> No need to mark struct arc_frame_info with GTY. It contains no pointers.
>
>
> That's not quite how it works. machine_function needs GTY. It uses
> arc_frame_info, hence arc_frame_info also needs GTY.
Gah, you'
On 10/01/13 15:26, Joern Rennecke wrote:
I have finished reading through these patches. They are OK to commit.
The changes indicated below are minor. Ideally, you'd address them
before committing the patch, but if it's easier to do it post-commit,
that's OK too.
Oops, I've already started my
On Tue, Oct 1, 2013 at 6:08 PM, Paolo Carlini wrote:
> What do you mean by "not well defined"? Non confoming? Why?
I don't know if the word 'define' is appropriate, maybe I should just
use 'implement'.
It's indeed the problem that needs extra support from ,
described by [28.7.7]. More detailed,
Hi,
> Il giorno 02/ott/2013, alle ore 00:03, Tim Shen ha
> scritto:
>
>> On Mon, Sep 30, 2013 at 2:25 PM, Paolo Carlini
>> wrote:
>> 3- Tweak the implementation status page
>> libstdc++/doc/xml/manual/status_cxx2011.xml (possibly clarify bits still
>> missing too)
>
> Here is the patch for t
On Mon, Sep 30, 2013 at 2:25 PM, Paolo Carlini wrote:
> 3- Tweak the implementation status page
> libstdc++/doc/xml/manual/status_cxx2011.xml (possibly clarify bits still
> missing too)
Here is the patch for this, along with some interface fixes.
Thank you!
--
Tim Shen
a.patch
Description:
On Tue, Oct 1, 2013 at 2:37 PM, Xinliang David Li wrote:
> On Tue, Oct 1, 2013 at 10:31 AM, Cong Hou wrote:
>> The current uniform_vector_p() function only returns non-NULL when the
>> vector is directly a uniform vector. For example, for the following
>> gimple code:
>>
>> vect_cst_.15_91 = {_9,
Quoting Diego Novillo :
No need to mark struct arc_frame_info with GTY. It contains no pointers.
That's not quite how it works. machine_function needs GTY. It uses
arc_frame_info, hence arc_frame_info also needs GTY.
Actually I will introduce optimizations in the next patch. Currently
the function uniform_vector_p () is rarely used in GCC, but there are
certainly some optimization opportunities with the help of this
function.
For example, when we widen a vector with 8 identical element of short
type to two vec
tree-ssa-threadupdate.c has a hash table so that it can efficiently find
cases where multiple incoming edges thread to the same destination.
That hash table used the old 3-edge representation of jump thread paths.
This patch changes it to utilize the full path.
Bootstrapped and regression t
On Tue, Oct 1, 2013 at 10:31 AM, Cong Hou wrote:
> The current uniform_vector_p() function only returns non-NULL when the
> vector is directly a uniform vector. For example, for the following
> gimple code:
>
> vect_cst_.15_91 = {_9, _9, _9, _9, _9, _9, _9, _9};
>
>
> The current implementation ca
Quoting Diego Novillo :
On Sat, Sep 28, 2013 at 9:54 AM, Joern Rennecke
wrote:
The main part of the port (everything but the testsuite) is still waiting
for review:
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00323.html
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00324.html
http://gcc.gnu.or
I'm typically against adding things to libiberty "because there's no
other place for them". The purpose of libiberty is to provide a
portability layer, not a trash can. However, htab is already in
there, and the argument for putting its accessors there is sound.
However, most of the other funct
This patch moves prototypes into gimple-fold.h (which already existed).
There were a few in tree-flow.h and a bunch in gimple.h. The routines
are used frequently enough that it makes sense to include gimple-fold.h
from gimple.h instead of from within each .c file that needs it.
(presumably why
In gfc_conv_string_tmp, gfortran allocates temporary strings. However,
using "TYPE_SIZE (type)" didn't yield one byte as intended but 64 -
which means that gfortran allocated 64 times as much memory as needed.
I wonder whether the same issue also occurs elsewhere.
Committed (Rev. ) after build
bounced from gcc-patches... must have been some html creep in..
Andrew
Original Message
Subject:Fwd: Re: [patch] move htab_iterator
Date: Tue, 01 Oct 2013 16:54:52 -0400
From: Andrew MacLeod
To: gcc-patches , tromey ,
Ian Lance Taylor , DJ Delorie
Anyone int
I have committed the patch after Janne's approval on IRC and fresh
building/regtesting as Rev. 203086. See
http://gcc.gnu.org/ml/fortran/2012-11/msg00092.html
As suggested by Janne, I will backport it to 4.8 in in a bunch of days.
Tobias
On November 29, 2012 12:38, Tobias Burnus wrote:
Tobi
> "Jan-Benedict" == Jan-Benedict Glaw writes:
Jan-Benedict> Since we're using $(CXX) instead of $(CC) these days, I
Jan-Benedict> suggest using CXX instead of CC. A quick check (without
Jan-Benedict> regenerating all configure and Makefile files just
Jan-Benedict> changing CC to CXX in gcc/co
On Tue, 2013-10-01 20:49:30 +0200, Jan-Benedict Glaw wrote:
[...]
> Since we're using $(CXX) instead of $(CC) these days, I suggest
> using CXX instead of CC. A quick check (without regenerating all
> configure and Makefile files just changing CC to CXX in gcc/configure)
> makes it build properl
> Hi Wei Mi,
>
> Have you checked in your patch?
>
> --
> H.J.
No, I havn't. Honza wants me to wait for his testing on AMD hardware.
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01603.html
Hi,
This patch disables the C++ frontend to add " *INTERNAL* " suffix to
maybe_in_charge_destructor/constructor. This is needed because these
functions could be emitted in the debug info, and we would want to
demangle these names.
Bootstrapped and passed all regression tests.
OK for trunk?
Than
Latest results for 4.4.x
-tgc
Testresults for 4.4.7:
i386-pc-solaris2.8 (2)
i386-pc-solaris2.9
sparc-sun-solaris2.7 (2)
sparc-sun-solaris2.8
sparc-sun-solaris2.9
Index: buildstat.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/
> "Andrew" == Andrew MacLeod writes:
Andrew> Sure, how's this?
Thanks!
Andrew> And who has to approve the libiberty bits?
libiberty DJ Delorie d...@redhat.com
libiberty Ian Lance Taylori...@airs.com
Tom
Latest results for 4.5.x
-tgc
Testresults for 4.5.4:
i386-pc-solaris2.8 (2)
i386-pc-solaris2.9
sparc-sun-solaris2.7 (2)
sparc-sun-solaris2.8
sparc-sun-solaris2.9
sparc64-sun-solaris2.7
sparc64-sun-solaris2.8
sparc64-sun-solaris2.9
Index: buildstat.html
===
Latest results for gcc 4.7.x.
-tgc
Testresults for 4.7.3
sparc64-sun-solaris2.8
Testresults for 4.7.2
i386-apple-darwin9.8.0
Index: buildstat.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/buildstat.html,v
retrieving revisi
Latest results for gcc 4.8.x.
-tgc
Testresults for 4.8.1
sparc64-sun-solaris2.9
Index: buildstat.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/buildstat.html,v
retrieving revision 1.4
diff -u -r1.4 buildstat.html
--- buildsta
On Tue, 2013-10-01 at 11:56 -0500, Bill Schmidt wrote:
> OK, thanks. The problem that you've encountered is that you are
> attempting to do something illegal. ;) (Bin's original patch is
> actually to blame for that, as well as me for not catching it then.)
>
> As your new test shows, it is un
Hi!
I'm trying to build GCC on an AIX ppc system (gcc111.fsffrance.org),
where IBM's XL C compiler is installed, but not XL C++. So my
configury uses CC=/usr/bin/xlC, and a default value (g++) for CXX.
Because $CC is used for dependency checking (gcc/configure.ac::977
or gcc/configure:8765), `d
On Tue, Oct 1, 2013 at 9: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
>> >>
On Sun, Sep 22, 2013 at 2:29 AM, Uros Bizjak wrote:
> On Wed, Sep 18, 2013 at 3:45 PM, Zamyatin, Igor
> wrote:
>> Ccing Uros. Changes in i386.md could be related to the fix for PR57954.
>
>> -Original Message-
>> From: Wei Mi [mailto:w...@google.com]
>> Sent: Thursday, September 12, 2013
Chung-Ju Wu writes:
>>> +mno-ctor-dtor
>>> +Target Report RejectNegative
>>> +Disable constructor/destructor feature.
>>
>> How is this option used?
>>
>
> It effects how we link crt stuff. Refer to nds32.h:
>
> /* The option -mno-ctor-dtor can disable constructor/destructor feature
>by app
2013-09-06 Joern Rennecke
* config/arc/arc.c (arc_conditional_register_usage):
Use ARC_FIRST_SIMD_VR_REG / ARC_LAST_SIMD_VR_REG.
Also set reg_alloc_order for DMA config regs.
diff --git a/gcc/config/arc/arc.c b/gcc/config/arc/arc.c
index 51ad7d7..796c768 100644
--- a/
On Tue, Sep 24, 2013 at 11:25 AM, Teresa Johnson wrote:
> On Tue, Sep 24, 2013 at 10:57 AM, Jan Hubicka wrote:
>>>
>>> I looked at one that failed after 100 as well (20031204-1.c). In this
>>> case, it was due to expansion which was creating multiple branches/bbs
>>> from a logical OR and guessin
Chung-Ju Wu writes:
> + /* Use $r15, if the value is NOT in the range of Is20,
> + we must output "sethi + ori" directly since
> + we may already passed the split stage. */
> + return "sethi\t%0, hi20(%1)\;ori\t%0, %0, lo12(%1)";
> +case 17:
> + return "#";
I d
The current uniform_vector_p() function only returns non-NULL when the
vector is directly a uniform vector. For example, for the following
gimple code:
vect_cst_.15_91 = {_9, _9, _9, _9, _9, _9, _9, _9};
The current implementation can only detect that {_9, _9, _9, _9, _9,
_9, _9, _9} is a unifor
Hello All
I'm re-reading toplev_main from gcc/toplev.c and I find strange that
invoke_plugin_callbacks for PLUGIN_FINISH was called before
diagnostic_finish (which I guess is finalizing all the diagnostic
infrastructure).
My guess would be that some GCC plugins might occasionally emit a
diagnosti
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 Sat, Sep 28, 2013 at 9:54 AM, Joern Rennecke
wrote:
> The main part of the port (everything but the testsuite) is still waiting
> for review:
> http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00323.html
> http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00324.html
> http://gcc.gnu.org/ml/gcc-patches/2
ping.
On Fri, Sep 27, 2013 at 3:53 PM, Rong Xu wrote:
> 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
ping.
On Fri, Sep 27, 2013 at 3:56 PM, Rong Xu 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 builtin_e
On 30/09/13 09:52, James Greenhalgh wrote:
>
> Hi,
>
> Recently I've found myself getting a number of segfaults from
> code calling in to the arm_early_load/alu_dep functions in
> aarch64-common.c. These functions expect a particular form
> for the RTX patterns they work over, but some of them do
OK, thanks. The problem that you've encountered is that you are
attempting to do something illegal. ;) (Bin's original patch is
actually to blame for that, as well as me for not catching it then.)
As your new test shows, it is unsafe to do the transformation in
backtrace_base_for_ref when wideni
On Tue, Oct 01, 2013 at 05:07:28PM +0200, Gerald Pfeifer wrote:
> > --- www/htdocs/gcc-4.9/changes.html.mp 2013-09-19 16:54:32.113724993
> > +0200
> > +++ www/htdocs/gcc-4.9/changes.html 2013-09-19 17:07:05.418030738 +0200
> > +UndefinedBehaviorSanitizer, a fast undefined behavior detecto
On Tue, Oct 1, 2013 at 6:50 PM, Richard Biener
wrote:
> On Mon, Sep 30, 2013 at 7:39 AM, bin.cheng wrote:
>>
>>
>
> I don't think you need
>
> + /* Sign extend off if expr is in type which has lower precision
> + than HOST_WIDE_INT. */
> + if (TYPE_PRECISION (TREE_TYPE (expr)) <= HOST_BITS
On Tue, Oct 1, 2013 at 10:10 AM, Joern Rennecke
wrote:
> Yes. Claudiu Zissulescu at Synopsys would in principle be available as
> co-maintainer, but I suppose it is customary to apply for write-after-
> approval status first.
I'm not sure. A question for the SC.
>> SC folks, could you appoint
OK.
Jason
On Tue, Oct 1, 2013 at 1:32 AM, Paolo Carlini wrote:
> Ok, thanks.
Committed.
Thanks!
--
Tim Shen
On Tue, 2013-10-01 at 12:40 +0100, Marcus Shawcroft wrote:
> On 30/09/13 13:40, Marcus Shawcroft wrote:
>
> >> Well, I thought this patch would work for me, but it does not. It looks
> >> like gcc_no_link is set to 'no' on my target because, technically, I can
> >> link even if I don't use a link
This patch moves 5 sets of prototypes out of tree-flow.h and creates 4
new header files.
I then #include the new header files from tree-flow.h as a temporary
measure until all prototypes have been cleared up. then as previously
discussed, I will revisit all the #includes *of* and *within*
tr
On Thu, 19 Sep 2013, Marek Polacek wrote:
> Maybe it'd be worth noting in changes.html that GCC now has the
> ubsan...
Not just maybe! :-)
> --- www/htdocs/gcc-4.9/changes.html.mp2013-09-19 16:54:32.113724993
> +0200
> +++ www/htdocs/gcc-4.9/changes.html 2013-09-19 17:07:05.418030738 +
> Please check whether it is ok. Boostrap and regression ok. I am also
> verifying its performance effect on google applications (But most of
> them are 64 bits, so I cannot verify its performance effect on 32 bits
> apps).
Have verified It has no performance impact on google applications.
Thanks
Hi Bill,
Thank you for the review and the offer to help.
On 10/01/13 15:36, Bill Schmidt wrote:
On Tue, 2013-10-01 at 08:17 -0500, Bill Schmidt wrote:
On Tue, 2013-10-01 at 12:19 +0200, Richard Biener wrote:
On Wed, Sep 25, 2013 at 1:37 PM, Yufeng Zhang wrote:
Hello,
Please find the update
On Sun, Sep 29, 2013 at 6:59 PM, Uros Bizjak wrote:
> Rather trivial fix - put @anchor before @heading, as texi manual suggests.
>
> 2013-09-29 Uros Bizjak
>
> * doc/install.texi (Host/target specific installation notes for GCC):
> Put @anchor before @heading.
>
> Tested by "make doc"
Hi!
This is just a preparation for the OMP_PLACES work, I've figured out before
changing the affinity stuff it might be better to fix this PR.
As gomp_init_num_threads is always called before gomp_init_affinity, there
is no point calling the same pthread_getaffinity_np twice, and I'll need
the ini
On Tue, 2013-10-01 at 08:17 -0500, Bill Schmidt wrote:
> On Tue, 2013-10-01 at 12:19 +0200, Richard Biener wrote:
> > On Wed, Sep 25, 2013 at 1:37 PM, Yufeng Zhang wrote:
> > > Hello,
> > >
> > > Please find the updated version of the patch in the attachment. It has
> > > addressed the previous
> 2013-09-30 Vidya Praveen
>
> * aarch64-simd.md
> (aarch64_l2_internal): Rename to
> ...
> (aarch64_l_hi_internal): ... this;
> Insert '\t' to output template.
> (aarch64_l_lo_internal): New.
> (aarch64_saddl2, aarch64_uaddl2): Modify to call
>
On 30 September 2013 14:19:01 Richard Biener wrote:
This fixes PR58554, pattern recognition in loop distribution now
needs to check whether all stmts are unconditionally executed.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2013-09-30 Richard Biener
The old code in tree-ssa-threadupdate.c had a 3-edge form to describe a
jump threading path. The incoming edge E, to which two additional edges
were attached onto e->aux.
The general form of the FSA opt really needs a full path to keep the SSA
graph updating code (particularly the PHI node
Quoting Diego Novillo :
I have been reviewing these patches (I've gone through 2), and so far
I find nothing surprising in them. I should be able to finish them
today or tomorrow. Joern, I assume that you'll be one of the
maintainers for the port? Anyone else?
Yes. Claudiu Zissulescu at Sy
On Tue, 2013-10-01 at 08:17 -0500, Bill Schmidt wrote:
> On Tue, 2013-10-01 at 12:19 +0200, Richard Biener wrote:
> > On Wed, Sep 25, 2013 at 1:37 PM, Yufeng Zhang wrote:
> > > Hello,
> > >
> > > Please find the updated version of the patch in the attachment. It has
> > > addressed the previous
Hi,
this fixes a bug in the literal pool splitting code in the s390 back
end. Jakub debugged the problem and provided a fix.
I've tested the patch on s390 and s390x with the default options as
well as -march=z10/-mtune=zEC12.
No regressions.
Committed to mainline.
Jakub tested the 4.8 version
2013/10/1 Diego Novillo :
> On Sat, Sep 28, 2013 at 9:54 AM, Joern Rennecke
> wrote:
>> The main part of the port (everything but the testsuite) is still waiting
>> for review:
>
> I have been reviewing these patches (I've gone through 2), and so far
> I find nothing surprising in them. I should
On Tue, 2013-10-01 at 12:19 +0200, Richard Biener wrote:
> On Wed, Sep 25, 2013 at 1:37 PM, Yufeng Zhang wrote:
> > Hello,
> >
> > Please find the updated version of the patch in the attachment. It has
> > addressed the previous comments and also included some changes in order to
> > pass the boo
Hi,
On Mon, 30 Sep 2013, Jeff Law wrote:
> > - the compiler better do an awesome job of sharing stack space for
> > user variables in a function... I wouldn't want to blow up the stack
> > with a bazillion unrelatd temps each wit their own location.
> If the objects have the same type and disj
On Sat, Sep 28, 2013 at 9:54 AM, Joern Rennecke
wrote:
> The main part of the port (everything but the testsuite) is still waiting
> for review:
> http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00323.html
> http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00324.html
> http://gcc.gnu.org/ml/gcc-patches/2
On 30/09/13 13:40, Marcus Shawcroft wrote:
Well, I thought this patch would work for me, but it does not. It looks
like gcc_no_link is set to 'no' on my target because, technically, I can
link even if I don't use a linker script. I just can't find any
functions.
In which case gating on gcc
On 30 September 2013 14:20, Renlin Li wrote:
> gcc/ChangeLog:
>
> 2013-09-30 Renlin Li
>
> * config/aarch64/aarch64.c (aarch64_expand_prologue): Use plus_constant.
> (aarch64_expand_epilogue): Likewise.
OK
/Marcus
On Tue, Oct 1, 2013 at 11:33 AM, Kyrill Tkachov wrote:
> On 01/10/13 09:28, Richard Biener wrote:
>>
>> On Mon, Sep 30, 2013 at 5:26 PM, Xinliang David Li
>> wrote:
>>>
>>> Yes, that will do. Can you do it for me? I can't do testing easily
>>> on arm myself.
>>
>> It also fails on x86_64 with -
On Mon, Sep 30, 2013 at 7:39 AM, bin.cheng wrote:
>
>
>> -Original Message-
>> From: Richard Biener [mailto:richard.guent...@gmail.com]
>> Sent: Friday, September 27, 2013 4:30 PM
>> To: Bin Cheng
>> Cc: GCC Patches
>> Subject: Re: [PATCH]Fix computation of offset in ivopt
>>
>> On Fri, Se
On Fri, Sep 27, 2013 at 8:36 PM, Andrew MacLeod wrote:
> On 09/27/2013 04:44 AM, Richard Biener wrote:
>>
>> On Thu, Sep 26, 2013 at 6:07 PM, Andrew MacLeod
>> wrote:
>>
>>>
>>> Ugg. I incorporated what we talked about, and it was much messier than
>>> expected :-P. I ended up with a chicken and
On Wed, Sep 25, 2013 at 1:37 PM, Yufeng Zhang wrote:
> Hello,
>
> Please find the updated version of the patch in the attachment. It has
> addressed the previous comments and also included some changes in order to
> pass the bootstrapping on x86_64.
>
> It's also passed the regtest on arm-none-ea
On 30 September 2013 14:23, Renlin Li wrote:
> OK for trunk?
>
> Kind regards,
> Renlin Li
>
> gcc/ChangeLog:
>
> 2013-09-30 Renlin Li
>
> * config/arm/arm.c (arm_output_mi_thunk): Use plus_constant.
OK
/Marcus
I'm committing this cleanup patch to my PR 57134,57586 changes as
obvious. That it is obvious can be seen from an assert in
tree-ssa-operands.c get_asm_expr_operands().
/* This should have been split in gimplify_asm_expr. */
gcc_assert (!allows_reg || !is_inout);
Bootstrapped, etc.
On 01/10/13 09:28, Richard Biener wrote:
On Mon, Sep 30, 2013 at 5:26 PM, Xinliang David Li wrote:
Yes, that will do. Can you do it for me? I can't do testing easily
on arm myself.
It also fails on x86_64 with -m32. I always test on x86_64 with
multilibs enabled:
make -k -j12 check RUNTEST
On 10/01/13 08:42, Kugan wrote:
Hi,
I am attaching a patch that reverts Split shift di patterns (r197527) as
it introduced PR58578. I am also attaching a patch to add a testcase
based on this failiures.
No regression on qemu for arm-none-eabi and new testcase now passes.
Is this OK?
Thanks,
K
Hi Mike,
It may be reasonable to special case ptr32plus to say no on your platform, from
check_effective_target_tls_native, we see code like:
you could do something like:
proc check_effective_target_ptr32plus { } {
# msp430 never really has 32 or more bits in a pointer.
if { [ista
On 30/09/13 14:23, Renlin Li wrote:
Hello all,
Sorry for my last patch that cause some test regressions. I have correct
it, and it has been tested for arm-none-eabi on the model.
This patch will replace all explicit calls to gen_rtx_PLUS and GEN_INT
with plus_constant.
OK for trunk?
Kind rega
[RFC] Allow functions calling mcount before prologue to be leaf functions
http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00993.html
[PATCH] PR57377: Fix mnemonic attribute
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01364.html
[PATCH] Doc: Add documentation for the mnemonic attribute
http://gcc.gn
On 30/09/13 14:20, Renlin Li wrote:
Hello all,
Sorry for my last patch that cause some test regressions. I have correct
it, and it has been tested for aarch64-none-elf on the model.
This patch will replace all explicit calls to gen_rtx_PLUS and GEN_INT
with plus_constant.
OK for trunk?
Kind r
Ping.
On Thu, Sep 19, 2013 at 05:12:34PM +0200, Marek Polacek wrote:
> Maybe it'd be worth noting in changes.html that GCC now has the
> ubsan...
>
> Ok to apply?
>
> --- www/htdocs/gcc-4.9/changes.html.mp2013-09-19 16:54:32.113724993
> +0200
> +++ www/htdocs/gcc-4.9/changes.html 2013
Ping~
Thanks,
Yufeng
On 09/25/13 12:37, Yufeng Zhang wrote:
Hello,
Please find the updated version of the patch in the attachment. It has
addressed the previous comments and also included some changes in order
to pass the bootstrapping on x86_64.
It's also passed the regtest on arm-none-eabi
On Mon, Sep 30, 2013 at 5:26 PM, Xinliang David Li wrote:
> Yes, that will do. Can you do it for me? I can't do testing easily
> on arm myself.
It also fails on x86_64 with -m32. I always test on x86_64 with
multilibs enabled:
make -k -j12 check RUNTESTFLAGS="--target_board=unix/\{,-m32\}"
R
On Mon, Sep 30, 2013 at 10:39 PM, Richard Sandiford
wrote:
> Richard Biener writes:
>> On Sun, Sep 29, 2013 at 11:08 AM, Richard Sandiford
>> wrote:
>>> Michael Matz writes:
Trever Saunders writes:
> Richard Biener writes:
> > Btw, I've come around multiple coding-styles in the pa
On Mon, Sep 30, 2013 at 5:48 PM, Andrew MacLeod wrote:
> Move the prototype for coalesce_ssa_name() out of tree-ssa-live.h and put it
> in a new tree-ssa-coalesce.h file.
> Include tree-ssa-coalesce.h from tree-outof-ssa.h as it forms part of the
> out-of-ssa module.
>
> Also move gimple_can_coal
1 - 100 of 103 matches
Mail list logo
