On Fri, Mar 07, 2014 at 09:21:48PM +0100, Thomas Schwinge wrote:
> Maybe it's just too late on a Friday evening, but I don't understand this
> change, part of r204863. GF_OMP_FOR_KIND_FOR has the value zero;
> shouldn't this comparison have remained unchanged? Is the following
> (untested) patch
Hi!
Ping.
On Fri, 07 Mar 2014 21:21:48 +0100, I wrote:
> On Fri, 15 Nov 2013 14:44:45 -0700, Aldy Hernandez wrote:
> > I fixed a few nits Jason pointed out off-line, and both him and Jakub
> > have approved the patch for trunk.
> >
> > In running the final round of tests I noticed a few proble
Hi!
On Fri, 15 Nov 2013 14:44:45 -0700, Aldy Hernandez wrote:
> I fixed a few nits Jason pointed out off-line, and both him and Jakub
> have approved the patch for trunk.
>
> In running the final round of tests I noticed a few problems with my
> choice of bit numbers for the GF_OMP_* masks. I
Hi!
On Fri, 15 Nov 2013 14:44:45 -0700, Aldy Hernandez wrote:
> Attached is the final version of the patch I have committed to trunk.
> --- a/gcc/gimple-pretty-print.c
> +++ b/gcc/gimple-pretty-print.c
> @@ -1118,6 +1118,8 @@ dump_gimple_omp_for (pretty_printer *buffer, gimple gs,
> int spc, in
Hi!
Ping. With a different subject line, this time. Let's first concentrate
on the ICE in the Cilk Plus structured block checker, then generalize
diagnose_omp_blocks' structured block logic, before finally getting to
the OpenACC extension.
Here starts the ICE patch:
On Fri, 10 Jan 2014 12:48:
Hi!
Ping.
On Thu, 19 Dec 2013 17:49:09 +0100, I wrote:
> Ping.
>
> On Tue, 10 Dec 2013 13:53:39 +0100, I wrote:
> > At the end of this email you can find the patch that I'd like to apply to
> > gomp-4_0-branch for OpenACC structured blocks, after the following two
> > have been approved:
>
> >
Hi!
Ping.
On Tue, 10 Dec 2013 13:53:39 +0100, I wrote:
> At the end of this email you can find the patch that I'd like to apply to
> gomp-4_0-branch for OpenACC structured blocks, after the following two
> have been approved:
> On Fri, 06 Dec 2013 19:33:35 +0100, I wrote:
> > On Fri, 15 Nov 2013
Hi!
At the end of this email you can find the patch that I'd like to apply to
gomp-4_0-branch for OpenACC structured blocks, after the following two
have been approved:
On Fri, 06 Dec 2013 19:33:35 +0100, I wrote:
> On Fri, 15 Nov 2013 14:44:45 -0700, Aldy Hernandez wrote:
> > --- a/gcc/omp-low.
Hi!
On Fri, 15 Nov 2013 14:44:45 -0700, Aldy Hernandez wrote:
> I fixed a few nits Jason pointed out off-line, and both him and Jakub
> have approved the patch for trunk.
>
> In running the final round of tests I noticed a few problems with my
> choice of bit numbers for the GF_OMP_* masks. I
The testcase c-c++-common/cilk-plus/PS/body.c needs an effective target
check for fopenmp before adding -fopenmp to its options, otherwise it'll
fail on bare-metal targets like arm-none-eabi.
This patch adds that.
Ok to commit?
Thanks,
Kyrill
2013-11-18 Kyrylo Tkachov
* c-c++-common
On 16/11/13 01:20, Aldy Hernandez wrote:
On 11/15/13 15:05, Aldy Hernandez wrote:
Why all this, and not keep everything but
GF_OMP_FOR_KIND_SIMD and GF_OMP_FOR_KIND_DISTRIBUTE
as they were, and just use:
GF_OMP_FOR_KIND_DISTIRBUTE = 1 << 0,
GF_OMP_FOR_KIND_SIMD = 2 << 0,
GF_
On 11/15/13 15:05, Aldy Hernandez wrote:
Why all this, and not keep everything but
GF_OMP_FOR_KIND_SIMD and GF_OMP_FOR_KIND_DISTRIBUTE
as they were, and just use:
GF_OMP_FOR_KIND_DISTIRBUTE = 1 << 0,
GF_OMP_FOR_KIND_SIMD = 2 << 0,
GF_OMP_FOR_KIND_CILKSIMD = 3 << 0,
Sounds
Why all this, and not keep everything but
GF_OMP_FOR_KIND_SIMD and GF_OMP_FOR_KIND_DISTRIBUTE
as they were, and just use:
GF_OMP_FOR_KIND_DISTIRBUTE = 1 << 0,
GF_OMP_FOR_KIND_SIMD = 2 << 0,
GF_OMP_FOR_KIND_CILKSIMD = 3 << 0,
Sounds good. Testing the following patch against
> --- a/gcc/gimple.h
> +++ b/gcc/gimple.h
> @@ -102,12 +102,13 @@ enum gf_mask {
> GF_CALL_ALLOCA_FOR_VAR = 1 << 5,
> GF_CALL_INTERNAL = 1 << 6,
> GF_OMP_PARALLEL_COMBINED = 1 << 0,
> -GF_OMP_FOR_KIND_MASK = 3 << 0,
> +GF_OMP_FOR_KIND_MASK = 7,
> GF_OMP
Yes, OpenMP user defined reductions are allowed.
In which case, there are no further changes to the C++ parser. The
committed version is correct.
Thanks for looking into this Balaji.
Aldy
> -Original Message-
> From: Aldy Hernandez [mailto:al...@redhat.com]
> Sent: Thursday, November 14, 2013 12:39 PM
> To: Jakub Jelinek
> Cc: Jason Merrill; gcc-patches; Iyer, Balaji V
> Subject: Re: PING: Fwd: Re: [patch] implement Cilk Plus simd loops on trunk
>
On Fri, Nov 15, 2013 at 08:24:36AM -0700, Aldy Hernandez wrote:
> Looks like we need to wait on Intel to pontificate on whether UDRs
> are valid or not. Who knows...maybe no work at all! Woo hoo!
>
> How does this look?
Looks good to me, but please wait if Jason doesn't have any feedback too.
> > I guess it depends on what the Cilk+ spec says about reduction clause, and
> > from what I saw it is just too vague.
> > http://software.intel.com/sites/products/documentation/doclib/stdxe/2013
> > /composerxe/compiler/cpp-win/index.htm#GUID-44B505B6-01AF-4865-
> > 8DF4-AF851F51DDA1.htm
>
> Ju
> -Original Message-
> From: Jakub Jelinek [mailto:ja...@redhat.com]
> Sent: Friday, November 15, 2013 2:38 AM
> To: Aldy Hernandez
> Cc: Jason Merrill; gcc-patches; Iyer, Balaji V
> Subject: Re: PING: Fwd: Re: [patch] implement Cilk Plus simd loops on trunk
>
>
On Thu, Nov 14, 2013 at 06:29:50PM -0700, Aldy Hernandez wrote:
> >Well, if you don't change anything in omp-low.c, then it wouldn't diagnose
> >setjmp call in #pragma simd, but given that also the OpenMP 4.0 spec
> >requires that #pragma omp simd doesn't contain calls to setjmp or longjmp
> >(ditt
Well, if you don't change anything in omp-low.c, then it wouldn't diagnose
setjmp call in #pragma simd, but given that also the OpenMP 4.0 spec
requires that #pragma omp simd doesn't contain calls to setjmp or longjmp
(ditto for #pragma omp declare simd functions), then scan_omp_1_stmt
should be
On Thu, Nov 14, 2013 at 10:39:02AM -0700, Aldy Hernandez wrote:
> On 11/14/13 10:05, Jakub Jelinek wrote:
>
> [Balaji, see below for question.]
>
> >On Thu, Nov 14, 2013 at 09:49:41AM -0700, Aldy Hernandez wrote:
> >>+case OMP_PARALLEL:
> >>+case OMP_TASK:
> >>+case OMP_FOR:
> >>+
On 11/14/13 09:57, Joseph S. Myers wrote:
Where you have
+ error ("break statement within <#pragma simd> loop body");
+ error ("continue statement within <#pragma simd> loop body");
I think you mean %< and %> (i.e. quotes) not < and >.
Indeed. Fixed.
Thank you.
On Thu, Nov 14, 2013 at 09:49:41AM -0700, Aldy Hernandez wrote:
> +case OMP_PARALLEL:
> +case OMP_TASK:
> +case OMP_FOR:
> +case OMP_SIMD:
> +case OMP_SECTIONS:
> +case OMP_SINGLE:
> +case OMP_SECTION:
> +case OMP_MASTER:
> +case OMP_ORDERED:
> +case OMP_CRIT
Where you have
+ error ("break statement within <#pragma simd> loop body");
+ error ("continue statement within <#pragma simd> loop body");
I think you mean %< and %> (i.e. quotes) not < and >.
--
Joseph S. Myers
jos...@codesourcery.com
On 10/18/2013 02:48 PM, Aldy Hernandez wrote:
This has the potential of throwing my mind for a spin. Can I do this as
a followup, and keep it simple for now?
Sure.
+ else if (!TREE_TYPE (e) || !TREE_CONSTANT (e)
+ || !INTEGRAL_TYPE_P (TREE_TYPE (e)))
+cp_pars
PING
On 10/18/13 13:48, Aldy Hernandez wrote:
On 10/02/13 16:53, Jason Merrill wrote:
Sorry for the delay, and thank you for the review.
On 08/27/2013 04:03 PM, Aldy Hernandez wrote:
+ /* First, try to parse as an initialized declaration. See
+ cp_parser_condition, from whence the bulk
PING: Fwd: Re: [patch] implement Cilk Plus simd loops on trunk
>
> On 10/02/13 16:53, Jason Merrill wrote:
> > On 08/27/2013 04:03 PM, Aldy Hernandez wrote:
>
> >
> >> + else if (!TREE_TYPE (e) || !TREE_CONSTANT (e)
> >> + || !INTEGRAL_T
On 10/16/2013 01:48 PM, Aldy Hernandez wrote:
On 10/02/13 16:53, Jason Merrill wrote:
Can't the step size be a value-dependent expression like a template
non-type parameter?
Jason, I'm not sure. The standard says:
"The conditional-expression in a simd-linear-step shall either
sa
On 10/02/13 16:53, Jason Merrill wrote:
On 08/27/2013 04:03 PM, Aldy Hernandez wrote:
+ else if (!TREE_TYPE (e) || !TREE_CONSTANT (e)
+ || !INTEGRAL_TYPE_P (TREE_TYPE (e)))
+cp_parser_error (parser,
+ "step size must be an integer constant");
On 08/27/2013 04:03 PM, Aldy Hernandez wrote:
+ /* First, try to parse as an initialized declaration. See
+ cp_parser_condition, from whence the bulk of this is copied. */
You didn't do this copy, but I'd appreciate it if you could reintegrate
this with cp_parser_condition. I notice th
On 09/09/13 07:54, Aldy Hernandez wrote:
PING^3
Hi guys!
PING for both C and C++.
Thanks.
Original Message
Subject: Re: PING: Fwd: Re: [patch] implement Cilk Plus simd loops on trunk
Date: Tue, 27 Aug 2013 15:03:26 -0500
From: Aldy Hernandez
To: Richard Henderson
CC
Hi guys!
PING for both C and C++.
Thanks.
Original Message
Subject: Re: PING: Fwd: Re: [patch] implement Cilk Plus simd loops on trunk
Date: Tue, 27 Aug 2013 15:03:26 -0500
From: Aldy Hernandez
To: Richard Henderson
CC: jason merrill , gcc-patches
On 08/26/13 12:22
> +static tree
> +c_check_cilk_loop_incr (location_t loc, tree decl, tree incr)
> +{
> + if (EXPR_HAS_LOCATION (incr))
> +loc = EXPR_LOCATION (incr);
> +
> + if (!incr)
> +{
> + error_at (loc, "missing increment");
> + return error_mark_node;
> +}
Either these tests are swa
On 07/27/2013 05:31 AM, Aldy Hernandez wrote:
trunk, but it depends on the OMP_SIMD patch which is also awaiting
review (actually, just the vectorizer bits since Jakub wrote and can
pre-approve the actual OMP changes):
Oh, right.
I can rebase off a more recent trunk if you prefer, or I can ev
On 07/27/13 01:09, Jason Merrill wrote:
On 07/26/2013 11:46 AM, Aldy Hernandez wrote:
How's this?
What branch is this supposed to apply to?
trunk, but it depends on the OMP_SIMD patch which is also awaiting
review (actually, just the vectorizer bits since Jakub wrote and can
pre-approve t
On 07/26/2013 11:46 AM, Aldy Hernandez wrote:
+ Upon return, *INITP will contain the initialization expression,
+ *DECLP will contain the induction variable.
+
+ *REAL_DECLP
+ *FOR_BLOCK */
DECLP is a variable declared in the for-init, if any. REAL_DECLP is the
induction v
On 07/26/2013 11:46 AM, Aldy Hernandez wrote:
How's this?
What branch is this supposed to apply to?
Jason
On 07/09/2013 09:09 AM, Aldy Hernandez wrote:
+ is the controlling variable. COND is the condition. INCRP is a
+ pointer the increment expression (in case, the increment needs to
"pointer to"
No comma after "in case"
+ error_at (loc, "initialization variable must be of integral "
+
39 matches
Mail list logo
