To implement OpenACC vector-single mode, we need to ensure that only one
thread out of the group representing a worker executes. The others skip
computations but follow along the CFG, so the results of conditional
branch decisions must be broadcast to them.
The patch below adds a new builtin a
Hi all,
This patch replaces 15, 16, 7 and 8 in aarch64_class_max_nregs with the macro
that they represent.
This should make the logic of that function easier to understand.
Bootstrapped and tested on aarch64.
Applying as obvious.
2015-05-20 Kyrylo Tkachov
* config/aarch64/aarch64.c (aa
Add new unspec name UNSPEC_TLSLE, use it for all tlsle pattern.
ok for trunk?
2015-05-19 Jiong Wang
gcc/
* config/aarch64/aarch64.md (UNSPEC_TLSLE): New enumeration.
(tlsle): Use new unspec name.
(tlsle_): Ditto.
--
Regards,
Jiong
diff --git a/gcc/config/aarch64/aarch64.md b/gcc/c
On Wed, 20 May 2015, Prathamesh Kulkarni wrote:
> On 20 May 2015 at 16:17, Prathamesh Kulkarni
> wrote:
> > Hi,
> > This patch rejects expanding operator-list to implicit 'for'.
> On second thoughts, should we reject expansion of operator-list _only_
> if it's mixed with 'for' ?
At least that, y
On Wed, 20 May 2015, Prathamesh Kulkarni wrote:
> Hi,
> This patch rejects expanding operator-list to implicit 'for'.
> OK for trunk after bootstrap+testing ?
Ok.
Thanks,
Richard.
Similar to the rename from SYMBOL_SMALL_TPREL to SYMBOL_TLSLE, this
patch rename the rtl pattern name.
ok for trunk?
2015-05-19 Jiong Wang
gcc/
* config/aarch64/aarch64.md (tlsle_small): Rename to tlsle.
(tlsle_small_): Rename to tlsle_.
* config/aarc64/aarch64.c (aarch64_load_symref_ap
For AArch64, TLS local-exec mode for all memory model (tiny/small/large)
is actually the same.
TLS LE Instruction generation depends on how big tls section is instead
of the memory model used.
The four instruction sequences we can implement based on relocations
provided:
sequence 1
==
On 20 May 2015 at 16:17, Prathamesh Kulkarni
wrote:
> Hi,
> This patch rejects expanding operator-list to implicit 'for'.
On second thoughts, should we reject expansion of operator-list _only_
if it's mixed with 'for' ?
We could define multiple operator-lists in simplify to be the same as
enclosin
No functional changes.
Bootstrapped/regtested on x86_64-linux, applying to trunk.
2015-05-20 Marek Polacek
* cfgexpand.c (expand_debug_expr): Use UNARY_CLASS_P.
* c-omp.c (check_omp_for_incr_expr): Use BINARY_CLASS_P.
diff --git gcc/c-family/c-omp.c gcc/c-family/c-omp.c
inde
Use COMPARISON_CLASS_P where appropriate. No functional changes.
Bootstrapped/regtested on x86_64-linux, applying to trunk.
2015-05-20 Marek Polacek
* expr.c (expand_cond_expr_using_cmove): Use COMPARISON_CLASS_P.
* gimple-expr.c (gimple_cond_get_ops_from_tree): Likewise.
Use DECL_P where appropriate. No functional changes.
Bootstrapped/regtested on x86_64-linux, applying to trunk.
2015-05-20 Marek Polacek
* gimple-fold.c (fold_const_aggregate_ref_1): Use DECL_P.
* gimplify.c (gimplify_modify_expr_rhs): Likewise.
* c-ada-spec.c (dump_
Hi,
This patch rejects expanding operator-list to implicit 'for'.
OK for trunk after bootstrap+testing ?
Thanks,
Prathamesh
2015-05-20 Prathamesh Kulkarni
* genmatch.c (parser::record_operlist): Remove.
(parser::oper_lists_set): Likewise.
(parser::oper_lists): Likewise.
Currently, AArch64 don't differentiate -fpic and -fPIC.
For -mcmodel=small, both allow 4G GOT table size, then we always need
two instructions to address GOT entry.
This patch implements -fpic for -mcmodel=small which allow 32K GOT table
size, smaller than -fPIC, but then we can use one instruct
> > gcc/
> > * config/mips/mips.h (micromips_globals): Declare.
>
> OK, thanks.
>
> Matthew
Committed as r223438.
Robert
On 20/05/15 11:17 +0100, Jonathan Wakely wrote:
On 04/05/15 22:31 +0200, François Dumont wrote:
Hi
Here is the patch to demangle symbols in debug messages. I have
also simplify code in formatter.h.
Here is an example of assertion message:
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gn
On 04/05/15 22:31 +0200, François Dumont wrote:
Hi
Here is the patch to demangle symbols in debug messages. I have
also simplify code in formatter.h.
Here is an example of assertion message:
/home/fdt/dev/gcc/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/debug/functions.h:213:
> > We could add -mflip-micromips complementing -mflip-mips16 and use
> > that for testing too. Chances are it'd reveal further issues.
> > Looking at how
> > -mflip-mips16 has been implemented it does not appear to me adding
> > -mflip-micromips would be a lot of effort.
>
> I'm in favour of ad
On Wed, May 20, 2015 at 12:01:21PM +0200, Marek Polacek wrote:
> The following patch is an effort to use the macro where appropriate
> in c/ and c-family/ directories. No functional changes intended.
>
> Bootstrapped/regtested on x86_64-linux, ok for trunk?
>
> 2015-05-20 Marek Polacek
>
>
On 03/05/15 22:19 +0200, François Dumont wrote:
On 30/04/2015 13:18, Jonathan Wakely wrote:
On 30/04/15 10:40 +0200, François Dumont wrote:
On 27/04/2015 13:55, Jonathan Wakely wrote:
(Alternatively, could the same simplification be made for
__miter_base? Do we need _Miter_base<> or just two o
The following patch is an effort to use the macro where appropriate
in c/ and c-family/ directories. No functional changes intended.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2015-05-20 Marek Polacek
* c-pragma.c: Use VAR_OR_FUNCTION_DECL_P throughout.
* c-common.
On Wed, May 20, 2015 at 11:32:20AM +0200, Thomas Schwinge wrote:
> Hi!
>
> On Wed, 20 May 2015 10:43:27 +0200, Jakub Jelinek wrote:
> > On Wed, May 20, 2015 at 10:23:21AM +0200, Thomas Schwinge wrote:
> > > I see that some checking is also being done gcc/omp-low.c:scan_omp_for:
> > > »gang, worke
Hi,
As we know, GCC is too conservative when checking overflow behavior in SCEV
and loop related optimizers. Result is some variable can't be recognized as
scalar evolution and thus optimizations are missed. To be specific,
optimizers like ivopts and vectorizer are affected.
This issue is more se
Hi!
On Wed, 20 May 2015 10:43:27 +0200, Jakub Jelinek wrote:
> On Wed, May 20, 2015 at 10:23:21AM +0200, Thomas Schwinge wrote:
> > I see that some checking is also being done gcc/omp-low.c:scan_omp_for:
> > »gang, worker and vector may occur only once in a loop nest«, and »gang,
> > worker and v
> I bootstrapped/regtested on x86_64-linux the patch bellow. If it will work
> for Firefox and Chrome I will go ahead with it at least temporarily.
Really? This introduced a LTO failure in the gnat.dg testsuite:
FAIL: gnat.dg/lto8.adb (internal compiler error)
FAIL: gnat.dg/lto8.adb (test for ex
> From: Steven Bosscher [mailto:stevenb@gmail.com]
> Sent: Tuesday, May 19, 2015 7:21 PM
>
> Not OK.
> This will break in move_invariants() when it looks at REGNO (inv->reg).
Indeed. I'm even surprised all tests passed. Ok I will just prevent moving
in such a case. I'm running the tests now a
On Tue, May 19, 2015 at 6:50 PM, Aditya K wrote:
>
>
>
>> Date: Tue, 19 May 2015 11:33:16 +0200
>> Subject: Re: Refactor gimple_expr_type
>> From: richard.guent...@gmail.com
>> To: hiradi...@msn.com
>> CC: tbsau...@tbsaunde.org; gcc-patches@gcc.gnu.org
>>
>
On Wed, 20 May 2015, Jan Hubicka wrote:
> Richard,
> this is my attempt to make sense of TYPE_CANONICAL at LTO. My undrestanding
> is
> that gimple_canonical_types_compatible_p needs to return true for all pairs of
> types that are considered compatible across compilation unit for any of
> langu
On Wed, May 20, 2015 at 10:23:21AM +0200, Thomas Schwinge wrote:
> > + if (gwv && auto_clause)
> > +c_parser_error (parser, "incompatible use of clause %");
> > + else if (gwv && seq_clause)
> > +c_parser_error (parser, "incompatible use of clause %");
> > + else if (auto_clause && seq_c
Hi,
This patch removes redundant gimple_build_nop calls from tree-chkp.c.
MPX-bootstrapped and regtested for x86_64-unknown-linux-gnu. Applied to trunk.
Thanks,
Ilya
--
2015-05-20 Ilya Enkovich
* tree-chkp.c (chkp_maybe_copy_and_register_bounds): Remove useless
gimple_build
On Wed, 20 May 2015, Prathamesh Kulkarni wrote:
> On 19 May 2015 at 14:34, Richard Biener wrote:
> > On Tue, 19 May 2015, Prathamesh Kulkarni wrote:
> >
> >> On 18 May 2015 at 20:17, Prathamesh Kulkarni
> >> wrote:
> >> > On 18 May 2015 at 14:12, Richard Biener wrote:
> >> >> On Sat, 16 May 201
Hi Mikael,
when I got you right on IRC, then you proposed this change about the pointer
attribute:
diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c
index 6d565ae..545f778 100644
--- a/gcc/fortran/trans-stmt.c
+++ b/gcc/fortran/trans-stmt.c
@@ -5361,6 +5361,7 @@ gfc_trans_allocate
Hi!
On Fri, 15 May 2015 11:10:21 -0700, Cesar Philippidis
wrote:
> This patch teaches the c and c++ front ends to error on invalid and
> conflicting acc loop clauses. E.g., an acc loop cannot have 'gang seq'
> and the worker and vector clauses inside parallel regions cannot have
> optional kerne
This is a new version of the patch submitted here:
https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00663.html
but handling (some) escape sequences.
I could not figure out a way to re-use the code from libcpp for this,
thus I implemented a simple function that given a string and offset in
bytes, it
On 18 May 2015 at 20:25, Mike Stump wrote:
> On May 18, 2015, at 8:01 AM, Alan Lawrence wrote:
>> Simulators such as qemu report the presence of fork (it's in glibc) but
>> generally do not support synchronization primitives between threads, so any
>> tests using fork are unreliable.
>
> Hum, I
Hi!
On Tue, 19 May 2015 09:24:51 +0200, Tom de Vries wrote:
> On 18-05-15 17:31, Tom de Vries wrote:
> > In ran into this bootstrap failure with branch gomp-4_0-branch:
> > ...
> > src/gcc-gomp-4_0-branch/gcc/omp-low.c:2897:1: error: 'omp_context*
> > enclosing_target_ctx(omp_context*)' defined b
On 05/12/2015 02:16 PM, Marat Zakirov wrote:
On 04/07/2015 03:22 PM, Jakub Jelinek wrote:
How are the automatic misaligned variables different from say heap
allocated ones, or global vars etc.?
No difference you are right Jakub. Shadow memory initialization for
heap values and globals of cou
101 - 136 of 136 matches
Mail list logo
