On Fri, Oct 24, 2014 at 11:28 PM, Yangfei (Felix) wrote:
>> On Fri, Oct 24, 2014 at 8:35 PM, Yangfei (Felix)
>> wrote:
>> >> Hi,
>> >>
>> >> I find that the -mlong-calls option is not there for AARCH64. So
>> >> can this port generate long calls?
>> >> Any plan on this option? I would li
> On Fri, Oct 24, 2014 at 8:35 PM, Yangfei (Felix)
> wrote:
> >> Hi,
> >>
> >> I find that the -mlong-calls option is not there for AARCH64. So
> >> can this port generate long calls?
> >> Any plan on this option? I would like to have a try on this if it's
> >> missing :-)
> >> Thank
Fixed PR/63582. Tested with no regressions on x86-64 and ix86. Ok?
* tree.c (build_common_tree_nodes): Don't even store the
__int128 types if they're not supported.
Index: tree.c
===
--- tree.c (revision 21667
On Fri, Oct 24, 2014 at 8:35 PM, Yangfei (Felix) wrote:
>> Hi,
>>
>> I find that the -mlong-calls option is not there for AARCH64. So can
>> this port
>> generate long calls?
>> Any plan on this option? I would like to have a try on this if it's
>> missing :-)
>> Thanks.
>
>
> Any co
> Hi,
>
> I find that the -mlong-calls option is not there for AARCH64. So can this
> port
> generate long calls?
> Any plan on this option? I would like to have a try on this if it's
> missing :-)
> Thanks.
Any comments?
> On 24 October 2014 03:21, Yangfei (Felix) wrote:
>
> > Thanks for the comments. I updated the patch with the intrinsic moved to its
> place.
> > Attached please find the new version of the patch.
> > OK for the trunk?
> >
> >
> > Index: gcc/ChangeLog
> >
> ==
[Jason approved this patch off-line, and I am committing now that tests
have successfully run.]
This is a bug I found while investigating early dwarf generation, but
that is broken mainline as well.
For the following code:
namespace S
{
int i=777;
int
f()
{
int i = 42;
{
On Fri, Oct 24, 2014 at 8:06 AM, Alan Lawrence wrote:
> This migrates the reduction patterns in altivec.md and vector.md to the new
> names. I've not touched paired.md as I wasn't really sure how to fix that
> (how do I vec_extractv2sf ?), moreover the testing I did didn't seem to
> exercise any o
On Wed, Oct 22, 2014 at 10:02 PM, Joseph S. Myers
wrote:
> Continuing the cleanups of libgcc soft-fp configuration for
> powerpc*-*-linux* in preparation for implementing
> TARGET_ATOMIC_ASSIGN_EXPAND_FENV for soft-float and e500, this patch
> optimizes the choice of which functions to build for t
On 10/24/14 17:37, Evgeny Stupachenko wrote:
What if we remove the check?
glibc build pass?
That would be my inclination... But it's not my decision to make.
The first check is to verify glibc builds and passes its testsuite with
the new compiler and that check removed.
jeff
On Fri, Oct 24, 2014 at 7:09 PM, Joseph S. Myers
wrote:
> rs6000_hard_regno_nregs_internal allows SPE vectors in single
> registers satisfying SPE_SIMD_REGNO_P (i.e. register numbers 0 to
> 31). However, the corresponding test for e500 double treats all
> registers as being able to store a 64-bit
What if we remove the check?
glibc build pass?
On Sat, Oct 25, 2014 at 3:09 AM, Andrew Pinski wrote:
> On Fri, Oct 10, 2014 at 12:43 AM, Evgeny Stupachenko
> wrote:
>> i386 specific part of the patch:
>>
>> 2014-10-08 Ilya Enkovich
>> Vladimir Makarov
>> * gcc/config/i3
genmatch is hanging when bootstrapping on AIX (gcc111). When I attach
to the process:
#0 0x1007efac in std::basic_string,
std::allocator >::basic_string ()
#1 0x1000e6b0 in _ZN6parser13parse_captureEP7operand (this=0x300594b8, op=0x0)
at /home/dje/src/src/gcc/genmatch.c:2607
#2 0x1000e9f0
On Mon, 20 Oct 2014, Alan Modra wrote:
> You were correct to be suspicious that we weren't simplifying as we
> should. After more time in the debugger than I care to admit, I found
> the underlying cause.
>
> One of the var loc expressions is
> (plus:SI (plus:SI (not:SI (debug_expr:SI D#9))
>
On Fri, Oct 10, 2014 at 12:43 AM, Evgeny Stupachenko wrote:
> i386 specific part of the patch:
>
> 2014-10-08 Ilya Enkovich
> Vladimir Makarov
> * gcc/config/i386/i386.c (ix86_use_pseudo_pic_reg): New.
> (ix86_init_pic_reg): New.
> (ix86_select_alt_pic_regn
rs6000_hard_regno_nregs_internal allows SPE vectors in single
registers satisfying SPE_SIMD_REGNO_P (i.e. register numbers 0 to
31). However, the corresponding test for e500 double treats all
registers as being able to store a 64-bit value, rather than just
those GPRs.
Logically this inconsistenc
Hi,
this patch has been mostly written by Ganesh and has only slightly
been then amended by me. It improves the current workaround which we
use to locate HSAIL until we can link it properly by attempting to
derive the file name from the current input name. More details in the
README.hsa changes.
Hi,
this is a very simple cleanup, renaming two fields of different
classes called offset to a more descriptive name and removal of one
which is no longer used.
Committed to the branch.
Thanks,
Martin
2014-10-24 Martin Jambor
* hsa.h (hsa_symbol): Renamed offset to directive_offse
OK. Gerald, were you thinking of specific software that would be
affected by this change?
Jason
On Sat, Oct 25, 2014 at 12:19 AM, Yuri Gribov wrote:
> Same fix for 5.0 will be probably commited in
Forgot to mention that this one is for 4.9.
-Y
On 10/17/14 14:41, Marc Glisse wrote:
On Thu, 16 Oct 2014, Jeff Law wrote:
BTW, I dislike having multiple DCE implementations...
Similarly. The proposal above was just to determine if we should
schedule DCE or not.
Thinking about it some more, I don't think we should need any kind of
DCE he
Hi all,
This patch fixes was approved by Jakub in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63638 . Same fix for 5.0
will be probably commited in
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02066.html .
-Y
commit 87a472b057af66d46a5437137e9535c70de5c786
Author: Yury Gribov
Date: Fri Oct 2
On 10/18/14 15:59, Marc Glisse wrote:
On Thu, 10 Jul 2014, Richard Biener wrote:
On Sun, Jun 29, 2014 at 12:33 AM, Marc Glisse
wrote:
we currently drop clobbers on variables whose address is not taken
anymore.
However, rewrite_stmt has code to replace them with an SSA_NAME with a
default def
On 10/23/14 08:30, jb...@gmx.de wrote:
"Jeff Law" :
On 10/21/14 12:21, jb...@gmx.de wrote:
"Jeff Law" :
On 10/21/14 16:13, Haswell wrote:
The additional source must have the same requirement crossmodule-indircall-1.c
has.
* crossmodule-indircall-1a.c: Add missing requirement.
Why?
On 10/22/14 15:11, Bernd Schmidt wrote:
On 10/22/2014 10:31 PM, Jeff Law wrote:
These tools currently require GNU extensions - something I probably
ought to fix if we decide to add them to the gcc build itself.
Would these be more appropriate in binutils?
I don't think so, given that we don't
On 10/23/14 00:56, Alan Modra wrote:
PR 63615 was caused by r21642 fixing the accounting of "n_constants"
in simplify_plus_minus. Previously, any expression handled by
simplify_plus_minus that expanded to more than two elements and
contained at least one constant would have resulted in "n_consta
I want to resurrect this patch that I didn't pursue for 4.8, because
our violates this very explicit requirement in the C++11
and C++14 standards:
18.10 [support.runtime] p8
"The header and the header shall not define
macros named bool, true, or false."
Is the gcc/ginclude/stdbool.h change OK
On Fri, Oct 24, 2014 at 10:55 AM, Xinliang David Li wrote:
> When orgin_addr == addr, is there a guarantee that this assert:
>
> gcc_assert (TREE_OPERAND (op,0) == addr);
>
> is always true?
It should be, that is the assumption of the code that we are trying to
enforce with the assert.
Teresa
On 10/24/14 08:09, Jiong Wang wrote:
ping~
thanks.
Regards,
Jiong
On 17/10/14 13:04, Jiong Wang wrote:
the cause should be one minor bug in prepare_cmp_insn.
the last mode parameter "pmode" of "prepare_cmp_insn" should match the
mode of the first parameter "x", while during the recursive cal
On 13 Oct 12:19, Jakub Jelinek wrote:
> On Sat, Oct 11, 2014 at 06:49:00PM +0400, Ilya Verbin wrote:
> > It introduces 2 new options:
> > 1. -foffload==
> >By default, GCC will build offload images for all offload targets
> > specified
> > in configure, with non-target-specific options passed
On Fri, Oct 24, 2014 at 10:29:50PM +0400, Ilya Verbin wrote:
> diff --git a/gcc/opts.c b/gcc/opts.c
> index 9b2e1af..d1a626c 100644
> --- a/gcc/opts.c
> +++ b/gcc/opts.c
> @@ -1732,6 +1732,13 @@ common_handle_option (struct gcc_options *opts,
>/* Deferred. */
>break;
>
> +#ifndef
On Fri, Oct 24, 2014 at 6:26 AM, Andreas Schwab wrote:
> Ian Taylor writes:
>
>> 2014-10-23 Ian Lance Taylor
>>
>> * config/mep/mep.h (TARGET_HAS_F_SETLKW): Don't define.
>
> s/define/undefine/
Thanks. Fixed. (Changes to ChangeLog files do not themselves require
ChangeLog entries.)
Ian
Ind
When orgin_addr == addr, is there a guarantee that this assert:
gcc_assert (TREE_OPERAND (op,0) == addr);
is always true?
David
On Fri, Oct 24, 2014 at 10:21 AM, Teresa Johnson wrote:
> This patch makes a fix to the reference fixups performed after LIPO
> node resolution, to better handle t
On 10/24/14 09:22, Andrew MacLeod wrote:
Don't let it's size scare you, this is actually fairly trivial now. I
split it into the more interesting patch and the big, boring, mechanical
one. all-in-all, it touches 351 files :-P.
This patch completely flattens basic-block.h. I manually adjusted s
On 10/24/14 07:16, Richard Biener wrote:
This patch makes GIMPLE forwprop fold all statements, following
single-use SSA edges only (as suggested by Jeff and certainly
how this will regress the least until we replace manual
simplification code that does not restrict itself this way).
forwprop is
This patch makes a fix to the reference fixups performed after LIPO
node resolution, to better handle the case where we are updating the
base address of a reference.
Fixes google benchmark and passes regression tests. Ok for google/4_9?
Thanks,
Teresa
2014-10-24 Teresa Johnson
Google
On 24/10/14 12:50, Marek Polacek wrote:
diff --git a/gcc/testsuite/gcc.target/arm/aapcs/abitest.h
b/gcc/testsuite/gcc.target/arm/aapcs/abitest.h
index 06a92c3..7bce58b 100644
--- a/gcc/testsuite/gcc.target/arm/aapcs/abitest.h
+++ b/gcc/testsuite/gcc.target/arm/aapcs/abitest.h
@@ -49,6 +49,8 @@
Well, I'd be happy with that. Curiously, that patch is identical to what I have
here...and that's not what I got having built gcc with
--target=sparc-sun-solaris2.11, but on further investigation it looks like the
require-effective-target-ilp32/64 is not working correctly on my setup.
FWIW I'v
> From: Richard Biener
> Date: Fri, 24 Oct 2014 09:56:51 +0200
> On Fri, 24 Oct 2014, Hans-Peter Nilsson wrote:
> > Still, I don't understand exactly how your patch
> > introduces build-subdirectories where there were none before.
> > Maybe that "+all-gcc: maybe-all-build-libcpp" was wrong and
> >
On 10/24/14 01:15, Phil Muldoon wrote:
On 10/10/14 22:58, Jeff Law wrote:
On 10/09/14 03:07, Phil Muldoon wrote:
Sorry for taking so long to reply. We've talked, on irc and elsewhere
a little (some at the Cauldron too!). I think the consensus is as
nobody has explicitly mentioned anything, t
On 10/24/14 04:12, Jan Beulich wrote:
On 24.10.14 at 11:52, wrote:
On Fri, Oct 24, 2014 at 11:18 AM, Jakub Jelinek wrote:
On Fri, Oct 24, 2014 at 11:10:08AM +0200, Richard Biener wrote:
For something in static storage, this seems OK. However, I think a hard
register variable ought to be lef
On 10/24/14 08:16, Marek Polacek wrote:
Our current C pretty printer output sometimes looks a bit goofy:
"expected ‘enum F *’ but argument is of type ‘enum F *’".
It's because it always prints "struct"/"union"/"enum" even though
the type is a typedef name. This patch ought to fix this.
We've got
On 23 October 2014 21:10, Dodji Seketeli wrote:
> Sorry, I forgot to make it clear that I have no power to approve the
> line-map changes. I just gave my casual point view; so please take it
> for what it is worth.
>
> I am CC-ing Tom and Jason who can approve this.
I don't see the CCs in the co
On 24 Oct 18:07, Jakub Jelinek wrote:
> On Fri, Oct 24, 2014 at 08:03:42PM +0400, Ilya Verbin wrote:
> > A small addition, refcount and copy_from were uninitialized for globals.
> >
> >
> > diff --git a/libgomp/target.c b/libgomp/target.c
> > index 4ace170..5b4873b 100644
> > --- a/libgomp/target
On Fri, Oct 24, 2014 at 08:03:42PM +0400, Ilya Verbin wrote:
> A small addition, refcount and copy_from were uninitialized for globals.
>
>
> diff --git a/libgomp/target.c b/libgomp/target.c
> index 4ace170..5b4873b 100644
> --- a/libgomp/target.c
> +++ b/libgomp/target.c
> @@ -647,6 +647,8 @@ go
On 08 Oct 13:08, Jakub Jelinek wrote:
> On Mon, Oct 06, 2014 at 07:53:17PM +0400, Ilya Verbin wrote:
> > libgomp/
> > * libgomp.map (GOMP_4.0.1): New symbol version.
> > Add GOMP_offload_register.
> > * libgomp_target.h: New file.
> > * splay-tree.h: New file.
> > * target.c: In
On 10/24/2014 02:43 PM, Eric Botcazou wrote:
some time ago, Andrew wrote a patch that fixes PR58867
(http://patchwork.ozlabs.org/patch/286866/), but for some reasons it
wasn't committed to trunk.
This is resurrected Andrew's patch, extended to support Tsan testsuite.
This patch broke --disable
On Fri, Oct 24, 2014 at 8:44 AM, Christophe Lyon
wrote:
> On 29 September 2014 15:01, Christophe Lyon
> wrote:
>> On 26 September 2014 23:05, Andreas Schwab wrote:
>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=34c65c4
>>>
>>> * sanitizer_common/sanitizer
On Fri, Oct 24, 2014 at 07:19:53PM +0400, Evgeny Stupachenko wrote:
> >What is wrong in emitting the set_got right before the PROLOGUE_END
> >note and that way sharing a single load from both?
> Can you please explain the idea? Now set_got emitted right after
> PROLOGUE_END, what is the advantage i
On 29 September 2014 15:01, Christophe Lyon wrote:
> On 26 September 2014 23:05, Andreas Schwab wrote:
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=34c65c4
>>
>> * sanitizer_common/sanitizer_platform_limits_posix.h
>> (__sanitizer___kernel_old_uid_
Don't let it's size scare you, this is actually fairly trivial now. I
split it into the more interesting patch and the big, boring, mechanical
one. all-in-all, it touches 351 files :-P.
This patch completely flattens basic-block.h. I manually adjusted some
of the remaining .h files and repli
>What is wrong in emitting the set_got right before the PROLOGUE_END
>note and that way sharing a single load from both?
Can you please explain the idea? Now set_got emitted right after
PROLOGUE_END, what is the advantage in emitting it right before?
Which load is going to be shared?
>This looks j
On Fri, Oct 24, 2014 at 07:08:44PM +0400, Ilya Verbin wrote:
> On 24 Oct 16:35, Jakub Jelinek wrote:
> > On Thu, Oct 23, 2014 at 07:41:12PM +0400, Ilya Verbin wrote:
> > > > malloc can fail, SIGSEGV in response to that is not desirable.
> > > > Can't you fallback to alloca, or use just alloca, or u
Alan Lawrence writes:
> Patches 7-11 migrate migrate ARM, x86, IA64 (I think), and mostly PowerPC,
> to
> the new reduc_(plus|[us](min|max))_scal_optab. I have not managed to work
> out
> how to do the same for MIPS (specifically what I need to add to
> mips_expand_vec_reduc), and have had no resp
On 24 October 2014 11:23, Marcus Shawcroft wrote:
> On 23 October 2014 18:51, Charles Baylis wrote:
>
>>> Otherwise this and the previous 1/2 associated patch look good, can
>>> you respin with these tidy ups?
>>
>> OK for trunk?
>
> OK
> /Marcus
Committed to trunk as r216671 and r216672.
On 24 Oct 16:35, Jakub Jelinek wrote:
> On Thu, Oct 23, 2014 at 07:41:12PM +0400, Ilya Verbin wrote:
> > > malloc can fail, SIGSEGV in response to that is not desirable.
> > > Can't you fallback to alloca, or use just alloca, or use alloca
> > > with malloc fallback?
> >
> > I replaced it with all
Function (or more narrow) scope static variables (as well as others not
placed on the stack) should also not have any effect on the stack
alignment. I noticed the issue first with Linux'es dynamic_pr_debug()
construct using an 8-byte aligned sub-file-scope local variable.
According to my checking
On Thu, Oct 23, 2014 at 07:41:12PM +0400, Ilya Verbin wrote:
> > malloc can fail, SIGSEGV in response to that is not desirable.
> > Can't you fallback to alloca, or use just alloca, or use alloca
> > with malloc fallback?
>
> I replaced it with alloca.
There is a risk if a suid or otherwise privi
On Fri, Oct 24, 2014 at 06:12:15PM +0400, Evgeny Stupachenko wrote:
> The following patch align stack for mcount and there should be no
> problems with unwind as ix86_frame_pointer_required is true when
> crtl->profile is true and flag_fentry is false (we call mcount after
> function prolog).
> Whe
On Fri, Oct 24, 2014 at 06:16:01PM +0400, Ilya Verbin wrote:
> We have to set the global have_offload flag in few places in omp-low.c and in
> FE
> (c/c-decl.c:c_decl_attributes, fortran/trans-common.c:build_common_decl,
> fortran/trans-decl.c:add_attributes_to_decl).
> This way looks for me a bit
Our current C pretty printer output sometimes looks a bit goofy:
"expected ‘enum F *’ but argument is of type ‘enum F *’".
It's because it always prints "struct"/"union"/"enum" even though
the type is a typedef name. This patch ought to fix this.
We've got a bunch of reports about this over the y
On 20 Oct 15:19, Ilya Verbin wrote:
> On 15 Oct 16:23, Richard Biener wrote:
> > > +static bool
> > > +initialize_offload (void)
> > > +{
> > > + bool have_offload = false;
> > > + struct cgraph_node *node;
> > > + struct varpool_node *vnode;
> > > +
> > > + FOR_EACH_DEFINED_FUNCTION (node)
> >
Our was implemented (by Benjamin IIRC) based on an early
C++0x draft when the spec was still trying to be valid for both C and
C++. Part of the C compatibility aspect was that std::atomic_int is
allowed to be either a typedef for std::atomic or a base class of
it, so that a C library could define
The following patch align stack for mcount and there should be no
problems with unwind as ix86_frame_pointer_required is true when
crtl->profile is true and flag_fentry is false (we call mcount after
function prolog).
When flag_fentry is true it is set to false in 32bit PIC mode:
if (!TARGET_64BI
ping~
thanks.
Regards,
Jiong
On 17/10/14 13:04, Jiong Wang wrote:
the cause should be one minor bug in prepare_cmp_insn.
the last mode parameter "pmode" of "prepare_cmp_insn" should match the
mode of the first parameter "x", while during the recursive call of
"prepare_cmp_insn",
x is with mo
On Fri, Oct 24, 2014 at 05:56:37PM +0400, Yury Gribov wrote:
> >From 1882c41de6c8ae53b7e199b3cc655b6f4b31e8fb Mon Sep 17 00:00:00 2001
> From: Yury Gribov
> Date: Thu, 16 Oct 2014 18:31:10 +0400
> Subject: [PATCH 1/2] Add strtoll and strtoull to libiberty.
>
> 2014-10-20 Yury Gribov
>
> inclu
2014-10-24 14:37 GMT+04:00 Georg-Johann Lay :
> Am 10/23/2014 08:16 PM schrieb Denis Chertykov:
>>>
>>> This optimization makes most sign-extensions one instruction shorter in
>>> the
>>> case when the source register may be clobbered and the register numbers
>>> are
>>> different. Source and dest
Hi all,
On 10/17/2014 11:53 AM, Yury Gribov wrote:
On 09/29/2014 09:21 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.
New patch which checks that -
On Fri, 24 Oct 2014, Jakub Jelinek wrote:
> On Fri, Oct 24, 2014 at 03:27:19PM +0200, Richard Biener wrote:
> > As noted by Marc I forgot to actually utilize the iterator variable.
> >
> > Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
> >
> > Richard.
> >
> > PS: How do we want
On Fri, Oct 24, 2014 at 03:27:19PM +0200, Richard Biener wrote:
> As noted by Marc I forgot to actually utilize the iterator variable.
>
> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
>
> Richard.
>
> PS: How do we want to refer to patterns in ChangeLogs?
Perhaps the syntax sh
As noted by Marc I forgot to actually utilize the iterator variable.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
PS: How do we want to refer to patterns in ChangeLogs?
2014-10-24 Richard Biener
* match.pd (0 % X): Properly use the iterator iterating over
Ian Taylor writes:
> 2014-10-23 Ian Lance Taylor
>
> * config/mep/mep.h (TARGET_HAS_F_SETLKW): Don't define.
s/define/undefine/
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely diffe
This patch makes GIMPLE forwprop fold all statements, following
single-use SSA edges only (as suggested by Jeff and certainly
how this will regress the least until we replace manual
simplification code that does not restrict itself this way).
forwprop is run up to 4 times at the moment (once only
Alan Lawrence writes:
> Rainer Orth wrote:
>>> However, as a quick first step, does adding the ilp32 / lp64 (and keeping
>>> the architectures list for now) solve the immediate problem? Patch
>>> attached, OK for trunk?
>>
>> No, as I said this is wrong for biarch targets like sparc and i386.
>
>
Hi,
tested x86_64-linux.
Thanks,
Paolo.
///
2014-10-24 Paolo Carlini
* include/bits/atomic_base.h: Avoid including .
* include/std/atomic: When __cplusplus < 201103L skip the rest of
the header.
* testsuite/29_atomics/headers/atomic/std_c+
Ooops, attached.commit 56296417b9f6795e541b1101dce6e6ac1789de9a
Author: Alan Lawrence
Date: Wed Oct 8 15:58:27 2014 +0100
IA64 (?!)
diff --git a/gcc/config/ia64/vect.md b/gcc/config/ia64/vect.md
index e3ce292..45f4156 100644
--- a/gcc/config/ia64/vect.md
+++ b/gcc/config/ia64/vect.md
@@ -
Ooops, attached.commit e48d59399722ce8316d4b1b4f28b40d87b1193fa
Author: Alan Lawrence
Date: Tue Oct 7 15:28:47 2014 +0100
PowerPC v2 (but not paired.md)
diff --git a/gcc/config/rs6000/altivec.md b/gcc/config/rs6000/altivec.md
index 02ea142..92bb5d0 100644
--- a/gcc/config/rs6000/altivec.m
This migrates the reduction patterns in altivec.md and vector.md to the new
names. I've not touched paired.md as I wasn't really sure how to fix that (how
do I vec_extractv2sf ?), moreover the testing I did didn't seem to exercise any
of those patterns (iow: I'm not sure what would be an appropr
This is an attempt to migrate IA64 to the newer optabs, however, I found none of
the tests in gcc.dg/vect seemed to touch any of the affected patternsso this
is only really tested by building a stage-1 compiler.
gcc/ChangeLog:
* config/ia64/vect.md (reduc_splus_v2sf): Rename to...
Hi,
Commit 216437 missed a part of Adhemerval's original change that made
`long_double_add_overflow', `complex_long_double_add_overflow',
`long_double_sub_overflow' and `complex_long_double_sub_overflow' tests
consistently defined only if called. These tests are now only made under
the `LDBL
Bootstrapped and check-gcc on x86_64-none-linux-gnu.
gcc/ChangeLog:
* config/i386/i386.c (ix86_expand_reduc): Extract result into scalar.
* config/i386/sse.md (reduc_splus_v8df, reduc__ * 3,
reduc_umin_v8hi): Rename to...
(reduc_plus_scal_v8df, reduc__scal_ * 3,
On Fri, 24 Oct 2014, Alan Lawrence wrote:
> This is the first half of my previous patch series
> (https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01456.html), that is the part
> making the REDUC_..._EXPR tree codes endian-neutral, and adding a new
> reduce-to-scalar optab in place of the endianness-
Similarly to last patch.
Tested, in combination with previous patch:
bootstrap on arm-none-linux-gnueabihf
cross-tested check-gcc on arm-none-eabi.
gcc/ChangeLog:
config/arm/neon.md (reduc_smin_ *2): Rename to...
(reduc_smin_scal_ *2): ...this; extract scalar result.
(re
On Fri, Oct 24, 2014 at 12:47 PM, Jiong Wang wrote:
> we should not add explicit declaration there.
>
> arm_neon.h contains those prototype already. they will be available if the
> compiler configuration is with related builtin predefine, for example
> __ARM_FEATURE_CRYPTO.
>
> so, actually, if th
This migrates ARM from reduc_splus_optab and reduc_uplus optab to a single
reduc_plus_optab.
Tested, in combination with next patch:
bootstrap on arm-none-linux-gnueabihf
cross-tested check-gcc on arm-none-eabi.
gcc/ChangeLog:
config/arm/neon.md (reduc_plus_*): Rename to...
(re
This is the first half of my previous patch series
(https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01456.html), that is the part
making the REDUC_..._EXPR tree codes endian-neutral, and adding a new
reduce-to-scalar optab in place of the endianness-dependent
reduc_[us](plus|min|max)_optab.
I'm
Rainer Orth wrote:
However, as a quick first step, does adding the ilp32 / lp64 (and keeping
the architectures list for now) solve the immediate problem? Patch
attached, OK for trunk?
No, as I said this is wrong for biarch targets like sparc and i386.
When you say no this does not solve the
On Fri, Oct 24, 2014 at 12:48:24PM +0100, Jiong Wang wrote:
> a furhter cleanup under aapcs sub-directory.
>
> ok for trunk?
>
> gcc/testsuite/
> * gcc.target/arm/aapcs/abitest.h: Declare memcpy.
> diff --git a/gcc/testsuite/gcc.target/arm/aapcs/abitest.h
> b/gcc/testsuite/gcc.target/arm/aapc
a furhter cleanup under aapcs sub-directory.
ok for trunk?
gcc/testsuite/
* gcc.target/arm/aapcs/abitest.h: Declare memcpy.
diff --git a/gcc/testsuite/gcc.target/arm/aapcs/abitest.h b/gcc/testsuite/gcc.target/arm/aapcs/abitest.h
index 06a92c3..7bce58b 100644
--- a/gcc/testsuite/gcc.target/arm/
we should not add explicit declaration there.
arm_neon.h contains those prototype already. they will be available if the
compiler configuration is with related builtin predefine, for example
__ARM_FEATURE_CRYPTO.
so, actually, if there is any warning when compile these test programs, they
are
On Fri, 24 Oct 2014, Marc Glisse wrote:
>
> > + /* Same applies to modulo operations, but fold is inconsistent here
> > +and simplifies 0 % x to 0, only preserving literal 0 % 0. */
> > + (for op (ceil_mod floor_mod round_mod trunc_mod)
> > + /* 0 % X is always zero. */
> > + (simplify
>
+ /* Same applies to modulo operations, but fold is inconsistent here
+and simplifies 0 % x to 0, only preserving literal 0 % 0. */
+ (for op (ceil_mod floor_mod round_mod trunc_mod)
+ /* 0 % X is always zero. */
+ (simplify
+ (trunc_mod integer_zerop@0 @1)
+ /* But not for 0 % 0 so
On Fri, 24 Oct 2014, Rainer Orth wrote:
> Richard Biener writes:
>
> > Dominique reported that this fails for system libiconv but built libintl.
> >
> > Which might be fixed by the following. Does that still work for you?
>
> It does: an i386-pc-solaris2.10 bootstrap has finished by now and ma
On Fri, Oct 24, 2014 at 12:04:52PM +0100, Marcus Shawcroft wrote:
> On 22 October 2014 15:20, Kyrill Tkachov wrote:
> > Hi all,
> >
> > This patch contains the LINK_SPEC changes required to pass on the linker
> > option --fix-cortex-a53-835769 when compiling with -mfix-cortex-a53-835769
> > (or by
2014-10-24 Richard Biener
Merge from trunk r216543 through r216631.
Brings back second merge piece.
On 22 October 2014 15:20, Kyrill Tkachov wrote:
> Hi all,
>
> This patch contains the LINK_SPEC changes required to pass on the linker
> option --fix-cortex-a53-835769 when compiling with -mfix-cortex-a53-835769
> (or by default when configured with --enable-fix-cortex-a53-835769).
>
> This requir
Richard Biener writes:
> Dominique reported that this fails for system libiconv but built libintl.
>
> Which might be fixed by the following. Does that still work for you?
It does: an i386-pc-solaris2.10 bootstrap has finished by now and make
check is running.
Rainer
--
-
On 17 October 2014 16:55, Kyrill Tkachov wrote:
> Hi all,
>
> This is the 4.8 backport of the configure option
> --enable-fix-cortex-a53-835769 to enable the workaround
> for the Cortex-A53 erratum 835769 by default. The patch is very similar to
> the trunk version, just some
> differences in the
This combines the already posted 3/n (first simple patterns),
4/n (hook into fold-const.c) and not yet posted 5/n (hook into
fold_stmt). Over the first posting this also contains
recent improvements to the generator from the branch regarding
to TREE_SIDE_EFFECTS and NON_LVALUE_EXPR handling.
The
On 17 October 2014 16:55, Kyrill Tkachov wrote:
> Hi all,
>
> This is the 4.8 backport of the Cortex-A53 erratum 835769 workaround.
> 4.8 doesn't have rtx_insns and the type attributes are different.
> Other than that there's not much different from the trunk version.
>
> Bootstrapped and tested o
1 - 100 of 143 matches
Mail list logo
