Hello,
The attached patch restores the SH fma combine patterns which I removed
when adding support for the fma patterns in 4.8.
It turned out that without these patterns things like 'a * b + a' won't
utilize the fmac instruction.
As far as I understand, this is actually a tree optimization issue,
On Mon, May 20, 2013 at 1:41 AM, Easwaran Raman wrote:
> PR tree-optimization/57322
> * (build_and_add_sum): If a BB is empty, set the UID of the statement
> added to the BB to be 1.
Maybe "gimple_set_uid (stmt, inc_gimple_stmt_max_uid (cfun));"? That
would keep the UIDs
Oleg Endo wrote:
> The attached patch restores the SH fma combine patterns which I removed
> when adding support for the fma patterns in 4.8.
> It turned out that without these patterns things like 'a * b + a' won't
> utilize the fmac instruction.
> As far as I understand, this is actually a tree
The way I was testing for whether or not we need to look at template
args for a particular decl was broken; DECL_TI_ARGS may not reflect the
number of template headers for the enclosing class if that class is an
explicit specialization.
Tested x86_64-pc-linux-gnu, applying to trunk. Jakub: it
Hi,
this issue was primarily about a bogus warning for line 9 of the
original testcase (the line 'ic < 5u;') which it's already fixed in 4.8.
While reassessing it, I noticed that the location for the genuine
warning, which should point to the '<' operator, is off two chars to the
right: that
On Fri, 17 May 2013, Aldy Hernandez wrote:
Errr, how did we miss this? Ok, I'm partly to blame for the lack of
transactional memory in changes.html, but something as big as getting
rid of reload?!
I guess I need to start being more of a nuisance again when it comes
to release notes / announce
OK.
Jason
On Mon, May 20, 2013 at 08:27:44AM -0400, Jason Merrill wrote:
> The way I was testing for whether or not we need to look at template
> args for a particular decl was broken; DECL_TI_ARGS may not reflect
> the number of template headers for the enclosing class if that class
> is an explicit special
review please?
On Mon, May 13, 2013 at 6:12 PM, Evgeniy Stepanov wrote:
> re-sending the patch
>
> On Mon, May 13, 2013 at 5:54 PM, Evgeniy Stepanov wrote:
>> friendly ping
>>
>> On Mon, Apr 22, 2013 at 5:23 PM, Evgeniy Stepanov wrote:
>>> Hi,
>>>
>>> this patch disables rdrand in c++11/random
On 20 May 2013 14:15, Evgeniy Stepanov wrote:
> review please?
I suggest you CC whoever approves changes for the google branches, maybe Diego?
On Mon, May 20, 2013 at 5:17 PM, Jonathan Wakely wrote:
> On 20 May 2013 14:15, Evgeniy Stepanov wrote:
>> review please?
>
> I suggest you CC whoever approves changes for the google branches, maybe
> Diego?
rdrand.patch
Description: Binary data
I still don't see anything wrong with the patch. Tested by boostrapping gcc.
The difference between the original patch (that got reverted without
any comment) and the one that was later applied to trunk is that the
original patch did
AC_SUBST(glibcxx_thread_h)
and the new one (that is currently
If you are suggesting using inc_gimple_stmt_max_uid(cfun) for all
statements, that won't work because we want to use the UIDs to
determine dominance within a BB. If your suggestion is to use that
instead of 1 when BB == NULL, that would work (even though setting it
to 1 is sufficient.)
Thanks,
Eas
On Mon, May 20, 2013 at 4:00 PM, Easwaran Raman wrote:
> If your suggestion is to use that
> instead of 1 when BB == NULL, that would work (even though setting it
> to 1 is sufficient.)
That's what I suggest, yes. I understand that 1 is sufficient for now,
but you never know if/when someone will u
Hi Richard,
Thanks for the quick review.
> No constraints on define_expand, only predicates.
>> +(define_insn "mulhi3_g13"
>These names are not used. They should be prefixed with "*" to indicate the
>name is just for documentation.
I have made the suggested changes. Please find below an updated
Hi,
this is also by and large fixed, but we can do a bit better in terms of
not producing a:
error: ISO C++ forbids declaration of ‘parameter’ with no type
[-fpermissive]
after a meaningful error. In grokdeclarator there is already a mechanism
to suppress those, but in cp_parser_parameter_
Hi!
After merging from trunk to get #pragma omp for zero iteration handling
fixes, this is a port of that for expand_omp_simd which doesn't exist on the
trunk.
Committed to gomp-4_0-branch.
2013-05-20 Jakub Jelinek
* omp-low.c (expand_omp_simd): For collapse > 1 loops,
if som
Hi,
I've noticed that testsuite/gcc.dg has some ISR related test cases that
probably should have went to testsuite/gcc.target. The tests in
question were mainly for SH, with two of them being used also for
H8/300.
Attached patch is supposed to fix that, also fixing some formatting
issues and tar
>> I think the problem is with same_line_p. It's using expand_location to
>> test whether two locations refer to the same line, but expand_location
>> always unwinds the macro stack so that it's looking at the line number
>> of the macro expansion point. That means that every token in the macro
>>
Okay after considering those questions. And thanks for catching
and addressing this!
Thank you.
I am committing the attached patch.
Index: gcc-4.8/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.8/changes.html,v
retrie
This patch is a revised version of one previously posted by Pat
Wellander a couple of years ago, to align arrays of size >= 16 bytes on
a 16-byte boundary to make better use of Altivec instructions.
http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01345.html
The original patch only increased the a
OK.
Jason
My patch for c++/55032 fixed this crash for arrays of known bound, but
the COMPLETE_TYPE_P test for when we need to copy the layout information
doesn't work for arrays of unknown bound. So let's check completeness
of the element type and accept that we might copy layout information
more than n
On Mon, May 20, 2013 at 12:49:25PM -0400, Jason Merrill wrote:
> Tested x86_64-pc-linux-gnu, applying to trunk and 4.7. Jakub, is
> this also OK for 4.8.1?
Yes, thanks.
Jakub
Hi all,
While working with conditional execution and in particular with
define_cond_exec, I would like to add an attribute to cond_exec
patterns that are produced through define_cond_exec. This is done by adding
an attributes vector to the define_cond_exec construct.
When a pattern is then process
In this testcase, even though B has a non-trivial move assignment
operator, it's only non-trivial because of the vtable pointer, so the
warning is a false positive. This patch avoids this false positive by
checking for a user-provided op= in the vbase or one of its subobjects
before warning.
I now realize that a less intrusive approach is available: just provide
replacement filenames.h, dwarf2.h in a separate directory and pick up those
headers for a standalone build. In replacement dwarf2.h, include system
dwarf.h, #define potentially missing enum values and provide dummy enum tags.
On May 20, 2013, at 9:40 AM, Sandra Loosemore wrote:
> The original patch only increased the alignment of local arrays, which works
> because the stack is already aligned at 16 bytes for Altivec. The comments
> on the original patch submission were that this should apply to all arrays
> and th
On Mon, May 20, 2013 at 6:55 PM, Kyrylo Tkachov wrote:
> This would allow us to, for example, disable the predicable variant of an
> insn
> based on a non-constant variable.
Is there a reason why you can't use attribute "enabled" for this?
Ciao!
Steven
On Mon, May 20, 2013 at 10:07 AM, Alexander Monakov wrote:
> I now realize that a less intrusive approach is available: just provide
> replacement filenames.h, dwarf2.h in a separate directory and pick up those
> headers for a standalone build. In replacement dwarf2.h, include system
> dwarf.h, #
On Mon, May 20, 2013 at 9:37 AM, Cary Coutant wrote:
>>> I think the problem is with same_line_p. It's using expand_location to
>>> test whether two locations refer to the same line, but expand_location
>>> always unwinds the macro stack so that it's looking at the line number
>>> of the macro exp
> Cool. So shall we get this patch in gcc-4_8 first, and after you
> change to encode discriminator in adhoc_locus map in trunk, we then
> backport it to 4_8 again?
Sure, sounds good.
-cary
On Fri, May 17, 2013 at 11:21 PM, Jakub Jelinek wrote:
> On Fri, May 17, 2013 at 09:00:21PM -0700, Sriraman Tallam wrote:
>> --- ipa-inline.c (revision 198950)
>> +++ ipa-inline.c (working copy)
>> @@ -374,7 +374,33 @@ can_early_inline_edge_p (struct cgraph_edge *e)
>>return fals
* PING *
Since today, due to a just committed patch, Open MPI (trunk version)
won't compile with GCC 4.9 without this patch ...
Patches in this trilogy - the last one is required for Open MPI:
*http://gcc.gnu.org/ml/fortran/2013-05/msg00048.html - COMMON
*http://gcc.gnu.org/ml/fortran/2013-0
Hi Tobias,
* PING *
Since today, due to a just committed patch, Open MPI (trunk version)
won't compile with GCC 4.9 without this patch ...
Patches in this trilogy - the last one is required for Open MPI:
*http://gcc.gnu.org/ml/fortran/2013-05/msg00048.html - COMMON
*http://gcc.gnu.org/ml/fort
> Hi,
>
> This patch implements the BFI variant of BFM. In doing so, it also
> implements the insv standard pattern.
>
> I've regression tested on bare-metal and linux.
>
> It comes complete with its own compilation and execution testcase.
>
> OK for trunk?
>
> Cheers,
> Ian
>
>
> 2013-05-0
Hello Aldy,
I have moved a couple prototypes from c-tree.h to c-family/c-common.h.
This way I can use the same function for the C++ implementation. Here is a
patch.
Thanks,
Balaji V. Iyer.
> -Original Message-
> From: Aldy Hernandez [mailto:al...@redhat.com]
> Sent: Monday, May
On 05/20/2013 11:55 AM, Ian Bolton wrote:
> I improved this patch during the work I did on the recent insv_imm patch
> (http://gcc.gnu.org/ml/gcc-patches/2013-05/msg01007.html).
Thanks, you cleaned up almost everything on which I would have commented
with the previous patch revision. The only thi
On 05/20/2013 09:55 AM, Kyrylo Tkachov wrote:
> For example, a setup like:
>
> (define_attr "predicated" "yes,no" (const_string "no"))
>
> (define_attr "control_attr" "yes,no" (const_string "yes"))
>
>
> (define_attr "enabled" "no,yes"
> (cond [(and (eq_attr "control_attr" "no")
>
On Mon, 2013-05-06 at 12:02 -0400, David Malcolm wrote:
> On Thu, 2013-04-25 at 14:10 -0400, David Malcolm wrote:
> > On Thu, 2013-04-25 at 13:43 -0400, Diego Novillo wrote:
> > > On 2013-04-25 12:30 , David Malcolm wrote:
> > >
> > > > diff --git a/contrib/ChangeLog b/contrib/ChangeLog
> > > > in
On May 10th, the Power Architecture Advisory Council announced the public
availability of Power ISA 2.07.
https://www.power.org/documentation/power-isa-version-2-07/
I will start submitting patches shortly which are our initial support for the
future power8 cpu which will implement the ISA 2.07 in
These patches are primarily infrastructure patches patches, that adds the
switches the following patches will use. I also added the new constraints and
predicates that will be used by future patches.
At this point of development, I have multiple switches for different
sub-features. I could reduc
On Mon, 2013-05-20 at 17:55 +0100, Kyrylo Tkachov wrote:
> I've been working and testing on the arm backend, however I noticed that
> ia64 and c6x use define_cond_exec as well,
> so I'm cc'ing Steve. Would it be possible for you to confirm that this
> doesn't break ia64?
I am not at HP anymore an
This seems like a reasonable change and *should* improve performance,
but what is the actual effect on performance, especially recent POWER
processors? We have had some recent cases where increased alignment
hurt performance because of secondary effects on spilling.
Thanks, David
If cgraph has done something with DECL_STRUCT_FUNCTION, we need to look
in DECL_SAVED_FUNCTION_DATA for the information we need.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit b25745ba91bedc5a8cdd1921f1e474d98eb7d3f4
Author: Jason Merrill
Date: Mon May 20 14:02:42 2013 -0400
PR c
instantiation_dependent_r was treating a null trait type as dependent.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit e0c77ebb435f3910ac533df1c7578e6fcb3ec306
Author: Jason Merrill
Date: Mon May 20 14:48:52 2013 -0400
PR c++/57016
* pt.c (instantiation_dependent_r) [TRAIT_EXP
After submitting the patch, I realized I had submitted a previous version of
the patch, that had the wq constraint that was initially for the quad memory
operations, and also had the changes for ChangeLog.ibm, that I keep on the
branch. However, the wq constraint was always equal to the r constrai
On Mon, May 20, 2013 at 10:40:40AM -0600, Sandra Loosemore wrote:
> This patch is a revised version of one previously posted by Pat
> Wellander a couple of years ago, to align arrays of size >= 16 bytes
> on a 16-byte boundary to make better use of Altivec instructions.
>
> http://gcc.gnu.org/ml/g
While looking at some matrix code I noticed that the generic mips scheduler
was putting out a bunch of integer madd instructions in a row and that
I got better performance (on 74kc and proAptiv) when they were spread out.
I was wondering what folks thought of this change to specify that the
intege
I've updated the patch. Bootstrapped and passed all regression test.
OK for google-4_8?
Thanks,
Dehao
On Mon, May 20, 2013 at 10:48 AM, Cary Coutant wrote:
>> Cool. So shall we get this patch in gcc-4_8 first, and after you
>> change to encode discriminator in adhoc_locus map in trunk, we then
forgot to attache the patch...
On Mon, May 20, 2013 at 3:39 PM, Dehao Chen wrote:
> I've updated the patch. Bootstrapped and passed all regression test.
>
> OK for google-4_8?
>
> Thanks,
> Dehao
>
> On Mon, May 20, 2013 at 10:48 AM, Cary Coutant wrote:
>>> Cool. So shall we get this patch in gc
On Mon, May 20, 2013 at 4:55 AM, Teresa Johnson wrote:
> * ifcvt.c (find_if_case_1): Replace BB_COPY_PARTITION with assert
> as this is now done by redirect_edge_and_branch_force.
> * function.c (thread_prologue_and_epilogue_insns): Insert new bb after
> barriers, a
>> I've updated the patch. Bootstrapped and passed all regression test.
>>
>> OK for google-4_8?
Index: gcc/Makefile.in
===
--- gcc/Makefile.in (revision 199127)
+++ gcc/Makefile.in (working copy)
@@ -1470,7 +1470,7 @@ OBJS-libcommon
This patch adds the builtins for the new ISA 2.07 crypto instructions. It
bootstraps and causes no regressions, is it ok to install after patch #1 has
been applied?
[gcc]
2013-05-20 Michael Meissner
* doc/extend.texi (PowerPC AltiVec/VSX Built-in Functions): Add
documentation
On Fri, May 17, 2013 at 03:18:01PM +0300, Janne Blomqvist wrote:
> Hi,
>
> the example we provide for the usage of the random_seed intrinsic
> could be better. At least one user has already been tripped over by
> the fact that on some targets the first call to system_clock returns
> 0, resulting i
Fixed the problem, and retested. New patch attached.
Dehao
On Mon, May 20, 2013 at 3:53 PM, Cary Coutant wrote:
>>> I've updated the patch. Bootstrapped and passed all regression test.
>>>
>>> OK for google-4_8?
>
> Index: gcc/Makefile.in
> ===
> I'd like to know if someone with better automake skills than I have
> can do anything about that warning, but otherwise that looks OK to me,
> thanks.
Hey dude. Caroline and I are working off-line on this.
-benjamin
On Mon, 2013-05-20 at 16:40 -0400, Michael Meissner wrote:
> Note, in order to build code for power8, you will need a power8 assembler,
> which will shortly be submitted to the binutils mailing lists.
Already submitted and committed upstream:
http://sourceware.org/ml/binutils/2013-05/msg00235.h
On 05/20/2013 04:14 PM, Jakub Jelinek wrote:
Isn't this ABI incompatible change? See http://gcc.gnu.org/PR56564
for more info (yeah, different target, but looks exactly the same issue).
If what this new DATA_ALIGNMENT value is optimization rather than an ABI
requirement, then you'll hit the sam
On Mon, May 20, 2013 at 10:51:16PM -0600, Sandra Loosemore wrote:
> On 05/20/2013 04:14 PM, Jakub Jelinek wrote:
> >
> >Isn't this ABI incompatible change? See http://gcc.gnu.org/PR56564
> >for more info (yeah, different target, but looks exactly the same issue).
> >If what this new DATA_ALIGNMENT
60 matches
Mail list logo
