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
> > 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 purp
On 17 September 2014 15:43, James Greenhalgh 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 -fstack-protect
On Thu, Sep 18, 2014 at 11:14 AM, Hans-Peter Nilsson 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
>> > wrote:
>> > > 'k so we'll track the regressions in a PR.
>> >
>> > Do you pre
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 s
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
> >
> > * gcc.target/aarch64/stack_protector_set_1.c: New.
> > * gcc.target/aarch64/stack_protector_set_2.c: Likewise.
>
> I agree with Andrew, these don't ne
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, achie
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-
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): All
On Wed, Sep 17, 2014 at 9:47 PM, Joseph S. Myers
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) indicates it is masked, an
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 +0
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 pat
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 unsimplified
On Wed, Sep 17, 2014 at 03:50:55PM +0100, pins...@gmail.com wrote:
>
>
> > On Sep 17, 2014, at 7:43 AM, James Greenhalgh
> > 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 ca
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
a
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), i.
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 ol
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: gcc/config/i386/i
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 arrang
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 bo
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 o
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 (scalar_typ
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_unpckhpd256"): Add masking.
(define_insn "avx512vl_
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 vecto
On Wed, 2014-09-17 10:52:34 -0500, Joel Sherrill
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
> > > Huber wrote:
> > > > > contrib/ChangeLog
> > > > > 2014-09-17 Sebastian Huber
>
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_unpckhps256"): Add masking.
(define_insn "vec_interleave_highv4sf"): Ditto.
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 aarch64-non
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_shufps256"): Add masking.
(define_insn "avx_shufps256_1"): Ditto.
(defin
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: ch
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_shufpd256"): Add masking.
(define_insn "avx_shufpd256_1"): Ditto.
(defi
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 (TARGET_GIMPLE_F
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 ia6
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 tr
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
neces
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 (particularly
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, s
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 a
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 dire
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 sur
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 powerp
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 little-end
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 t
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 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
> VEC_RSHIFT_EXPR alwa
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))
opts->x_flag
On 17 Sep 20:06, Uros Bizjak wrote:
> On Wed, Sep 17, 2014 at 6:31 PM, Ilya Enkovich 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) should be c
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
PR testsuite/63292
* gcc.dg/vect/pr59594.c (b): Increase size
On 17 Sep 20:51, Uros Bizjak wrote:
> On Wed, Sep 17, 2014 at 8:35 PM, Ilya Enkovich wrote:
> > On 16 Sep 12:22, Uros Bizjak wrote:
> >> On Tue, Sep 16, 2014 at 11:37 AM, Ilya Enkovich
> >> wrote:
> >> > 2014-09-16 13:08 GMT+04:00 Uros Bizjak :
> >> >>
> >> >> Can x86_64_immediate_operand predic
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
ca
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
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
>
> * config-list.mk (LIST): Ad
On 9/18/2014 6:51 AM, Jan-Benedict Glaw wrote:
> On Wed, 2014-09-17 10:52:34 -0500, Joel Sherrill
> 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
Huber wrote:
>> contrib/Ch
OK to commit?
2014-09-18 Joel Sherrill
* config-list.mk (LIST): Add v850-rtems.
Index: contrib/config-list.mk
===
--- contrib/config-list.mk (revision 215357)
+++ contrib/config-list.mk (working copy)
@@ -68,7 +6
On Sep 17, 2014, at 6:22 PM, David Malcolm 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 for these docs.
On Sep 18, 2014, at 1:40 AM, Yury Gribov 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 as a plugin for
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 c
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 diff
On Sep 18, 2014, at 3:12 AM, Richard Earnshaw 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 I have to bu
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
PR target/61360
* lra.c (lra): Call recog_init.
2014-
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".
* docs/exampl
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
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 l
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 renam
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
except.h: Fix header guard.
addresses.h: Add missing header guard.
cfghooks.h: Likewise.
- 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) = 1;
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 wh
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?
Al
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:
* c
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 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.
Her
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.
>>
>
On Thu, Sep 18, 2014 at 1:47 PM, Kirill Yukhin 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/
> * config/i386/sse.md
>
On Thu, Sep 18, 2014 at 1:54 PM, Kirill Yukhin 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_unpckhps256"
Hello,
VxWorks ports typically come in two flavors: regular VxWorks and VxWorksAE
(653). In most cases, /vxworks.h is used as a common configuration file
for the two flavors and /vxworksae.h overrides/adds on top of that.
There are also config/vx*.h shared by everybody.
The x86 port departs from
On Thu, Sep 18, 2014 at 1:59 PM, Kirill Yukhin 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 "avx_shufps256"):
On Thu, Sep 18, 2014 at 2:02 PM, Kirill Yukhin 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 "avx_shufpd256")
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 enabl
On Thu, Sep 18, 2014 at 4:00 PM, Ilya Enkovich wrote:
> On 17 Sep 20:51, Uros Bizjak wrote:
>> On Wed, Sep 17, 2014 at 8:35 PM, Ilya Enkovich
>> wrote:
>> > On 16 Sep 12:22, Uros Bizjak wrote:
>> >> On Tue, Sep 16, 2014 at 11:37 AM, Ilya Enkovich
>> >> wrote:
>> >> > 2014-09-16 13:08 GMT+04:00
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 non-determin
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 wrote:
> Thanks for your comments. Below is a fixed verison.
>
> Ilya
> --
> 2014-09-17 Ilya Enkovich
>
> * config/i386/i386-builtin-types.def (BND): New.
> (ULONG): New.
> (BND_FTYPE_PCVOID_ULONG): New.
> (VOID_FT
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 o
Jakub Jelinek 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 rev.
On Thu, Sep 18, 2014 at 10:56 AM, Yury Gribov 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" || "$ARG
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 wrote:
> On Wed, Sep 17, 2014 at 10:44:12AM +0200, Tobias Burnus wrote:
> > Cesar Philippidis wrote:
On 09/18/2014 01:36 PM, Richard Sandiford wrote:
> Jakub Jelinek 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 bootstra
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.
gcc/j
On Thu, Sep 18, 2014 at 9:44 AM, Alan Lawrence 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
> -B/home/alalaw01/bootstrap_r
1 - 100 of 170 matches
Mail list logo
