> On Oct 22, 2015, at 12:44 AM, Steve Ellcey wrote:
>
>
> A bug was reported against the GCC MIPS64 compiler that involves a bad combine
> and this patch fixes the bug.
>
> When using '-fexpensive-optimizations -march=mips64r2 -mabi=64' GCC is
> combining these instructions:
>
> (insn 13 12
> On Oct 15, 2015, at 1:42 AM, Renato Golin wrote:
>
>> On 15 October 2015 at 08:29, Yury Gribov wrote:
>> Do you have any estimation for when full AArch64 support is ready in LLVM?
>> If it's still months away, I wonder if we may want to enable at least
>> current (partial) support for non-Th
> On Oct 7, 2015, at 9:28 AM, Maxim Ostapenko
> wrote:
>
>
>
>> On 07/10/15 19:18, Andrew Pinski wrote:
>> On Wed, Oct 7, 2015 at 9:11 AM, Maxim Ostapenko
>> wrote:
>>> Hi,
>>>
>>> when testing OpenSSL performance, I found out that sometimes PGO-built
>>> binaries can actually introduce pe
> On Oct 1, 2015, at 7:51 AM, James Greenhalgh wrote:
>
> On Thu, Oct 01, 2015 at 03:28:22PM +0100, pins...@gmail.com wrote:
>>>
>>> On Oct 1, 2015, at 6:57 AM, James Greenhalgh
>>> wrote:
>>>
>>>
>>> Hi,
>>>
>>> If it is cheap enough to treat a floating-point value as an integer and
>>> t
>
> On Oct 1, 2015, at 6:57 AM, James Greenhalgh wrote:
>
>
> Hi,
>
> If it is cheap enough to treat a floating-point value as an integer and
> to do bitwise arithmetic on it (as it is for AArch64) we can rewrite:
>
> x * copysign (1.0, y)
>
> as:
>
> x ^ (y & (1 << sign_bit_position))
W
> On Sep 24, 2015, at 10:16 AM, Teresa Johnson wrote:
>
> This patch unsets -freorder-blocks-and-partition when -fprofile-use
> is not specified. Function splitting was not actually being performed
> in that case, as probably_never_executed_bb_p does not distinguish
> any basic blocks as being
> On Sep 21, 2015, at 4:39 AM, Bernd Schmidt wrote:
>
>> On 09/18/2015 05:21 PM, Jiong Wang wrote:
>>
>> Current conditional compare (CCMP) support in GCC aim to optimize
>> short circuit for cascade comparision, given a simple conditional
>> compare candidate:
>>
>> if (a == 17 || a == 32)
> On Sep 10, 2015, at 7:57 PM, tbsaunde+...@tbsaunde.org wrote:
>
> From: Trevor Saunders
>
> Hi,
>
> I thought I'd see how hard it is to get tm.h out of libobjc/ so it wouldn't be
> necessary to check there for uses of target macros.
I once had a branch which did this and then I got busy
> On Sep 7, 2015, at 7:22 PM, Kugan wrote:
>
>
>
> On 07/09/15 20:46, Wilco Dijkstra wrote:
>>> Kugan wrote:
>>> 2. vector-compare-1.c from c-c++-common/torture fails to assemble with
>>> -O3 -g Error: unaligned opcodes detected in executable segment. It works
>>> fine if I remove the -g. I
> On Sep 3, 2015, at 11:58 PM, Sebastian Pop wrote:
>
> On Wed, Aug 26, 2015 at 11:58 AM, Benedikt Huber
> wrote:
>> ping
>>
>> [PATCH v4][aarch64] Implemented reciprocal square root (rsqrt) estimation in
>> -ffast-math
>>
>> https://gcc.gnu.org/ml/gcc-patches/2015-07/msg02698.html
>>
>>
> On Sep 1, 2015, at 11:04 PM, Kyrill Tkachov wrote:
>
> Hi all,
>
> This third patch implements the new optabs for arm.
> Conveniently, we can reuse the recently refactored *if_neg_move pattern
> and extend it to cover the conditional NOT case.
> Although arm has conditional execution capab
> On Aug 6, 2015, at 11:40 AM, Renlin Li wrote:
>
> Hi all,
>
> This is a simple patch to add a new cmovdi_insn_uxtw rtx pattern to aarch64
> backend.
>
> For the following simple test case:
>
> unsigned long
> foo (unsigned int a, unsigned int b, unsigned int c)
> {
> return a ? b : c;
> On Jul 28, 2015, at 3:25 AM, Kyrill Tkachov wrote:
>
> Hi all,
>
> Currently we assign the wrong rtx cost to instructions of the form
> add x0, x0, x1, sxtw
>
> that is, an arith operation plus a single extend (no shifting).
> We correctly catch the cases where the extend is inside a sh
> On Jul 27, 2015, at 2:26 AM, Jiong Wang wrote:
>
>
> Andrew Pinski writes:
>
>>> On Fri, Jul 24, 2015 at 2:07 AM, Jiong Wang wrote:
>>>
>>> James Greenhalgh writes:
>>>
> On Wed, May 20, 2015 at 01:35:41PM +0100, Jiong Wang wrote:
> Current IRA still use both target macros in a
> On Jul 26, 2015, at 11:50 AM, Andi Kleen wrote:
>
> Mikhail Maltsev writes:
>
>> Hi, all!
>> Recently I did some profiling of GCC to find hotspots and areas of possible
>> performance improvement among them. glibc malloc(3) is one of (perhaps
>> known)
>
> I've been compiling gcc with tc
> On Jul 24, 2015, at 7:36 PM, tbsaunde+...@tbsaunde.org wrote:
>
> From: Trevor Saunders
>
> gcc/ChangeLog:
>
> 2015-07-25 Trevor Saunders
>
>* defaults.h (ASM_OUTPUT_ASCII): Remove default definition.
>* doc/tm.texi: Regenerate.
>* doc/tm.texi.in (ASM_OUTPUT_AS
> On Jul 21, 2015, at 3:31 AM, Kyrill Tkachov wrote:
>
>
>> On 21/07/15 10:26, pins...@gmail.com wrote:
>>
>>
>>
>>> On Jul 21, 2015, at 2:15 AM, Hurugalawadi, Naveen
>>> wrote:
>>>
>>> Hi,
>>>
>>> Please find attached the patch which performs following patterns folding
>>> in match.p
> On Jul 21, 2015, at 2:15 AM, Hurugalawadi, Naveen
> wrote:
>
> Hi,
>
> Please find attached the patch which performs following patterns folding
> in match.pd:-
>
> a ==/!= a p+ b to b ==/!= 0.
> a << N ==/!= 0 to a&(-1>>N) ==/!= 0.
> a * N ==/!= 0 where N is a power of 2 to a & (-1< log2
> On Jul 17, 2015, at 9:58 PM, Kyrill Tkachov wrote:
>
>
>> On 10/07/15 14:45, Kyrill Tkachov wrote:
>>> On 10/07/15 10:00, pins...@gmail.com wrote:
>>>
>>>
On Jul 10, 2015, at 1:47 AM, Kyrill Tkachov wrote:
Hi Andrew,
> On 10/07/15 09:40, pins...@gmail.com wrote
> On Jul 13, 2015, at 5:48 PM, Kyrill Tkachov wrote:
>
> Hi all,
>
> For the testcase in the patch we were generating an extra neg instruction:
>cmp w0, wzr
>csneg w0, w0, w0, ge
>neg w0, w0
>ret
>
> instead of the optimal:
>cmp w0, wzr
> On Jul 10, 2015, at 1:47 AM, Kyrill Tkachov wrote:
>
> Hi Andrew,
>
>> On 10/07/15 09:40, pins...@gmail.com wrote:
>>
>>
>>
>>> On Jul 10, 2015, at 1:34 AM, Kyrill Tkachov wrote:
>>>
>>> Hi all,
>>>
>>> Currently when evaluating expressions like (a ? 24 : 25) we will move 24
>>> and
> On Jul 10, 2015, at 1:34 AM, Kyrill Tkachov wrote:
>
> Hi all,
>
> Currently when evaluating expressions like (a ? 24 : 25) we will move 24 and
> 25 into
> registers and perform a csel on them. This misses the opportunity to instead
> move just 24
> into a register and then perform a cs
> On Jun 29, 2015, at 4:44 AM, Dr. Philipp Tomsich
> wrote:
>
> James,
>
>> On 29 Jun 2015, at 13:36, James Greenhalgh wrote:
>>
>>> On Mon, Jun 29, 2015 at 10:18:23AM +0100, Kumar, Venkataramanan wrote:
>>>
-Original Message-
From: Dr. Philipp Tomsich [mailto:philipp.t
> On Jun 25, 2015, at 9:44 AM, Kumar, Venkataramanan
> wrote:
>
> I got around ~12% gain with -Ofast -mcpu=cortex-a57.
I get around 11/12% on thunderX with the patch and the decreasing the
iterations change (1/2) compared to without the patch.
Thanks,
Andrew
>
> Regards,
> Venkat.
>
> On Jun 18, 2015, at 5:04 AM, Benedikt Huber
> wrote:
>
> arch64 offers the instructions frsqrte and frsqrts, for rsqrt estimation and
> a Newton-Raphson step, respectively.
> There are ARMv8 implementations where this is faster than using fdiv and
> rsqrt.
> It runs three steps for double
> On Jun 12, 2015, at 12:51 AM, Ulrich Weigand wrote:
>
> Hello,
>
> since the new type-based pool allocator was merged, the SPU toolchain
> automated build / regression test has been failing due to crashes of
> the compiled GCC due to random memory corruption.
>
> Debugging this, it seems
> On May 19, 2015, at 5:54 AM, Ramana Radhakrishnan
> wrote:
>
> Hi,
>
> Like the ARM port, the AArch64 ports needs to set glibc_integral_traps to
> false as integer divide instructions do not trap.
>
> Bootstrapped and regression tested on aarch64-none-linux-gnu
>
> Ok to apply ?
Not r
> On May 1, 2015, at 8:30 PM, tbsaunde+...@tbsaunde.org wrote:
>
> From: Trevor Saunders
>
> Hi,
>
> This adds a configure check to libobjc to find out if types of bitfields
> effect
> their layout, and uses it to replace the rather broken usage of
> PCC_BITFIELD_TYPE_MATTERS.
>
> bootstr
> On Apr 29, 2015, at 3:22 AM, Eric Botcazou wrote:
>
> You can easily get -fcompare-debug failures on AIX with small functions, in
> fact you get the failure for the empty function:
>
> void foo (void) {}
>
> eric@polaris:~/build/gcc/powerpc-ibm-aix7.1> gcc/xgcc -Bgcc -S t.c -O -
> fcompa
> On Apr 20, 2015, at 11:52 AM, Szabolcs Nagy wrote:
>
> Set up dynamic linker name for aarch64.
>
> gcc/Changelog:
>
> 2015-04-16 Gregor Richards
>Szabolcs Nagy
>
>* config/aarch64/aarch64-linux.h (MUSL_DYNAMIC_LINKER): Define.
I don't think you need to check if default
> On Mar 16, 2015, at 2:28 AM, Yangfei (Felix) wrote:
>
> Hi,
>
> For this trivial testcase:
>
> extern int bar (int , int);
>
> int foo (int *a, int *b)
> {
>return bar (*a, *b);
> }
>
> I noticed that GCC generate redundant zero-extension instructions under ILP32
> (aarch64-linux
> On Mar 6, 2015, at 1:45 AM, James Greenhalgh wrote:
>
>> On Thu, Feb 12, 2015 at 03:37:33PM +, Christophe Lyon wrote:
>>> On 8 February 2015 at 03:24, Andrew Pinski wrote:
>>> On Fri, Feb 6, 2015 at 5:02 PM, Andrew Pinski wrote:
>>>PR target/64893
>>>* config/aarch
> On Feb 13, 2015, at 1:48 AM, Kyrill Tkachov wrote:
>
> Hi all,
>
> In my tree added a pattern to the arm backend that's supposed to match:
> (set (reg:SI r0)
> (subreg:SI
> (plus:DI
> (mult:DI (sign_extend:DI (reg:SI r1))
> (sign_extend:DI (reg:SI r2)))
>
> On Feb 3, 2015, at 3:57 AM, Alan Lawrence wrote:
>
>
> Andrew Pinski wrote:
>> While trying to build the GCC 5 with GCC 5, I ran into an ICE when
>> building libcpp at -O0. The problem is the C++ front-end was not
>> folding sizeof(a)/sizeof(a[0]) when passed to a function at -O0. The
>>
On Jan 28, 2015, at 2:01 AM, Thomas Preud'homme
wrote:
>> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
>> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
>>
>> Hi Andrew,
>>
>> cortex-a57-fma-steering.c is really meant to be autosufficient with
>> aarch64_register_fma_steeri
> On Jan 21, 2015, at 1:02 AM, Matthias Klose wrote:
>
> __objc_get_forward_imp and get_imp were exported in libobjc since GCC 4.1, for
> some reason these are not exported anymore in GCC 5 (both declared inline).
> So
> either export these as before, or don't export them and bump the sonam
> On Jan 16, 2015, at 9:57 PM, David Edelsohn wrote:
>
> This patch has broken bootstrap on AIX
>
> May I mention that this really should have been tested on systems
> other than x86 Linux.
It also broke all newlib targets too. So you could have tested one listed in
the sim-test web page.
> On Jan 9, 2015, at 4:20 AM, Matthew Fortune
> wrote:
>
> Robert Suchanek writes:
>
>> gcc/
>>* simplify-rtx.c (simplify_replace_fn_rtx): Simplify (lo_sum (high x)
>>(const (plus x offset))) to (const (plus x offset)).
>
> The fix appears valid to me. Just some comments on the te
> On Jan 8, 2015, at 1:35 PM, Ian Lance Taylor wrote:
>
> This patch adds support to the GCC tree for building tools that are
> used with Go. There are two external used tools (go, gofmt) and one
> tool used internally by go (cgo). This patch is pure machinery, with
> no source code. The t
> On Jan 4, 2015, at 1:35 AM, Bin.Cheng wrote:
>
>> On Sun, Jan 4, 2015 at 6:55 AM, Andrew Pinski wrote:
>>> On Mon, Nov 24, 2014 at 1:32 PM, Jeff Law wrote:
On 11/22/14 21:20, Andrew Pinski wrote:
Hi,
The problem here is here is that OBJCOPY is not being set to the
>
> On Dec 11, 2014, at 10:06 AM, Tejas Belagod wrote:
>
>> On 22/11/14 23:41, Andrew Pinski wrote:
>> Hi,
>> After the conditional compare patches, the some of the
>> gcc.target/aarch64/test_frame_*.c testcases start to fail. This was
>> due to no longer duplicating simple_return and causin
> On Nov 17, 2014, at 8:59 AM, Ramana Radhakrishnan
> wrote:
>
>> On Mon, Nov 17, 2014 at 2:48 PM, Kyrill Tkachov
>> wrote:
>> Hi all,
>>
>> Some configurations of Cortex-A53 and Cortex-A57 don't ship with crypto,
>> so enabling it by default for -mcpu=cortex-a53 and cortex-a57 is
>> inap
> On Nov 14, 2014, at 12:54 AM, Marcus Shawcroft
> wrote:
>
>> On 14 November 2014 08:19, Andrew Pinski wrote:
>>> On Fri, Nov 14, 2014 at 12:12 AM, Tejas Belagod
>>> wrote:
>>>
>>> Hi,
>>>
>>> Following the discussion here
>>> https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02237.html, t
> On Nov 6, 2014, at 12:55 AM, Richard Biener wrote:
>
>
> This merges patterns implementing the bitwise patterns from
> tree-ssa-forwprop.c. I've removed duplicate functionality from
> fold-const.c as I found them, some may be still lurking in the
> depths.
>
> This also fixes a bug in g
> On Oct 31, 2014, at 4:07 AM, Matthew Fortune
> wrote:
>
> Andrew Pinski writes:
>> On Thu, Oct 30, 2014 at 11:30 PM, Zhenqiang Chen
>> wrote:
>>> Thank you all for the comments. Patch is updated.
>>>
>>> Bootstrap and no make check regression on X86-64.
>>> No make check regression with
> On Oct 12, 2014, at 12:37 PM, Anthony Brandon
> wrote:
>
> Hi,
>
> I'm a new contributor and I don't yet have a copyright assignment or
> commit access.
Thanks for you contribution. Your new function is missing a comment before it
saying what it does. Yes it might be obvious what the
> On Sep 22, 2014, at 11:43 PM, Zhenqiang Chen wrote:
>
> Ping?
>
> Patch is attached for easy to apply.
Note I have been using an earlier version of this patch set in house and not
have found any issues with it.
Thanks,
Andrew
>
> Thanks!
> -Zhenqiang
>
>> -Original Message-
> 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 case...
>
> How is the attached patch for trunk? I've bootstrapped it on AArch64
> with
> On Sep 10, 2014, at 9:47 PM, Yury Gribov wrote:
>
> Segher Boessenkool kernel.crashing.org> writes:
>> I am saying it is very anti-social to make
>> people's editor behave differently from what they are used to.
>> ...
>> The Emacs dir-locals file simply
>> configures some settings for files
> On Sep 10, 2014, at 9:24 AM, "Steve Ellcey " wrote:
>
> Someone noticed that the MIPS GCC compiler was not putting out the
> .note.GNU-stack section. This simple patch fixes that problem by
> calling the standard file_end_indicate_exec_stack function.
>
> Tested on mips-mti-linux-gnu, OK to
> On Sep 9, 2014, at 2:50 AM, Marcus Shawcroft
> wrote:
>
> +static unsigned HOST_WIDE_INT
> +aarch64_asan_shadow_offset (void)
> +{
> + return (HOST_WIDE_INT_1 << 36);
> +}
> +
>
> Looking around various other ports I see magic numbers including 29,
> 41, 44 Help me understand why 36 is
> On Sep 2, 2014, at 1:36 AM, Steven Bosscher wrote:
>
>> On Tue, Sep 2, 2014 at 9:22 AM, Andrew Pinski wrote:
>>> On Tue, Sep 2, 2014 at 12:20 AM, Andi Kleen wrote:
>>>
there have been bugs in the past in the area of always_inline too.
>>>
>>> You're arguing for my patch. It would find
> On Aug 18, 2014, at 1:33 AM, Tom de Vries wrote:
>
>> On 14-08-14 16:34, Richard Biener wrote:
>>> On Sat, Aug 9, 2014 at 7:14 AM, Tom de Vries wrote:
>>> On 08-08-14 17:17, Tom de Vries wrote:
>
> Maybe instead of a new mem_alias_equal_p simply compare MEM_ATTRs
> with mem_attr
> On Aug 12, 2014, at 7:40 AM, Alan Lawrence wrote:
>
> (It is no more expensive.)
Yes on some processors it could be.
Thanks,
Andrew
>
> gcc/ChangeLog:
>
>* config/aarch64/aarch64.md (subdi3, adddi3_aarch64): Don't penalize
>SIMD reg variant.
> diff --git a/gcc/config/aarch64/aa
> On Jun 6, 2014, at 1:50 AM, James Greenhalgh wrote:
>
>
> Hi,
>
> The move_by_pieces infrastructure performs a copy by repeatedly trying
> the largest safe copy it can make. So for a 15-byte copy we might see:
>
> offset amount bytes copied
> 08 0-7
> 84 8-11
> On Jul 27, 2014, at 4:53 AM, Alan Modra wrote:
>
>> On Sun, Jul 27, 2014 at 07:16:07PM +0930, Alan Modra wrote:
>>> On Sat, Jul 26, 2014 at 01:45:12PM +0200, Matthias Klose wrote:
>>> Am 17.07.2014 02:41, schrieb Ulrich Weigand:
Hello,
this is the variant intended for the 4.8/
> On Jul 6, 2014, at 7:23 AM, Marc Glisse wrote:
>
>> On Mon, 30 Jun 2014, Jeff Law wrote:
>>
>>> On 06/28/14 16:33, Marc Glisse wrote:
>>> In an earlier version of the patch, I was using
>>> get_or_create_ssa_default_def (cfun, sym);
>>> (I was reusing the same variable). This passed bootstra
> On Jul 5, 2014, at 11:42 AM, Gerald Pfeifer wrote:
>
> Farther below in wide-int.h, we define wide_int_storage as a class:
>
> class GTY(()) wide_int_storage
> {
> private:
>HOST_WIDE_INT val[WIDE_INT_MAX_ELTS];
>unsigned int len;
>unsigned int precision;
> :
>
> The patch b
> On Jun 24, 2014, at 2:08 AM, Kyrill Tkachov wrote:
>
>
>> On 23/06/14 22:12, Andrew Pinski wrote:
>> Hi,
>> When looking at the current conditional compare patch, I find that
>> we don't have a testcase to test that we don't ICE for the case where
>> we have conditional compares and condit
> On Jun 23, 2014, at 12:37 AM, Zhenqiang Chen
> wrote:
>
>> On 23 June 2014 15:09, Andrew Pinski wrote:
>> On Mon, Jun 23, 2014 at 12:01 AM, Zhenqiang Chen
>> wrote:
>>> Hi,
>>>
>>> The patch enhances ifcvt to handle conditional compare instruction
>>> (ccmp) to make it work with cmov. For
> On Jun 17, 2014, at 6:07 AM, Richard Biener wrote:
>
>
> First this adds a controlling option to the phiopt pass (-fssa-phiopt).
> Second, this moves the first phiopt pass from the main optimization
> pipeline into early opts (before merge-phi which confuses phiopt
> but after dce which will
> On May 29, 2014, at 10:09 AM, "H.J. Lu" wrote:
>
>> On Thu, May 29, 2014 at 9:23 AM, wrote:
>>
>>
On May 29, 2014, at 9:13 AM, "H.J. Lu" wrote:
> On Wed, May 28, 2014 at 9:52 PM, Andrew Pinski wrote:
>> On Wed, Jul 13, 2011 at 9:39 AM, H.J. Lu wrote:
>>> On Wed,
> On May 29, 2014, at 9:13 AM, "H.J. Lu" wrote:
>
>> On Wed, May 28, 2014 at 9:52 PM, Andrew Pinski wrote:
>>> On Wed, Jul 13, 2011 at 9:39 AM, H.J. Lu wrote:
On Wed, Jul 13, 2011 at 9:13 AM, Paolo Bonzini wrote:
> On 07/11/2011 05:54 PM, H.J. Lu wrote:
>
> The key is the
>
On May 28, 2014, at 1:03 AM, Matthew Fortune wrote:
>> You shouldn't need to declare __builtin_* functions anyway. And if a
>> function can be represented directly with GNU C vector extensions, it's
>> preferred to implement it that way inline in the header rather than having
>> built-in funct
> On May 19, 2014, at 2:39 AM, Richard Biener
> wrote:
>
>> On Mon, May 19, 2014 at 10:58 AM, Eric Botcazou
>> wrote:
>> Hi,
>>
>> this fixes an over-optimization of the GIMPLE optimizer, whereby two
>> otherwise
>> identical calls to a pure function present in different EH regions are CSE
> On May 16, 2014, at 4:13 AM, Richard Biener
> wrote:
>
> On Fri, May 16, 2014 at 1:03 PM, Richard Biener
> wrote:
>> On Fri, May 16, 2014 at 12:56 PM, wrote:
>>>
>>>
On May 16, 2014, at 3:48 AM, Richard Biener
wrote:
On Fri, May 16, 2014 at 12:07 PM, Thomas Preud'
> On May 16, 2014, at 3:48 AM, Richard Biener
> wrote:
>
> On Fri, May 16, 2014 at 12:07 PM, Thomas Preud'homme
> wrote:
>> Ping?
>
> Sorry ...
>
>> Best regards,
>>
>> Thomas Preud'homme
>>
>>> -Original Message-
>>> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
>>> ow
> On May 13, 2014, at 12:59 AM, Konstantin Serebryany
> wrote:
>
> I've committed this upstream and will include it into my next updated patch:
>
> +#if defined(__x86_64__) && !defined(_LP64)
> + typedef long long __sanitizer_time_t;
> +#else
> + typedef long __sanitizer_time_t;
> +#endif
>
> On May 7, 2014, at 2:32 AM, "Herman, Andrei"
> wrote:
>
>
> Hi,
>
> Currently GCC only emits DWARF debug information (DW_TAG_lexical_block DIEs)
> for compound statements containing significant local declarations.
> However, code coverage tools that process the DWARF debug information to
>
> On May 2, 2014, at 2:21 AM, James Greenhalgh wrote:
>
>> On Fri, May 02, 2014 at 10:00:15AM +0100, Andrew Pinski wrote:
>> On Fri, May 2, 2014 at 1:48 AM, James Greenhalgh
>> wrote:
>>>
>>> Hi,
>>>
>>> Unlike the mid-end's concept of an ABS_EXPR, which treats overflow as
>>> undefined/impo
> On Apr 27, 2014, at 10:09 AM, Prathamesh Kulkarni
> wrote:
>
>> On Sun, Apr 27, 2014 at 8:48 PM, Trevor Saunders
>> wrote:
>>> On Sun, Apr 27, 2014 at 06:21:20PM +0530, Prathamesh Kulkarni wrote:
On Sun, Apr 27, 2014 at 5:31 PM, Trevor Saunders
wrote:
> On Sun, Apr 27, 2014
> On Apr 22, 2014, at 2:36 AM, Zhenqiang Chen wrote:
>
> Ping?
>
> Rebase and test. Bootstrap and no make check regression with qemu.
>
> OK for trunk?
This is the exact same patch we (Cavium) came up with for this missed
optimization.
Thanks,
Andrew
>
> Thanks!
> -Zhenqiang
>
>> On 18
> On Apr 2, 2014, at 7:37 AM, Richard Henderson wrote:
>
>> On 04/01/2014 03:41 PM, Andrew Pinski wrote:
>>> On Tue, Apr 1, 2014 at 3:24 PM, Richard Henderson wrote:
>>> Comments? If approved, should this go in for 4.9, or wait for stage1?
>>> Certainly it's self-contained...
>>
>> On Cavium
> On Mar 28, 2014, at 7:48 AM, James Greenhalgh
> wrote:
>
> On Fri, Mar 28, 2014 at 11:11:58AM +, pins...@gmail.com wrote:
>>> On Mar 28, 2014, at 2:12 AM, James Greenhalgh
>>> wrote:
>>> Hi,
>>>
>>> There is no way to perform scalar addition in the vector register file,
>>> but with t
> On Mar 28, 2014, at 2:12 AM, James Greenhalgh
> wrote:
>
>
> Hi,
>
> There is no way to perform scalar addition in the vector register file,
> but with the RTX costs in place we start rewriting (x << 1) to (x + x)
> on almost all cores. The code which makes this decision has no idea that w
The original patch http://gcc.gnu.org/ml/gcc-patches/2007-04/msg01862.htm
Thanks,
Andrew Pinski
> On Feb 25, 2014, at 12:00 AM, Uros Bizjak wrote:
>
> On Tue, Feb 25, 2014 at 7:10 AM, Gopalasubramanian, Ganesh
> wrote:
>> I could see "storent" pattern in x86 machine descriptions (in sse.md).,
> On Jan 14, 2014, at 7:19 AM, Alex Velenko wrote:
>
> Hi,
>
> This patch turns off the vec_perm patterns for aarch64_be, this should resolve
> the issue highlighted here
> http://gcc.gnu.org/ml/gcc-patches/2014-01/msg00321.html
> With this patch applied, the test case provided in that link
> On Dec 5, 2013, at 1:33 AM, Oleg Endo wrote:
>
>> On Thu, 2013-12-05 at 01:11 -0800, pins...@gmail.com wrote:
>>
>>> On Dec 5, 2013, at 1:00 AM, Oleg Endo wrote:
>>>
>>> Hi,
>>>
>>> When building GCC on OSX with its native XCode/Clang tools, it outputs
>>> quite some "struct X was previou
> On Dec 5, 2013, at 1:00 AM, Oleg Endo wrote:
>
> Hi,
>
> When building GCC on OSX with its native XCode/Clang tools, it outputs
> quite some "struct X was previously declared as a class" or similar
> warnings (-Wmismatched-tags is enabled by default).
>
> The attached patch fixes a mismatch
> On Dec 5, 2013, at 12:48 AM, Oleg Endo wrote:
>
> Hi,
>
> When building GCC on OSX with its native XCode/Clang tools, it outputs
> quite some "struct X was previously declared as a class" or similar
> warnings (-Wmismatched-tags is enabled by default).
>
> The attached patch fixes this for
> On Nov 26, 2013, at 6:00 AM, "H.J. Lu" wrote:
>
> On Tue, Nov 26, 2013 at 5:55 AM, Richard Biener
> wrote:
>> On Tue, Nov 26, 2013 at 2:44 PM, Richard Earnshaw wrote:
>>> On 26/11/13 09:18, Eric Botcazou wrote:
> you are correct - this was an incorrect change. I believe that the
>
> On Nov 8, 2013, at 9:20 AM, Steven Bosscher wrote:
>
>> On Wed, Oct 30, 2013 at 5:03 AM, Andrew Pinski wrote:
>> Here is what I applied in the end; Jeff told me just to remove the
>> testcase. I added the comment trying to explain why it was the
>> opposite order of PHI-opt.
>>
>> Thanks,
>
> On Oct 28, 2013, at 11:24 AM, Jeff Law wrote:
>
>> On 10/26/13 15:08, Joseph S. Myers wrote:
>> As far as I can see, the commit left empty libmudflap directories around
>> rather than removing them (SVN, unlike git, allows empty directories to be
>> represented in the repository).
> I'll chec
Sent from my iPad
> On Oct 22, 2013, at 7:23 PM, Cong Hou wrote:
>
> This patch aims at PR58762.
>
> Currently GCC could not vectorize abs() operation for integers on x86
> with only SSE2 support. For int type, the reason is that the expand on
> abs() is not defined for vector type. This patc
> On Oct 15, 2013, at 5:32 AM, Jakub Jelinek wrote:
>
> Hi!
>
> Especially on i?86/x86_64 if-conversion pass seems to be often
> a pessimization, but the vectorization relies on it and without it we can't
> vectorize a lot of the loops.
I think on many other targets it actually helps. I know
> On Oct 1, 2013, at 7:12 PM, Cong Hou wrote:
>
> When alias exists between data refs in a loop, to vectorize it GCC
> does loop versioning and adds runtime alias checks. Basically for each
> pair of data refs with possible data dependence, there will be two
> comparisons generated to make sure
On Sep 8, 2013, at 7:01 PM, "Bin.Cheng" wrote:
> On Wed, Sep 4, 2013 at 5:20 PM, Richard Biener wrote:
>>
>> The patch below moves IVOPTs out of the GIMPLE loop pipeline more
>> closer to RTL expansion. That's done for multiple reasons.
>>
>> First, the loop passes that at the moment preceede
87 matches
Mail list logo
