On Wed, 17 Sep 2014, Hans-Peter Nilsson wrote:
On Thu, 18 Sep 2014, Janne Blomqvist wrote:
On Thu, Sep 18, 2014 at 12:57 AM, Hans-Peter Nilsson h...@bitrange.com
wrote:
'k so we'll track the regressions in a PR.
Do you prefer to tack on to 62768 or a new PR?
Hijacking 62768 for the
On 17 September 2014 15:43, James Greenhalgh james.greenha...@arm.com wrote:
On Wed, Sep 17, 2014 at 09:30:31AM +0100, Richard Earnshaw wrote:
=r is correct for an early-clobbered scratch.
R.
In that case...
How is the attached patch for trunk? I've bootstrapped it on AArch64
with
On Thu, Sep 18, 2014 at 11:14 AM, Hans-Peter Nilsson h...@bitrange.com wrote:
On Wed, 17 Sep 2014, Hans-Peter Nilsson wrote:
On Thu, 18 Sep 2014, Janne Blomqvist wrote:
On Thu, Sep 18, 2014 at 12:57 AM, Hans-Peter Nilsson h...@bitrange.com
wrote:
'k so we'll track the regressions in a
On 09/18/2014 07:52 AM, Segher Boessenkool wrote: +# Local Vim config
+
+vimrc:
+ (cd $(srcdir); $(LN_S) contrib/vimrc .local.vimrc; $(LN_S)
contrib/vimrc .lvimrc)
+
This is another target than what the doc (in the script itself) mentions.
Right, I've forgot to fix it before sending the
On Sep 18 2014, Janne Blomqvist wrote:
Apparently libgfortran is not compiled with -Werror, at least
not for crosses. Maybe -Werror is there for native but I'm not
sure as I see some warning: array subscript has type 'char'
[-Wchar-subscripts] which seems generic and also some others.
Though
On Thu, Sep 18, 2014 at 09:18:53AM +0100, Marcus Shawcroft wrote:
gcc/testsuite/
2014-09-15 James Greenhalgh james.greenha...@arm.com
* gcc.target/aarch64/stack_protector_set_1.c: New.
* gcc.target/aarch64/stack_protector_set_2.c: Likewise.
I agree with Andrew,
Thanks for the reply - and the in-depth investigation. I agree that the
correctness of the compiler is critical rather than particular platforms such as
Ada / Alpha.
Moreover, I think we both agree that if result_mode==shift_mode, the
transformation is correct. Just putting that check in,
Hi,
A possible source of errors is in keeping the iterators.md file and the
iterator macros in aarch64-builtin.c synchronized.
Clearly this shouldn't be a problem given standard unix tools, it is just a
text processing job.
This patch adds geniterators.sh to the AArch64 backend which takes the
Hi all,
While browsing the code I noticed that the pattern in the patch has a
store type when it is really a vld1 operation. Looking at the patterns
around it, I think it was just a copy-pasto.
The patch corrects that.
Tested arm-none-eabi.
Ok for trunk?
2014-09-18 Kyrylo Tkachov
On 18/09/14 11:01, Kyrill Tkachov wrote:
Hi all,
While browsing the code I noticed that the pattern in the patch has a
store type when it is really a vld1 operation. Looking at the patterns
around it, I think it was just a copy-pasto.
The patch corrects that.
Tested arm-none-eabi.
This series is a cleaned-up version of:
https://gcc.gnu.org/ml/gcc/2014-03/msg00163.html
The underlying problem is that the semantics of subregs depend on the
word size. You can't have a subreg for byte 2 of a 4-byte word, say,
but you can have a subreg for word 2 of a 4-word value (as well
Patch 4 needs to pass a const HARD_REG_SET to AND/COPY_HARD_REG_SET.
This patch allows that for all intent-in arguments.
gcc/
* hard-reg-set.h (COPY_HARD_REG_SET, COMPL_HARD_REG_SET)
(AND_HARD_REG_SET, AND_COMPL_HARD_REG_SET, IOR_HARD_REG_SET)
(IOR_COMPL_HARD_REG_SET):
On Wed, Sep 17, 2014 at 9:47 PM, Joseph S. Myers
jos...@codesourcery.com wrote:
The i386 sfp-machine.h defines FP_TRAPPING_EXCEPTIONS in a way that is
always wrong: it treats a set bit as indicating the exception is
trapping, when actually a set bit (both for 387 and SSE floating
point)
Try to clarify what subreg_get_info does and doesn't check.
gcc/
* rtl.h (subreg_info): Expand commentary
* rtlanal.c (subreg_get_info): Likewise.
Index: gcc/rtl.h
===
--- gcc/rtl.h 2014-09-15 10:00:14.693366097
On 18/09/14 10:53, James Greenhalgh wrote:
Hi,
A possible source of errors is in keeping the iterators.md file and the
iterator macros in aarch64-builtin.c synchronized.
Clearly this shouldn't be a problem given standard unix tools, it is just a
text processing job.
This patch adds
combine.c:subst should refuse to substitute a hard register
into a subreg if the new subreg would not be simplified to a
simple hard register, since the result would have to be reloaded.
This is more for optimisation than correctness, since in theory
the RA should be able to fix up any
On Wed, Sep 17, 2014 at 03:50:55PM +0100, pins...@gmail.com wrote:
On Sep 17, 2014, at 7:43 AM, James Greenhalgh james.greenha...@arm.com
wrote:
On Wed, Sep 17, 2014 at 09:30:31AM +0100, Richard Earnshaw wrote:
=r is correct for an early-clobbered scratch.
R.
In that
Hi,
As discussed in https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01334.html
The construct
(clobber (match_scratch 0 r))
is invalid - operand 0 must be marked either write or read/write.
Likewise
(match_* 0 r)
is invalid, marking an operand earlyclobber does not remove the need to
also
It seems to be the change to arm_regno_class relating to PC_REGNUM. I see
scal-to-vec1.c failing with just that, or that in combination with the changes
to cfgexpand.c+varasm.c.
And scal-to-vec1.c is OK on -fPIC if I apply the changes to cfgexpand.c,
varasm.c, and arm.c (arm_hard_regno_ok),
This is the main patch for the bug. We should treat a register as invalid
for a mode change if simplify_subreg_regno cannot provide a new register
number for the result. We should treat a class as invalid for a mode change
if all registers in the class are invalid. This is an extension of the
Patch 4 should make it possible to relax i386'a CANNOT_CHANGE_MODE_CLASS,
solving the missed optimisation that triggered the original thread.
gcc/
* config/i386/i386.c (ix86_cannot_change_mode_class): Remove
GET_MODE_SIZE (to) GET_MODE_SIZE (from) test.
Index:
Hello,
We have been maintaining a port to VxWorks MILS for powerpc for a while now
and thought others might be interested.
VxWorksMILS is very close to VxWorksAE, so the patch is pretty small. The main
noticeable difference is that only the vthreads environment headers are
available, so we
On Mon, Sep 15, 2014 at 01:38:42PM +0400, Yury Gribov wrote:
--- a/gcc/builtins.def
+++ b/gcc/builtins.def
@@ -176,7 +176,7 @@ along with GCC; see the file COPYING3. If not see
DEF_BUILTIN (ENUM, __builtin_ NAME, BUILT_IN_NORMAL, TYPE, TYPE,\
true, true, true, ATTRS,
Ok, the approach with additional --enable-offload-targets arguments seems to be
more appropriate, so I will fix offloading infrastructure pach #1.
Thanks,
-- Ilya
On Mon, Sep 15, 2014 at 01:46:14PM +0400, Yury Gribov wrote:
On 09/08/2014 06:29 PM, Yury Gribov wrote:
Kasan developers has asked for an option to override offset of Asan
shadow memory region. This should simplify experimenting with memory
layouts on 64-bit architectures.
I've bootstrapped
On 09/18/2014 03:01 PM, Jakub Jelinek wrote:
On Mon, Sep 15, 2014 at 01:46:14PM +0400, Yury Gribov wrote:
On 09/08/2014 06:29 PM, Yury Gribov wrote:
Kasan developers has asked for an option to override offset of Asan
shadow memory region. This should simplify experimenting with memory
layouts
The end goal here is to remove this code from tree-vect-loop.c
(vect_create_epilog_for_reduction):
if (BYTES_BIG_ENDIAN)
bitpos = size_binop (MULT_EXPR,
bitsize_int (TYPE_VECTOR_SUBPARTS (vectype) - 1),
TYPE_SIZE
The gimple folding ties the AArch64 backend to the tree representation of the
midend via the neon intrinsics. This code enables constant folding of Neon
intrinsics reduction ops, so improves performance, but is not necessary for
correctness. By temporarily removing it (here), we can then change
Hello,
Patch in the bottom extends/adds patterns for masked unpack
instructions.
Bootstrapped.
AVX-512* tests on top of patch-set all pass
under simulator.
Is it ok for trunk?
gcc/
* config/i386/sse.md
(define_insn avx_unpckhpd256mask_name): Add masking.
(define_insn
This fixes PR/61114 by redefining the REDUC_{MIN,MAX,PLUS}_EXPR tree codes.
These are presently documented as producing a vector with the result in element
0, and this is inconsistent with their use in tree-vect-loop.c (which on
bigendian targets pulls the bits out of the wrong end of the
On Wed, 2014-09-17 10:52:34 -0500, Joel Sherrill joel.sherr...@oarcorp.com
wrote:
On 9/17/2014 10:41 AM, Sebastian Huber wrote:
On 09/17/2014 04:45 PM, Jan-Benedict Glaw wrote:
On Wed, 2014-09-17 15:37:32 +0200, Sebastian
Hubersebastian.hu...@embedded-brains.de wrote:
Hello,
This patch adds rest of unpack insn patterns.
Bootstrapped.
AVX-512* tests on top of patch-set all pass
under simulator.
Is it ok for trunk?
gcc/
* config/i386/sse.md
(define_insn avx_unpckhps256mask_name): Add masking.
(define_insn
These match their corresponding tree codes, by taking a vector and returning a
scalar; this is more architecturally neutral than the (somewhat loosely defined)
previous optab that took a vector and returned a vector with the result in the
least significant bits (i.e. element 0 for little-endian
This migrates AArch64 over to the new optab for 'plus' reductions, i.e. so the
define_expands produce scalars by generating a MOV to a GPR. Effectively, this
moves the vget_lane inside every arm_neon.h intrinsic, into the inside of the
define_expand.
Tested: aarch64.exp vect.exp on
Hello,
Patch in the bottom extends AVX-512 shufps.
Bootstrapped.
AVX-512* tests on top of patch-set all pass
under simulator.
Is it ok for trunk?
gcc/
* config/i386/sse.md
(define_expand avx_shufps256mask_expand4_name): Add masking.
(define_insn
Similarly to the previous patch (r/2205), this migrates AArch64 to the new
reduce-to-scalar optabs for min and max. For consistency we apply the same
treatment to the smax_nan and smin_nan patterns (used for __builtins), even
though reduc_smin_nan_scal (etc.) is not a standard name.
Tested:
Hello,
This patch supports AVX-512's vshufpd insns.
Bootstrapped.
AVX-512* tests on top of patch-set all pass
under simulator.
Is it ok for trunk?
gcc/
* config/i386/sse.md
(define_expand avx_shufpd256mask_expand4_name): Add masking.
(define_insn
This gives us back the constant-folding of the neon-intrinsics that was removed
in the first patch, but is now OK for bigendian too.
bootstrapped on aarch64-none-linux-gnu.
check-gcc on aarch64-none-elf and aarch64_be-none-elf.
gcc/ChangeLog:
* config/aarch64/aarch64.c
On Thu, 18 Sep 2014, Uros Bizjak wrote:
OK for mainline and release branches.
I've omitted ia64 from the targets in the testcase in the release branch
version, given the lack of any definition of FP_TRAPPING_EXCEPTIONS at all
there.
(I think a definition as (~_fcw 0x3f) should work for
For reduction operations (e.g. multiply) that don't have such a tree code ,or
where the target platform doesn't define an optab handler for the tree code, we
can perform the reduction using a series of log(N) shifts (where N = #elements
in vector), using the VEC_RSHIFT_EXPR=whole-vector-shift
These are like the previous patch, but using | rather than * - I was unable to
get the previous test to pass on PowerPC and MIPS.
I note there is no inherent vector operation here - a bitwise OR across a word,
and a reduction via shifts using scalar (not vector) ops would be all that's
The VEC_RSHIFT_EXPR is only ever used by the vectorizer in tree-vect-loop.c
(vect_create_epilog_for_reduction), to shift the vector by a whole number of
elements. The tree code allows more general shifts but only for integral types.
This only causes pain and difficulty for backends
A while back a customer complained about this program crashing, which I
explained was because the behavior is undefined; it crashes specifically
because when we try to do the dynamic_cast the F vptr is pointing to a
construction vtable for E-in-F which doesn't have a vbase offset entry
for C,
This allows reduction of non-(plus|min|max) operations using log_2(N) shifts
rather than N vec_extracts; e.g. for example code
int
main (unsigned char argc, char **argv)
{
unsigned char in[16] = { 1,3,5,7,9,11,13,15,17,19,21,23,25,27,29,31 };
unsigned char i = 0;
unsigned char sum = 1;
The VEC_LSHIFT_EXPR tree code, and the corresponding vec_shl_optab, seem to have
been added for completeness, providing a counterpart to VEC_RSHIFT_EXPR and
vec_shr_optab. However, whereas VEC_RSHIFT_EXPRs are generated (only) by the
vectorizer, VEC_LSHIFT_EXPR expressions are not generated at
The direction of VEC_RSHIFT_EXPR has been endian-dependent, contrary to the
general principles of tree. This patch updates fold-const and the vectorizer
(the only place where such expressions are created), such that VEC_RSHIFT_EXPR
always shifts towards element 0.
The tree code still maps
OK.
Jason
The previous patch broke aarch64_be by redefining VEC_RSHIFT_EXPR /
vec_shr_optab to always shift the vector towards gcc's element 0. This fixes
aarch64_be to do that.
check-gcc on aarch64-none-elf (no changes) and aarch64_be-none-elf (fixes all
regressions produced by previous patch, i.e. no
Following earlier patches, vect_create_epilog_for_reduction contains exactly one
case where extract_scalar_result==true. Hence, move the code 'if
(extract_scalar_result)' there, and tidy-up/remove some variables.
bootstrapped on x86_64-none-linux-gnu + check-gcc + check-g++.
gcc/ChangeLog:
Has the changes that have gone into the check parallelization made the
.sum file non-deterministic?
I'm seeing a lot of small hunks in different orders which cause my
comparison scripts to show big differences.
I haven't been paying attention to the nature of the make check changes
so Im not
Patch 12 of 14 (https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01475.html) will
break bigendian targets implementing vec_shr. This is a PowerPC parallel of
patch 13 of 14 (https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01477.html) for
AArch64. I've checked I can build a stage 1 compiler for
Patch 12 of 14 (https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01475.html) will
break bigendian targets implementing vec_shr. This is a MIPS parallel of
patch 13 of 14 (https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01477.html) for
AArch64; the idea is that vec_shr should be unaffected on
On 09/18/2014 09:01 AM, Jakub Jelinek wrote:
On Thu, Sep 18, 2014 at 08:56:50AM -0400, Andrew MacLeod wrote:
Has the changes that have gone into the check parallelization made the .sum
file non-deterministic?
I'm seeing a lot of small hunks in different orders which cause my
comparison scripts
On Thu, Sep 18, 2014 at 08:56:50AM -0400, Andrew MacLeod wrote:
Has the changes that have gone into the check parallelization made the .sum
file non-deterministic?
I'm seeing a lot of small hunks in different orders which cause my
comparison scripts to show big differences.
I haven't been
On Thu, Sep 18, 2014 at 8:42 AM, Alan Lawrence alan.lawre...@arm.com wrote:
The direction of VEC_RSHIFT_EXPR has been endian-dependent, contrary to the
general principles of tree. This patch updates fold-const and the vectorizer
(the only place where such expressions are created), such that
Added Marek to comment on proposed UBSan option change.
On 09/18/2014 02:52 PM, Jakub Jelinek wrote:
--- a/gcc/opts.c
+++ b/gcc/opts.c
@@ -1551,6 +1551,12 @@ common_handle_option (struct gcc_options *opts,
| SANITIZE_RETURNS_NONNULL_ATTRIBUTE))
On 17 Sep 20:06, Uros Bizjak wrote:
On Wed, Sep 17, 2014 at 6:31 PM, Ilya Enkovich enkovich@gmail.com wrote:
I don't like the way arguments are prepared. For the case above,
bnd_ldx should have index_register_operand predicate in its pattern,
and this predicate (and its mode)
Hi!
This testsuite contains a buffer overflow, I've fixed it thusly,
tested that it still fails with the fix reverted and works with current
trunk and committed as obvious to 4.9 and trunk.
2014-09-18 Jakub Jelinek ja...@redhat.com
PR testsuite/63292
* gcc.dg/vect/pr59594.c
On 17 Sep 20:51, Uros Bizjak wrote:
On Wed, Sep 17, 2014 at 8:35 PM, Ilya Enkovich enkovich@gmail.com wrote:
On 16 Sep 12:22, Uros Bizjak wrote:
On Tue, Sep 16, 2014 at 11:37 AM, Ilya Enkovich enkovich@gmail.com
wrote:
2014-09-16 13:08 GMT+04:00 Uros Bizjak ubiz...@gmail.com:
Hi!
Clobber stmts, being artificial statements, were certainly never
meant to be instrumented. In 4.8 when asan has been introduced into gcc,
the lhs of clobber could be only a decl and as a whole decl store would not
be really instrumented, but with *this clobbers in 4.9 that is no longer the
Hi Andrew!
What is the status of this patch? Enabling ASan and UBSan testsuites is
useful for testing installed toolchain, so I wonder if you are going to
commit this.
-Maxim
On 08/04/2014 12:14 PM, Tom de Vries wrote:
On 04-08-14 08:45, Yury Gribov wrote:
Thanks! My 2 (actually 4) cents below.
Hi Yuri,
thanks for the review.
+if ($#ARGV == 1 ($ARGV[0] eq -i || $ARGV[0] eq
--inline)) {
+$diff = $ARGV[1];
Can we shift here and then just set $diff to
I committed this to 4.9 and head.
Sebastian.. please double check that it is OK please.
I had some issues with applying it to the head and
manually did it.
--joel
On 9/17/2014 8:37 AM, Sebastian Huber wrote:
contrib/ChangeLog
2014-09-17 Sebastian Huber sebastian.hu...@embedded-brains.de
On 9/18/2014 6:51 AM, Jan-Benedict Glaw wrote:
On Wed, 2014-09-17 10:52:34 -0500, Joel Sherrill joel.sherr...@oarcorp.com
wrote:
On 9/17/2014 10:41 AM, Sebastian Huber wrote:
On 09/17/2014 04:45 PM, Jan-Benedict Glaw wrote:
On Wed, 2014-09-17 15:37:32 +0200, Sebastian
OK to commit?
2014-09-18 Joel Sherrill joel.sherr...@oarcorp.com
* config-list.mk (LIST): Add v850-rtems.
Index: contrib/config-list.mk
===
--- contrib/config-list.mk (revision 215357)
+++ contrib/config-list.mk
On Sep 17, 2014, at 6:22 PM, David Malcolm dmalc...@redhat.com wrote:
I greatly prefer to use Sphinx over Texinfo, both for the ease of
editing, and the quality of the generated HTML; I already use it for
both the Python bindings to libgccjit, and for gcc-python-plugin.
Hence I've used Sphinx
On Sep 18, 2014, at 1:40 AM, Yury Gribov y.gri...@samsung.com wrote:
How about adding a disclaimer? E.g. beware that Vim plugins are a GAPING
SECURITY HOLE
so use the at YOUR OWN RISK. (And note that Braun's plugin does use
sandboxes).
Building gcc features a security risk at least as big
Ping.
On 09/11/2014 08:20 PM, Maxim Ostapenko wrote:
Hi, Joseph,
Thanks for your review! I've added comments for new functions and
replaced POSIX subprocess interfaces with libiberty's ones.
In general, when cc1 or cc1plus ICE-es, we try to reproduce the bug by
running compiler 3 times and
On 09/18/2014 09:05 AM, Andrew MacLeod wrote:
On 09/18/2014 09:01 AM, Jakub Jelinek wrote:
On Thu, Sep 18, 2014 at 08:56:50AM -0400, Andrew MacLeod wrote:
Has the changes that have gone into the check parallelization made
the .sum
file non-deterministic?
I'm seeing a lot of small hunks in
On Sep 18, 2014, at 3:12 AM, Richard Earnshaw rearn...@arm.com wrote:
Is there any real need to write this into the source directory and have
the built file checked in? Ie. can't we always write to the build
directory and use it from there.
I build part of my .md file from a C++ program, so
The following patch fixes the PR. The details can be found on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61360
The patch was bootstrapped and tested on x86/x86-64.
Committed as rev. 215358.
2014-09-18 Vladimir Makarov vmaka...@redhat.com
PR target/61360
* lra.c (lra):
Doing this caught missing return statements in the examples.
This brings the result I see in jit.sum to: # of expected passes 4286
Committed to branch dmalcolm/jit:
gcc/jit/ChangeLog.jit:
* docs/examples/install-hello-world.c (main): Fix missing
return.
*
On Thu, Sep 18, 2014 at 12:04:30PM -0400, Vladimir Makarov wrote:
The following patch fixes the PR. The details can be found on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61360
The patch was bootstrapped and tested on x86/x86-64.
Committed as rev. 215358.
What effect does this have
Similarly named DECL_ABSTRACT, DECL_ABSTRACT_ORIGIN, and DECL_ORIGIN are
somewhat confusing to my poor brain. Particularly annoying is
DECL_ABSTRACT which is actually a boolean, unlike the other two.
Would it be OK to rename it something more sensible like
DECL_ABSTRACT_P? I know this is a
On Thu, Sep 18, 2014 at 10:11:24AM -0600, Aldy Hernandez wrote:
Similarly named DECL_ABSTRACT, DECL_ABSTRACT_ORIGIN, and DECL_ORIGIN are
somewhat confusing to my poor brain. Particularly annoying is DECL_ABSTRACT
which is actually a boolean, unlike the other two.
Would it be OK to rename it
Hi Joseph:
Here is updated patch and ChangeLog,
However I don't have commit write yet, can you help me to commit it? thanks
btw, I has already signed FSF agreement:)
2014-09-19 Kito Cheng k...@0xlab.org
except.h: Fix header guard.
addresses.h: Add missing header guard.
- DECL_ABSTRACT (fn) = 1;
+ DECL_ABSTRACT_P (fn) = 1;
It'd probably make sense to use 'true' now.
I thought about it, but I wanted to change as little as possible, plus I
wanted to follow the same style as what we've been doing for a lot of
the _P macros:
DECL_HAS_VALUE_EXPR_P (t) =
On Thu, Sep 18, 2014 at 10:30:30AM -0600, Aldy Hernandez wrote:
- DECL_ABSTRACT (fn) = 1;
+ DECL_ABSTRACT_P (fn) = 1;
It'd probably make sense to use 'true' now.
I thought about it, but I wanted to change as little as possible, plus I
wanted to follow the same style as what we've been
output_inline_function was removed in tree-ssa times, no sense
referencing it a decade later.
I still see DECL_ABSTRACT_ORIGIN pointing to itself in some instances,
though I haven't tracked down where, so I assume we still need the
functionality, just not the comment :).
OK for mainline?
We've been seeing errors using aarch64-none-linux-gnu gcc to build the 403.gcc
benchmark from spec2k6, that we've traced back to this patch. The error looks like:
/home/alalaw01/bootstrap_richie/gcc/xgcc -B/home/alalaw01/bootstrap_richie/gcc
-O3 -mcpu=cortex-a57.cortex-a53 -DSPEC_CPU_LP64
Hello,
the ABI warning messages I introduced in recent patches refer to a GCC
version 4.10. As GCC has since adopted a new version naming scheme,
this patch updates those messages to refer to GCC 5 instead.
Tested on powerpc64le-linux.
OK for mainline?
Bye,
Ulrich
ChangeLog:
*
On Wed, Sep 10, 2014 at 05:21:07PM +0200, Thomas Schwinge wrote:
Hi!
On Wed, 10 Sep 2014 12:23:04 +0200, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Sep 10, 2014 at 12:12:03PM +0200, Thomas Schwinge wrote:
Are the following issues known?
No, please file a PR.
Will do tomorrow.
On 09/18/2014 12:10 PM, Jakub Jelinek wrote:
On Thu, Sep 18, 2014 at 12:04:30PM -0400, Vladimir Makarov wrote:
The following patch fixes the PR. The details can be found on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61360
The patch was bootstrapped and tested on x86/x86-64.
Committed as
On Thu, Sep 18, 2014 at 1:47 PM, Kirill Yukhin kirill.yuk...@gmail.com wrote:
Hello,
Patch in the bottom extends/adds patterns for masked unpack
instructions.
Bootstrapped.
AVX-512* tests on top of patch-set all pass
under simulator.
Is it ok for trunk?
gcc/
*
On Thu, Sep 18, 2014 at 1:54 PM, Kirill Yukhin kirill.yuk...@gmail.com wrote:
Hello,
This patch adds rest of unpack insn patterns.
Bootstrapped.
AVX-512* tests on top of patch-set all pass
under simulator.
Is it ok for trunk?
gcc/
* config/i386/sse.md
(define_insn
Hello,
VxWorks ports typically come in two flavors: regular VxWorks and VxWorksAE
(653). In most cases, cpu/vxworks.h is used as a common configuration file
for the two flavors and cpu/vxworksae.h overrides/adds on top of that.
There are also config/vx*.h shared by everybody.
The x86 port
On Thu, Sep 18, 2014 at 1:59 PM, Kirill Yukhin kirill.yuk...@gmail.com wrote:
Hello,
Patch in the bottom extends AVX-512 shufps.
Bootstrapped.
AVX-512* tests on top of patch-set all pass
under simulator.
Is it ok for trunk?
gcc/
* config/i386/sse.md
(define_expand
On Thu, Sep 18, 2014 at 2:02 PM, Kirill Yukhin kirill.yuk...@gmail.com wrote:
Hello,
This patch supports AVX-512's vshufpd insns.
Bootstrapped.
AVX-512* tests on top of patch-set all pass
under simulator.
Is it ok for trunk?
gcc/
* config/i386/sse.md
(define_expand
On Thu, Sep 18, 2014 at 12:40:08PM +0400, Yury Gribov wrote:
When typing 'make .local.vimrc' in GCC build directory one would expect
.local.vimrc to be created at the root of build directory, not srcdir.
Yes, you would not expect it to do anything to your source dir, ever :-)
+ To enable
On Thu, Sep 18, 2014 at 4:00 PM, Ilya Enkovich enkovich@gmail.com wrote:
On 17 Sep 20:51, Uros Bizjak wrote:
On Wed, Sep 17, 2014 at 8:35 PM, Ilya Enkovich enkovich@gmail.com
wrote:
On 16 Sep 12:22, Uros Bizjak wrote:
On Tue, Sep 16, 2014 at 11:37 AM, Ilya Enkovich
On 09/18/2014 05:03 PM, Andrew MacLeod wrote:
On 09/18/2014 09:05 AM, Andrew MacLeod wrote:
On 09/18/2014 09:01 AM, Jakub Jelinek wrote:
On Thu, Sep 18, 2014 at 08:56:50AM -0400, Andrew MacLeod wrote:
Has the changes that have gone into the check parallelization made
the .sum
file
Committed to branch dmalcolm/jit:
gcc/jit/ChangeLog.jit:
* docs/intro/install.rst: Markup fixes.
* docs/intro/tutorial01.rst: Likewise.
* docs/intro/tutorial02.rst: Likewise.
* docs/topics/contexts.rst: Likewise.
* docs/topics/expressions.rst: Likewise.
On Thu, Sep 18, 2014 at 3:47 PM, Ilya Enkovich enkovich@gmail.com wrote:
Thanks for your comments. Below is a fixed verison.
Ilya
--
2014-09-17 Ilya Enkovich ilya.enkov...@intel.com
* config/i386/i386-builtin-types.def (BND): New.
(ULONG): New.
On Thu, Sep 18, 2014 at 07:32:00PM +0200, Bernd Schmidt wrote:
hum. My 3rd run (which has no compilation change from the 2nd one) is
different from both other runs :-P. I did tweak my -j parameter in
the make check, but that is it.
I'm also seeing this. Python 3.3.5 here.
Segher on IRC
Jakub Jelinek ja...@redhat.com writes:
On Thu, Sep 18, 2014 at 12:04:30PM -0400, Vladimir Makarov wrote:
The following patch fixes the PR. The details can be found on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61360
The patch was bootstrapped and tested on x86/x86-64.
Committed as
On Thu, Sep 18, 2014 at 10:56 AM, Yury Gribov y.gri...@samsung.com wrote:
On 08/04/2014 12:14 PM, Tom de Vries wrote:
On 04-08-14 08:45, Yury Gribov wrote:
Thanks! My 2 (actually 4) cents below.
Hi Yuri,
thanks for the review.
+if ($#ARGV == 1 ($ARGV[0] eq -i || $ARGV[0] eq
Hi!
Here is my OpenACC acc_on_device patch, in a more complete form, with
test cases and all that. Thanks, Cesar, for getting the ball rolling!
On Wed, 17 Sep 2014 10:49:54 +0200, Jakub Jelinek ja...@redhat.com wrote:
On Wed, Sep 17, 2014 at 10:44:12AM +0200, Tobias Burnus wrote:
Cesar
On 09/18/2014 01:36 PM, Richard Sandiford wrote:
Jakub Jelinek ja...@redhat.com writes:
On Thu, Sep 18, 2014 at 12:04:30PM -0400, Vladimir Makarov wrote:
The following patch fixes the PR. The details can be found on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61360
The patch was
Committed to branch dmalcolm/jit:
The default Sphinx theme is perhaps a little dated; switch
to a non-default one. The pyramid one is clean and attractive IMHO.
I've updated the prebuilt docs currently at:
https://dmalcolm.fedorapeople.org/gcc/libgccjit-api-docs/
to use the new theme.
On Thu, Sep 18, 2014 at 9:44 AM, Alan Lawrence alan.lawre...@arm.com wrote:
We've been seeing errors using aarch64-none-linux-gnu gcc to build the
403.gcc benchmark from spec2k6, that we've traced back to this patch. The
error looks like:
/home/alalaw01/bootstrap_richie/gcc/xgcc
1 - 100 of 162 matches
Mail list logo
