On Fri, Jan 10, 2014 at 12:51:10PM +0100, Thomas Schwinge wrote:
> > > +static bool
> > > +maybe_fold_stmt (gimple_stmt_iterator *gsi)
> > > +{
> > > + bool changed = false;
> > > + struct gimplify_omp_ctx *ctx;
> > > + for (ctx = gimplify_omp_ctxp; ctx; ctx = ctx->outer_context)
> > > +if (
Hi!
Ping.
On Thu, 19 Dec 2013 17:44:25 +0100, I wrote:
> Ping.
>
> On Fri, 13 Dec 2013 11:13:03 +0100, I wrote:
> > On Thu, 5 Sep 2013 18:11:05 +0200, Jakub Jelinek wrote:
> > > 4) the reference testcase showed a problem with fold_stmt calls
> > > we do very early, during gimplification, becaus
Hi!
Ping.
On Fri, 13 Dec 2013 11:13:03 +0100, I wrote:
> On Thu, 5 Sep 2013 18:11:05 +0200, Jakub Jelinek wrote:
> > 4) the reference testcase showed a problem with fold_stmt calls
> > we do very early, during gimplification, because for TREE_READONLY
> > vars with DECL_INITIAL fold_stmt can rep
On Thu, Dec 19, 2013 at 12:51:43PM +0100, Thomas Schwinge wrote:
> OK for gomp-4_0-branch, and trunk (without the first hunk, obviously)?
>
> commit 1f4dbb1842804b39c3b7ac1e80783734516dc965
> Author: Thomas Schwinge
> Date: Thu Dec 19 12:41:21 2013 +0100
>
> Add clobber for object, after l
Hi!
On Wed, 18 Dec 2013 22:46:48 +0100, Jakub Jelinek wrote:
> On Wed, Dec 18, 2013 at 09:03:40PM +0100, Thomas Schwinge wrote:
> > On Mon, 16 Dec 2013 16:38:18 +0100, Jakub Jelinek wrote:
> > > The reason for 3 separate arrays is that some of the values
> > > are always variable, some are somet
On Wed, Dec 18, 2013 at 09:03:40PM +0100, Thomas Schwinge wrote:
> This one's owed to me still learning about GCC internals; if someone
> could please be so kind to poit me to the appropriate documentation, or
> explain:
>
> On Mon, 16 Dec 2013 16:38:18 +0100, Jakub Jelinek wrote:
> > The reason
Hi!
This one's owed to me still learning about GCC internals; if someone
could please be so kind to poit me to the appropriate documentation, or
explain:
On Mon, 16 Dec 2013 16:38:18 +0100, Jakub Jelinek wrote:
> The reason for 3 separate arrays is that some of the values
> are always variable,
Hi!
On Mon, 16 Dec 2013 17:58:26 +0100, Jakub Jelinek wrote:
> I'd indeed prefer if you just used one
> array, it can be say just uchar array of twice the width, with even chars
> for alignment and odd for kinds (or vice versa), compared to two arrays
> it is tiny bit cheaper at the caller side I
On Tue, Dec 17, 2013 at 08:21:57PM +0100, Thomas Schwinge wrote:
> On Mon, 16 Dec 2013 17:58:26 +0100, Jakub Jelinek wrote:
> > I'd indeed prefer if you just used one
> > array, it can be say just uchar array of twice the width, with even chars
> > for alignment and odd for kinds (or vice versa),
On Mon, Dec 16, 2013 at 05:35:36PM +0100, Thomas Schwinge wrote:
> Sure, that's fine by me, and thanks for the explanation.
>
> > Plus, the change, being an ABI change, would need to be done on the
> > trunk rather than just on gomp-4_0-branch.
>
> It's not an ABI change, as I had limited the cha
Hi!
On Mon, 16 Dec 2013 16:38:18 +0100, Jakub Jelinek wrote:
> On Mon, Dec 16, 2013 at 08:41:02AM +0100, Thomas Schwinge wrote:
> > Here is the patch I propose for gomp-4_0-branch; OK?
>
> No. The reason for 3 separate arrays is that some of the values
> are always variable, some are sometimes
On Mon, Dec 16, 2013 at 08:41:02AM +0100, Thomas Schwinge wrote:
> Here is the patch I propose for gomp-4_0-branch; OK?
No. The reason for 3 separate arrays is that some of the values
are always variable, some are sometimes variable (sizes), some are
never variable (alignment + kind).
So, if anyt
Hi!
On Thu, 12 Dec 2013 10:53:02 +0100, I wrote:
> On Thu, 5 Sep 2013 18:11:05 +0200, Jakub Jelinek wrote:
> > 3) I figured out we need to tell the runtime library not just
> > address, size and kind, but also alignment (we won't need that for
> > the #pragma omp declare target global vars though
Hi!
On Thu, 5 Sep 2013 18:11:05 +0200, Jakub Jelinek wrote:
> 4) the reference testcase showed a problem with fold_stmt calls
> we do very early, during gimplification, because for TREE_READONLY
> vars with DECL_INITIAL fold_stmt can replace the uses of the var with
> its initializer, but as the
Hi!
On Thu, 12 Dec 2013 11:02:30 +0100, Jakub Jelinek wrote:
> On Thu, Dec 12, 2013 at 10:53:02AM +0100, Thomas Schwinge wrote:
> > On Thu, 5 Sep 2013 18:11:05 +0200, Jakub Jelinek wrote:
> > > 3) I figured out we need to tell the runtime library not just
> > > address, size and kind, but also a
On Thu, Dec 12, 2013 at 10:53:02AM +0100, Thomas Schwinge wrote:
> On Thu, 5 Sep 2013 18:11:05 +0200, Jakub Jelinek wrote:
> > 3) I figured out we need to tell the runtime library not just
> > address, size and kind, but also alignment (we won't need that for
> > the #pragma omp declare target glo
Hi!
On Thu, 5 Sep 2013 18:11:05 +0200, Jakub Jelinek wrote:
> 3) I figured out we need to tell the runtime library not just
> address, size and kind, but also alignment (we won't need that for
> the #pragma omp declare target global vars though), so that the
> runtime library can properly align i
Hi!
I've committed this patch to gomp4 branch to:
1) fix handling of reference based array sections - reference to array
and reference to pointer. The latter actually needs 3 map clauses,
one to map the array section, one to map the pointer to it, and one to
map the reference to the pointer.
2) i
18 matches
Mail list logo
