Hi!
When expanding #pragma omp atomic or reduction merging using
expand_omp_atomic_pipeline loop, we start by fetching the initial value
using normal memory read and only in the second and following iteration
use the one from the atomic compare and exchange. The initial value
is just an optimizat
Hi!
I'd like to ping 2 patches:
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00140.html
- Ensure GET_MODE_{SIZE,INNER,NUNITS} (const) is constant rather than
memory load after optimization (I'd like to keep the current
patch for the reasons mentioned there, but also add this patch)
http://g
On Mon, Jan 13, 2014 at 9:07 AM, Jakub Jelinek wrote:
> http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00131.html
> - PR target/59617
> handle gather loads for AVX512 (at least non-masked ones, masked ones
> will need to wait for 5.0 and we need to find how to represent it in
> GIMPLE)
This
On Mon, Jan 13, 2014 at 09:15:14AM +0100, Uros Bizjak wrote:
> On Mon, Jan 13, 2014 at 9:07 AM, Jakub Jelinek wrote:
>
> > http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00131.html
> > - PR target/59617
> > handle gather loads for AVX512 (at least non-masked ones, masked ones
> > will need to w
On Sun, Jan 12, 2014 at 10:53:12PM +0100, Bernd Edlinger wrote:
> Yes, explicit /* { dg-do run } */ works.
Ok, I've committed
2014-01-13 Jakub Jelinek
* gcc.dg/vect/vect-simd-clone-10.c: Add dg-do run.
* gcc.dg/vect/vect-simd-clone-12.c: Likewise.
--- gcc/testsuite/gcc.dg/vect
On Sun, Jan 12, 2014 at 10:51 PM, Trevor Saunders wrote:
> On Sun, Jan 12, 2014 at 02:23:21PM +0100, Richard Biener wrote:
>> On Fri, Jan 10, 2014 at 6:37 PM, Richard Henderson wrote:
>> > On 01/09/2014 03:34 PM, Jakub Jelinek wrote:
>> >> 2014-01-09 Jakub Jelinek
>> >>
>> >> * target-gl
On 11/01/14 23:42, Kugan wrote:
> Hi,
>
> aarch64_build_constant incorrectly truncates the immediate when
> constants are generated with MOVN. This causes coinor-osi tests to fail
> (tracked also in https://bugs.launchpad.net/gcc-linaro/+bug/1263576)
>
> Attached patch fixes this. Also attaching
On Sat, Jan 11, 2014 at 12:42 AM, Eric Botcazou wrote:
> [Sorry for dropping the ball here]
>
>> I think that may_be_unaligned_p is just seriously out-dated ... shouldn't it
>> be sth like
>>
>> get_object_alignment_1 (ref, &align, &bitpos);
>> if step * BITS_PER_UNIT + bitpos is misaligned
>>
On Mon, 13 Jan 2014, Jakub Jelinek wrote:
> On Mon, Jan 13, 2014 at 09:15:14AM +0100, Uros Bizjak wrote:
> > On Mon, Jan 13, 2014 at 9:07 AM, Jakub Jelinek wrote:
> >
> > > http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00131.html
> > > - PR target/59617
> > > handle gather loads for AVX512 (at
> Note that this now lets unaligned vector moves slip through as
> their TYPE_ALIGN (TREE_TYPE (ref)) is properly reflecting this
> fact, so is anything which dereferences a type with an aligned
> attribute lowering its alignment.
>
> Which of course raises the question what the function is
> supp
On Fri, 10 Jan 2014, Jakub Jelinek wrote:
> Hi!
>
> If folded_casts is true, sccp can introduce undefined behavior even when
> there was none in the original loop, e.g. all actual additions performed in
> unsigned type and then cast back to signed.
>
> The following patch fixes that by turning t
On Mon, Jan 13, 2014 at 11:37 AM, Eric Botcazou wrote:
>> Note that this now lets unaligned vector moves slip through as
>> their TYPE_ALIGN (TREE_TYPE (ref)) is properly reflecting this
>> fact, so is anything which dereferences a type with an aligned
>> attribute lowering its alignment.
>>
>> Wh
Hello,
there is another test case, that misses the necessary check_vect() runtime
check.
Tested on i686-pc-linux-gnu.
OK for trunk?
Regards
Bernd.
patch-vect-nop-move.diff
Description: Binary data
On Sat, Nov 23, 2013 at 8:21 PM, Mike Stump wrote:
> Richi has asked the we break the wide-int patch so that the individual port
> and front end maintainers can review their parts without have to go through
> the entire patch.This patch covers the constant folding code.
>
> Ok?
Ok for stage
On Sat, Nov 23, 2013 at 8:23 PM, Mike Stump wrote:
> Richi has asked the we break the wide-int patch so that the individual port
> and front end maintainers can review their parts without have to go through
> the entire patch.This patch covers the new wide-int code.
>
> Ok?
I know the patch
Hi Jakub,
I can confirm it's OK now.
Thanks,
Christophe.
On 10 January 2014 17:56, Christophe Lyon wrote:
> On 10 January 2014 17:45, Jakub Jelinek wrote:
>> On Fri, Jan 10, 2014 at 05:44:22PM +0100, Christophe Lyon wrote:
>>> It seems this patch causes several regressions in gfortran on ARM t
On Wed, 27 Nov 2013, Jakub Jelinek wrote:
> On Wed, Nov 27, 2013 at 10:53:56AM +0100, Richard Biener wrote:
> > Hmm. I'm still thinking that we should handle this during the regular
> > transform step.
>
> I wonder if it can't be done instead just in vectorizable_load,
> if LOOP_REQUIRES_VERSION
On Mon, Jan 13, 2014 at 02:37:38PM +0100, Richard Biener wrote:
> 2014-01-13 Richard Biener
>
> PR tree-optimization/58921
> PR tree-optimization/59006
> * tree-vect-loop-manip.c (vect_loop_versioning): Remove code
> hoisting invariant stmts.
> * tree-vect-stmts.c
Hi Kyrill,
Your patch fixes most of the problems I noticed, however, it makes the
compiler crash on vld1Q_dupp64 when the target is big-endian:
--with-target= armeb-none-linux-gnueabihf
--with-cpu=cortex-a9
--with-fpu=neon-fp16
/aci-gcc-fsf/sources/gcc-fsf/trunk/gcc/testsuite/gcc.target/arm/neon
ansidecl.h still defines a number of macros which I think are now
obsolete. I recently removed all uses of these macros from
binutils-gdb.git; and there are no more uses in gcc. So, I'd like to
propose removing the old macros entirely.
This patch removes the last uses of PARAMS from include, and
On 13/01/14 13:57, Christophe Lyon wrote:
Hi Kyrill,
Your patch fixes most of the problems I noticed, however, it makes the
compiler crash on vld1Q_dupp64 when the target is big-endian:
--with-target= armeb-none-linux-gnueabihf
--with-cpu=cortex-a9
--with-fpu=neon-fp16
/aci-gcc-fsf/sources/gcc
On 13 January 2014 15:51, Kyrill Tkachov wrote:
> On 13/01/14 13:57, Christophe Lyon wrote:
>>
>> Hi Kyrill,
>>
>> Your patch fixes most of the problems I noticed, however, it makes the
>> compiler crash on vld1Q_dupp64 when the target is big-endian:
>> --with-target= armeb-none-linux-gnueabihf
>>
On 10-01-14 09:47, Richard Sandiford wrote:
Tom de Vries writes:
Why not just collect the usage information at
the end of final rather than at the beginning, so that all splits during
final have been done?
If we have a call to a leaf function, the final rtl representation does not
contain c
On 01/13/14 01:07, Jakub Jelinek wrote:
Hi!
I'd like to ping 2 patches:
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00140.html
- Ensure GET_MODE_{SIZE,INNER,NUNITS} (const) is constant rather than
memory load after optimization (I'd like to keep the current
patch for the reasons mention
On 01/13/14 08:20, Jakub Jelinek wrote:
On Mon, Jan 13, 2014 at 08:15:11AM -0700, Jeff Law wrote:
On 01/13/14 01:07, Jakub Jelinek wrote:
I'd like to ping 2 patches:
http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00140.html
- Ensure GET_MODE_{SIZE,INNER,NUNITS} (const) is constant rather than
Hi all,
I've committed this obvious typo fix to trunk as r206580.
Kyrill
2014-01-13 Kyrylo Tkachov
* config/arm/arm.h (MAX_CONDITIONAL_EXECUTE): Fix typo in description.diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index 409589d..b815488 100644
--- a/gcc/config/arm/arm.h
+++
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 hook
>for AArch64, once we all agree on how the hook should l
On Mon, Jan 13, 2014 at 08:15:11AM -0700, Jeff Law wrote:
> On 01/13/14 01:07, Jakub Jelinek wrote:
> >I'd like to ping 2 patches:
> >
> >http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00140.html
> >- Ensure GET_MODE_{SIZE,INNER,NUNITS} (const) is constant rather than
> > memory load after optimiza
On Fri, Jul 12, 2013 at 3:16 PM, Sriraman Tallam wrote:
> Patch attached to fix this: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57698
>
> Here is what is going on. In rev. 200179, this change to tree-inline.c
>
> Index: tree-inline.c
>
This doesn't really fix the PR, but solves a related issue, where we
have e.g.
struct U {};
static struct U b[6];
int foo (struct U *p, struct U *q)
{
return q - p;
}
int main()
{
return foo (&b[0], &b[4]);
}
Such a program SIGFPEs at runtime. But subtraction of pointers to empty
structures/u
On 01/13/2014 05:32 PM, Marek Polacek wrote:
This doesn't really fix the PR, but solves a related issue, where we
have e.g.
struct U {};
static struct U b[6];
int foo (struct U *p, struct U *q)
{
return q - p;
}
int main()
{
return foo (&b[0], &b[4]);
}
Such a program SIGFPEs at runtim
On Mon, Jan 13, 2014 at 05:32:26PM +0100, Marek Polacek wrote:
> This doesn't really fix the PR, but solves a related issue, where we
> have e.g.
> struct U {};
> static struct U b[6];
>
> int foo (struct U *p, struct U *q)
> {
> return q - p;
> }
> int main()
> {
> return foo (&b[0], &b[4]);
On Thu, Jan 9, 2014 at 7:48 PM, Yangfei (Felix) wrote:
> And here is the xtensa configuration tested (include/xtensa-config.h):
>
> #define XCHAL_HAVE_BE 0
> #define XCHAL_HAVE_LOOPS1
Hi Felix,
I like this patch, and expect I will approve it. However, I would like
you
On 01/09/14 10:45, Steve Ellcey wrote:
While looking at PR 59335 (plugin doesn't build) I saw the comments about
tree-flow.h and tree-flow-inline.h not existing anymore. While these
files have been removed there are still some references to them in
Makefile.in, doc/tree-ssa.texi, and a couple of
Hello,
On 13 Jan 09:35, Jakub Jelinek wrote:
> On Mon, Jan 13, 2014 at 09:15:14AM +0100, Uros Bizjak wrote:
> > On Mon, Jan 13, 2014 at 9:07 AM, Jakub Jelinek wrote:
> > Kirill, is it possible for you to test the patch in the simulator? Do
> > we have a testcase in gcc's testsuite that can be used
On Mon, Jan 13, 2014 at 7:26 PM, Kirill Yukhin wrote:
>> On Mon, Jan 13, 2014 at 09:15:14AM +0100, Uros Bizjak wrote:
>> > On Mon, Jan 13, 2014 at 9:07 AM, Jakub Jelinek wrote:
>> > Kirill, is it possible for you to test the patch in the simulator? Do
>> > we have a testcase in gcc's testsuite t
On Mon, Jan 13, 2014 at 7:26 PM, Kirill Yukhin wrote:
>> > Kirill, is it possible for you to test the patch in the simulator? Do
>> > we have a testcase in gcc's testsuite that can be used to check this
>> > patch?
>>
>> E.g. gcc.target/i386/avx2-gather* and avx512f-gather*.
> This tests are for
On Mon, Jan 13, 2014 at 07:40:16PM +0100, Uros Bizjak wrote:
> An unrelated observation: gcc should figure out that %k1 mask register
> can be used in all gather insns and avoid unnecessary copies at the
> beginning of the loop.
I thought about that too, even started modifying sse.md, but then I r
Hi!
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?
C++ already does a similar thing (though in that case with TARGET_EXPRs).
Note1: had to tweak ssa-fr
On Mon, Jan 13, 2014 at 11:42:11AM +0100, Richard Biener wrote:
> > + if (TREE_CODE (def) == INTEGER_CST && TREE_OVERFLOW (def))
>
> TREE_OVERFLOW_P (), but it seems to me that the SCEV machinery
> should do this at a good place (like where it finally records
> the result into its cache before
The call change avoids a problem on hardware where indirect calls that
use SP as a base register don't seem to do what you expect. The 'J'
one fixes a link-time error wrt epilogue helper functions. Committed.
* config/msp430/msp430.md (call_internal): Don't allow memory
referenc
On 01/11/2014 08:28 AM, H.J. Lu wrote:
> +2013-12-25 H.J. Lu
>> +
>> + PR libitm/53113
>> + * Makefile.am (x86_sse.lo): Append -msse to CXXFLAGS.
>> + (x86_avx.lo): Append -mavx to CXXFLAGS.
>> + * Makefile.in: Regenerate.
>> +
Ok.
r~
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 the lhs in the optimized dump instead.
These alternate
Hello,
This patch adds support to the SISD variants of SCVTF/UCVTF instructions.
This also refactors the existing support for floating point instruction
variants of SCVTF/UCVTF in order to direct the instruction selection based
on the constraints. Given that the floating-point variations supports
Hi,
We should report some early inlining errors. This patch is based on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57698#c7
It adds report_early_inliner_always_inline_failure and uses it in
expand_call_inline. Tested on Linux/x86-64. OK to install?
Thanks.
H.J.
commit 7b18b53d308b2c25
On 12/22/2013 09:55 PM, François Dumont wrote:
On 12/22/2013 12:51 PM, Jonathan Wakely wrote:
On 21 December 2013 08:51, François Dumont wrote:
Any feedback for this proposal ?
It looks good but I don't have time to review it fully yet, please be
patient.
I'm more concerned about your commen
On Sun, Jan 12, 2014 at 7:53 PM, Bill Schmidt
wrote:
> This patch provides for interpreting element numbers for the Altivec
> vec_insert and vec_extract intrinsics as big-endian (left to right in a
> vector register) when targeting a little endian machine and specifying
> -maltivec=be. New test c
On Mon, Jan 13, 2014 at 05:48:59PM +0100, Marek Polacek wrote:
> The patch will need some tweaking, I realized that e.g. for struct S {
> union {}; }; it doesn't do the right thing...
Done in the patch below. CCing Jason for the C++ part. Does this
look sane now?
Regtested/bootstrapped on x86_6
On Mon, Jan 13, 2014 at 07:35:41PM +0100, Uros Bizjak wrote:
> Jakub, do you plan to submit this patch?
That would be following patch then, tested on x86_64-linux.
Unfortunately, it doesn't help for the avx512f-vmovdqu32-1.c
testcase, the thing is that the __m512i type is V8DImode and while
the em
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 test cases are added to test this functionality on
all supporte
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 calls. I updated the
current two tuning variables (
I noticed that LIM could not hoist vector invariant, and that is why
my first implementation tries to hoist them all.
In addition, there are two disadvantages of hoisting invariant load +
lim method:
First, for some instructions the scalar version is faster than the
vector version, and in this ca
Hello,
This patch introduces missing AVX-512PF intrinsics and tests.
It also renames store/load intrinsics according to EAS.
gcc/
* config/i386/avx512fintrin.h (_mm512_loadu_si512): Rename.
(_mm512_storeu_si512): Ditto.
* config/i386/avx512pfintrin.h (_mm512_mask_prefetch_i
53 matches
Mail list logo
