Hi Mike,
As discussed on irc, I'm applying the following as obvious to fix a
bug in the vsx fusion peepholes. The bug is simply that the peepholes
are enabled when -mno-vsx, which leads to replacing RTL that would
emit lvx insns with RTL that emits lxvw4x or lxvd2x. This is clearly
wrong, and wor
On Sat, Nov 23, 2013 at 1:57 AM, Wei Mi wrote:
> On Fri, Nov 22, 2013 at 9:21 AM, Wei Mi wrote:
>>> I think the problem can be showed by below example:
>>> struct tag
>>> {
>>> int a[10];
>>> int b;
>>> };
>>> struct tag s;
>>> int foo(int len)
>>> {
>>> int i = 0;
>>> int sum = 0;
>>>
Hi Joseph,
Thank you for the detail explanation.
> You need to ensure that, when new glibc is built, whatever compiler it's
> built with, it continues to export the __stack_chk_guard symbol at version
> GLIBC_2.17. Furthermore, if any released GCC version would generate
> references to __stack_c
On Fri, Nov 22, 2013 at 10:41 AM, Bill Schmidt
wrote:
> Hi,
>
> Most of our constant vector permutes use the vperm instructions, but for
> V2DImode and V2DFmode we use xxpermdi. This patch corrects the
> generated xxpermdi to be correct for little endian, which fixes failures
> of the test cases
Hi All,
This RFC patch enables new divide algorithm for ARMV7-A
Regression tested on arm-none-linux-gnueabi with no issues.
OK?
Thanks,
Kugan
+2013-11-22 Kugan Vivekanandarajah
+
+ * libgcc/config/arm/pbapi-lib.h (HAVE_NO_HW_DIVIDE): Define for
+ __ARM_ARCH_7_A__.
+
diff --git a
Hi All,
This RFC patch series implements a simple align divisor shift dividend
method.
Regression tested on arm-none-linux-gnueabi with no issues.
OK?
Thanks,
Kugan
+2013-11-22 Kugan Vivekanandarajah
+
+ * libgcc/libgcc2.c (__udivmoddi4): Define new implementation when
+ HAVE_NO
Upps, one comment I missed
- Original Message -
> On 11/21/13 08:15, Kai Tietz wrote:
>
> WHen I looked over a bunch of .i files, the results were mixed.
> Sometimes better, sometimes worse without any clear bias.
>
> So here's an example that gets worse:
>
>
> *** rshift_
Hi All,
This RFC patch series implements a simple align divisor shift dividend
method for 64bit divide and enables for ARMv7-a.
This algorithm runs (K+1) times where K is the number of bits divisor is
shifted to align. I have done repeated divides and found that this
implementation performs bett
- Original Message -
> On 11/21/13 08:15, Kai Tietz wrote:
> > Hi,
> >
> > this is the required forward-propagation part for the type-demotion pass as
> > separate patch.
> > This patch is sharing some adjustments in testsuite due new optimization of
> > type-casts on shift-operations.
> >
On Mon, 18 Nov 2013, Jan Hubicka wrote:
> there was many changes in this area. The following are ones I can think
> of. Please fell free to suggest more changes. We probably should mention
> Teresa's splitting work once it is complete and new micro-architectures
> targetd by x86 backend.
Yes,
Hi
Currently in GCC vectorization, some loop invariant may be detected
after aliasing checks, which can be hoisted outside of the loop. The
current method in GCC may break the information built during the
analysis phase, causing some crash (see PR59006 and PR58921).
This patch improves the loop i
fixing SMS, do you mean that we only modify the SMS pass?
if so, the problem we have to solve:
* how to make unroll and sms work together? calling unroll pass in sms,
but it would be needed more passes such as web, and it's perfect to rerun
all the passes between unroll and sms.
* unroll and
Richard Sandiford wrote:
> I have a patch to upgrade most genrecog warnings into errors. This patch
> fixes the ones for sh. There were some warnings about the match_operands
> in some define_peephole2s having constraints. There were also a few
> cases where a destination predicate allowed a co
On 11/21/13 08:15, Kai Tietz wrote:
Hi,
this is the required forward-propagation part for the type-demotion pass as
separate patch.
This patch is sharing some adjustments in testsuite due new optimization of
type-casts on shift-operations.
This patch tries to generate the "normal" form (TYPE)
ok thanks.
David
On Fri, Nov 22, 2013 at 1:59 PM, Dehao Chen wrote:
> Patch updated...
>
> There is no performance change with/without the patch. I think this
> was used to workaround the debug info accuracy issue. But after debug
> info is more improved now, the heuristic is not needed any more
use-linux --
prefix=/home/eric/install/gcc --enable-languages=c,c++,objc,obj-
c++,java,fortran,ada --enable-checking=yes,rtl --enable-__cxa_atexit --
disable-nls
Thread model: posix
gcc version 4.9.0 20131122 (experimental) [trunk revision 205244] (GCC)
> I'm having a hard time seeing wh
> I back ported your list of changes from mainline to GCC 4.8. See the
> attached patches. In addition to your proposed changes I had to add
>
> 2013-04-10 Steven Bosscher
>
> * config/sparc/sparc.c: Include tree-pass.h.
> (TARGET_MACHINE_DEPENDENT_REORG): Do not redefine.
>
Patch updated...
There is no performance change with/without the patch. I think this
was used to workaround the debug info accuracy issue. But after debug
info is more improved now, the heuristic is not needed any more.
Thanks,
Dehao
Index: gcc/auto-profile.c
On Fri, Nov 22, 2013 at 4:03 AM, Richard Biener
wrote:
> On Fri, Nov 22, 2013 at 4:51 AM, Rong Xu wrote:
>> Hi,
>>
>> This patch injects a condition into the instrumented code for edge
>> counter update. The counter value will not be updated after reaching
>> value 1.
>>
>> The feature is under a
Michael Matz wrote:
after much pondering about the issue we came up with this design to
handle restrict more generally.
Cool! Thanks for the last-minute patch.
If I understand the patch correctly, it does handle the problem of
inlining restrict pointers correctly – which was previously a
mis
Andi Kleen writes:
PING^4 if it isn't already too late for 4.9.
> Andi Kleen writes:
>
>
> PING^3
>
> Since it doesn't look like a generic solution for the
> LTO options problem will appear this development cycle,
> I would still like to pursue this option for 4.9.
> This would help fixing part
.
(store_bit_field): Fix formatting.
2013-11-22 Eric Botcazou
* gcc.c-torture/execute/20131122-1.c: New test.
It looks like this patch was for gcc-4.8; the code has changed a little
since then.
I'm having a hard time seeing why this change was made:
/* Optimize the access just
On Fri, Nov 22, 2013 at 12:27 PM, Dehao Chen wrote:
> This patch removes the zero_edge heuristic during profile propagation.
> The zero_edge heuristic does not seem to be effective in improving
> performance.
"not effective" here means degrading performance?
David
>
> Tested:
> Bootstrapped and
On Fri, Nov 22, 2013 at 09:47:13PM +0100, Dodji Seketeli wrote:
> > This patch adds support for -fsanitize=leak and -static-liblsan options.
> > If combined with -fsanitize=address, it does nothing,
>
> >From this hunk:
>
> @@ -8123,7 +8133,10 @@ sanitize_spec_function (int argc, const
>
On Fri, Nov 22, 2013 at 3:27 PM, Dehao Chen wrote:
> This patch removes the zero_edge heuristic during profile propagation.
> The zero_edge heuristic does not seem to be effective in improving
> performance.
>
> Tested:
> Bootstrapped and passed regression test and performance test.
>
> OK for goo
Jakub Jelinek writes:
> This patch adds support for -fsanitize=leak and -static-liblsan options.
> If combined with -fsanitize=address, it does nothing,
>From this hunk:
@@ -8123,7 +8133,10 @@ sanitize_spec_function (int argc, const
return (flag_sanitize & SANITIZE_THREAD) ? "" : N
On 11/21/13 03:49, Jan Hubicka wrote:
Hi,
this patch fixes problem with missing dump files with -flto and vectorizer
and also silence error in gcc.dg/20081223-1.c testcase. We ought to error
these even w/o -ffat-lto-objects, I will look into it ASAP.
We need to move these errors from varasm/wrap
On Mon, Nov 18, 2013 at 9:57 AM, Ulrich Weigand
wrote:
> Ian Lance Taylor wrote on 18.11.2013 18:32:08:
>> On Sun, Nov 17, 2013 at 2:00 PM, Ulrich Weigand
> wrote:
>> >
>> > - It seems you've already updated libgo's libtool.m4 to support
> powerpc64le.
>> > However, the patch to fix this unfor
On Nov 22, 2013, at 12:03 PM, Richard Biener wrote:
> For the merge you want to have trunk frozen
I can do the required work without needing the trunk frozen. I prefer to not
freeze.
On 11/22/13 13:05, Steven Bosscher wrote:
On Fri, Nov 22, 2013 at 11:09 AM, Jeff Law wrote:
So we've long had an arbitrary restriction in the jump thread identification
code which made it very conservative when searching for threading
opportunities once it encountered a back edge.
You're addi
This patch removes the zero_edge heuristic during profile propagation.
The zero_edge heuristic does not seem to be effective in improving
performance.
Tested:
Bootstrapped and passed regression test and performance test.
OK for google-4_8?
Thanks,
Dehao
Index: gcc/auto-profile.c
===
Hi
> On 22/nov/2013, at 21:12, Jakub Jelinek wrote:
>
> Hi!
>
> I've noticed recently that the 28_regex/ tests look very expensive
> testing time wise, while there are only ~ 120 tests, I'm routinely seeing
> 28_regex/* complete last. This patch moves the most expensive 28_regex/
> tests ([ab]
On 11/22/2013 03:03 PM, Richard Biener wrote:
On Thu, Nov 21, 2013 at 11:08 PM, Mike Stump wrote:
This patch adds support for ints wider than double_int.
Ok?
Please split the patch into pieces. I suggest to separate changes to
the various frontends
(CC maintainers), the new wide-int files,
Hi!
This PR is about what I understood (can't reproduce, seems ltoish)
about reassoc now creating say _24 = (int) 0; with _Bool 0, and
forwprop ICEing on that.
The patch fixes forwprop not to ICE on it (I think we don't require
the IL to be always folded), and reassoc not to create it in this cas
Hi!
I've noticed recently that the 28_regex/ tests look very expensive
testing time wise, while there are only ~ 120 tests, I'm routinely seeing
28_regex/* complete last. This patch moves the most expensive 28_regex/
tests ([ab]*, about 2/3 of all the regex tests) to a separate job, while
one of
On Fri, Nov 22, 2013 at 11:09 AM, Jeff Law wrote:
>
> So we've long had an arbitrary restriction in the jump thread identification
> code which made it very conservative when searching for threading
> opportunities once it encountered a back edge.
You're adding a pretty complex piece of code, for
On Thu, Nov 21, 2013 at 11:08 PM, Mike Stump wrote:
> This patch adds support for ints wider than double_int.
>
> Ok?
>
Please split the patch into pieces. I suggest to separate changes to
the various frontends
(CC maintainers), the new wide-int files, the example rs6000
conversion and the rest.
On Fri, Nov 22, 2013 at 11:13:26PM +0400, Konstantin Serebryany wrote:
> +eugenis, dvyukov
> libbacktrace doesn't call malloc -- good.
> Most other functions it does call (memset,strlen, etc) will be
> rerouted to sanitizer interceptors.
> This is just generally scary and I think we've been hit by
-22 Eric Botcazou
* gcc.c-torture/execute/20131122-1.c: New test.
--
Eric Botcazou/* PR middle-end/59138 */
/* Testcase by John Regehr */
extern void abort (void);
#pragma pack(1)
struct S0 {
int f0;
int f1;
int f2;
short f3;
};
short a = 1;
struct S0 b = { 1 }, c, d, e
On Fri, Nov 22, 2013 at 3:57 AM, Marc Glisse wrote:
> On Thu, 21 Nov 2013, Cong Hou wrote:
>
>> On Thu, Nov 21, 2013 at 4:39 PM, Marc Glisse wrote:
>>>
>>> On Thu, 21 Nov 2013, Cong Hou wrote:
>>>
While I added the new define_insn_and_split for vec_merge, a bug is
exposed: in config/i38
On Fri, Nov 22, 2013 at 1:32 AM, Uros Bizjak wrote:
> Hello!
>
>> In consequence, the ix86_expand_multi_arg_builtin() function tries to
>> check two args but based on the define_expand of xop_vmfrcz2,
>> the content of insn_data[CODE_FOR_xop_vmfrczv4sf2].operand[2] may be
>> incorrect (because it
On 11/21/13 10:09, Martin Jambor wrote:
PR rtl-optimization/10474
* ira.c (interesting_dest_for_shprep_1): New function.
(interesting_dest_for_shprep): Use interesting_dest_for_shprep_1,
also check parallels.
testsuite/
* gcc.dg/pr10474.c: Also test ppc64.
+eugenis, dvyukov
libbacktrace doesn't call malloc -- good.
Most other functions it does call (memset,strlen, etc) will be
rerouted to sanitizer interceptors.
This is just generally scary and I think we've been hit by this in
reality with early llvm-symbolizer.
More likely in tsan and msan than in
On Thu, Nov 21, 2013 at 10:03:39PM -0500, David Edelsohn wrote:
> Okay.
>
> I look forward to clean test results :-).
I committed this on subversion id 205278. We still have these 3 long standing
bugs:
gcc.target/powerpc/405-dlmzb-strlen-1.c 32-bit fail
gcc.target/powerpc/440-dlmzb-strl
On Fri, Nov 22, 2013 at 10:40:00PM +0400, Konstantin Serebryany wrote:
> [I beg my pardon if this has already been discussed here]
> Does libbacktrace call any functions we intercept (malloc, memset,
> memcpy, strlen, etc)?
> If so, they will have to be un-intercepted there.
Why?
> Our hermetic l
There was a typo/thinko in the version I posted last night (reversed
arguments to a bitmap_copy call) that I spotted this morning. Those
were some of the newer bits to get the maps reset after handling each
successor of a joiner block.
So re-bootstrapped and re-regression tested on x86_64-u
[I beg my pardon if this has already been discussed here]
Does libbacktrace call any functions we intercept (malloc, memset,
memcpy, strlen, etc)?
If so, they will have to be un-intercepted there.
Our hermetic llvm-symbolizer took as so much work for a reason. :(
And doing this work for libbacktrac
On Fri, Nov 22, 2013 at 10:19:02PM +0400, Alexey Samsonov wrote:
> On Tue, Nov 19, 2013 at 8:42 PM, Jakub Jelinek wrote:
> > Ok, here it is (untested though, because libsanitizer in gcc is older and I
> > don't have spare cycles to play with llvm).
> > Guess you need to write it up into compiler-r
On Fri, Nov 22, 2013 at 10:19 AM, Alexey Samsonov wrote:
> On Tue, Nov 19, 2013 at 8:42 PM, Jakub Jelinek wrote:
>>
>> On Tue, Nov 19, 2013 at 04:33:50PM +0100, Jakub Jelinek wrote:
>> > I will try.
>>
>> Ok, here it is (untested though, because libsanitizer in gcc is older and I
>> don't have sp
On Tue, Nov 19, 2013 at 8:42 PM, Jakub Jelinek wrote:
>
> On Tue, Nov 19, 2013 at 04:33:50PM +0100, Jakub Jelinek wrote:
> > I will try.
>
> Ok, here it is (untested though, because libsanitizer in gcc is older and I
> don't have spare cycles to play with llvm).
> Guess you need to write it up int
On Fri, Nov 22, 2013 at 9:21 AM, Wei Mi wrote:
>> I think the problem can be showed by below example:
>> struct tag
>> {
>> int a[10];
>> int b;
>> };
>> struct tag s;
>> int foo(int len)
>> {
>> int i = 0;
>> int sum = 0;
>> for (i = 0; i < len; i++)
>> sum += barr (&s.a[i]);
>>
>>
On Fri, Nov 22, 2013 at 09:46:47PM +0400, Alexander Potapenko wrote:
> Side note: init order checking isn't supposed to work on Darwin, at least
> for now.
I'll let Darwin maintainers/users if any to worry about it, that said,
does it have any compiler side effects (like, that dynamic_init shouldn
> I think the problem can be showed by below example:
> struct tag
> {
> int a[10];
> int b;
> };
> struct tag s;
> int foo(int len)
> {
> int i = 0;
> int sum = 0;
> for (i = 0; i < len; i++)
> sum += barr (&s.a[i]);
>
> return sum;
> }
> The dump before IVOPT is like:
>
> :
>
On Fri, Nov 22, 2013 at 6:11 AM, Zdenek Dvorak wrote:
> Hi,
>
>> >> > If a pointer typed use is plainly value passed to a func call, it is
>> >> > not an address use, right? But as you said, x86 lea may help here.
>> >>
>> >> But that's what you are matching ... (well, for builtins you know
>> >>
On 11/22/13 01:22, Richard Sandiford wrote:
I have a patch to upgrade most genrecog warnings into errors. This patch
fixes one for mn10300 about mn10300_store_multiple_operation not being
defined as a predicate at the .md level.
Tested by building mn10300-elf with the warnings turned to errors,
This fixes the versioned namespace build by moving some macros and
adding std::experimental in c++config.
Bootstrap works again now, but regex tests all fail with versioned
namespaces due to a lookup problem with friend functions and inline
namespaces (PR 59256).
2013-11-22 Jonathan Wakely
On Fri, Nov 30, 2012 at 11:33 AM, H.J. Lu wrote:
> Hi,
>
> Toplevel configure supports:
>
> # Handle --enable-gold, --enable-ld.
> # --disable-gold [--enable-ld]
> # Build only ld. Default option.
> # --enable-gold [--enable-ld]
> # Build both gold and ld. Install gold as "ld.gold", inst
On Fri, 22 Nov 2013, Andrew MacLeod wrote:
> The target hook patch is checked into mainline, revision 205273.
Thanks!
The target patch is there too now; tested with the previous
version of the hook-patch. I'm confident my autotester will
yell at me if I goofed.
gcc:
* config/cris/cris.c
On 11/18/2013 04:50 PM, Iyer, Balaji V wrote:
+ int flags = LOOKUP_PROTECT | LOOKUP_ONLYCONVERTING;
Why not LOOKUP_NORMAL? LOOKUP_ONLYCONVERTING isn't relevant in this context.
+ tree exp = build_new_op (EXPR_LOCATION (op1), code, flags, op0, op1,
+ NULL_TREE, NULL,
On Fri, Nov 22, 2013 at 2:19 AM, Richard Biener wrote:
> On Thu, 21 Nov 2013, Xinliang David Li wrote:
>
>> On Thu, Nov 21, 2013 at 10:03 AM, Michael Matz wrote:
>> > Hello,
>> >
>> > after much pondering about the issue we came up with this design to
>> > handle restrict more generally. Without
On 11/22/13 08:15, Jakub Jelinek wrote:
On Fri, Nov 22, 2013 at 10:10:26AM -0500, Vladimir Makarov wrote:
It looks ok to me, Martin. The only problem is stage 3 start today.
I don't know what to do in this situation. So let the release
managers decide this. On the other hand a new bug (a miss
On Fri, Nov 22, 2013 at 8:17 AM, Uros Bizjak wrote:
> On Fri, Nov 22, 2013 at 4:55 PM, H.J. Lu wrote:
>
>>> This is addendum to H.J.'s patch for SIlvermont.
>>>
>>> Testing is in progress.
>>>
>>> Is it OK for the trunk after testing completion?
>>>
>>> 2013-11-22 Yuri Rumyantsev
>>>
>>> libgc
On 11/22/13 08:56, Richard Biener wrote:
So the issue here is we can create irreducible regions & new nested
loops. Does just setting the header,latch fields for the current loop
handle those cases?
Yes.
Good. I'll take care of it.
Thanks,
Jeff
On 11/21/2013 06:40 PM, Hans-Peter Nilsson wrote:
On Thu, 21 Nov 2013, Hans-Peter Nilsson wrote:
with this/these patches
at least I'll be able to tell people that _Atomic for C11 works.
Oh right, gcc still doesn't remove target-introduced "manual"
alignment checks (when expanding atomic intrins
On Fri, Nov 22, 2013 at 8:02 AM, Andrew MacLeod wrote:
> On 11/21/2013 02:31 PM, Jeff Law wrote:
>>
>> On 11/21/13 11:15, Andrew MacLeod wrote:
>>>
>>>
>>>
>>> This bootstraps on x86_64-unknown-linux-gnu, and regressions are
>>> currently running. Assuming it passes fine, OK?
>>
>> patch#1 in the
On Fri, Nov 22, 2013 at 4:55 PM, H.J. Lu wrote:
>> This is addendum to H.J.'s patch for SIlvermont.
>>
>> Testing is in progress.
>>
>> Is it OK for the trunk after testing completion?
>>
>> 2013-11-22 Yuri Rumyantsev
>>
>> libgcc:
>>
>> * config/i386/cpuinfo.c (get_intel_cpu): Add Silvermont
Jakub Jelinek writes:
> On Fri, Nov 22, 2013 at 04:38:58PM +0100, Dodji Seketeli wrote:
>> Jakub Jelinek writes:
>>
>> > --- gcc/cgraph.h.jj2013-11-13 18:32:52.0 +0100
>> > +++ gcc/cgraph.h 2013-11-15 12:05:25.950985500 +0100
>> > @@ -520,6 +520,11 @@ class GTY((tag ("SYMTAB_V
On Fri, Nov 22, 2013 at 10:11 PM, Zdenek Dvorak
wrote:
> Hi,
>
>> >> > If a pointer typed use is plainly value passed to a func call, it is
>> >> > not an address use, right? But as you said, x86 lea may help here.
>> >>
>> >> But that's what you are matching ... (well, for builtins you know
>> >>
On 11/21/2013 02:31 PM, Jeff Law wrote:
On 11/21/13 11:15, Andrew MacLeod wrote:
This bootstraps on x86_64-unknown-linux-gnu, and regressions are
currently running. Assuming it passes fine, OK?
patch#1 in the series is fine too.
Checked in as revision 205272.
Ian, here is the go frontend
Jeff Law wrote:
>On 11/22/13 05:10, Richard Biener wrote:
>
>>> + if (totally_clobbered_loops)
>>> +{
>>> + /* Release the current loop structures, they are totally
>>> +clobbered at this point. */
>>> + loop_optimizer_finalize ();
>>> + current_loops = NULL;
>>
>> Thi
On Fri, Nov 22, 2013 at 7:40 AM, Yuri Rumyantsev wrote:
> Hi,
>
> This is addendum to H.J.'s patch for SIlvermont.
>
> Testing is in progress.
>
> Is it OK for the trunk after testing completion?
>
> 2013-11-22 Yuri Rumyantsev
>
> libgcc:
>
> * config/i386/cpuinfo.c (get_intel_cpu): Add Silverm
On Fri, Nov 22, 2013 at 04:38:58PM +0100, Dodji Seketeli wrote:
> Jakub Jelinek writes:
>
> > --- gcc/cgraph.h.jj 2013-11-13 18:32:52.0 +0100
> > +++ gcc/cgraph.h2013-11-15 12:05:25.950985500 +0100
> > @@ -520,6 +520,11 @@ class GTY((tag ("SYMTAB_VARIABLE"))) var
> > public:
> >/
On 13/11/22 10:31 PM, Bernd Schmidt wrote:
>> If you don't object, I'll keep the clobbers there for now.
>
> If they serve no purpose (and I think they don't), they should go.
I'll check again, but I remember df_regs_ever_live_p doesn't include the
RA reg if the call pattern doesn't have the clob
On 11/22/2013, 8:08 AM, dxq wrote:
hi,
I'm doing a work to make unroll, doloop, and sms pass work together as
following way:
* before the first unroll pass, duplicate all global information such as
insn chain and CFG as backup.
* unroll with factor = 1, go on to finish sms, and record the
On 11/21/2013 05:40 PM, Iyer, Balaji V wrote:
+/* Returns a TRY_CATCH_EXPR that will encapsulate BODY, EXCEPT_DATA and
+ EXCEPT_FLAG. */
+
+tree
+create_cilk_try_catch (tree except_flag, tree except_data, tree body)
+{
+ tree catch_list = alloc_stmt_list ();
+ append_to_statement_list (excep
In PR target/59216 we have a case where the compiler generates incorrect
code for (neg:DI (sign_extend:DI (reg:SI))). This splitter pattern
generates the wrong output when the register contains INT_MIN.
The shortest sequence we can use here is three insns, but since there
are cases where not havi
On Thu, Nov 21, 2013 at 1:22 PM, Cary Coutant wrote:
> I've made a small revision to this patch to handle recursive
> invocations of d_expression and d_operator_name, restoring the
> previous values of is_expression and is_conversion instead of just
> setting them to 0 upon return. I've also added
On 11/22/13 05:10, Richard Biener wrote:
+ if (totally_clobbered_loops)
+{
+ /* Release the current loop structures, they are totally
+clobbered at this point. */
+ loop_optimizer_finalize ();
+ current_loops = NULL;
This is definitely a no-go and should be immedia
Hi,
Most of our constant vector permutes use the vperm instructions, but for
V2DImode and V2DFmode we use xxpermdi. This patch corrects the
generated xxpermdi to be correct for little endian, which fixes failures
of the test cases gcc.dg/torture/vshuf-v2d[fi].c. Note that we can't
fix this direc
Dodji Seketeli writes:
> Also, do we have some tests for this? I am not sure how I'd write
> multi-tu dejagnu tests for this myself though ;-)
Woops, I have just seen the sub-thread about the tests with Konstantin,
you and Alexey. Sorry.
Cheers.
--
Dodji
On Fri, Nov 22, 2013 at 03:19:35PM +, Marcus Shawcroft wrote:
> 2013/11/21 Alex Velenko :
>
> > 2013-11-21 Alex Velenko
> >
> > * config/aarch64/arm_neon.h (vmov_n_f32): Implemented in C.
> > (vmov_n_f64): Likewise.
> > (vmov_n_p8): Likewise.
Hi,
This is addendum to H.J.'s patch for SIlvermont.
Testing is in progress.
Is it OK for the trunk after testing completion?
2013-11-22 Yuri Rumyantsev
libgcc:
* config/i386/cpuinfo.c (get_intel_cpu): Add Silvermont cases.
gcc:
* config/i386/i386.c(processor_alias_table): Enable PTA_AES
Hello,
Jakub Jelinek writes:
> --- gcc/cgraph.h.jj 2013-11-13 18:32:52.0 +0100
> +++ gcc/cgraph.h 2013-11-15 12:05:25.950985500 +0100
> @@ -520,6 +520,11 @@ class GTY((tag ("SYMTAB_VARIABLE"))) var
> public:
>/* Set when variable is scheduled to be assembled. */
>unsigne
On Nov 22, 2013, at 3:43 AM, Richard Sandiford
wrote:
> genrecog does some useful sanity checks on the .md files. At the moment
> it only reports most of the problems as warnings though, which means you
> won't notice them unless you specifically look.
>
> I think the only message in validate
2013/11/21 Alex Velenko :
> 2013-11-21 Alex Velenko
>
> * config/aarch64/arm_neon.h (vmov_n_f32): Implemented in C.
> (vmov_n_f64): Likewise.
> (vmov_n_p8): Likewise.
> (vmov_n_p16): Likewise.
> (vmov_n_s8): Likewis
On Fri, Nov 22, 2013 at 10:10:26AM -0500, Vladimir Makarov wrote:
> It looks ok to me, Martin. The only problem is stage 3 start today.
> I don't know what to do in this situation. So let the release
> managers decide this. On the other hand a new bug (a missed
> optimization opportunity) can be
Hi,
The vtbx_8 and vtbx_psu>8 intrinsics were buggy and could
generated junk. We fix that by moving their emulation to use
other neon intrinsics.
These new intrinsic sequences are closely inspired by
those suggested in the latest version of the Neon Intrinsics
specification.
Tested on aarch64-n
Hi,
I've spotted that our emulation of the behaviour of the vtbx1
and vtbx3 intrinsics is not correct. From time to time we end up
with completely the wrong value.
Rather than fix this by rewriting the assembler block I'd rather
rewrite vtbx{1,3} in terms of other intrinsics.
To do that effectiv
Hi,
This patch wires up the bsl intrinsics in arm_neon.h
using builtins.
Regression tested on aarch64-none-elf with no regressions.
OK?
Thanks,
James
---
gcc/
2013-11-22 James Greenhalgh
* config/aarch64/aarch64-builtins.c
(aarch64_types_bsl_p_qualifiers): New.
(a
Hi,
It would be helpful if the new Simd types infrastructure could also
handle Poly types. Wire this up. This also has the side effect of
allowing us to properly model Poly types as unsigned types.
Tested on aarch64-none-elf with no regressions.
OK?
Thanks,
James
---
2013-11-22 James Greenha
Hi,
One oversight in the design for the AArch64 Simd Builtins type
building foo I put in this week is that you cannot have both
signed and unsigned versions of the same builtin.
Although I solved the problem at a user level by appending a "type"
string to the builtin name, I didn't manage to sol
On 11/21/2013, 12:09 PM, Martin Jambor wrote:
Hi,
the patch below enables IRA live-range splitting that later
facilitates shrink-wrapping also work on ppc64. The difference is
that while on x86_64 it was enough to look for single sets from a hard
register to a pseudo in the first BB, on ppc the
Thanks for the feedback, Richard. I'll do some experiment to see if I
can get the post-expansion validation work.
Regards,
Yufeng
On 11/22/13 13:48, Richard Biener wrote:
On Fri, Nov 22, 2013 at 2:00 PM, Yufeng Zhang wrote:
Hi,
Currently the address legitimization (by calling memory_addres
I am sorry that in the haste of battle that mike did not have an
opportunity to write a proper introduction to the is patch. The patch
was submitted last night so that it could be formally submitted by the
end of stage 1.
This patch is the same as the top of the wide-int branch that has been
On 11/16/2013 11:01 AM, Chung-Lin Tang wrote:
> My response to the various issues you raised are below. The new patch
> has been re-tested. Please see if you can approve for committing now.
I agree with all the comments Richard has been making, so I'll just add
a few other points.
> If you don't
On Fri, 2013-11-22 at 12:57 +0100, Richard Biener wrote:
> On Fri, Nov 22, 2013 at 4:31 AM, David Malcolm wrote:
> > The following patch series eliminates the following macros that
> > implicitly use input_location:
> > input.h:
> > #define input_line LOCATION_LINE (input_location)
> > #
On Fri, Nov 22, 2013 at 02:55:52PM +0100, Jakub Jelinek wrote:
> On Fri, Nov 22, 2013 at 10:54:16AM +0100, Marek Polacek wrote:
> > 1) currently, we seem to miscompile some code with -Os. That's why
> >I skipped -Os in some of the test.
>
> The following (untested) incremental fix should hope
Hi,
> >> > If a pointer typed use is plainly value passed to a func call, it is
> >> > not an address use, right? But as you said, x86 lea may help here.
> >>
> >> But that's what you are matching ... (well, for builtins you know
> >> will expand that to a memory reference).
> >>
> >> What I disli
committed as revision 205260.
thanks
kenny
On 11/22/2013 03:58 AM, Richard Biener wrote:
On Thu, 21 Nov 2013, Kenneth Zadeck wrote:
Richi,
Here is the patch. As you can see, i chose the unsigned option.
It was bootstrapped and tested on x86 with all languages including ada.
Ok to commit?
On Fri, Nov 22, 2013 at 10:54:16AM +0100, Marek Polacek wrote:
> 1) currently, we seem to miscompile some code with -Os. That's why
>I skipped -Os in some of the test.
The following (untested) incremental fix should hopefully fix it.
Perhaps the calls before expand_normal aren't needed, dunn
1 - 100 of 157 matches
Mail list logo
