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
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, 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
> 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
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
> ===
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
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
>> 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
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
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
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
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
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
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
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
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
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
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
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 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
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 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 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
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
> 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
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
* 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
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
> 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 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
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 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 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
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.
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.
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
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
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
OK.
Jason
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
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
>> 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
>>
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
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,
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 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
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
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
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
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
On 20 May 2013 14:15, Evgeniy Stepanov wrote:
> review please?
I suggest you CC whoever approves changes for the google branches, maybe Diego?
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 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
OK.
Jason
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
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
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
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
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
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,
60 matches
Mail list logo
