What is currently submitted for LLVM review was submitted before we determined
this naming scheme. I will mark the current submittal as abandoned, as the
scheduling model needs to be split out and revised.
Joel Jones
Sent from my AArch64 powered iPhone
> On Nov 2, 2016, at 3:55 AM, James
> I think you're right. I suppose the new condition should be:
>
> #ifdef LOAD_EXTEND_OP
> /* If this is a typical RISC machine, we only have to worry
>about the way loads are extended. */
> if (!WORD_REGISTER_OPERATIONS
>
> || ((LOAD_EXTEND_OP
On Wed, 2 Nov 2016, Richard Biener wrote:
>
> This fixes the alias check in terminate_all_aliasing_chains -- the
> base we use for the hash table indexing does not constitute an object
> that aliases all stores in the chain (consider for example the MEM_REF
> handling which strips the offset
On Tue, Nov 1, 2016 at 12:21 PM, Kyrill Tkachov
wrote:
> Hi Tamar,
>
>
> On 26/10/16 16:01, Tamar Christina wrote:
>>
>> Hi Christophe,
>>
>> Here's the updated patch.
>>
>> Cheers,
>> Tamar
>>
>> From: Christophe Lyon
On Wed, Nov 2, 2016 at 11:08 AM, Richard Biener
wrote:
> On Tue, Nov 1, 2016 at 4:24 PM, Bin.Cheng wrote:
>> On Thu, Aug 11, 2016 at 11:38 AM, Richard Biener
>> wrote:
>>> On Thu, Aug 11, 2016 at 11:56 AM, Bin.Cheng
Hi Eric,
On 02/11/16 10:47, Eric Botcazou wrote:
This converts the preprocessor check for WORD_REGISTER_OPERATIONS into a
runtime one in rtlanal.c.
Since this one was in combination with an "#if defined" and used to guard an
if-statement I'd appreciate it if someone gave it a double-check that
On Tue, Nov 1, 2016 at 4:24 PM, Bin.Cheng wrote:
> On Thu, Aug 11, 2016 at 11:38 AM, Richard Biener
> wrote:
>> On Thu, Aug 11, 2016 at 11:56 AM, Bin.Cheng wrote:
>>> On Thu, Aug 11, 2016 at 10:50 AM, Richard Biener
>>>
On Tue, Nov 01, 2016 at 11:08:53AM -0700, Andrew Pinski wrote:
> On Tue, Nov 17, 2015 at 2:10 PM, Andrew Pinski wrote:
> > Since ThunderX T88 pass 1 (variant 0) is a ARMv8 part while pass 2 (variant
> > 1)
> > is an ARMv8.1 part, I needed to add detecting of the variant also
This fixes the alias check in terminate_all_aliasing_chains -- the
base we use for the hash table indexing does not constitute an object
that aliases all stores in the chain (consider for example the MEM_REF
handling which strips the offset completely).
I've refactored data structures a bit in
> This converts the preprocessor check for WORD_REGISTER_OPERATIONS into a
> runtime one in rtlanal.c.
>
> Since this one was in combination with an "#if defined" and used to guard an
> if-statement I'd appreciate it if someone gave it a double-check that I
> dind't screw up the intended
On Wed, Nov 2, 2016 at 10:02 AM, Richard Biener
wrote:
> On Mon, Oct 31, 2016 at 4:35 PM, Segher Boessenkool wrote:
>> On Mon, Oct 31, 2016 at 04:09:48PM +0100, Steven Bosscher wrote:
>>> On Sun, Oct 30, 2016 at 8:10 PM, Segher Boessenkool wrote:
>>> > +
On 02/11/16 10:07, Thomas Preudhomme wrote:
Ping?
Best regards,
Thomas
On 26/10/16 17:42, Thomas Preudhomme wrote:
Hi,
This patch adds support for the Cortex-M33 processor launched by ARM [1]. The
patch adds support for the name and wires it up to the ARMv8-M Mainline with DSP
extensions
On 02/11/16 10:07, Thomas Preudhomme wrote:
Ping?
Best regards,
Thomas
On 26/10/16 17:42, Thomas Preudhomme wrote:
Hi,
This patch adds support for the Cortex-M23 processor launched by ARM [1]. The
patch adds support for the name and wires it up to the ARMv8-M Baseline
architecture and
On Wed, Nov 02, 2016 at 10:59:26AM +0100, Jakub Jelinek wrote:
> > Which is gimplified as:
> >
> > int * ptr;
> >
> > switch (argc) , case 1: >
> > {
> > int a;
> >
> > try
> > {
> > ASAN_MARK (2, , 4);
> > :
> > goto ;
> >
On 11/02/2016 10:59 AM, Jakub Jelinek wrote:
> On Wed, Nov 02, 2016 at 10:36:44AM +0100, Martin Liška wrote:
>> On 11/01/2016 03:53 PM, Jakub Jelinek wrote:
>>> What kind of false positives it is for each case? Is it with normal
>>> asan-bootstrap (without your -fsanitize-use-after-scope
Ping?
Best regards,
Thomas
On 26/10/16 17:42, Thomas Preudhomme wrote:
Hi,
This patch adds support for the Cortex-M23 processor launched by ARM [1]. The
patch adds support for the name and wires it up to the ARMv8-M Baseline
architecture and arm_v6m_tune tuning parameters for the time being.
Ping?
Best regards,
Thomas
On 26/10/16 17:42, Thomas Preudhomme wrote:
Hi,
This patch adds support for the Cortex-M33 processor launched by ARM [1]. The
patch adds support for the name and wires it up to the ARMv8-M Mainline with DSP
extensions architecture and arm_v7m_tune tuning parameters
Ping?
Best regards,
Thomas
On 24/10/16 09:07, Thomas Preudhomme wrote:
Ping?
Best regards,
Thomas
On 13/10/16 16:35, Thomas Preudhomme wrote:
Hi ARM maintainers,
This patchset aims at adding multilib support for R and M profile ARM
architectures and allowing it to be built alongside
Ping?
Best regards,
Thomas
On 27/10/16 15:26, Thomas Preudhomme wrote:
Hi Kyrill,
On 27/10/16 10:45, Kyrill Tkachov wrote:
Hi Thomas,
On 24/10/16 09:06, Thomas Preudhomme wrote:
Ping?
Best regards,
Thomas
On 13/10/16 16:35, Thomas Preudhomme wrote:
Hi ARM maintainers,
This patchset
Ping?
Best regards,
Thomas
On 28/10/16 10:49, Thomas Preudhomme wrote:
On 22/09/16 16:47, Richard Earnshaw (lists) wrote:
On 22/09/16 15:51, Thomas Preudhomme wrote:
Sorry, noticed an error in the patch. It was not caught during testing
because GCC was built with --with-mode=thumb. Correct
On Wed, Nov 02, 2016 at 10:36:44AM +0100, Martin Liška wrote:
> On 11/01/2016 03:53 PM, Jakub Jelinek wrote:
> > What kind of false positives it is for each case? Is it with normal
> > asan-bootstrap (without your -fsanitize-use-after-scope changes), or
> > only with those changes, or only with
On Wed, Nov 02, 2016 at 10:40:35AM +0100, Richard Biener wrote:
> > I wonder if the sanitize_asan_mark wouldn't better be some PROP_* property
> > set during the asan pass and kept on until end of compilation of that
> > function. That means even if a var only addressable because of ASAN_MARK is
On 11/01/2016 04:12 PM, Jakub Jelinek wrote:
> On Tue, Nov 01, 2016 at 03:53:46PM +0100, Martin Liška wrote:
>> @@ -1504,7 +1505,7 @@ non_rewritable_lvalue_p (tree lhs)
>>
>> static void
>> maybe_optimize_var (tree var, bitmap addresses_taken, bitmap not_reg_needs,
>> -bitmap
On Wed, 2 Nov 2016, Jakub Jelinek wrote:
> On Wed, Nov 02, 2016 at 10:34:15AM +0100, Richard Biener wrote:
> > Ok, just looking at regex.c (I happen to have regex.i around) shows
> > the first hit as
> >
> > #2 0x008d9914 in true_dependence_1 (mem=0x761ef360,
> >
On 11/02/2016 10:40 AM, Richard Biener wrote:
> On Tue, Nov 1, 2016 at 4:12 PM, Jakub Jelinek wrote:
>> On Tue, Nov 01, 2016 at 03:53:46PM +0100, Martin Liška wrote:
>>> @@ -1504,7 +1505,7 @@ non_rewritable_lvalue_p (tree lhs)
>>>
>>> static void
>>> maybe_optimize_var (tree
On Wed, Nov 02, 2016 at 10:34:15AM +0100, Richard Biener wrote:
> Ok, just looking at regex.c (I happen to have regex.i around) shows
> the first hit as
>
> #2 0x008d9914 in true_dependence_1 (mem=0x761ef360,
> mem_mode=DImode, mem_addr=0x76220cf0, x=0x76605060,
>
On Tue, Nov 1, 2016 at 4:12 PM, Jakub Jelinek wrote:
> On Tue, Nov 01, 2016 at 03:53:46PM +0100, Martin Liška wrote:
>> @@ -1504,7 +1505,7 @@ non_rewritable_lvalue_p (tree lhs)
>>
>> static void
>> maybe_optimize_var (tree var, bitmap addresses_taken, bitmap not_reg_needs,
>>
On 11/01/2016 03:53 PM, Jakub Jelinek wrote:
> What kind of false positives it is for each case? Is it with normal
> asan-bootstrap (without your -fsanitize-use-after-scope changes), or
> only with those changes, or only with those changes and
> -fsanitize-use-after-scope used during bootstrap?
On Wed, 2 Nov 2016, Jakub Jelinek wrote:
> On Wed, Nov 02, 2016 at 10:08:25AM +0100, Richard Biener wrote:
> > On Mon, 31 Oct 2016, Jakub Jelinek wrote:
> >
> > > Hi!
> > >
> > > Some automatic VAR_DECLs don't get DECL_RTL set - e.g. if its SSA_NAMEs
> > > expand to multiple rtls, then there is
On Wed, Nov 02, 2016 at 10:19:26AM +0100, Richard Biener wrote:
> On Tue, Nov 1, 2016 at 1:09 AM, Jakub Jelinek wrote:
> > On Mon, Oct 31, 2016 at 05:28:42PM -0500, Bill Schmidt wrote:
> >> The PowerPC back end loses performance on vector intrinsics, because
> >> currently
> >>
On Tue, Nov 1, 2016 at 12:54 PM, Kyrill Tkachov
wrote:
> Hi all,
>
> Store merging ICEs on this invalid testcase because it trips up on the
> negative bitposition to store to.
> It doesn't really expect to handle negative offsets and I believe they won't
> occur very
On Wed, Nov 02, 2016 at 10:08:25AM +0100, Richard Biener wrote:
> On Mon, 31 Oct 2016, Jakub Jelinek wrote:
>
> > Hi!
> >
> > Some automatic VAR_DECLs don't get DECL_RTL set - e.g. if its SSA_NAMEs
> > expand to multiple rtls, then there is not a single one that can be used.
> > Using DECL_RTL
On Tue, Nov 1, 2016 at 12:54 PM, Kyrill Tkachov
wrote:
> Hi all,
>
> In this PR the code writes a -1 to a bitfield of size 17 bits and ends up
> overwriting another bitfields.
> The problem is that the intermediate buffer in encode_tree_to_bitpos holding
> the value
On Tue, Nov 1, 2016 at 1:09 AM, Jakub Jelinek wrote:
> On Mon, Oct 31, 2016 at 05:28:42PM -0500, Bill Schmidt wrote:
>> The PowerPC back end loses performance on vector intrinsics, because
>> currently
>> all of them are treated as calls throughout the middle-end phases and
On 27 October 2016 at 15:34, Jonathan Wakely wrote:
> On 26/10/16 09:24 +0200, Christophe Lyon wrote:
>>
>> Hi Jonathan,
>>
>> On 25 October 2016 at 17:32, Jonathan Wakely wrote:
>>>
>>> Two more fixes for the filesystem TS, and improved tests.
>>>
>>>
On Mon, 31 Oct 2016, Jakub Jelinek wrote:
> Hi!
>
> Some automatic VAR_DECLs don't get DECL_RTL set - e.g. if its SSA_NAMEs
> expand to multiple rtls, then there is not a single one that can be used.
> Using DECL_RTL on such VAR_DECLs ICEs.
>
> I've tried to just return 0 in
On Mon, Oct 31, 2016 at 4:35 PM, Segher Boessenkool
wrote:
> On Mon, Oct 31, 2016 at 04:09:48PM +0100, Steven Bosscher wrote:
>> On Sun, Oct 30, 2016 at 8:10 PM, Segher Boessenkool wrote:
>> > This patch solves this problem by simply running the
>> >
On Mon, Oct 31, 2016 at 3:56 PM, Martin Liška wrote:
> On 10/31/2016 12:11 PM, Richard Biener wrote:
>> On Mon, Oct 31, 2016 at 11:18 AM, Richard Sandiford
>> wrote:
>>> Richard Biener writes:
On Mon, Oct 31, 2016 at
On Wed, Nov 02, 2016 at 12:39:08PM +0530, Prathamesh Kulkarni wrote:
> On 1 November 2016 at 23:41, Uros Bizjak wrote:
> > On Tue, Nov 1, 2016 at 5:05 PM, Jakub Jelinek wrote:
> >> On Tue, Nov 01, 2016 at 10:05:22AM +0100, Uros Bizjak wrote:
> >>> ...
The following makes EVRP use infer_value_range. It also adds a bit of
dump verbosity to make EVRP traceable with -details.
Bootstrapped and tested on x86_64-unkown-linux-gnu, applied to trunk.
Richard.
2016-11-02 Richard Biener
* tree-vrp.c
On Tue, 1 Nov 2016, Marc Glisse wrote:
> On Mon, 31 Oct 2016, Richard Biener wrote:
>
> > On Fri, 28 Oct 2016, Marc Glisse wrote:
> >
> > > On Wed, 28 Sep 2016, Richard Biener wrote:
> > >
> > > > The following patch implements patterns to catch x / abs (x)
> > > > and x / -x, taking advantage
On Tue, Nov 01, 2016 at 08:55:03PM -0600, Martin Sebor wrote:
> struct S {
> int a, b, c, d;
> };
>
> #define bos(p, t) __builtin_object_size (p, t)
> #define memset0(p, i, n) __builtin___memset_chk (p, i, n, bos (p, 0))
> #define memset1(p, i, n) __builtin___memset_chk (p, i, n, bos (p, 1))
>
Pinging patch: https://gcc.gnu.org/ml/gcc-patches/2016-10/msg01545.html
Thanks,
Prathamesh
On 1 November 2016 at 23:41, Uros Bizjak wrote:
> On Tue, Nov 1, 2016 at 5:05 PM, Jakub Jelinek wrote:
>> On Tue, Nov 01, 2016 at 10:05:22AM +0100, Uros Bizjak wrote:
>>> ... simplify some conditions and add i?86-*-* target where missing.
>>>
>>> 2016-11-01
On 11/01/16 22:31, Jason Merrill wrote:
> On Tue, Nov 1, 2016 at 4:00 PM, Bernd Edlinger
> wrote:
>> On 11/01/16 20:48, Jason Merrill wrote:
else if ((DECL_EXTERN_C_P (newdecl)
&& DECL_EXTERN_C_P (olddecl))
On 11/02/16 07:11, Bernd Edlinger wrote:
> On 11/01/16 19:15, Bernd Edlinger wrote:
>> On 11/01/16 18:11, Jason Merrill wrote:
>>> On Tue, Nov 1, 2016 at 11:45 AM, Bernd Edlinger
>>> wrote:
On 11/01/16 16:20, Jason Merrill wrote:
> On 10/17/2016 03:18 PM, Bernd
On 11/01/16 19:15, Bernd Edlinger wrote:
> On 11/01/16 18:11, Jason Merrill wrote:
>> On Tue, Nov 1, 2016 at 11:45 AM, Bernd Edlinger
>> wrote:
>>> On 11/01/16 16:20, Jason Merrill wrote:
On 10/17/2016 03:18 PM, Bernd Edlinger wrote:
I'm not even sure we need
101 - 147 of 147 matches
Mail list logo