On Sat, Oct 26, 2013 at 12:19:33AM +0200, Jakub Jelinek wrote:
> And here is a patch that allows vectorization without peeling for alignment
> and scalar loop for bound even for fn2, fn3 and fn4 in the following
> testcase, though as with the range __builtin_unreachable () notes, it is
> quite frag
> Updated patch, re-bootstrapped on x86_64 and committed to trunk.
>
> Also applied to 4.7 and 4.8 branches, the same problem is present there.
You only asked for approval on trunk though, and I'm not sure we really care
about the results of the GDB testsuite on the 4.7 branch at this point, so
Hello!
> For the define_expand I added as below, the else body is there to
> avoid fall-through transformations to ABS operation in optabs.c.
> Otherwise ABS will be converted to other operations even that we have
> corresponding instructions from SSSE3.
No, it wont be.
Fallthrough will generate
Hi,
On Mon, 28 Oct 2013 21:29:24, Sandra Loosemore wrote:
>
> On 10/28/2013 03:20 AM, Bernd Edlinger wrote:
>>
>> On Sun, 20 Oct 2013 20:23:49, Sandra Loosemore wrote:
>>>
>>> I tried a backport to GCC 4.8 and tested on arm-none-eabi. On the new
>>> pr56997-1.c testcase, it got stuck in infinite r
-fvect-cost-model changed its behavior dependent on the optimization
level. The former behavior is restored by using -fvect-cost-model=dynamic
for -fvect-cost-model and -fvect-cost-model=unlimited for
-fno-vect-cost-model. The following patch makes this change
throughout the testsuite - which a
Hi,
I noticed that IVOPT generates complex address expressions like below for iv
base.
&arr_base[0].y
&arr[0]
&MEM[p+o]
It's even worse for targets support auto-increment addressing mode because
IVOPT adjusts such base expression with +/- step, then creates below:
&a
Hi,
Please consider this as a reminder to review the ldp and stp peephole
implementation for AArch64 target.
The patch was originally posted at:-
http://gcc.gnu.org/ml/gcc-patches/2013-03/msg01051.html
Please review the same and let me know if its okay.
Build and tested on aarch64-thunder-elf
On Sat, Oct 26, 2013 at 7:07 PM, Marc Glisse wrote:
> On Fri, 25 Oct 2013, Marc Glisse wrote:
>
>> On Fri, 25 Oct 2013, Richard Biener wrote:
>>
>>> you can followup with handling POINTER_PLUS_EXPR if you like.
>>
>>
>> Like this? (bootstrap+testsuite on x86_64-unknown-linux-gnu)
>>
>> 2013-10-26
On 10/24/13 00:04, Kugan wrote:
Hi,
arm testcases neon-vcond-ltgt.c and neon-vcond-unordered.c fails in
Linaro 4.8 branch. It is not reproducable with trunk but it can happen.
Both neon-vcond-ltgt.c and neon-vcond-unordered.c scans for vbsl
instruction, with other vector instructions. However, a
On 10/24/13 00:04, Kugan wrote:
Hi,
arm testcases neon-vcond-ltgt.c and neon-vcond-unordered.c fails in
Linaro 4.8 branch. It is not reproducable with trunk but it can happen.
Both neon-vcond-ltgt.c and neon-vcond-unordered.c scans for vbsl
instruction, with other vector instructions. However, a
On Wed, Oct 16, 2013 at 09:35:21AM +0400, Yury Gribov wrote:
> >>> I've recently submitted a bug report regarding invalid
> unpoisoning of stack frame redzones
> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58543). Could someone
> take a look at proposed patch (a simple one-liner) and check whether
Hello,
I've cooperating with Jan on a new profile-based function
reordering stuff. This first patch introduces a new GCOV counter that
instruments each function call and stores the time of first run of a
function.
Bootstrapped/regtested on x86_64-linux and i686-linux.
Thanks,
Martin
diff --git
Hello,
I've noticed that some part of documentation is obsolete and this
patch adds documentation for new functions that replace old macros.
Thanks,
Martin
diff --git a/ChangeLog b/ChangeLog
index 1c50b9b..d64fbcf 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+2013-10-29 Martin Liska
+
You are better off CCing the maintainers for such reviews. Let me do
that for you. I cannot approve or reject this patch but I have a few
comments as below.
On 10/29/13 09:22, Hurugalawadi, Naveen wrote:
diff -uprN '-x*.orig' mainline-orig/gcc/config/aarch64/aarch64.md
gcc-4.8.0/gcc/confi
Hello Richard,
On 28 Oct 14:45, Richard Henderson wrote:
> On 10/28/2013 01:58 PM, Kirill Yukhin wrote:
> > Hello Richard,
> > On 28 Oct 08:20, Richard Henderson wrote:
> >> Why is a masked *scalar* operation useful?
> >
> > The reason the instructions exist is so that
> > you can do fully fault
On Mon, Oct 28, 2013 at 10:21 PM, Jeff Law wrote:
> On 10/25/13 11:57, Ilya Enkovich wrote:
>
>>
>> There are currently two known issues with LTO. The first one is ICE in
>> LTO streamer when it reads instrumented code. The second one is
>> unitialized flag_check_pointers when code is compiled by
On Mon, Oct 28, 2013 at 9:16 PM, Mike Stump wrote:
> Ping?
Can you please get rid of PARTIAL_INT_MODE_NAME by
making the name a required argument to PARTIAL_INT_MODE?
Ok with that change (given target maintainers are ok with this).
Thanks,
Richard.
> On Oct 18, 2013, at 10:03 AM, Mike Stump w
On 29/10/13 09:12, Eric Botcazou wrote:
>> Updated patch, re-bootstrapped on x86_64 and committed to trunk.
>>
>> Also applied to 4.7 and 4.8 branches, the same problem is present there.
>
> You only asked for approval on trunk though,
Eric,
Sorry about that.
> and I'm not sure we really care
>
On 10/09/13 23:16, Christophe Lyon wrote:
Hi,
This patch is a first small sample of dejagnu-ization of my ARM Neon
intrinsics tests.
Thanks for attempting this and apologies for the slow response - I've
been busy with a few other things internally.
It's derived from my previous work at
ht
On Sun, Oct 27, 2013 at 7:55 PM, Andrew Pinski wrote:
> On Sat, Oct 26, 2013 at 4:49 PM, Andrew Pinski wrote:
>> On Sat, Oct 26, 2013 at 2:30 PM, Andrew Pinski wrote:
>>> On Fri, Oct 18, 2013 at 2:21 AM, Zhenqiang Chen
>>> wrote:
On 18 October 2013 00:58, Jeff Law wrote:
> On 10/17/13
Hi, all,
This is v4 patch for Andes nds32 port on libgcc part.
Thanks Joseph Myers's comments. Now we remove the .file directive
from crtzero.S. The rationale of this can be referred to:
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg00123.html
The diff is as follows and the patch file is atta
On Mon, Oct 28, 2013 at 11:05 PM, Marc Glisse wrote:
> On Mon, 28 Oct 2013, Jeff Law wrote:
>
>> On 10/26/13 01:15, Marc Glisse wrote:
>>>
>>> Hello,
>>>
>>> this patch teaches gcc that free kills the memory its argument points
>>> to. The equality test is probably too strict, I guess we can loose
This is v4 patch for Andes nds32 port on documentation part.
Thanks Joseph Myers's comments. Now we use @deftypefn and @samp
to refine our documentation content.
The diff is as follows and the patch file is attached.
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index f0002a9..5f91813
On Tue, Oct 29, 2013 at 6:35 AM, Jeff Law wrote:
> On 10/28/13 16:05, Marc Glisse wrote:
>>
>>
>> I checked and it does the wrong thing (I don't have the testcase handy
>> anymore, but it shouldn't be hard to recreate one), I even wrote a patch
>> (attached) but it is related to:
>> http://gcc.gnu
2013/10/29 Joseph S. Myers :
> Since Richard looked at the machine description part of the port, I looked
> at the other pieces. I'm happy with those pieces with the following minor
> changes:
>
> http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00520.html (libgcc): remove
> the .file directive from c
Hi,
On 10/28/2013 07:05 PM, Jason Merrill wrote:
My question is, why do we need that whole block for massaging VAR_DECL
initializers? That all ought to be handled properly by cp_finish_decl.
Does removing everything after
else if (!VAR_P (value))
gcc_unreachable ();
work?
In fact, it works
> Reverted on the 4.7 branch.
Thanks.
--
Eric Botcazou
On Fri, 25 Oct 2013, Jakub Jelinek wrote:
> Hi!
>
> As discussed on IRC, this patch attempts to preserve VRP computed
> range info for some simple __builtin_unreachable () using assertions.
> If there are no immediate uses of some SSA_NAME except for those in
> a condition guarding __builtin_unre
On Fri, 25 Oct 2013, Jakub Jelinek wrote:
> Hi!
>
> tree-ssa-ccp.c already computes which bits are known to be zero, but
> we preserve that info only for pointers and not for integers.
> This patch changes SSA_NAME_RANGE_INFO, so we preserve that info even for
> integers. The bitmask is also com
> Sorry for the delay, I finally found time to look at it.
Np, thanks for helping!
> While your patch fixes the issue, I wonder
> ...
> potentially increase register pressure.
Makes sense. I didn't take care of this because I believed that we can
freely allocate vregs and rely on register allo
Hi,
The vst_lane_ intrinsics should write
(sizeof (lane_type) * n) bytes to memory.
In their current form, their asm constraints suggest a write size of
(sizeof (vector_type) * n). This is anywhere from 1 to 16 times too
much data, can cause huge headaches with dead store elimination.
This patc
On Fri, 25 Oct 2013, Jakub Jelinek wrote:
> Hi!
>
> The following patch makes use of the computed nonzero_bits preserved
> in the SSA_NAME_RANGE_INFO.
> I chose to write a new routine instead of improving current
> highest_pow2_factor, because that routine didn't care about overflows etc.
> and b
> My reading of memory_address_addr_space is that MODE is the mode of the
> memory reference, not the mode of the address. I fail to see how
> passing in the mode of the address in the first call can be correct.
>
> What am I missing?
Nothing, it's me confusing
rtx memory_address_addr_space (en
> On Wed, Oct 2, 2013 at 12:51 PM, Konstantin Serebryany
> > 2013-10-XX Kostya Serebryany
> >
> > * g++.dg/asan/asan_test.cc: Update the test
> > to match the fresh asan run-time.
> > * c-c++-common/asan/stack-overflow-1.c: Ditto.
> >
> > === gcc/ChangeLog
> >
> >
Hi all,
This patch adds the new rtx costs for the Cortex-A7 core as well as a new tuning
structure to contain it.
Tested arm-none-eabi on qemu and no benchmark regressions.
Ok for trunk?
Thanks,
Kyrill
[gcc/]
2013-10-29 Kyrylo Tkachov
* config/arm/arm.c (cortexa7_extra_costs): New t
On 10/29/13 12:15, Kyrill Tkachov wrote:
Hi all,
This patch adds the new rtx costs for the Cortex-A7 core as well as a new tuning
structure to contain it.
Tested arm-none-eabi on qemu and no benchmark regressions.
Ok for trunk?
Ok.
Ramana
On Sun, 27 Oct 2013, Richard Sandiford wrote:
> Until now, eq_p and ne_p have enforced the same argument rules as things
> like addition, while order comparisons like lts_p have treated the two
> arguments as independent and signed. Richard, I think you said on IRC
> that you thought lts_p should
On Sun, 27 Oct 2013, Richard Sandiford wrote:
> This patch adds some more optimisations to the wi:: comparison functions.
> It uses the:
>
> #define CONSTANT(X) (__builtin_constant_p (X) && (X))
>
> idiom that was mentioned before, except that I thought CONSTANT would be
> too easily confused
Jakub Jelinek writes:
> On Wed, Oct 16, 2013 at 09:35:21AM +0400, Yury Gribov wrote:
>> >>> I've recently submitted a bug report regarding invalid
>> unpoisoning of stack frame redzones
>> (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58543). Could someone
>> take a look at proposed patch (a simple
Hi,
>> You are better off CCing the maintainers for such reviews. Let me do
>> that for you. I cannot approve or reject this patch but I have a few
>> comments as below.
Thanks for the quick review and comments.
Please find attached the modified patch as per review comments.
Please review the sa
On Tue, Oct 29, 2013 at 12:25:33PM +, Richard Sandiford wrote:
> >> Any updates on this one? Note that this bug is a huge blocker for
> >> using AddressSanitizer on ARM platforms.
> >
> > Sorry for the delay, I finally found time to look at it.
> > While your patch fixes the issue, I wonder if
Richard Biener writes:
> On Sun, 27 Oct 2013, Richard Sandiford wrote:
>> This patch adds some more optimisations to the wi:: comparison functions.
>> It uses the:
>>
>> #define CONSTANT(X) (__builtin_constant_p (X) && (X))
>>
>> idiom that was mentioned before, except that I thought CONSTANT
On 10/29/13 04:17, Richard Biener wrote:
On Mon, Oct 28, 2013 at 10:21 PM, Jeff Law wrote:
On 10/25/13 11:57, Ilya Enkovich wrote:
There are currently two known issues with LTO. The first one is ICE in
LTO streamer when it reads instrumented code. The second one is
unitialized flag_check_poi
Jakub Jelinek writes:
> On Tue, Oct 29, 2013 at 12:25:33PM +, Richard Sandiford wrote:
>> >> Any updates on this one? Note that this bug is a huge blocker for
>> >> using AddressSanitizer on ARM platforms.
>> >
>> > Sorry for the delay, I finally found time to look at it.
>> > While your patch
On Tue, Oct 29, 2013 at 01:06:21PM +, Richard Sandiford wrote:
> > If it is a pseudo, it is certainly a pseudo that isn't used for
> > anything else, as it is the result of (base >> 3) + constant, if it isn't a
> > pseudo, then supposedly it is better not to just keep adding the offsets to
> >
On Tue, Oct 29, 2013 at 06:49:30AM -0700, Konstantin Serebryany wrote:
> Thanks!
> (At this time I will be slow with response due to travel)
BTW, don't have compiled clang/llvm pre-3.4 around to look at, for the use
after return, do you emit always the the __asan_*malloc/free calls for the
stack v
On 29 Oct 06:59, Jeff Law wrote:
> On 10/29/13 04:17, Richard Biener wrote:
> >On Mon, Oct 28, 2013 at 10:21 PM, Jeff Law wrote:
> >>On 10/25/13 11:57, Ilya Enkovich wrote:
> >>
> >>>
> >>>There are currently two known issues with LTO. The first one is ICE in
> >>>LTO streamer when it reads instru
On Tue, Oct 29, 2013 at 12:28:49PM +0100, Richard Biener wrote:
> Otherwise ok.
So like this?
2013-10-29 Jakub Jelinek
* tree-cfg.c (assert_unreachable_fallthru_edge_p): New function.
* tree-cfg.h (assert_unreachable_fallthru_edge_p): New prototype.
* tree-vrp.c (all_i
On Tue, Oct 29, 2013 at 6:52 AM, Jakub Jelinek wrote:
> On Tue, Oct 29, 2013 at 06:49:30AM -0700, Konstantin Serebryany wrote:
>> Thanks!
>> (At this time I will be slow with response due to travel)
>
> BTW, don't have compiled clang/llvm pre-3.4 around to look at, for the use
> after return, do y
On Tue, 29 Oct 2013, Jakub Jelinek wrote:
> On Tue, Oct 29, 2013 at 12:28:49PM +0100, Richard Biener wrote:
> > Otherwise ok.
>
> So like this?
Yes, Thanks.
Richard.
> 2013-10-29 Jakub Jelinek
>
> * tree-cfg.c (assert_unreachable_fallthru_edge_p): New function.
> * tree-cfg.h (a
Just figured while "optimizing" Michas ADD_RESTRICT patch ...
(well, make it "work").
Tested on x86_64-unknown-linux-gnu, committed.
Richard.
2013-10-29 Richard Biener
* gcc.dg/torture/restrict-2.c: New testcase.
* gcc.dg/torture/restrict-3.c: Likewise.
* gcc.dg/tort
Hi,
PR 58789 has been fixed on trunk by revision 198743 which needs
cgraph_get_create_real_symbol_node introduced in revision 196750.
This patch backports both. It has been pre-approved by Honza in
person and passed bootstrap and testing on the branch. I am about
to commit it momentarily.
Thank
On 10/29/2013 02:51 AM, Bernd Edlinger wrote:
On Mon, 28 Oct 2013 21:29:24, Sandra Loosemore wrote:
I again tried backporting the patch series along with your fix to GCC
4.8 and tested on arm-none-eabi. I found that it was still getting
stuck in infinite recursion unless the test from this patc
On 10/28/2013 05:48 PM, Tobias Burnus wrote:
I am not completely sure whether you had the following in mind, but
that's what I have now implemented:
DEFTREECODE (RANGE_FOR_STMT, "range_for_stmt", tcc_statement, 4)
has now a 5th operator (RANGE_FOR_IVDEP), which has the value
boolean_true_node
OK.
Jason
On Sat, 26 Oct 2013, Jakub Jelinek wrote:
> Hi!
>
> And here is a patch that allows vectorization without peeling for alignment
> and scalar loop for bound even for fn2, fn3 and fn4 in the following
> testcase, though as with the range __builtin_unreachable () notes, it is
> quite fragile, becaus
On Tue, 29 Oct 2013, Jakub Jelinek wrote:
> On Sat, Oct 26, 2013 at 12:19:33AM +0200, Jakub Jelinek wrote:
> > And here is a patch that allows vectorization without peeling for alignment
> > and scalar loop for bound even for fn2, fn3 and fn4 in the following
> > testcase, though as with the range
Hi,
The problem here is that both asan and ubsan testsuite test if we
have set a library path before running the testsuite. This is
incorrect when running the already installed testing as there is no
path to set.
This patch changes it so it tests if the executable is able to be
built/linked bef
On 10/28/2013 06:12 PM, Dehao Chen wrote:
ping...
Sorry for the slow response.
If we're actually emitting the name now, we need to give it a name
different from the complete constructor. I suppose it makes sense to go
with C4/D4 as in the decloning patch,
http://gcc.gnu.org/ml/gcc-patches
On 10/29/13 04:40, Richard Biener wrote:
Of course in the example we have the "global memory" storage class
(incoming function argument) and "malloc memory" which is really
the same storage class. It only becomes a different storage class
if you factor in flow analysis (for which the current PT
On Wed, Aug 28, 2013 at 10:06 PM, Jeff Law wrote:
> On 08/28/2013 03:50 AM, Mikael Pettersson wrote:
>>
>> This patch fixes an ICE that occurs in #ifdef HAVE_cc0 code. The ICE
>> breaks both Java and Ada bootstrap on m68k-linux. There is also a
>> tiny C++ test case in the BZ entry.
>>
>> The IC
On Mon, Oct 28, 2013 at 10:51 PM, Jeff Law wrote:
> On 10/27/13 12:55, Andrew Pinski wrote:
>>
>> Here is my latest patch which adds the testcases from Zhenqiang's
>> patch and fixes item 1 and 2.
>>
>> OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
>>
>> Thanks,
>> Andrew P
On Tue, Oct 29, 2013 at 4:01 PM, Jeff Law wrote:
> On 10/29/13 04:40, Richard Biener wrote:
>>
>>
>> Of course in the example we have the "global memory" storage class
>> (incoming function argument) and "malloc memory" which is really
>> the same storage class. It only becomes a different storag
On 10/29/2013 08:43 AM, Richard Sandiford wrote:
Richard Biener writes:
On Sun, 27 Oct 2013, Richard Sandiford wrote:
This patch adds some more optimisations to the wi:: comparison functions.
It uses the:
#define CONSTANT(X) (__builtin_constant_p (X) && (X))
idiom that was mentioned befor
On Tue, Oct 29, 2013 at 12:55:04PM +0100, Richard Biener wrote:
> Surely you can't rely on CCP and VRP compute exactly the same
> nonzero_bits. As you don't record/compute zero_bits you can't
> tell whether a not set bit in nonzer_bits is "don't know" or
> if it is "zero". And you cannot do an as
On 10/29/13 09:15, Richard Biener wrote:
On Tue, Oct 29, 2013 at 4:01 PM, Jeff Law wrote:
On 10/29/13 04:40, Richard Biener wrote:
Of course in the example we have the "global memory" storage class
(incoming function argument) and "malloc memory" which is really
the same storage class. It o
On 10/29/13 06:10, Eric Botcazou wrote:
My reading of memory_address_addr_space is that MODE is the mode of the
memory reference, not the mode of the address. I fail to see how
passing in the mode of the address in the first call can be correct.
What am I missing?
Nothing, it's me confusing
2 target files also included lto-streamer.h but did not include
gimple.h.Fixed thusly.
Applied as revision 204166
Andrew
* config/darwin.c: Include gimple.h.
* config/i386/winnt.c: Likewise.
Index: config/darwin.c
===
***
On Mon, Oct 28, 2013 at 5:28 PM, Uros Bizjak wrote:
>> PR 58079 is about the do_SUBST assert:
>>
>> /* Sanity check that we're replacing oldval with a CONST_INT
>> that is a valid sign-extension for the original mode. */
>> gcc_assert (INTVAL (newval)
>> == trunc_int_for_mode (INTVA
On 10/29/13 00:38, Marc Glisse wrote:
Indeed. Do you want to commit it xfailed or put it in bugzilla so we
don't lose it? (it becomes harder if you replace p with p-1 in the
memset arguments).
I'll either add it as xfailed, or I'll add it as-is if I fix the alias
code. It'd primarly be to add
On Tue, Oct 29, 2013 at 01:11:53PM +0100, Richard Biener wrote:
> > +/* Return number of known trailing zero bits in EXPR, or, if the value of
> > + EXPR is known to be zero, the precision of it's type. */
> > +
> > +int
>
> unsigned int?
Ok.
> > +case PLUS_EXPR:
> > +case MINUS_EXPR:
On 10/25/2013 11:19 AM, Martin Jambor wrote:
> Hi,
>
> On Thu, Oct 24, 2013 at 01:02:51AM +0200, Steven Bosscher wrote:
>> On Wed, Oct 23, 2013 at 6:46 PM, Martin Jambor wrote:
>>
>>> /* Perform the second half of the transformation started in
>>> @@ -4522,7 +4704,15 @@ ira (FILE *f)
>>> all
On 10/29/13 10:03, David Malcolm wrote:
commit 739276306f1d8f5d0b1202da21cc29b5fcac102e
Author: David Malcolm
Date: Mon Oct 28 22:25:38 2013 -0400
Add chain_next and chain_prev options back to symtab_node_base
gcc/
* cgraph.h (symtab_node_base): Add missing chain_next and
This patch replaces the problematic use of _Hashtable_ebo_helper with
a new type.
2013-10-29 Jonathan Wakely
* include/bits/hashtable.cc (__access_protected_ctor): Define and use
new type instead of _Hashtable_ebo_helper.
* testsuite/23_containers/unordered_set/
On 10/29/13 09:12, Vladimir Makarov wrote:
Tomorrow I'd like commit the following patch.
The patch removes regmove pass.
I'm buying next time we get together :-) You have my eternal gratitude.
I've found only one useful transformations in regmove pass:
dst = src
On Tue, 29 Oct 2013, Chung-Ju Wu wrote:
> Thank you very much for the comments on libgcc and documentation parts.
> Here I re-list the v4 patch of nds32 port:
>
> Machine Description --
> http://gcc.gnu.org/ml/gcc-patches/2013-10/msg02153.html
> http://gcc.gnu.org/ml/gcc-patches/2013-10
On 10/28/2013 03:38 PM, Andrew MacLeod wrote:
I noticed there were a few .h files which we including tree-core.h
themselves. expr.h was one of them, and many of the rtl files used
that to get at the basic tree structure for various bits.
I moved the include of tree-core.h to rtl.h instead.
On 10/29/2013 03:02 AM, Kirill Yukhin wrote:
> Hello Richard,
>
> On 28 Oct 14:45, Richard Henderson wrote:
>> On 10/28/2013 01:58 PM, Kirill Yukhin wrote:
>>> Hello Richard,
>>> On 28 Oct 08:20, Richard Henderson wrote:
Why is a masked *scalar* operation useful?
>>>
>>> The reason the instru
Hello,
A very minor nit: in common.opt, entries for the options should be changed to
fregmove
Common Ignore
Does nothing. Preserved for backward compatibility.
instead of removing them altogether, so the compiler does not start rejecting
build commands with such options. There are now a few suc
Please change the .opt entries to
foptimize-register-move
Common Ignore
Does nothing. Preserved for backward compatibility.
and
fregmove
Common Ignore
Does nothing. Preserved for backward compatibility.
rather than removing them completely. In general, when removing an option
that's purely ab
On 10/29/2013 12:26 PM, Jeff Law wrote:
> On 10/29/13 09:12, Vladimir Makarov wrote:
>>I've found only one useful transformations in regmove pass:
>>
>>dst = srcdst = src (src dies)
>>... no dst or src modification => src changed on
On 10/29/2013 12:43 PM, Alexander Monakov wrote:
> Hello,
>
> A very minor nit: in common.opt, entries for the options should be changed to
>
> fregmove
> Common Ignore
> Does nothing. Preserved for backward compatibility.
>
> instead of removing them altogether, so the compiler does not start reje
On 10/29/2013 12:44 PM, Joseph S. Myers wrote:
> Please change the .opt entries to
>
> foptimize-register-move
> Common Ignore
> Does nothing. Preserved for backward compatibility.
>
> and
>
> fregmove
> Common Ignore
> Does nothing. Preserved for backward compatibility.
>
> rather than removing th
On Mon, Oct 28, 2013 at 9:49 PM, Xinliang David Li wrote:
> Is it sufficient to check if the final caller is defined in primary module?
This might not be sufficient because the final caller may come from
comdat of aux-modules (not defined in the primary module).
>
> Note that in some cases, doin
Hi!
On Tue, Oct 29, 2013 at 04:29:56PM +0100, Jakub Jelinek wrote:
> > Surely you can't rely on CCP and VRP compute exactly the same
> > nonzero_bits. As you don't record/compute zero_bits you can't
> > tell whether a not set bit in nonzer_bits is "don't know" or
> > if it is "zero". And you can
On Tue, Oct 29, 2013 at 1:38 AM, Uros Bizjak wrote:
> Hello!
>
>> For the define_expand I added as below, the else body is there to
>> avoid fall-through transformations to ABS operation in optabs.c.
>> Otherwise ABS will be converted to other operations even that we have
>> corresponding instruct
On 10/29/13 10:46, Vladimir Makarov wrote:
On 10/29/2013 12:26 PM, Jeff Law wrote:
On 10/29/13 09:12, Vladimir Makarov wrote:
I've found only one useful transformations in regmove pass:
dst = srcdst = src (src dies)
... no dst or src
On Tue, Oct 29, 2013 at 6:18 PM, Cong Hou wrote:
>>> For the define_expand I added as below, the else body is there to
>>> avoid fall-through transformations to ABS operation in optabs.c.
>>> Otherwise ABS will be converted to other operations even that we have
>>> corresponding instructions from
On Tue, Oct 29, 2013 at 7:58 AM, Jason Merrill wrote:
> On 10/28/2013 06:12 PM, Dehao Chen wrote:
>>
>> ping...
>
>
> Sorry for the slow response.
>
> If we're actually emitting the name now, we need to give it a name different
> from the complete constructor. I suppose it makes sense to go with
The situation you described is worse -- hopefully it will be addressed
in the next version of lipo.
The change is ok.
David
On Tue, Oct 29, 2013 at 10:08 AM, Dehao Chen wrote:
> On Mon, Oct 28, 2013 at 9:49 PM, Xinliang David Li wrote:
>> Is it sufficient to check if the final caller is define
On 10/29/13 03:53, Martin Liška wrote:
Hello,
I've noticed that some part of documentation is obsolete and this
patch adds documentation for new functions that replace old macros.
[ ... ]
Thanks. Installed on the trunk.
jeff
On 10/29/13 09:14, Andrew Pinski wrote:
On Mon, Oct 28, 2013 at 10:51 PM, Jeff Law wrote:
On 10/27/13 12:55, Andrew Pinski wrote:
Here is my latest patch which adds the testcases from Zhenqiang's
patch and fixes item 1 and 2.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressio
On 29 October 2013 03:24, Ramana Radhakrishnan wrote:
> On 10/09/13 23:16, Christophe Lyon wrote:
> Irrespective of our earlier conversations on this now I'm actually wondering
> if instead of doing this and integrating this in the GCC source base it
> maybe easier to write a harness to test this
On Tue, Oct 29, 2013 at 10:34 AM, Uros Bizjak wrote:
> On Tue, Oct 29, 2013 at 6:18 PM, Cong Hou wrote:
>
For the define_expand I added as below, the else body is there to
avoid fall-through transformations to ABS operation in optabs.c.
Otherwise ABS will be converted to other oper
This patch fixes a profiledbootstrap failure that occurred after I
added some profile fixup. The initial profile insanity occurred
upstream of my change, but my change caused the insanity to spread to
the edge probability, resulting in a verify failure. The patch below
ensures this doesn't occur.
On 10/24/13 02:20, Zhenqiang Chen wrote:
Hi,
REG_INC note is lost in subreg2 pass when resolve_simple_move, which
might lead to wrong dependence for ira. e.g. In function
validate_equiv_mem of ira.c, it checks REG_INC note:
for (note = REG_NOTES (insn); note; note = XEXP (note, 1))
On Mon, 2013-10-28 at 23:37 -0600, Jeff Law wrote:
> On 10/28/13 20:57, David Malcolm wrote:
> >>> * cgraph.h (symtab_node_base): Convert to a class;
> >>> add GTY((desc ("%h.type"), tag ("SYMTAB_SYMBOL"))).
> >>> (cgraph_node): Inherit from symtab_node; add GTY option
> >>> tag ("SYMTAB_FU
On 10/29/13 00:38, Marc Glisse wrote:
On Mon, 28 Oct 2013, Jeff Law wrote:
On 10/28/13 16:05, Marc Glisse wrote:
I checked and it does the wrong thing (I don't have the testcase handy
anymore, but it shouldn't be hard to recreate one), I even wrote a patch
(attached) but it is related to:
htt
>
> The conversion of the symtab types from inheritance-in-C to a C++ class
> hierarchy is now in trunk: I committed the manual parts of the
> conversion as r204170, and the automated part as r204171. I then
> noticed that this broke the gdb debugging hooks for printing a
> (cgraph_node *). I te
On 10/29/13 07:52, Ilya Enkovich wrote:
Yeah. I'm working on it right now. I've fixed known issues and now
I'm looking for others. Meanwhile here is a new patch version with
required renames and without LTO restriction.
I can't help but but curious, what turned out to be the root cause of
th
1 - 100 of 133 matches
Mail list logo
