On Tue, Jan 14, 2014 at 06:18:22AM -0800, H.J. Lu wrote:
> 2014-01-14 H.J. Lu
>
> PR target/59794
> * config/i386/i386.c (type_natural_mode): Add a bool parameter
> to indicate if type is used for function return value. Warn
> ABI change if the vector mode isn't availab
This patch fixes what appears to have been a long standing failure in
the conversion of tree-vect-generic.c:build_replicated_const. This
failure caused several regressions on the branch.
Committed as revision 206616
Index: gcc/tree-vect-generic.c
This Go frontend patch from Chris Manghane uses the backend interface
for interface info and field expressions. Bootstrapped and ran Go
testsuite on x86_64-unknown-linux-gnu. Committed to mainline.
Ian
2014-01-14 Chris Manghane
* go-gcc.cc (Gcc_backend::compound_expression): New fu
While writing the Thunder tunings, I got an internal compiler error
while building glibc. The reduced testcase is:
typedef unsigned int size_t;
typedef unsigned int wchar_t;
extern __thread int __libc_errno;
extern __thread int * t;
int _IO_vfprintf_internal (char *string, char *workend
This patch from Chris Manghane adds a Backend_function_type: a function
type that is implemented as a function pointer rather than as the
pointer to a struct that is the implementation of a Go function. This
will be used in other backend conversions. Bootstrapped and ran Go
testsuite on x86_64-un
On Tue, Jan 14, 2014 at 3:42 PM, Pat Haugen wrote:
> This patch fixes a problem where the attribute no_instrument_function was
> being ignored and profile code was emitted. Testcase
> gcc.target/powerpc/ppc64-abi-2.c exposed the issue.
>
> Bootstrap/regtest with no new regressions, ok for trunk?
>
On Mon, 13 Jan 2014, Marek Polacek wrote:
> +/* Return true if T is a pointer to a zero-sized struct/union. */
> +
> +bool
> +pointer_to_zero_sized_aggr_p (tree t)
> +{
> + t = strip_pointer_operator (t);
> + if (RECORD_OR_UNION_TYPE_P (t)
> + && TYPE_SIZE (t)
> + && integer_zerop (TY
On Mon, 13 Jan 2014, Jakub Jelinek wrote:
> This patch fixes the following testcase by preevaluating rhs if it has
> (can have) side-effects in lhs op= rhs expressions. Bootstrapped/regtested
> on x86_64-linux and i686-linux, ok for trunk?
OK.
--
Joseph S. Myers
jos...@codesourcery.com
This patch fixes a problem where the attribute no_instrument_function
was being ignored and profile code was emitted. Testcase
gcc.target/powerpc/ppc64-abi-2.c exposed the issue.
Bootstrap/regtest with no new regressions, ok for trunk?
-Pat
2014-01-13 Pat Haugen
* config/rs6000/r
On Mon, Jan 13, 2014 at 6:37 PM, Bill Schmidt
wrote:
> This patch provides for interpreting parity of element numbers for the
> Altivec vec_mule and vec_mulo intrinsics as big-endian (left to right in
> a vector register) when targeting a little endian machine and specifying
> -maltivec=be. New t
On Thu, Jan 9, 2014 at 6:56 AM, Jan Hubicka wrote:
>> As suggested by Honza, avoid bloating libgcov from gcc_assert by using
>> a new macro gcov_nonruntime_assert in gcov-io.c that is only mapped to
>> gcc_assert when not in libgcov.
>>
>> Bootstrapped and tested on x86_64-unknown-linux-gnu. Ok fo
On 12/05/2013 07:47 PM, Tom de Vries wrote:
> On 14-03-13 10:34, Tom de Vries wrote:
>>> I thought about implementing your optimization for LRA by myself.
>>> But it
>>> >is ok if you decide to work on it. At least, I am not going to start
>>> >this work for a month.
>>I'm also currently look
Thanks for the hint Vladimir, I'll pass some validation on arm.c and
arm.md/aarch64.md separately.
On 14 January 2014 20:09, Vladimir Makarov wrote:
> On 01/14/2014 01:41 PM, Yvan Roux wrote:
>>> A quick grep of the arm backend shows 11 instances of reload_in_progress:
>>>
>>> arm.c: && !(re
On Tue, Jan 14, 2014 at 07:37:33PM +0100, Uros Bizjak wrote:
> OK, let's play safe. I'll revert these two changes (modulo size of
> nocona prefetch block).
Thanks.
> > opt we never return a smaller number from ix86_data_alignment than
> > we did in 4.8 and earlier, because otherwise if you have 4
On 01/14/2014 12:22 PM, Peter Bergner wrote:
> The mainline fix for PR58139 which is a wrong code gen bug was
> submitted here:
>
> http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00910.html
>
> and approved for mainline and 4.8 (after a few weeks) here:
>
> http://gcc.gnu.org/ml/gcc-patches/2
On 01/14/2014 01:41 PM, Yvan Roux wrote:
>> A quick grep of the arm backend shows 11 instances of reload_in_progress:
>>
>> arm.c: && !(reload_in_progress || reload_completed)
>> arm.c: if (! (reload_in_progress || reload_completed)
>> arm.c: if (! (reload_in_progress || reload_completed)
>>
On Tue, Jan 14, 2014 at 10:37 AM, Uros Bizjak wrote:
> On Tue, Jan 14, 2014 at 6:09 PM, Jakub Jelinek wrote:
>
>>> On a second thought, the crossing of 16-byte boundaries is mentioned
>>> for the data *access* (the instruction itself) if it is not naturally
>>> aligned (please see example 3-40 an
> A quick grep of the arm backend shows 11 instances of reload_in_progress:
>
> arm.c: && !(reload_in_progress || reload_completed)
> arm.c: if (! (reload_in_progress || reload_completed)
> arm.c: if (! (reload_in_progress || reload_completed)
> arm.c: if (! (reload_in_progress || reload_co
On Tue, Jan 14, 2014 at 6:09 PM, Jakub Jelinek wrote:
>> On a second thought, the crossing of 16-byte boundaries is mentioned
>> for the data *access* (the instruction itself) if it is not naturally
>> aligned (please see example 3-40 and fig 3-2), which is *NOT* in our
>> case.
>>
>> So, we don'
On 14/01/14 16:48, Vladimir Makarov wrote:
> The following patch fixes
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59787
>
> The problem of LRA looping was in that address with soft frame pointer
> was rejected as valid constraint in iwmmxt_amd_movdi insn.
>
> Ok to commit?
>
> 2014-01-
On 14/01/14 16:48, Vladimir Makarov wrote:
> The following patch fixes
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59787
>
> The problem of LRA looping was in that address with soft frame pointer
> was rejected as valid constraint in iwmmxt_amd_movdi insn.
>
> Ok to commit?
>
> 2014-01-
On 01/13/2014 09:48 PM, Marek Polacek wrote:
+bool
+pointer_to_zero_sized_aggr_p (tree t)
+{
+ t = strip_pointer_operator (t);
+ if (RECORD_OR_UNION_TYPE_P (t)
+ && TYPE_SIZE (t)
+ && integer_zerop (TYPE_SIZE (t)))
+return true;
+ return false;
+}
I think you can just return th
Hi Vladimir,
I have test your patch with the following configurations, , and it
indeed eliminates the ICE.
--target=arm-none-linux-gnueabihf
--with-arch=armv7-a
--with-fpu=vfpv3-d16
--with-float=softfp
Thank you!
Kind regards,
Renlin Li
On 14/01/14 16:48, Vladimir Makarov wrote:
The fol
The mainline fix for PR58139 which is a wrong code gen bug was
submitted here:
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg00910.html
and approved for mainline and 4.8 (after a few weeks) here:
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00134.html
However, my fix exposed a latent x86
On Fri, Jan 03, 2014 at 05:04:39PM +0100, Uros Bizjak wrote:
> On a second thought, the crossing of 16-byte boundaries is mentioned
> for the data *access* (the instruction itself) if it is not naturally
> aligned (please see example 3-40 and fig 3-2), which is *NOT* in our
> case.
>
> So, we don'
Hi!
In the buildrobot's logs for building with config-list.mk, I noticed
this warning:
g++ -c -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -O2 -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-
On Tue, Jan 14, 2014 at 7:20 AM, Felix Yang wrote:
> Hi Sterling,
>
> I found that we can avoid emitting excessive literal loading
> instructions with with section anchors.
> This patch also passed the cases in testsuite/gcc.c-torture/execute/ dir.
> Please apply it if OK for trunk.
Hi Feli
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59787
The problem of LRA looping was in that address with soft frame pointer
was rejected as valid constraint in iwmmxt_amd_movdi insn.
Ok to commit?
2014-01-14 Vladimir Makarov
PR target/59787
* confi
On Tue, Jan 14, 2014 at 7:14 AM, Felix Yang wrote:
> Hi Sterling,
>
> The xtensa backend uses register windows, and we need to define
> LOCAL_REGNO for it.
Hi Felix,
How does this change the produced code? In particular, please identify
a problem this patch is solving. I know that the docume
Hi Guys,
Several PRs (28865, 57180 and 59719) have reported that the assembler
directives emitted by gcc to describe a structure with a variable
length field occupy too much space. That is a serious problem for
targets which use section anchors as they rely upon objects in the
data area
On Tue, Jan 14, 2014 at 3:18 PM, H.J. Lu wrote:
> There are several problems with i386 MMX/SSE/AVX ABI change detection:
>
> 1. MMX/SSE return value isn't checked for -m32 since revision 83533:
>
> http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=83533
>
> which added ix86_struct_value_rtx.
On Sun, Jan 12, 2014 at 10:02 PM, Kirill Yukhin wrote:
> Hello,
> On 11 Jan 12:42, Uros Bizjak wrote:
>> On Fri, Jan 10, 2014 at 5:24 PM, Jakub Jelinek wrote:
>> > This means you should ensure aligned_mem will be set for
>> > CODE_FOR_avx512f_movntdqa in ix86_expand_special_args_builtin.
> Fixed.
On Tue, Jan 14, 2014 at 02:49:30PM +, Richard Earnshaw wrote:
> On 14/01/14 14:32, Jakub Jelinek wrote:
> > Anyway, the above is really a simple case, and I'd call it a
> > backend bug if it isn't able to generate good code out of that.
>
> Exactly which back-end pass are you expecting to simp
> On Jan 14, 2014, at 7:19 AM, Alex Velenko wrote:
>
> Hi,
>
> This patch turns off the vec_perm patterns for aarch64_be, this should resolve
> the issue highlighted here
> http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00321.html
> With this patch applied, the test case provided in that link
Mike Stump writes:
> diff --git a/gcc/expmed.c b/gcc/expmed.c
> index ce063eb..720d8c1 100644
> --- a/gcc/expmed.c
> +++ b/gcc/expmed.c
> @@ -4963,6 +4963,7 @@ make_tree (tree type, rtx x)
>return t;
>
> case CONST_DOUBLE:
> + gcc_assert (HOST_BITS_PER_WIDE_INT * 2 <= MAX_BITSI
Hi Sterling,
I found that we can avoid emitting excessive literal loading
instructions with with section anchors.
This patch also passed the cases in testsuite/gcc.c-torture/execute/ dir.
Please apply it if OK for trunk.
Index: gcc/ChangeLog
Hi,
This patch turns off the vec_perm patterns for aarch64_be, this should
resolve
the issue highlighted here
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00321.html
With this patch applied, the test case provided in that link compiles
without an ICE.
However, the Big-Endian port is still i
On 14/01/14 14:49, Richard Earnshaw wrote:
> On 14/01/14 14:32, Jakub Jelinek wrote:
>> Anyway, the above is really a simple case, and I'd call it a
>> backend bug if it isn't able to generate good code out of that.
>
> Exactly which back-end pass are you expecting to simplify
>
> (set (subreg:SI
Hi Sterling,
The xtensa backend uses register windows, and we need to define
LOCAL_REGNO for it.
The dataflow may not be accurate with this macro. This patch
passed the cases in testsuite/gcc.c-torture/execute dir.
Please apply it if OK for trunk. Thanks.
Index: gcc/ChangeLog
From: Thomas Schwinge
gcc/c/
* c-parser.c (OACC_PARALLEL_CLAUSE_MASK): Add
PRAGMA_OMP_CLAUSE_COPY, PRAGMA_OMP_CLAUSE_COPYIN,
PRAGMA_OMP_CLAUSE_COPYOUT, PRAGMA_OMP_CLAUSE_CREATE,
PRAGMA_OMP_CLAUSE_DEVICEPTR, PRAGMA_OMP_CLAUSE_PRESENT,
PRAGMA_OMP_CLAU
From: Thomas Schwinge
gcc/
* tree-core.h (omp_clause_map_kind): Add OMP_CLAUSE_MAP_FORCE,
OMP_CLAUSE_MAP_FORCE_ALLOC, OMP_CLAUSE_MAP_FORCE_TO,
OMP_CLAUSE_MAP_FORCE_FROM, OMP_CLAUSE_MAP_FORCE_TOFROM,
OMP_CLAUSE_MAP_FORCE_PRESENT, OMP_CLAUSE_MAP_FORCE_DEALLOC
From: Thomas Schwinge
gcc/
* gimplify.c (gimplify_call_expr, gimplify_modify_expr)
(omp_firstprivatize_variable, omp_notice_threadprivate_variable)
(omp_notice_variable, gimplify_adjust_omp_clauses)
(gimplify_omp_workshare): Treat ORT_TARGET as a flag, not
From: Thomas Schwinge
gcc/
* tree-core.h (omp_clause_map_kind): Make the identifiers' bit
patterns more obvious. Add comments.
* omp-low.c (lower_oacc_parallel, lower_omp_target): Test for
omp_clause_map_kind flags set instead of for values.
---
gcc/omp-l
From: Thomas Schwinge
gcc/c/
* c-parser.c (c_parser_oacc_all_clauses): New function.
(c_parser_oacc_parallel): Use it.
* c-typeck.c (c_finish_omp_clauses): Update comment. Remove
duplicated variable initialization.
---
gcc/c/c-parser.c | 59 ++
From: Thomas Schwinge
gcc/c-family/
* c-pragma.h (pragma_omp_clause): Add PRAGMA_OMP_CLAUSE_COPY,
PRAGMA_OMP_CLAUSE_COPYOUT, PRAGMA_OMP_CLAUSE_CREATE,
PRAGMA_OMP_CLAUSE_DELETE, PRAGMA_OMP_CLAUSE_DEVICEPTR,
PRAGMA_OMP_CLAUSE_PRESENT, PRAGMA_OMP_CLAUSE_PRESEN
Hi!
Here is a patch series that adds initial support for OpenACC data
clauses. It is not yet complete, but I thought I might as well already
now strive to get this integrated upstream instead of "hoarding" the
patches locally.
Would it be a good idea to also commit to trunk the (portions of the)
This resolves a bootstrap issue found after reducing the size of the maximal
wide_int; the real code really does want a slightly larger type so we create on
just for real.
Ok?
diff --git a/gcc/builtins.c b/gcc/builtins.c
index 81bb407..f4ffdb0 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@
On 14/01/14 14:32, Jakub Jelinek wrote:
> Anyway, the above is really a simple case, and I'd call it a
> backend bug if it isn't able to generate good code out of that.
Exactly which back-end pass are you expecting to simplify
(set (subreg:SI (reg:HI 1) 0) (and:SI (subreg:SI (reg:HI 0) 0)
(const_
On 9 January 2014 21:55, François Dumont wrote:
> Hi
>
> Here is a patch for this small problem with clang. It is not a blocking
> issue for the 4.9 release but at the same time it is a rather safe fix so
> just tell me if I can commit it.
>
> All unordered_* tests run under Linux x86_64. I
The C++ part is OK.
Jason
2014/1/14 Richard Biener :
> On Tue, Jan 14, 2014 at 1:47 PM, Ilya Enkovich wrote:
>> 2014/1/14 Richard Biener :
>>> On Tue, Jan 14, 2014 at 10:15 AM, Ilya Enkovich
>>> wrote:
Hi,
I've been working for some time on the prototype of the Pointer Bounds
Checker which uses functi
On 14/01/14 14:25, Richard Biener wrote:
> On Tue, Jan 14, 2014 at 3:21 PM, Kyrill Tkachov
> wrote:
>> Moving to gcc, I accidentally sent it to gcc-patches previously...
>>
>>
>> On 14/01/14 14:09, Richard Biener wrote:
>>>
>>> On Tue, Jan 14, 2014 at 3:03 PM, Kyrill Tkachov
>>> wrote:
On Tue, Jan 14, 2014 at 02:21:52PM +, Kyrill Tkachov wrote:
> If I look at the dump before forwprop, the number of statements is
> exactly the same, so it's not any shorter in that sense.
>
>
> IsAwake (struct b2Body * b)
> {
> short unsigned int _3;
> int _4;
> int _5;
> _Bool _6;
>
On 01/14/14 03:37, Richard Sandiford wrote:
While experimenting with a patch to use conditional returns, I hit a case
where a conditional jump between hot and cold sections was being converted
into a conditional return. The new jump still had the REG_CROSSING_JUMP
and later passes were confused
On 01/14/14 06:42, Richard Biener wrote:
This fixes the slowness seen in LCM compute_available accounted
to RTL cprop. Currently the dataflow problem uses a "random"
basic-block order to seed the initial worklist (it wants to
visit predecessors before successors) - the following patch
makes it
On Tue, Jan 14, 2014 at 3:21 PM, Kyrill Tkachov wrote:
> Moving to gcc, I accidentally sent it to gcc-patches previously...
>
>
> On 14/01/14 14:09, Richard Biener wrote:
>>
>> On Tue, Jan 14, 2014 at 3:03 PM, Kyrill Tkachov
>> wrote:
>>>
>>> Hi all,
>>>
>>> I'm looking into PR 54168 where we end
Moving to gcc, I accidentally sent it to gcc-patches previously...
On 14/01/14 14:09, Richard Biener wrote:
On Tue, Jan 14, 2014 at 3:03 PM, Kyrill Tkachov wrote:
Hi all,
I'm looking into PR 54168 where we end up generating an unnecessary extend
operation on arm.
Given code:
struct b2Body {
Hi,
There are several problems with i386 MMX/SSE/AVX ABI change detection:
1. MMX/SSE return value isn't checked for -m32 since revision 83533:
http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=83533
which added ix86_struct_value_rtx. Since MMX/SSE condition is always
false, the MMX/SSE re
On Tue, Jan 14, 2014 at 3:03 PM, Kyrill Tkachov wrote:
> Hi all,
>
> I'm looking into PR 54168 where we end up generating an unnecessary extend
> operation on arm.
>
> Given code:
>
> struct b2Body {
> unsigned short flags;
> int type;
> };
>
> static _Bool IsAwake(struct b2Body *b)
> {
>
Hi all,
I'm looking into PR 54168 where we end up generating an unnecessary extend
operation on arm.
Given code:
struct b2Body {
unsigned short flags;
int type;
};
static _Bool IsAwake(struct b2Body *b)
{
return (b->flags & 2) == 2;
}
int foo(struct b2Body *bA, struct b2Body *
On Tue, Jan 14, 2014 at 1:47 PM, Ilya Enkovich wrote:
> 2014/1/14 Richard Biener :
>> On Tue, Jan 14, 2014 at 10:15 AM, Ilya Enkovich
>> wrote:
>>> Hi,
>>>
>>> I've been working for some time on the prototype of the Pointer Bounds
>>> Checker which uses function clones for instrumentation
>>> (h
This fixes the slowness seen in LCM compute_available accounted
to RTL cprop. Currently the dataflow problem uses a "random"
basic-block order to seed the initial worklist (it wants to
visit predecessors before successors) - the following patch
makes it use inverted postorder (similar to tree PRE
On Tue, 14 Jan 2014, Jakub Jelinek wrote:
> On Tue, Jan 14, 2014 at 10:01:06AM +0100, Richard Biener wrote:
> > Jakub, adding the new flag is ok with me.
>
> So like this?
Ok if it passes testing.
Thanks,
Richard.
> 2014-01-14 Jakub Jelinek
>
> * tree-vectorizer.h (struct _loop_vec_i
On Tue, Jan 14, 2014 at 10:01:06AM +0100, Richard Biener wrote:
> Jakub, adding the new flag is ok with me.
So like this?
2014-01-14 Jakub Jelinek
* tree-vectorizer.h (struct _loop_vec_info): Add no_data_dependencies
field.
(LOOP_VINFO_NO_DATA_DEPENDENCIES): Define.
2014/1/14 Richard Biener :
> On Tue, Jan 14, 2014 at 10:15 AM, Ilya Enkovich
> wrote:
>> Hi,
>>
>> I've been working for some time on the prototype of the Pointer Bounds
>> Checker which uses function clones for instrumentation
>> (http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03327.html). After
>
On 6 January 2014 12:30, Yufeng Zhang wrote:
> This patch fixes the implementation of vcvtmd_s64_f64 and vcvtpd_s64_f64 in
> arm_neon.h to use llfloor and llceil instead, which are ILP32-friendly.
>
> This patch will fix the following test failure in the ILP32 mode:
>
> FAIL: gcc.target/aarch64/ve
Ping~
Originally posted here:
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00185.html
Thanks,
Yufeng
On 01/06/14 12:30, Yufeng Zhang wrote:
This patch fixes the implementation of vcvtmd_s64_f64 and vcvtpd_s64_f64
in arm_neon.h to use llfloor and llceil instead, which are ILP32-friendly.
This
On Tue, Jan 14, 2014 at 10:15 AM, Ilya Enkovich wrote:
> Hi,
>
> I've been working for some time on the prototype of the Pointer Bounds
> Checker which uses function clones for instrumentation
> (http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03327.html). After
> several experiments with this approa
On Tue, 14 Jan 2014, Richard Biener wrote:
> On Mon, 13 Jan 2014, Cong Hou wrote:
>
> > I noticed that LIM could not hoist vector invariant, and that is why
> > my first implementation tries to hoist them all.
>
> Yes, I filed PR59786 for this. I'll see if I can come up with
> a fix suitable fo
While experimenting with a patch to use conditional returns, I hit a case
where a conditional jump between hot and cold sections was being converted
into a conditional return. The new jump still had the REG_CROSSING_JUMP
and later passes were confused by the combination of that and a return
JUMP_L
On 14/01/14 01:49, Andrew Pinski wrote:
> Hi,
> While writing a scheduler for Cavium's aarch64 processor (Thunder),
> I found there was no way currently to change the issue rate in
> back-end. This patch adds a field (issue_rate) to tune_params and
> creates a new function that the middle-end ca
Uros Bizjak wrote:
> The same tsan failures are reported in one of HJ's testers [2], with message:
Can this be duplicate of http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410 ?
-Y
On 13/01/14 16:16, Tom de Vries wrote:
> On 10-01-14 12:39, Richard Earnshaw wrote:
>> Consequently, you'll need to add a patch for AArch64 which has two
>> registers clobbered by PLT-based calls.
>>
Thanks for pointing that out. That's r16 and r17, right? I can propose the
>
> FAIL: g++.dg/tsan/default_options.C -O2 execution test
This one looks plain wrong to me. It should be checked for success
instead of failure.
-Y
I've started a separate topic about flaky tsan tests here:
https://groups.google.com/forum/#!topic/thread-sanitizer/KIok3F_b1oI
--kcc
On Fri, Jan 10, 2014 at 7:20 PM, Jakub Jelinek wrote:
> On Fri, Jan 10, 2014 at 03:50:33PM +0400, Maxim Ostapenko wrote:
>> On Fri, Jan 10, 2014 at 10:39 AM, Jaku
On 14/01/14 09:06, Zhenqiang Chen wrote:
> Hi,
>
> The patch fixes two IT issues:
> 1) IT block is splitted for A15 (and Cortex-M).
>
> For A15 tune, max cond insns (max_insns_skipped) is 2, which is set as the
> maximum allowed insns in an IT block (see thumb2_final_prescan_insn). So IT
> which
Hi,
I've been working for some time on the prototype of the Pointer Bounds
Checker which uses function clones for instrumentation
(http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03327.html). After
several experiments with this approach I want to share my results and
ask for some feedback to make a d
Hi,
The patch fixes two IT issues:
1) IT block is splitted for A15 (and Cortex-M).
For A15 tune, max cond insns (max_insns_skipped) is 2, which is set as the
maximum allowed insns in an IT block (see thumb2_final_prescan_insn). So IT
which has 3 or 4 instructions, will be splitted. Take the first
On Mon, 13 Jan 2014, Cong Hou wrote:
> I noticed that LIM could not hoist vector invariant, and that is why
> my first implementation tries to hoist them all.
Yes, I filed PR59786 for this. I'll see if I can come up with
a fix suitable for stage3.
> In addition, there are two disadvantages of h
On Mon, 13 Jan 2014, Jakub Jelinek wrote:
> Hi!
>
> As discussed in the PR and on IRC, this testcase is very fragile, counting
> additions with vect_ named SSA_NAME on lhs works only for some tunings,
> for other tunings reassoc width etc. affect it and we can e.g. have
> anonymous SSA_NAMEs on t
80 matches
Mail list logo
